Today the Eclipse Foundation have announced an Update on Jakarta EE Rights to Java Trademarks which has dramatic implications for the future of Java EE and Jakarta EE. The Payara team have only recently learned about this - so we thought we would blog about how we feel this impacts customers and users of the Payara Platform. We'll also give our thoughts on how Jakarta EE should evolve given the constraints outlined in Mike Milinkovich's blog from the Eclipse Foundation.
To summarise Mike's blog:
"Eclipse and Oracle have agreed that the javax* package namespace cannot be evolved by the Jakarta EE community. As well, Java trademarks such as the existing specification names cannot be used by Jakarta EE specifications."
How Does this Impact Jakarta EE 8?
There is no impact on Jakarta EE 8. Jakarta EE 8 is planned for release in late summer or early autumn 2019 and Jakarta EE 8 will be binary compatible with Java EE 8 with no API changes or namespace changes. It is the intention of the Payara team that we will certify Payara Server 5 and Payara Micro 5 as compatible implementations of Jakarta EE 8 in the quarterly Payara release that follows publication of the Jakarta EE 8 specifications.
How Does this Impact Jakarta EE after Jakarta EE 8?
The most important impact on Jakarta EE is that backwards compatibility with Jakarta EE 8 and therefore Java EE 8 at the source code level will have to be broken in future versions. Any API that is modified going forward will have to move from the javax.* namespace to the jakarta.* namespace.
Thoughts on Evolving Jakarta EE.Next
Given that backward compatibility must be broken, how should we proceed going forward? Due to the short time we have had visibility of this decision, our thoughts are still evolving. We'll further develop our thoughts and strategy moving forward in consultation with our customers, the community and other members in the Jakarta EE community. However, we do feel that this is a historical opportunity for a brave new start and a big bang migration of all APIs to the new jakarta* namespace should take place for Jakarta EE 9. Our thoughts on why are below and we welcome feedback.
Jakarta EE 8 is an LTS and Provides Stability for 8+ Years
Given that Jakarta EE 8 will be released later in 2019 and this will provide backwards compatibility within the javax* namespace, Jakarta EE 8 can form a stable foundation for existing production applications for many years. Payara Platform 5 will be certified compatible with Jakarta EE 8 and has a support roadmap out until 2028. This provides a stable, long term release for the community and customers to migrate to Jakarta EE.
Break Source Code Compatibility Once
As breaking of binary compatibility is a given for Jakarta EE beyond Jakarta EE 8, we should embrace this change and follow a big bang approach and migrate all the javax.* APIs that make up Jakarta EE 8 to the jakarta.* namespace. We feel that moving all APIs in one release means we only have to take the pain once and future stability is then assured. The alternative is to move APIs when they need to be modified but this could result in a drip. If the APIs are only moved as they need to be modified rather than all at once, a drip of changes and source code incompatibilities over a number of releases will erode developer confidence.
Embrace JDK 11+ and Modularity
We also have to move the APIs to support JDK 11. We should embrace this and ensure all APIs moved to the jakarta* namespace, embrace JDK 11 and JPMS, and enable enhanced modularity going forward. This will also give us an opportunity to tidy up the dependency graph to make Jakarta EE more modular and allow easier creation of modular servers and new modular Jakarta runtimes.
Remove Legacy
Given the stated aim of the Jakarta EE working group is the development of Cloud Native APIs, we should look to reduce the footprint of Jakarta EE and remove old APIs and legacy during the transition to the new namespace.
Increased Freedom and Innovation
Moving everything to the new namespace will give Eclipse project teams the space to innovate freely at the Eclipse Foundation without having to be concerned about the details of the legal agreements. Also removing legacy APIs and the requirement for backwards compatibility with Jakarta EE 8 will enable new vendors to enter the market and enable current vendors to create new modular runtimes that do not have to support the old APIs.
Release Cadence and LTS Strategy
Finally, we need to outline a Long Term Release (LTS) strategy for Jakarta EE with Jakarta EE 8 being the first LTS. Together we must put together a roadmap with a regular release cadence that drives Jakarta EE forward rapidly with a release train model that delivers regular Jakarta EE releases in the future.
How Can Payara Support Customers and the Community?
The Payara team will be focused on easing the transition from the javax* namespace to the jakarta* namespace. Payara Platform 5 will be a certified Jakarta EE 8 compatible implementation and will enable customers to migrate to Jakarta EE 8 from Java EE easily without application changes. Payara Platform 5 has a published support lifecycle out to 2028 which also includes underlying JDK support. This ensures customers have a stable production platform for many years on the javax* namespace.
Beyond Payara Platform 5, we will be supporting the development of Jakarta EE and will release future versions of the Payara Platform that are certified compatible and that support the new Jakarta namespace. As these releases become available we expect to provide tooling that aids in the migration of applications from the old namespace to the new. There are many potential options for how to develop this tooling and we hope to collaborate in the Jakarta EE working group to deliver industry wide and product specific solutions long before Payara Platform 5 reaches end of life.
How the Payara Team Helps Through the Transition
In summary, versions of Jakarta EE beyond Jakarta EE 8 will need to move APIs into a new package namespace. This will break source code backwards compatibility for future applications targeting Jakarta EE 9 and beyond.
The Payara team feel that a big bang break of compatibility should be carried out in the Jakarta EE 9 timeframe.
The Payara team will have a supported platform for applications using the old javax* namespace out to 2028.
The Payara team will develop tooling to ease the migration of applications using the old javax* namespace for future versions of the Payara Platform.
Although this is not where we wanted to be, this is a one-off opportunity to free the platform of the legacy of old APIs, old licensing, and be free to innovate, enhance and develop future APIs in an inclusive and collaborative open source foundation.
I hope you will join us on this journey. You can see more of our plans for the future of the Payara Platform in our 2019 Roadmap.
