posted 9-May-2012 | 28 comments | , , ,

As the first candidate of our evaluation series we reviewed the Play Framework v2.0.

The tutorial and reference documentation used for this article is all available from the Play documentation site.

The first part of the article will go over the set of tasks we proposed to do with each framework, then moving on to evaluate each criteria item.

Install the framework in a development workstation

Extremely simple, three steps:

  1. Download the ZIP distribution
  2. Unzip it
  3. Add the unzipped folder to your PATH

And it’s good to go!

Setup a development environment using a free IDE, application server and database

Nothing to do here. The framework provides an internal application server for development and you can work with the internal database both in memory or file system based flavours.

As far as IDE support goes, you can use your favourite text editor or a full blown Java IDE such as Netbeans and Eclipse. Since Play reloads all resources on the fly as you modify them, you don’t really need any fancy IDE integration.

It’s worth noting though, that the framework provides extended support for Eclipse and IntelliJ, in terms of built-in actions, shortcuts, autocomplete, etc. So you might want to use one of those two if you are already familiar with them.

Develop the “Hello world” or similar sample outlined by the frameworks tutorial

The framework’s tutorial proposes the development of a To-Do list application. Going from scratch to a working “hello world” status is completely trivial and really fast (minutes). And moving forward from that to a fully working app feels natural and easy to understand.

Modify the sample app to perform a specific database query over a custom structure and display the results

Play 2.0 uses the EBean library as default data access layer, it’s quite easy to use and understand. The use of custom SQL queries is supported out of the box by the framework and there is no mystery to it, it’s similar to JPA native queries and doesn’t require any major hassle to use.

Add a dependency to a third party library and perform a computation using it in our app

Play 2.0 has both the option to add a JAR file directly to the project (copying it to the /lib project folder), or to add a dependency through it’s built-in dependency system (using Apache Ivy via SBT).

To push it a little I decided to add a Maven central repo reference and use the library. It proved straightforward, just add a line to the Build.scala file and if needed you can even add your own repository in the same file.

As a sidenote, you need to rebuild your app dependencies after changing stuff like this or it won’t compile.

Develop a “Hello world” REST service

Publishing a JSON REST service is quite simple, the documentation is clear and to the point. The only complaint is that it’s not explicit on this documentation page what imports are needed (I had to loose two precious minutes of my life browsing the API to find them :P).

Play provides all the tools you need to encode/decode JSON and XML quite easily, and the built-in routing mechanism makes it simple to map all HTTP methods to specific controller Java/Scala methods.

Consume our own service from our app

Play provides a built-in library to consume web services. Handling of JSON and XML responses is simple and easy.

Calls are made asynchronously and handled via Promises (a structure similar to Java’s Futures), which makes them quite powerful in terms of how you can handle them within the flow of your app.

On the other hand, the code to invoke a simple REST GET service seems a little bigger/more complex than it needs to be. I would appreciate it if shortcuts were provided in the API for simple (ie. blocking calls) use cases while still supporting the full async power for the developers who need/want it.


Ok, lets pass veredict! This is our evaluation based on the items described above:

Learning curve: GOOD

If you are a Java developer (I infer it’s the same for Scala skilled devs) it’s really, really simple to get going with Play. It took me less than a day’s work to feel at home with the framework, and all my Java skills felt like still available and empowering what I was doing.

It should also feel very familiar to developers that often use RoR, Django and similar frameworks, since the structure of projects and command line usage is very similar.

Development performance for simple tasks: GOOD

It’s a breeze to code the usual stuff. And the capability to change a file and just refresh your browser to see the changes will seem like a miracle to Java web developers.

Development performance for complex/singular tasks: GOOD

The structure of the projects and transparent integration with Maven makes it really simple to include third party Java libraries or to add completely custom built classes to perform specific computations. In short, all you can do in any Java framework you can do in a Play project, in the worst case you just code plain old Java and it will work just fine.

Dependency management: GOOD

Maven integration works fine and is easy to use, you can connect your Play projects to existing corporate Maven repositories and re-use all the major Maven public repositories.

Code performance/security tuning capabilities: MEDIUM

Regarding performance tuning, on the back-end side you can basically do everything you can do on any other Java based framework. You can customize and tweak your code as much as you want, using the frameworks built-in APIs or not.

In the security front I miss the posibility to write a Servlet Filter to manage injections and XSS generically, but you can manage to develop your own XSS and CSRF prevention components quite easily.

Version 2 of the framework still lacks built-in mechanisms against common attacks though, which in my opinion should be provided out-of-the-box. The developers seem to be working on it though.

Platform escalation/redundancy capabilities: BAD

It runs on a JVM, so it leverages all it’s corporate goodies. But at this moment (versions 2.0.x) there is no way to deploy a Play 2 app as a WAR file to regular application servers.

This is a big problem in my opinion, since using a robust and proven application server for corporate and/or mission critical systems is a must in my book, and the built-in play server is nice, but I woulnd’t sleep too sound with a big app deployed on it in a production environment.

The Play team is working on solving the WAR deployment compatibility and the feature is tagged for version 2.1, so it shouldn’t be long before this is solved.

Acceptance in corporate markets: MEDIUM

Java is stablished, accepted and proven, so the platform itself is almost always not a problem. The big thing here is the same as the previous item, at this moment you can not deploy a Play 2 app in other application servers, and most companies IT departments have already chosen their application servers and they are not Play 2.

Hopefully when version 2.1 comes along this issue will be gone.

Complexity of developing and consuming SOAP and REST services: GOOD

The bundled WS API is straightforward and easy to learn, and it gets the job done. It could be a little simpler for simple scenarios, but it’s not a big deal.


