In Play 1.1, we started exploring the possibility of using the Scala programming language for writing Play applications. We initially introduced this work as an external module to be able to experiment freely without impacting the framework itself.

Properly integrating Scala into a Java-based framework is not trivial. Considering Scala’s compatibility with Java, one can quickly achieve a first naive integration that simply uses Scala’s syntax instead of Java’s. This, however, is certainly not the optimal way of using the language. Scala is a mix of true object orientation with functional programming. Leveraging the full power of Scala requires rethinking most of the framework’s APIs. After several versions we now have a clean Scala module that allows the use of most of Play's features from Scala, in a Scala-ish manner.

Now, we are reaching the limits of what we can do with Scala support as a separate module. Initial design choices we made in Play 1.x, relying heavily on Java reflection API and byte code manipulation, have made it harder to progress without completely rethinking some essential parts of Play’s internals. Meanwhile, we have created several awesome components for the Scala module, like the new type-safe template engine and the brand new SQL access component Anorm. So we have decided that, to fully unleash the power of Scala with Play, we are moving Scala support from a separate module to the core of Play 2.0, which will be designed from the beginning to natively support Scala as a programming language.

Java, on the other hand, is certainly not getting any less support from Play 2.0; quite the contrary. The Play 2.0 build provides us with an opportunity to enhance the development experience for Java developers. Backed by our experience throughout the project we have a clear idea of what we need to achieve and what mistakes we have to avoid.

From the beginning we have chosen a fresh way to run, compile and deploy Play applications. At the time it may have looked like an esoteric design - but it was crucial to providing an asynchronous HTTP API instead of the standard Servlet API, short feedback cycles through live compilation and reloading of source code during development, and promoting a fresh packaging approach. Consequently, It was difficult to make Play follow the standard JEE conventions.

Today, this idea of container-less deployment is more and more accepted in the Java world. It's a design choice that has allowed the Play framework to run natively on platforms like Heroku, which introduced a model that we consider the future of Java applications deployment on elastic PaaS platforms.

Existing Java build systems, however, were not flexible enough to support this new approach. Since we wanted to provide straightforward tools to run and deploy Play applications, in Play 1.x we created a collection of Python scripts to handle all build and deployment related tasks.

But developers using Play for more enterprise-scale projects, which require build process customization and integration with their existing company build systems, were a bit lost. The Python scripts we provide with Play 1.x are in no way a fully featured build system and are not easily customizable. That's why we've decided to go for a more powerful build system for Play 2.0.

As we need a modern build tool, flexible enough to support Play original conventions and able to build Java and Scala projects, we have chosen to integrate sbt in Play 2.0. This, however, should not scare existing Play users who are happy with the simplicity of Play build. We are leveraging the same simple play new, run, start experience on top of an extensible model: Play 2.0 will come with a preconfigured build script that will just work for most users. On the other hand, if you need to change the way your application is built, deployed, etc., a Play project being a standard sbt project will hand you all the power to customize and adapt it to your special needs.

This also mean better integration with Maven projects out of the box, the ability to package and publish your project as a simple set of jar files to any repository, and especially live compiling and reloading at development time of any depended project even for standard Java or Scala libraries projects.

One benefit of using Java as programming language for writing Play applications is that the Java compiler can check certain parts of your code. This is not only useful for detecting mistakes early in the development process, but it also makes it a lot easier to work on large projects with a lot developers involved.

Adding Scala to the mix for Play 2.0, we will clearly benefit from even stronger compiler guarantees - but that’s not enough. In Play 1.x, the template system is dynamic, based on the Groovy language, and the compiler can’t do much for you. As a result, errors in templates can only be detected at runtime. The same goes for verification of glue code with controllers.

We really want to push further this idea of having Play check most of your code at compilation time in the 2.0 version. Accordingly, we have decided to use the Scala-based template engine as the default for Play applications - even for developers using Java as the main programming language. This doesn't mean that you have to become a Scala expert to write templates in Play 2.0, just like you were not really required to know Groovy to write templates in Play 1.x. Scala will be mainly used to navigate your object graph in order to display relevant information with a syntax that is very close to the Java one. However if you want to unleash the power of Scala to write advanced templates abstractions, you will quickly discover how Scala, being expression-oriented and functional, is a perfect fit for a template engine.

And that's not only true for the template engine: the routing system will also be fully type-checked. Play 2.0 will check all your routes' descriptions, and verify that the everything is coherent, including the reverse routing part.

As a nice side effect, being fully compiled, the templates and route files will be easier to package and reuse and you can expect high performance gain on these parts at runtime.

Today's web applications are integrating more concurrent realtime data, so web frameworks need to support a full asynchronous HTTP programming model. Play 1.x was initially designed to handle classic Web applications with many short lived requests. But now, the event model is the way to go for persistent connections - though comet, long-polling and WebSockets.

Play 1.2 already provides great asynchronous HTTP support and WebScokets using continuations. Play 2.0 will be architected from the start under the assumption that every request is potentially long living. We want, for instance, to generalize Controller and WebsocketController concepts into one single simple model that fits all needs.

But that’s not all: we also need a powerful way to schedule and run long running tasks. Although the original Play 1.0 Jobs model was introduced for this, we really need something more powerful and robust. The Actor based model is unquestionably the best model today to handle highly concurrent systems, and the best implementation of that model available for both Java and Scala is Akka - so it's going in. We will be introducing native Akka support for Play applications, making it possible to write highly distributed systems.

Datastore is no longer synonymous with "SQL database", and it probably never was. A lot of interesting models of datastores are becoming popular, providing different properties for different scenarios. For this reason it has become difficult for a Web framework like Play to make bold assumptions regarding the kind of datastore that will be used by developers. A generic play.db.Model concept in Play no longer makes sense, since it is almost impossible to abstract over all these kinds of technology with a single API.

We want to make it really easy in Play 2.0 to use any datastore driver, ORM, or any another database access library without any special integration with the Web framework. We simply want to offer a minimal set of helpers to handle common technical issues, like managing the connection bounds. We also want, however, to maintain the full-stack aspect of Play framework by bundling default tools to access classical databases for users that don't have specialized needs.

Today, the preferred way for a Play Java application to access an SQL database is the Play Model library that is powered by Hibernate. But since it's annoying in a stateless Web framework like Play to manage stateful entities such as the ones defined in the official JPA specification, we have provided a special flavor of JPA keeping things as stateless as possible. This forced us to hack Hibernate in a way that is probably not sustainable in the long term. To address this, we plan to move to an existing implementation of stateless JPA called EBean. If you don't care too much about what is used under the hood then it will change almost nothing for you, but if you really want to use Hibernate or even another official JPA implementation you will be able to do it without any special integration with Play. And if you are using Scala we will continue to bundle Anorm.

Play 2.0 will be a major release so it is unlikely that it will be compatible at the API level with previous versions. Of course at the architecture level you will find the same set of components, organized in the same way, and most importantly, you will live the same 'Play experience'.

What about my existing Play applications? How difficult will it be to migrate?

Don't worry, we don't expect you to migrate your existing applications to Play 2.0. The Play 1.x versions will continue to be maintained and you don't need to move to Play 2.0. We ourselves have many Play 1.x web applications running and we will of course continue to support them.

Remember: Play 1.2.3 is still the best way to write Web applications in Java while Play 2.0 is still under development, and will continue to be maintained and developed by the core team and contributors. Play 2.0 is an opportunity to move to for your next project, or the next major rewrite of your application.