The American Dream Realized: NYC-based Java Consultant. Author of Play Framework Mods Elastic Search, RabbitMQ. JavaLobby Featured MVB Writer. I blog at and tweet at Felipe is a DZone MVB and is not an employee of DZone and has posted 13 posts at DZone. View Full User Profile

Why Did I Fall in Love with Play! Framework?

  • submit to reddit
Some time ago, I was the tech lead for a few very large deployments on the Real Estate market for companies like Fannie Mae, Freddie Mac, and HUD. We were running that traditional enterprise Java stack you are probably familiar with—Spring, Hibernate, Solr, etc. It took a few years but we had built a very nice system; it performed well but deep inside I felt development wasn’t as productive as it should have been. I also noticed that the whole dev process wasn’t as fun as it used to be. Of course, I had heard a lot of great stories about Rails, Django and, more recently, Node.js; there were actually some compelling stories surrounding those technologies. I ended up spending a fair amount of my spare time working on those technologies, and I actually had a really great time building some small apps and prototypes with them. But then I would wake up the next morning, go to work, face another big important project and go right back into my tried and true: Java.

One of those projects was an online offer management system for Fannie Mae which was to receive a billion dollars in offers in its first month. In my mind, there was no way I would introduce a brand new language—especially a scripting language like Python or Ruby—to the team for such an important project. From personal experience, I feel it’s difficult to manage a large project without type checking. I was basically between a rock and a hard place because I wasn’t very excited about the options in the Java space, and I had only a very modest level of success with the other alternatives like Grails, Spring Roo, etc. At the same time, I wasn’t about to give up on Java as a language, especially on the JVM which I grew to trust because of its reliability. Then I ran into Play; it was love at first sight for me. (I’d love to tell you how I ran into Play … just follow me on Twitter—[@_felipera] so I can beat Justin “Beaver”‘s Klout score!) Once I decided to take it for a ride, I was up and running right away! With a simple command, “play new”, the whole application structure was defined. Follow that with another simple command, “play run”, and I was ready to get the party started! I felt instant relief because I didn’t need to come up with all those XML files, Spring’s applicationContext.xml, the web.xml, Hibernate’s HBM files, and THEN figure out how to wire them all together! Even after years working on those technologies, I still had to copy and paste them from somewhere; I could never remember all that syntax.

Another obvious compelling point for me was Play’s ability to reload classes on the fly without having to re-deploy the entire application or restart the server. I think we all know what it’s like to be working on an application, make a change to a class, execute maven or ant deploy … wait until a war is packaged … copied to a deploy directory … wait for the servlet context to get destroyed … then wait some more for the application to be deployed. And THEN … once the application is FINALLY deployed, we open the browser, hit our development environment and THERE’S A BUG! The problem could be as simple as a single character misplaced somewhere. It doesn’t matter what the problem is, we still need to go over that entire process all over again. By the third or fourth time that happens, the developer zones off on Slashdot, Hacker News or whatever his/her favorite website is. Play handles class reloading beautifully; you really don’t have to restart your server!

I was also attracted to Play’s Stateless model, that “Share Nothing” HTTP architecture. Many of us were unfortunate enough to have developed, and even worse, supported J2EE-based applications that were built on a Stateful model. It was really hard managing state, cluster-safe cache objects, HTTP sessions, especially for those Enterprise Java Beans (EJBs) and that whole concept of attached objects. Play doesn’t share state between each node which simplifies the management of your cluster, and it provides a cluster-aware and cluster-safe caching solution.

Man, I could go on and on all night but I’ll spare you from all my craziness! In a nutshell, Play is a full stack framework for modern Web applications with a NIO-based development and production servers, full support for MVC, a persistence engine, a fully integrated testing framework (unit testing and functional testing), a powerful async Web Service client, an async-based job manager, multiple extensions are available through modules, support for full customization on the framework behavior through its plugin mechanism, dependency management, validation framework and even more advanced features such as WebSockets.

I don’t know if you guys know this but I’m an old man; I’ve been developing Web applications for 15 or so years now. And for the most part, with undying passion. But Play has rejuvenated my love for developing Web applications all over again.

This is—more than anything—a declaration of love,
Felipe Oliveira

Published at DZone with permission of Felipe Oliveira, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Nicolas Frankel replied on Fri, 2011/08/26 - 1:13am

Strange: despite all your years, you never realized Eclipse/Tomcat integration (or even better, Eclipse/Glassfish) let you not deploy your application in the painful process you describe. Too bad...

Andrew Spencer replied on Fri, 2011/08/26 - 2:49am

Where I'm sitting, a text edit in a JSP, or a single-line change in Java source (without changes to class structure) requires a restart of Tomcat. Granted, it saves rebuilding the project in Maven every time, but it still costs close to a minute each time on my current project, which leaves plenty of room for improvement.

