Jakarta EE 9 Release Plan Approved

The approval of the Jakarta EE 9 Release Plan is a great milestone for the Jakarta EE project and a stepping stone towards the evolution of Jakarta EE into a project that meets the community's needs and wants. View the approved Jakarta EE 9 Release Plan here.

The release plan was authored in a very open way on the mailing lists and through weekly project calls. The initial plan evolved substantially over time, based on input from the Java EE community on what they wanted to see and what APIs they wanted us to support.

I was heavily involved in drafting the release plan, alongside other members of the Jakarta EE community and the Jakarta Platform project at Eclipse. I won't go into detail as far as what is included in the release plan and what isn't, as you can read all of the details in the plan itself or in Mike Milinkovich's blog: Moving Forward with Jakarta EE 9. Instead, in this blog, I want to explore some of the rationale behind the decisions made from my perspective.

The Goals of the Jakarta EE 9 Release Plan

The team started with some initial goals:

• lower the barrier of entry to new vendors and implementations to achieve compatibility
• make the release available rapidly as a platform for future innovation
• provide a platform that developers can use as a stable target for testing migration to the new namespace

The first goal of lowering the barrier of entry to new vendors and implementations is important as Java EE has acquired a lot of baggage over many years as a result of its strong backwards compatibility. Strong backwards compatibility is a double edged sword. It makes it easier for developers to run an application on a new version. However, it also makes it burdensome for those developing Jakarta EE runtimes to support all the old stuff. Strong backwards compatibility can also result in developers not moving to the latest APIs or not even realising they are using old APIs. This can then perpetuate old myths into new versions of Jakarta EE and limit adoption of the latest techniques.

With the namespace change required from javax-jakarta it created a breaking change to backwards compatibility. The project took the opportunity to remove a number of old APIs, make some more optional (and therefore not required for a new application server) and to not require backwards compatibility with applications written in the old namespace. This means it is possible to deliver a new application server that is fully compatible with Jakarta EE 9 that only supports the Jakarta EE 9 APIs in the new namespace on JDK 11. For me, this is a huge win and gives us an opportunity to innovate with new Jakarta EE 9 runtimes, while still giving the option to support old applications on Jakarta EE 9 products.

I see Jakarta EE 9 as a stepping stone release therefore the second goal of making the release available rapidly as a platform for future innovation is essential. We have to get the namespace change done and dusted and end with a new baseline for Jakarta EE 10 work and I want to see the Jakarta EE 10 work move forward in parallel so it is delivered soon after Jakarta EE 9. With this goal in mind, the project team decided on no new APIs and no changes to existing APIs beyond minor enhancements, corrections, or bug fixes. This ensures we can deliver as fast as possible and get APIs into the jakarta namespace and in the hands of tools vendors, application server vendors, and developers. We hope to deliver Jakarta EE 9 in the first half of 2020 which is an aggressive timeline but consistent with our goals.

Keeping API changes to a minimum while at the same time moving all existing APIs into the jakarta package also satisfies our third goal, of providing a platform that developers can use as a stable target for testing migration to the new namespace. When moving to the jakarta package, developers can depend on the fact that there will be no behaviour change and no code change needed beyond the package rename. This is also true of tools vendors that look to support the jakarta namespace in IDEs or in tools to migrate old applications to the new packages. In addition, to satisfy this goal, and with a strong steer from the community, we decided to adopt a number of the APIs that have been removed from Java SE 9+ but are used heavily in Jakarta EE applications e.g. JAX-B, JAX-WS and others. These APIs will also move to the jakarta namespace for consistency. Finally, to make the platform simple and consistent, we decided to require Java 11 support for Jakarta EE compatible runtimes.

Looking Forward to Jakarta EE 10

Once we deliver Jakarta EE 9, we will have a solid platform for innovation. All the APIs will have been moved to the Eclipse Foundation and moved to the new namespace. We have open source specifications and APIs developed in an open process that allows contributions from everyone and anyone. The TCK is open source, everyone and anyone can use and contribute to it. We have a low barrier of entry for organisations that want to release Jakarta EE branded products. This is huge for the industry as many server side frameworks not thought of as traditionally Java EE, are dependent on these technologies and their continued evolution.

Get Involved

Jakarta EE 10 innovation can start now. There is a lot of desire to evolve many of the APIs under the Jakarta EE working group. If you want to contribute, the simplest way to get involved is to browse the GitHub projects at https://github.com/eclipse-ee4jand raise issues and new ideas for API improvements on the API projects.

Join the mailing lists of projects you are interested in https://projects.eclipse.org/projects/ee4j and make your voice heard.

Jakarta EE is all open source, all are welcome, let's go!

 Payara Server is Jakarta EE Compatible.