Play 1 vs Play 2 Framework

| May 14, 2013

Today's guest post comes to you from our friend and user, Dane Marcelo, JArchitect product manager. He points out some interesting differences between the Play 1 and the Play 2 frameworks. So, let's dive into this great post!

Play is an open source web application framework, written in Scala and Java, which follows the model–view–controller (MVC) architectural pattern. It aims to optimize developer productivity by using convention over configuration, hot code reloading and display of errors in the browser.

Play is heavily inspired by Ruby on Rails and Django and is similar to this family of frameworks. Play uses Java to build web applications in an environment that may be less Java Enterprise Edition-centric. Play uses no Java EE constraints. This can make Play simpler to develop compared to other Java-centric platforms.

Due to its simplicity Play became very popular. It is supported by many PaaS providers, but among them I want to emphasize Jelastic, which impressed me with its user-friendly interface. It's really amazing!

Let’s analyze the play framework with JArchitect and discover the differences between the Play 1 and the Play 2 frameworks.

Play 1

Let’s take a look inside Play 1.2, and here’s the dependency graph showing all libraries used by it:

play 1 vs play2 vs play3

The Play framework uses many libraries to achieve its job, we can enumerate:


Netty is a NIO client server framework which enables quick and easy development of network applications such as protocol servers and clients. It greatly simplifies and streamlines network programming such as TCP and UDP socket server.

Although Play applications are designed to be run using the built-in JBoss Netty web server, they can also be packaged as WAR files to be distributed to standard Java EE application servers.

Let’s search for all methods from Play using the Netty library, for that we can execute the following CQLinq query:

from m in Methods where m.IsUsing (“netty-3.2.5.Final”)
 select new { m, m.NbBCInstructions }
playn 1 vs play 2

What’s interesting is that only a few methods from classes inside the play.server package use the Netty library, so it can be changed easily by another networking library.

The PlayHandler class is the one mostly using Netty, it inherits from and it’s the entry point of the upcoming http requests. The messageReceived method is invoked when an http request is received.

Cache libraries

Caching data is a typical optimization in modern applications, and so Play provides a global cache. An important point about the cache is that it behaves just like a cache should: the data you just stored may just go missing.

Play use EhCache and here are all methods using it.

from m in Methods where m.IsUsing (“ehcache-core-2.0.0?)
 select new { m, m.NbBCInstructions }

Like Netty only some few methods use directly EhCache, and EhCacheImpl act as facade to the cache library, it implements the CacheImpl interface. Let’s search for all types implementing this interface.

from t in Types where t.Implement (“play.cache.CacheImpl”)
 select new { t, t.NbBCInstructions }

With Play 1 we can use EhCache or Memcached.


Play use also the Groovy jar, but why it’s needed? To answer this question let’s search for all methods using it.


The groovy is used as a template engine. A template file is a text file, some parts of which have placeholders for dynamically generated content. The template’s dynamic elements are written using the Groovy language. Groovy’s syntax is very close to Java’s.

JPA and Hibernate

Play provides a set of very useful helpers to simplify the management of your JPA entities.

We can search for methods using the hibernate-jpa jar

from m in Methods where m.IsUsing (“hibernate-jpa-2.0-api-1.0.0.Final”)
 select new { m, m.NbBCInstructions }

Play 2

The Play 2 was rewritten from scratch, and many big changes were introduced, here’s the dependency graph of the Play 2 framework.


The first remark is that the Scala library is used. While the original version of the Play Framework was written primarily in Java (and provided Scala support through a plug-in), Play 2.0 embraces Scala more completely. Not only has Play’s core transitioned to Scala, but the new release also makes the Scala language a first class citizen for developing Play applications. As a result, the new version of the framework now provides two equally polished sets of APIs: one for Scala developers and one for Java developers.

Memcached support removed
Only EhCache is supported by default, and if you want to use Memcached you have to implement the CacheApi interface.

Groovy templates removed
Play2 does not use groovy any more, Scala templates are used instead.

JPA and Hibernate support removed
There is no built-in JPA implementation in Play 2.0, The Scala module includes a brand new data access layer called Anorm that uses plain SQL to make your database request and provides several API to parse and transform the resulting dataset. Or you can use ebean orm instead.

from m in Methods where m.IsUsing (“avaje-ebeanorm-api”)
 select new { m, m.NbBCInstructions }

Akka is actor based, event-driven framework for building highly concurrent, reliable applications.

Akka uses the Actor Model to raise the abstraction level and provide a better platform to build correct concurrent and scalable applications. For fault-tolerance it adopts the ‘Let it crash’ model, which has been used with great success in the telecom industry to build applications that self-heal – systems that never stop. Actors also provide the abstraction for transparent distribution and the basis for truly scalable and fault-tolerant applications.

async support is now delegated to Akka, and the Akka helper classes are inside the play.api.libs.concurrent package.

Play is a very interesting framework to develop web applications easily, however it’s preferable to use the Play 2 framework, as many big changes were introduced, and it became more powerful.