After having chosen Play! for two enterprise projects requiring roughly 1-2 developer years of work, I couldn't be happier with the decision.
Play! is by far the best web framework I've ever seen for Java.
It is as hot as node.js and socket.io combined! I can't really recommend it highly enough.
======
Strong points:
* A life-changingly fast edit-test loop. (Faster than Django!)
- Excellent beaning for form parameters (no longer have to mess around with Integer.parseInt(getParameter("objectId")))
- Libraries that obviate the crufty old ones, e.g. instead of Apache WebClient, just use WS.url("google.com ").get(). It has OAuth, Emailers, etc.
- Support for new technologies, e.g. WebSockets
- Support for non-blocking IO in imperative-looking code. (e.g. you can "waitFor()" a Future, which will cause Play! to suspend your request until the Future is ready, reusing your Thread for another request, and resume where you left off)
- Much better interceptor model than J2EE (can apply interceptors to your entire class, to individual methods by annotating, e.g. @Before, @After, @Finally)
- A routes file instead of web.xml
- Large selection of community modules to do everything from rendering your template as PDF to inlining CoffeeScript in your page.
- A framework for running scheduled jobs and for triggering asynchronous jobs from web requests.
======
Weak points:
- The default Groovy templates are powerful, but notoriously slow. The template system is supposed to be pluggable, but I haven't yet found a templating technology that feels perfect.
- The heavy use of reflection and bytecode manipulation is what makes things so convenient, but I can also imagine it being a turn-off for some.
I'm trying to choose a framework for a new project, and Play! has really caught my eye - I'm not really a Java guy, and the whole "enterprise" mindset is a bit of a turnoff for me, so Play is really tempting.
One of the concerns internally was that it has a much smaller community than more established frameworks - have you found this to be an issue?
Also, it sounds like you used it for a reasonably large project. How does code organization and maintainability compare with traditional frameworks?
Code organization is basically up to you. The default organization is the typical MVC directories, but that's not a requirement for anything (and you can add other directories / subdirectories as you wish).
The one caveat on code organization is that Play! hot-compiles all code under its /app directory. My approach to sharing code with other non-Play! projects is to use "ant" to build a jar, and add that to the classpath of my Play! project. The end result is that you get hot-compilation of everything specific to your webapp, but you have to use ant to build code outside of that. I find it works fine in practice, and if it's a standalone app then you never have to leave hot-compile land.
Maintainability is great -- Play! makes heavy use of ThreadLocals, so you can access the current Request, Response, template arguments, etc etc no matter where you are, without having to pass it all around as method parameters. So making helper methods is super easy. We created a "helpers" package to put functionality shared across Controllers and can follow DRY without a problem.
I dont think the community is that small. The google group is very active and the committers almost always reply to answers very quickly.
Also, the documentation is absolutely first rate. I think this really counts for a lot. Compare the Play documentation with, say, Struts2. Chalk and cheese.
Play! is by far the best web framework I've ever seen for Java.
It is as hot as node.js and socket.io combined! I can't really recommend it highly enough.
======
Strong points:
* A life-changingly fast edit-test loop. (Faster than Django!)
- Excellent beaning for form parameters (no longer have to mess around with Integer.parseInt(getParameter("objectId")))
- Libraries that obviate the crufty old ones, e.g. instead of Apache WebClient, just use WS.url("google.com ").get(). It has OAuth, Emailers, etc.
- Support for new technologies, e.g. WebSockets
- Support for non-blocking IO in imperative-looking code. (e.g. you can "waitFor()" a Future, which will cause Play! to suspend your request until the Future is ready, reusing your Thread for another request, and resume where you left off)
- Much better interceptor model than J2EE (can apply interceptors to your entire class, to individual methods by annotating, e.g. @Before, @After, @Finally)
- A routes file instead of web.xml
- Large selection of community modules to do everything from rendering your template as PDF to inlining CoffeeScript in your page.
- A framework for running scheduled jobs and for triggering asynchronous jobs from web requests.
======
Weak points:
- The default Groovy templates are powerful, but notoriously slow. The template system is supposed to be pluggable, but I haven't yet found a templating technology that feels perfect.
- The heavy use of reflection and bytecode manipulation is what makes things so convenient, but I can also imagine it being a turn-off for some.
- The Play! codebase is very light on comments.
======
Give it a shot if you haven't already.
- Play! Fanboi