The latest expert opinions, articles, and guides for the Java professional.

Play! Framework Un-features That Really Irk My Inner Geek

Play! Framework is getting a lot of praise. It is growing in usage and popularity. You can spot presentations about it at conferences, numerous blog posts etc. Even I praised my favorite features of the Play! Framework couple of months ago, My Top 5 Play Framework Features. There is so much positive feedback about it, that I thought it would be a bit refreshing to list the features (um, “un-features”?) that really get on my nerves. Here is my list of Play! un-features that limit my productivity, encourage me to read, and really irk my inner geek…

Application Startup Time Grows with Application Size

If you create a new application in Play! and start your app via play run then it takes about 2 seconds for the application to start. Basically just the time to switch to your browser and hit refresh. Once your application grows in size the startup time also grows. Our application starts for 28s in development mode (on my MBP with a SSD). This is already enough time to take a quick peek at your Google Reader. Of course the same is true for any JEE application, at first they are blazingly fast but as time goes on the startup times just grows and grows.

Reloading 3rd Party Library Code

Play! Framework applications have support for really quick turnaround because a large part of the application code changes can be reloaded instantly. So you add a method, change params and you don’t need to restart the app. This is all freakin’ awesome, but the moment you happen to develop a library that you are using within your application, you need to make room for restarts. Every code change then requires a restart. Not so happy anymore (let me find my jrebel.jar file!)

Memory Hog

Play! Framework templates are quite the memory hog. You might not notice it in the beginning, but once you have some larger pages and more users, then you will see a spike in memory consumption. This is due to the design of sub-templates. The sub-template is read into a String variable on every request that uses it. This will spike memory usage to the effect of the HTML file size. You can bypass this by giving your app more memory, having smaller templates and moving static content into static files instead of templates. There is also a more effective memory usage on the way in the 1.2.x branch.

Fear of Upgrade

Upgrading has been a bumpy ride so far, (the minors not so much) and the leap from 1.0 » 1.2 was quite scary. Our tests started failing left and right once we packaged our application. We stumbled upon quite a few  bugs and the choices in the end were to either use our custom build of Play! framework, or downgrade. We chose the first option. Now another major version is looming and a lot has changed again–check out the graphics at the 2.0 page. I’m afraid that our products will need a major overhaul if we want to get on to the next bandwagon. It just scares me.

An Issue Here and There

Play! Framework is guaranteed to surprise you when you least expect it. Just the other day I got a report from a colleague, saying that he got a verify error from Play! code. Ok, great. What can I say, try to reproduce and file a bug report? Or what about these:

  • You’re programming some feature and suddenly you start getting ClassCastExceptions. Oh well, I restart and I’m unable to reproduce. Not enough for a bug report, but there seems to be something fishy with Play! Framework reloading and Jobs. Oh well, lets hope it won’t happen again any time soon.
  • Everything is super until one of the Jenkins nodes is showing failing tests. You dig for couple of hours and you find there is special handling of a folder with a dot preceding it, finally resolved.
  • You find a controller method that produces OutOfMemoryErrors because of the dark bytecode magic that is happening behind the scenes. You’re able to reproduce it, but when submitting a bug report you try to reproduce on an empty application, which just won’t happen. You add a @ByBass to your own method and the problem goes away. Argh!

These small issues that pop up suprisingly end up stealing confidence and time. You start doubting the underlying system and lose the edge that this tool is supposed to give you. Just imagine the problems you will stumble on once Python, Groovy, Ivy is replaced by sbt, Scala, Akka.

So why do I still use Play! Framework?

When writing this piece @ekabanov asked my why on earth are using this framework then? My answer was, well, we would have just as many issues with any framework out there, but the nature of those issues would probably be different. You will always stumble upon bugs, you will always have problems when the application grows in size, and, of course, you will have problems when upgrading your dependencies. So far, there is nothing to be done.

I’d love to hear about your pet peeves with Play! Framework – please leave your comments below!

