BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Play 2.3 Released: Modularization, Java 8 and WebJars

Play 2.3 Released: Modularization, Java 8 and WebJars

Leia em Português

This item in japanese

Lire ce contenu en français

Bookmarks

The Play team at Typesafe has released version 2.3 of their web framework for Java and Scala. One of the first things that developers will notice is the absence of the play command, which has been replaced by the Typesafe Activator. It still supports all the options of the original play command, but also comes with support for project templates and a browser-based UI as an alternative to the Play shell.

Play 2.3 also has better tooling for static assets through sbt-web. Sbt-web provides a common framework for sbt plug-ins like sbt-coffeescript, sbt-less, etc, that handle client side assets. It also brings support for WebJars to Play. For example, the Bootstrap library can now be included with just a single line in the configuration:

libraryDependencies += "org.webjars" % "bootstrap" % "3.0.0"

Play's templating library has also been moved to its own project and has been renamed to Twirl, making it easier to use a different template engine. Another library that was extracted from Play is the Web Services client.

Besides these reorganizations of the framework, Play 2.3 also supports the recently released Scala 2.11 (in addition to Scala 2.10), and API improvements to make using Play from Java 8 more pleasant (the documentation shows examples of both the Java 7 and 8 syntax).

Anorm, Play's simple database access layer, has improved support for writing queries with string interpolation:

SQL"SELECT * FROM table WHERE id = $id"

If you're using Typesafe's Slick, then the play-slick integration is available as a plug-in.

Working with web sockets has always been convenient in Play using Iteratees. With 2.3, it is also possible to wire websockets directly to an actor system, so that incoming messages on the socket are sent to an actor and replies can be sent through the socket to the client (see the documentation for some example code).

InfoQ had the opportunity to talk to James Roper, Play's tech lead, to learn more about the new release and their future plans for the framework.

InfoQ: It might surprise some Play useres to see that the Play shell has been replaced by Activator. What was the rationale behind this change? 

Firstly, I need to point out that activator is just a wrapper around the sbt shell, with a few extra features built in such as the ability to start a UI and create a new project. The Play shell was also just a wrapper around the sbt shell, with a few extra features built in such as the ability to create a new project. The activator shell command is therefore a drop in replacement for the play shell command, you can alias play to activator and you won't notice a difference in user experience. When we released the first milestone of Play 2.3, we found that people weren't aware of this, and this created some confusion, or surprise as you put it, but in our documentation and release notes for RC1 we've now hopefully cleared that up.

Activator was written as an extension, or the next evolution, of the productive development environment that people love in Play. At Typesafe, we wanted to take this development environment, and extend it beyond Play, so that other Typesafe and non Typesafe projects could take advantage of it. We also wanted to provide new features such as community contributed templates, in context tutorials, and a host of new dev related tools for Play, and so this effort was done in Activator, while improvement of the Play shell and distribution was put on hold, with the intention that the play shell and distribution would eventually be superseded by the activator shell and distribution. This has come to fruition in Play 2.3.

InfoQ: Anorm is still the default data-access component in Play, not Typesafe's Slick. Are you planning to integrate the play-slick plug-in more tightly into Play or will it remain a third-party plug-in? 

It was the intention that in Play 2.3 we would pull play-slick into the core Play project, there is an open pull request for that. However when we came to actually review and merge that, we found a problem. The most common usage patterns of Slick in Play required the use of some form of dependency injection. Up until now, Play has tried to remain completely unopinionated about dependency injection - providing mechanisms to allow you to use either compile time or runtime dependency injection mechanisms, but not requiring its use, and providing documentation that is neutral to any particular dependency injection strategy. But this would mean a shift, we couldn't document Slick's use in Play without taking a stance on or pushing a particular flavour of dependency injection.

So we decided that it was time to change this, that we needed to become opinionated about dependency injection, provide better support, and include it as a best practice in our documentation, but it was too late to address this in Play 2.3, so incorporating play-slick as a first class citizen in Play was put on hold and delayed until 2.4. Moving the play-slick repo into the playframework organisation is a step that we've taken to assure users that we will support play-slick, and Typesafe is also committed to providing commercial support for play-slick.

InfoQ: Many of the changes in Play 2.3 seem to be about modularizing the framework. Are you going to continue doing this for the next release? 

Yes. I think this is a natural shift for any framework as it matures. Initially in a framework, it makes more sense to bundle everything together, this removes friction when modifying APIs, allowing the framework to improve and deliver new features faster. As APIs become stable, then the advantages of modularising become more apparent, it means individual components can have their own release cycles, which means fixes to those modules can be delivered faster, and other changes that would otherwise be impossible to do in a point release due to our strict binary compatibility rules become possible to deliver. In Play 2.4 we are planning to target modularising our support for individual database libraries.

InfoQ: Speaking about the next release, can you share what you have planned for Play 2.4 (or even 3.0)? 

We have published an up to date roadmap. Note that roadmap doesn't equal promise! But the big ticket items for Play 2.4 should be a dependency injection strategy, initial (possibly experimental) support for reactive streams and akka-http, and an improved deployment experience (unified across the Typesafe platform).

Play 3.0 will hopefully see the eradication of Play's global state, and will definitely see the introduction of reactive streams as the base level IO API in Play. This will open up the ability to do asynchronous IO in all parts of Play to Java users, such as the ability to write custom body parsers in Java, in contrast to what we have now which is a few limited APIs for a few specific use cases.

InfoQ: Thank you for the interview!

After downloading the new Play 2.3, don't forget to have a look at the Migration Guide to see what changes you'll need to make to your existing application.

Rate this Article

Adoption
Style

BT