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 discussion forums: https://discuss.playframework.com
✓ = Completed
Play 2.7
ETA: 2018 Q2
Future releases on the 2.7 branch will aim to make minor improvements, some of which may also appear in 3.0.
gRPC client support
- Support code generation for gRPC clients
Create and announce discuss.playframework.com
Crosslink documentation to Akka and Lagom
- Cross-linking API docs and references docs
- Unified search across reference documentation
Complete Akka HTTP server backend in Play
- ✓ Don't parse HTTP headers in Akka HTTP
- HTTP/2 test improvements:
Turn-off global state by default
- ✓ Set play.allowGlobalApplication=false by default
Scala 2.13 Support
- ✓ Provide support for Scala 2.13
Improve Java 9 & 10 compatibility
- ✓ Remove compilation warnings when compiling with Java 9
- ✓ Build and test all sample projects using Java 8 and 9
- ✓ Update Guice to the latest version
- ✓ Added JAXB-API so that JDK 9 & 10 classpath works without configuration
Java API improvements
- ✓ Better annotation support for Forms, Validation and Action Composition
Akka Coordinated Shutdown
- ✓ Support for Akka Coordinated shutdown:
New Cache implementation using Caffeine
- ✓ Added Caffeine Cache module and made it the default Cache:
Enhanced Content Security Policy
- ✓ Better default with a nonce
- ✓ Fine-grained configuration
- ✓ Logging of violations
- Credit: @wsargent
PlayService for minimal applications
- ✓ Create minimal sbt plugin for Play services
Support Java actions without a thread-local Context
- Investigate and explore options
- Deprecated existing methods:
Developer experiences fixes and improvements
- ✓ Avoid multiple compilations when detecting file changes
- ✓ Preserve all development settings configured for the project:
Gradle support for Play 2.7
- Update Gradle to support Play 2.7
Remove deprecated APIs
- ✓ Remove Java deprecated APIs
- Remove Scala deprecated APIs
Under discussion: Remove support for Scala 2.11 and sbt 0.13
Play 2.6 Released 2017-06-23
ETA: April-May 2017
Scala 2.12 Support
- ✓ Provide support for Scala 2.12
Request/Response modeling
- ✓ Create API for storing structured typed data on requests. Similar to the current tags feature but more sophisticated and type-safe.
- https://github.com/playframework/playframework/pull/6321
- (?) 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 backward compatibility).
Action APIs
- ✓ Provide APIs for Action, BodyParser, Cookies, etc. that do not require any global state (a lot of these things depend on each other).
Json
- ✓ 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.
Configuration
- ✓ 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).
Dependency Injection
- ✓ Separate Guice into an 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!
HTTP/2
- ✓ Provide HTTP/2 support (using Netty 4.1 or Akka HTTP)
WS API
- ✓ Split WS into separate project
- ✓ Shade AsyncHttpClient and Netty
- ✓ Add HTTP Caching
Play Cache
- ✓ Provide async cache API
Testing
- ✓ Provide APIs for play.api.test that do not require any global state (Play.current, Play etc)
Play 3.0
ETA: 2019?, depending on Play team resources
Global state
- Eliminate the need for Play’s “current application” global state
Request/Response modeling
- 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 a consistent structure. (e.g. both have a similar type of HttpEntity). May build on top of Akka HTTP types.
- Provide an 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")
- Remove the Netty Server Backend (or move it to its own repository)
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
JSON
- Switch to json4s for underlying AST in Scala JSON (?)
- Switch to new validation API. Perhaps https://github.com/jto/validation
Maven Support
- 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.
- Provide proper guidance for JavaScript and client-side assets; most likely it’s best to use another task runner like gulp or grunt for dev mode.
Gradle Support
- 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.
Versioning
- 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.
Layout
- Switch to standard maven layout by default, with an optional SBT/Maven plugin to support the old layout.