Responses (26)

  1. Avatar  

    Sylvain MATHIEU

    September 27, 2011 @ 3:15 pm

    The first focus of Play 1.x is the productivity, and less the maintainability. Thanks to Play! you can bootstrap a Web applications and new features really quickly and it’s something really valuable! But when you have a big applications to maintain it becomes not so great, as you noticed. I think Play2.x aim a lot more the maintainability. It will use less “magic features” and will tends to correct that kind of negative aspects. I just hope it won’t affect the productivity, which is in my opinion, the real value of Play!.

  2. Avatar  

    Drew Hamlett

    September 27, 2011 @ 3:23 pm

    At my company we’ve split every section of the web application into a module(which is recommended) that can then be ran on it’s on.  So we have 10 modules.  Each of those modules has an application.conf. The modules can be ran and tested independently of the main application.  Even though it’s a module you can still put an application.conf in the project folder and it will not cause any issues with it being a dependency/module in another application.

    My templates are in one module and models in another so most modules are dependent on those.  Since we work on these independently we never see the application startup issues you see.The template memory issue is solved in the scala templates or you can use japid templates.

    I agree with your other points though.

    Every framework is going to have some downsides but I find Play! to have the least negatives out of everything I’ve tried.

  3. Avatar  


    September 27, 2011 @ 7:59 pm

    You should the try the Java-pure Template Engine Japid, superior speed + small memory footprint. All parts of Play are good, and fast, except for this peace of the Groovy-based Template Engine, slow and comsumes alot of memory.

  4. Avatar  

    Nicolas Frankel

    September 27, 2011 @ 9:10 pm

    What is a real show stopper for me is that you’re tied to the running platform! Give me back my JEE compatible servlet containers!

  5. Avatar  

    Matthew Vincent

    September 27, 2011 @ 9:34 pm

    No you’re not

  6. Avatar  


    September 28, 2011 @ 7:31 am

    You’re a bit harsh…
    It’s not false about upgrades which were quite hard sometimes but it was a project on the edge… Hope now it will be controlled a bit better even if I know 2.0 will be a big change…
    About memory consumption, it’s once again about groovy templates apparently which is not very economic in term of memory and not quick also (try other templating engines as someone says in the comments)…
    About reload of code, as someone says also, try modules which are really cool stuff to modularize your projects!
    About the load time, you end with a 28sec boot, ok this is not 2sec but in general for lots of reasonable sites, it’s really 2sec and you change and reload instantly. I work with traditional JEE/Spring everyday and I never had those reload time. My Java webapps in general don’t take 28sec to boot but rather 3 or 4 minutes and there are not crazy apps!
    But the real why I use Play for more than one year now is that I do things with it, I don’t spend all my day in the doc or google to find how I could do it (if possible), how the people designing this stuff damn think, what XML should I put and where…
    It’s funny, I stopped using Grails one year ago because I began to have memory problems, load problems etc… :) Yes, Play has defaults but until now, I’m still enjoying the ratio creation/destruction I have when working with it ;)
    Anyway, critics are good sometimes and make people go further! Just keep seeing the good aspects sometimes!

  7. Avatar  

    Toomas Römer

    September 28, 2011 @ 7:33 am

    Check out the ‘play war’. You will get a WAR file that you can deploy to your favourite container. There is a servlet that wraps the Play! regular entry point for requests.

  8. Avatar  

    Toomas Römer

    September 28, 2011 @ 7:35 am

    Did not know about Japid, checking it out. I think we should look into modules more.

  9. Avatar  

    Toomas Römer

    September 28, 2011 @ 7:35 am

    Will check them out, thanks.

  10. Avatar  

    Alexis MP

    September 28, 2011 @ 9:12 am

  11. Avatar  


    September 28, 2011 @ 11:41 am

    Coming from the founders of jRebel is a bit skeptical, especially about the startup time. Since I haven’t yet ventured into this framework in production mode, I can’t really comment upon this problem. The startup lags are there in spring applications as well. However, the traditional jee application startup times are something which frustrate all developers.

  12. Avatar  

    Toomas Römer

    September 28, 2011 @ 12:00 pm

    Startup time of DEV mode, not production. Why skeptical about startup times from founders of JRebel? I’ve been doing startup time measurements for most containers and frameworks out there, nothing to be skeptical about. Latest was titled Apples and Oranges,

  13. Avatar  


    September 28, 2011 @ 1:57 pm

    Great post.  Things don’t get better by blowing smoke up someones …  Also, I would believe a website/platform more if it actually had a “BEST THINGS and a WORST THINGS” section.  Every framework has its weakness/painful parts.  It sucks that it’s usually a surprise.

    I develop a fair bit using GWT.  It has many similar magic features and a Dev mode that avoids full recompilation on changes.  It’s also flaky from time to time… and this is with a giant army of Google engineers behind it.

    Is the pain worth the benefit.  After a frustrating debugging session I feel like throwing it all out.  Actually, I sometimes ponder a career change to digging ditches or something without so much chaos. Then I get over it and start coding again, and it’s all good and I start to appreciate the magic again.

    Btw, you might also want to check out Cambrige – another template engine that is XHTML.  I just added a Janino (Java code) expression module to it, and there are other expression language options (MVEL, JEXL).  The awesome thing about Cambridge is it is really well (clear code) written and simple to add your own template extensions.  It is a young project tho, but seems built on a clean foundation.

  14. Avatar  


    September 28, 2011 @ 2:06 pm

    It would be utterly fantastic if JRebel could help Play improve the magic-bytecode spells – it sounds like you’ve got lots of experience in this.

    Can JRebel be used out-of-the-box with Play?

  15. Avatar  

    Igor Polevoy

    October 5, 2011 @ 1:53 am

    This is interesting, so far I have seen rave reviews of the PLay framework, thanks for input. Also, I developed a web framework which is like Play takes a lot from Ruby on Rails. You might want to check it out here:
    Unlike Play, it uses standard Servlet architecture and standard Maven build.

  16. Avatar  

    Mikhail Gavryuchkov

    October 8, 2011 @ 12:15 am

    Great article. I am still going through the tutorial and quite like it. One thing I don’t quite like the the routs file – honestly not very intuitive. The template engine is not as clear as JSTL for example, but maybe I am just too used to JSTL.

  17. Avatar  


    October 8, 2011 @ 12:16 am

    very interesting approach, I still haven’t got the chance to play with a really big app… it’s good to know it’s possible to modularize a large app…

  18. Avatar  


    October 8, 2011 @ 12:22 am

    yeap, I also thinkg they are going in that direction (specially for the build system and the type safety everywhere)… I’m also concerned about loosing that minimalistic approach… here are some thoughts I shared at play discussion list

    the api seems to be becoming more complex…

  19. Avatar  

    Andrew Fink

    November 27, 2011 @ 7:52 am

    Happy with
    no byteCode magic, templates are freemarker, velocity or jsp (in near future MVEL)
    Component and page Oriented design

  20. Avatar  


    April 11, 2012 @ 9:36 am

    I was thinking whether to use Tapestry5 or Play! on my next project. When i read class cast exception I am thinking more about going back to good-old-plain PHP and yiiFramework. It could save time as you have less complicated issues like class cast exceptions, dependence on libraries and complex server-setups etc…

  21. Avatar  


    April 11, 2012 @ 9:48 am

    I think the major question should be: which framework is most efficient in the long-term for different project sizes. My requirements for a webframework (all programming languages) are:

    – can I outsource a feature / part without having to provide all source code?

    – can a new developer get started quickly without having to spend weeks on analyzing existing code?

    – how much time does a developer spend on infrastructure setup / waiting for things / debugging weird issues / googling as he got stuck with a problem and won’t find any help or documentation

    – how much development time is spent on doing new stuff how much time is spent on repairing existing things that broke but used to work in the past but for some reasons stopped to work due to dependencies or upgrades

    – how much time is being spent on developing code as there is no existing code for common requirements (tagcloud, solr integration, chat, ajax upload, jquery related things, forum, blog, flickr/twitter, oauth/facebook)

    In the end, what counts is the development costs. The less time and money is spend on achieving a goal. the better.

    There are some frameworks that will “freeze” developer resources in a project for code maintenance – so 4 developers repair old code and only a single developer will have time for new stuff. Also the hourly rate of a developer is important. The more expensive a developer the less attractive a framework.

    Even if a framework is better, but it is harder / more expensive to get a developer, it is no use to choose this framework – unless it is your own personal webproject were costs dont matter.

  22. Avatar  


    June 23, 2012 @ 9:00 pm

    This article is about Play 1.x?

    Play 2.0 is quiet different, do you have a new take on things?

  23. Avatar  

    Toomas Römer

    June 30, 2012 @ 4:39 am

    I don’t have personal experience with Play 2.0. As I’ve read the docs, announcements and followed some threads then definitely quite different!

  24. Avatar  


    December 29, 2012 @ 11:14 am

    I am trying to evaluate Play. With the 2.0 release, if you are still using it, do you still see any of these issues?

  25. Avatar  

    Mirko Adari

    January 2, 2013 @ 8:20 pm

    This question deserves a blog post on its own for a proper answer, but we do use Play 2.0 in-house and are quite pleased. Typesafe provides active development, fast release cycles and additional team members respond to the issues quite fast. 2.1 was also almost backwards-compatible with 2.0, just some minor changes that got handled with replace all. Feature-wise it brings a lot to the table, i.e. I’m in love with statically checked templates, but you’ll get a good overview by taking a glimpse at their docs.

  26. Avatar  

    Mirko Adari

    January 2, 2013 @ 8:24 pm

    This question deserves a blog post on its own for a proper answer, but we do use Play 2.0 in-house and are quite pleased. Typesafe provides active development, fast release cycles and additional team members respond to the issues quite fast. 2.1 was also almost backwards-compatible with 2.0, just some minor changes that got handled with replace all. Feature-wise it brings a lot to the table, i.e. I’m in love with statically checked templates, but you’ll get a good overview by taking a glimpse at their docs.

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.