Play Framework 2 is an excellent choice for every type of web based development, specially for developers already skilled in Java or Scala. It’s easy to learn, a breeze to use and leverages all the power of the JVM and the huge ecosystem of available Java libraries.

The latest iteration of the project (v2.0) lacks the possibility of packaging your apps as regular Java WAR files and deploy them to other application servers. This is a big problem, specially for corporate environments, because most organizations already have a stablished selection of application servers. The Play team is working on adding this feature for v2.1, we await eagerly.

On my next post I’ll review Ruby on Rails, I know it’s not news to anyone, but I think using the same evaluation process on all our options will light the way.

  • opensas

    very nice review

    about the lack of imports in the documentation, you can fix it!

    the doc is available as a wiki for everyone to contribute

  • opensas

    here you have a step by step video about developing a play framework 2 app with java and scala, and deploying it on openshift

    hope you like it

  • Steve Chaloner

    There is war support for Play 2, but it doesn’t allow you to use the full power of Play 2.  This is due to the current servlet API.  You can find the war plugin at

    Excellent write-up – I look forward to the next one!

  • Erwan Loisant

    While not recommended, you can do a blocking rest call by using value on the Promise you get form the call.

    So, if you want the Json for example, you can do:
    JsValue json = WS.url(“http://…”).get().value.get.json

    Or, if you want to handle errors :
    WS.url(“http://…”).get().value.fold(t:Throwable => { … }, r:Response => { … })

  • Nicolás Zuasti

    The WAR issue is why im still using Grails in my 8 to 5. Im looking forward to your RoR review.

  • Ricardo Zuasti

    Nice tip, didn’t know it and it sure does shorten the code.

  • Ricardo Zuasti

    Yes, but I still think the framework needs the built-in support and that it is transparent to the developer (as in it should work exactly the same be it in the Play built-in server or as a WAR deployed in an third party app server).

  • Ricardo Zuasti

    Thanks for the tip, already updated it :)

  • ojou-sama

    Thank you for the writeup!  I currently am evaluating whether or not to go play1 or play2, and clear-cut scenarios like this really help.  Your comment about “transparent integration with Maven” is misleading, as it strongly implies an ability to specify dependencies via pom files, not just point to Maven Central.  I’m also curious how you got auto-complete, etc, support from Eclipse for play2, as I was not able to find working instructions online.  Thanks.

  • Ricardo Zuasti

    Check out for a reference on using a POM to declare Maven dependencies, though I think it’s best to use the default syntax if you are starting a project from scratch. On the details on how to do it you’ll have to refer to the SBT documentation.

    Regarding the Eclipse integration I’ll try to write a follow-up with the steps, I already deleted my configuration (I use Netbeans myself).

  • ojou-sama

    Thanks for the speedy reply, Ricardo.  Looks like what I’ve seen elsewhere – Maven dependencies are ultimately handled by SBT.  

    Looking forward to your Eclipse followup!  

  • Rafael

    I got to know Play about 1 year and fell in love with it. The absence of war deployment can be considered a drawback but it’s important to notice that play’s embedded server is jboss netty, the jboss server web layer, so I don’t think using play’s embedded server is any worse than using a regular jboss. On “escalation/redundancy” play is a stateless framework (at last it encourages you to code statelessly) and as long as you keep your code stateless “escalation/redundancy” shouldn’t be a problem, you just need a load balancer, actually it’s even easier to build a play cluster than any jee server cluster, much easier. On the “war deployment” problem, I face the very same problem. Here we use Glassfish and, though, I would like to deploy my play apps on play’s embedded server (cause it’s simpler), well I have to follow some rules. To deal with it you may try play2war plugin. It’s still alpha but, as I know, it’s working pretty well.

  • Ricardo Zuasti

    Indeed, the main issue is corporate acceptance, not the actual technical complications. The WAR support really needs to come out of alpha and make it into the framework itself to provide more confidence/stability and the chance for developers working within “strict” companies to convince their bosses that Play is a real option and that it will boost the productivity without compromising the installed platform.

  • Julien Tournay

    It will, as soon as the servlet API makes it possible (3.1)

  • Pingback: Hongtium » 2012-05的Scala新资源()

  • ★Damien Lecan★

    I am the author of Play2War

    > The WAR support really needs to come out of alpha

    Next version will have “beta” status, as the plugin is deployed in “real life” (see and support all Play HTTP features (except WebSocket).
    I prefer to go slowly, but with quality (with many integration tests).

    I need Glassfish testers :)

    > make it into the framework itself to provide more confidence/stability

    First implementation of Play2War was coded to be delivered and integrated into Play core, not as an extension.
    But Zenexity guys don’t want to work/accept contribution on WAR packaging now because of missing websocket feature in servlet containers.

  • Ricardo Zuasti

    Hi Damien, thanks for your feedback :)

    We’ll definitively try out the beta version and will probably use Glassfish since most devs in my company use it as the preferred development app. server.

  • Linux Hosting In India

    Great post!!! Highly recommend!!!!

  • Windows Cloud Reseller Hosting

    I have already recommended your site to others.

  • Ganapathi Homam Mantra

    Great site….Love it.

  • Unlimited Web Hosting India

    This was a great article.

  • Windows Website Hosting

    Very nice read.

  • Java Web Hosting India

    This is amazing! Thank you.

  • Unlimited Java Web Hosting

    Outstanding post. I recommend it to ALL my friends.

  • Cheap VPS Cloud Web Hosting In

    Thanks for this interesting post.

  • Cheap VPS Cloud Server Hosting

    Thanks for such kind of useful post.

  • Linux Web Hosting India

    Thanks for making your blog.

  • Dedicated Hosting

    Highly recommended!!