Play Framework Roadmap
This roadmap is provided for informational purposes and is subject to change. The Play team makes no promises about the delivery of any features by the estimated dates.
If you are interested in working on any of these features or suggesting changes to the roadmap, feel free to open a discussion on the Play developer mailing list: https://groups.google.com/forum/#!forum/play-framework-dev
ETA: April-May 2017
✓ = Completed
Scala 2.12 Support
- ✓ Provide support for Scala 2.12
- ✓ Create API for storing structured typed data on requests. Similar to the current tags feature but more sophisticated and type-safe.
- (?) Provide the option to use a type-safe version of HTTP headers for headers we know about (but still provide the stringly-typed API for backwards compatibility).
- ✓ Provide APIs for Action, BodyParser, Cookies, etc. that do not require any global state (a lot of these things depend on each other).
- ✓ Improve JSON macros to make them more configurable and add additional features, e.g. change property naming scheme and use default parameters in case classes.
- ✓ Separate play-json from the main Play project and give it its own release cycle.
- ✓ Prefer convention of always having default configuration values defined (in reference.conf or application.conf).
- ✓ Provide typeclass-based configuration parser in Scala, so arbitrary types can be parsed from Config.
- ✓ Switch to using raw Config object for Java (Configuration is just a thin wrapper).
- ✓ Separate Guice into optional module so non-Guice-users don’t have to worry about it.
- Provide better documentation for integrating alternative DI approaches, particularly Scala compile-time DI. Perhaps start explicitly recommending something like Macwire.
- ✓ Work with third-party developer(s) to make sure Spring support is possible.
- Java Compile Time Dependency Injection!
- ✓ Provide HTTP/2 support (using Netty 4.1 or Akka HTTP)
- ✓ Split WS into separate project
- ✓ Shade AsyncHttpClient and Netty
- ✓ Add HTTP Caching
- ✓ Provide async cache API
- ✓ Provide APIs for play.api.test that do not require any global state (Play.current, Play etc)
ETA: late 2017 (estimated)
Future releases on the 2.7 branch will aim to make minor improvements, some of which may also appear in 3.0.
ETA: 2018?, depending on Play team resources
- Eliminate need for Play’s “current application” global state
- All request/response objects become simple immutable objects
- Headers become strongly typed, with a way to define custom header types (similar to akka-http)
- Request and response objects have consistent structure. (e.g. both have a similar type of HttpEntity). May build on top of Akka HTTP types.
- Provide alternative way to access Java Context that does not require a thread local.
- Look into Scala's ImplicitFunction for default implicit request scope
- Look into strongly typed request access, i.e. request.queryParameter[UUID]("uuid")
Java/Scala API separation
- Java/Scala APIs both become thin wrappers over lower level API
- Java request/response objects no longer simply wrap Scala ones
- Interoperability between Java/Scala actions and filters possible
- Java Action APIs will not require annotations or routes compiler magic
- Switch to json4s for underlying AST in Scala JSON (?)
- Switch to new validation API. Perhaps https://github.com/jto/validation
- Provide a way to create a simple Play app without any SBT magic. At minimum, this should allow you to write a simple REST API using the RoutingDsl or SIRD.
- Possibly create a way to run twirl from Maven (or use https://github.com/JakeWharton/twirl-maven-plugin)
- We should still support SBT with all the SBT magic, but should have at least one test or example project that shows how to run an app on maven as well.
- Separate SBT-specific code so Gradle can easily use it to work with Play
- Work with the Gradle team to ensure basic gradle support works.
- Play will switch its versioning scheme in 3.0 to semantic versioning, or something that more closely resembles it. So minor versions will not introduce major API changes.
- Since Play 3.0 will differ from 2.x in significant ways, we plan to maintain 2.x for several years, and provide some of the new features (e.g. Java functional action syntax) as options in Play 2.x to allow users to migrate more easily.
- Switch to standard maven layout by default, with an optional SBT/Maven plugin to support the old layout.