Finagle: Protocol agnostic extensible RPC system for the JVM with Java & Scala APIs (via)

Finagle is an extensible RPC system for the JVM, used to construct high-concurrency servers. Finagle implements uniform client and server APIs for several protocols, and is designed for high performance and concurrency. Most of Finagle’s code is protocol agnostic, simplifying the implementation of new protocols.

Finagle is written in Scala, but provides both Scala and Java idiomatic APIs.

Spray: Build REST/HTTP-based integration layers on top of Scala & Akka

Spray Logo

From the Spray Website:

Spray is a suite of lightweight Scala libraries providing client- and
server-side REST/HTTP support on top Akka.

Fully asynchronous, non-blocking
All APIs are fully asynchronous, blocking code is avoided wherever at all

Actor- and Future-based
spray fully embraces the programming model of the platform it is built upon.
Akka Actors and Futures are key constructs of its APIs.

Especially sprays low-level components are carefully crafted for excellent
performance in high-load environments.

All dependencies are very carefully managed, sprays codebase itself is kept
as lean as possible.

Being structured into a set of integrated but loosely coupled components your
application only needs to depend onto the parts that are actually used.

All spray components are structured in a way that allows for easy and
convenient testing.

Play Framework: Open source, Java/Scala, web development framework, based on a stateless architecture

Play Framework Logo

Play is a web application framework designed to make web development simpler. It is inspired by convention-based frameworks such as Ruby on Rails and Djnago. Play seems to be trying to take the best from the Java web development ecosystem and strip away some of the more cumbersome parts.

From the Play Framework Wikipedia page:

Major differences From other Java frameworks:

  • Stateless: Play 2 is fully RESTful – there is no Java EE session per
  • Integrated unit testing: JUnit and Selenium support is included in the core.
  • API comes with most required elements built-in.
  • Static methods: all controller entry points are declared as static (or
    equivalently, in Scala, methods on Scala objects). After requests were made
    for this to be customisable, Play 2.1 now supports other styles of
    controllers, so controllers need not be static/Scala objects; however, this
    is still the default.
  • Asynchronous I/O: due to using JBoss Netty as its web server, Play can
    service long requests asynchronously rather than tying up HTTP threads doing
    business logic like Java EE frameworks that don’t use the asynchronous
    support offered by Servlet 3.0.
  • Modular architecture: like Rails and Django, Play comes with the concept of
  • Native Scala support: Play 2 uses Scala internally, but also exposes both a
    Scala API, and a Java API that is deliberately slightly different to fit in
    with Java conventions, and Play is completely interoperable with Java.