Anyway, that's off topic. Thanks for the article, Felipe. Something I would like to read is a balanced critique of Play!. It has made many choices that are radically different from standard JEE, and the approach is almost diametrically opposed to Vaadin (the most extreme example I know of hiding the web from developers). I wonder what are the advantages and pitfalls of Play!'s approach.

Otengi Miloskov replied on Fri, 2011/08/26 - 2:46am

Despite the comments around the web that Scala is a complicate language, Don't listen to them. If you are a professional Programmer/Developer you can tackle any technology even assembly language or Perl all over again. But Don't worry Scala is not as Perl that after 1 month you don't know what you coded or assemble language with all the spaghetti code. Scala is a great language and more if you are a pro Java dev you will feel at home. If you are the average joe please do you a favor, learn the proper programming concepts and get a degree. Programming Scala for me is like I'm programming with Java with a taste of Groovy and Python. Not complicate it is just different with the functional concepts Scala adds but Scala is a more small language than Java so I think it will be not a problem for you or your team to get used with Scala plus Scala integrates with Java code nicely and right now important companies and developers are starting to use more Scala. Anyway my comment is not about just Scala but talking about Web Frameworks I recommend definitely you check Lift web framework, because all the pain you are experiencing in this article about on using Spring, Hibernate etc and connect together all that plus all the xml and lots of spaghetti, It will disappear and you gain more features than using play. With lift you don't need complex code generators or layers of the architecture to create the mvc pattern etc. Lift is a very simple and easy web framework that also supports parallel concepts, comet protocols etc. If you see the examples especially the chat example you will see that with just a few of lines code you have a comet chat server and client app fully functional. Also the tools for Scala are more mature than before, the eclipse or intellij plugins work without problems. If you are not an IDE guy well Scala with Lift you can use your preferred text editor as notepad++ or VIM or emacs. Give it a chance, try it and you will see you will love Scala and Lift.

Mohan Ambalavanan replied on Fri, 2011/08/26 - 4:01am

Your arguments are so weak....You shud try JRebel or Netbeans/Eclipse-Glassfish next time instead of ur mvn/ant deploys...

Erik Post replied on Fri, 2011/08/26 - 6:20am

I've looked at Play and I can understand why you would like it, it looks very cool, especially after endless years of faffing about with Java, Spring and whatnot. That said, my redeployment woes are solved by JRebel, which I use in combination with Scala and Jetty and Maven/SBT. What I mean to say is that Play is not the only way out of the JEE Netherworld.

Alex Scott replied on Fri, 2011/08/26 - 6:32am

It all sounds very similar to Grails to me.....

Erik Post replied on Fri, 2011/08/26 - 6:35am in response to: Andrew Spencer

From my brief look at Play, it seems to me that it's very Javascript centric where the UI is concerned. Other frameworks (GWT, Vaadin) try to hide this from the developer, in favour of a Java interface to Javascript. (I find this an insane solution, but IU understand that there are many people who appreciate it.) Other frameworks, such as Wicket and Lift do have features that allow you to pretend that you needn't be concerned with Javascript all that much if you don't want to, but at the same time they do make it easy to write some if you like. Lift for instance has a Scala DSL that maps to Javascript, as well as support for straight Javascript. Personally, I prefer the straight Javascript approach, because hey, the web = HTML+CSS+JS, so I'm all for an architecture like Play has. Furthermore, Play runs in its own 'container', which really isn't a container but simply a straight Java program, so you don't need Jetty or Tomcat or whatever. As with the previous point, this may or may not be an advantage to you.

Amir Pashazadeh replied on Fri, 2011/08/26 - 5:51pm

Have you used an IDE/Container integration at all?

We are using IDEA/Tomcat, and for changing, JSPs, and most of classes (except for example JPA entities and defining some new components) there is no need to restart the container, just compile the class and reload it. So I don't see the problem you mentioned at all.

 In Play you write static methods! Do you believe it as OO? I don't.

And you must use its container, so what about features you get from some more bullet proof containers? Don't tell me that the Play container can give you all the JBoss or WebLogic features.

I looked at Play framework, and its static methods, and its self container were two things that I could not stand.

James Cole replied on Fri, 2011/08/26 - 6:07pm

Nice article, I can see the draw of Play, but for my day to day, I find just using "mvn jetty:run" for my war projects works close enough to the same way without completely tying myself to yet another framework.

Raju Kumar replied on Tue, 2012/10/16 - 12:31pm

"I had only a very modest level of success with the other alternatives like Grails, Spring Roo, etc"

Could you substantiate this further?

The first advantages of Play that you mention are exactly alike what Grails and Roo have to offer (project bootstrapping). 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.