The Play Framework 2 blip has generated many internal discussions. We had competing suggestions to move it to adopt and hold. These differences relate primarily to the specific applications for which it is used, how it is used, and what expectations people have for it. While none of these issues are unique for Play, Play has generated far more controversy than is typical in the standard library versus framework debate. We reiterate the cautions stated in the previous radar, and we will monitor how Play continues to mature to support its sweet spot.
The recent release of Play Framework 2.1.1 with support for controller dependency injection, asynchronous, non-blocking I/O, a code-reload workflow, database migrations, asset pipelining, and flexible deployment options has made it more attractive to developers. For this reason Play re-appears on the radar as something for teams to seriously consider when building web applications and services on the JVM. A word of caution however, Play embraces a functional programming style which, when working with the Java language, still translates into a plethora of static methods that may be difficult to unit test outside a running server.