Jakarta EE 9 Work
This page is something of a work-in-progress, but attempts to serve as an entrypoint for anyone looking to get involved with this work.
Challenge
Jakarta EE 9 removes a very small number of specifications, and doesn’t introduce functional changes to the specifications. It does, however, introduce a package rename, which will have a very wide impact. Not only do the specification jars and implementations in the server need to change their namespaces, user applications will need to change any references as well.
Goals
-
Try and maintain a single codebase for javax and jakarta. It’s tempting to fork master and embark on a massive renaming exercise. That’s complex as we’d need to do that for various dependencies as well, who may also have other branches and timelines. Having two code-bases also means that any changes need to be applied twice, and with renamed packages, its unlikely the git merging or cherry-picking will work.
-
Be backwards compatible - One goal I had in my mined, is that if you have an application that uses javax, you’d probably like to be able to run it on a new Jakarta EE server. There are some options here - I quite like the idea of running the Transformer as a javaagent, so any applications deployed using the old namespaces are converted on the fly at the bytecode level.
-
Tooling - I wonder what tooling we could potentially provide? One thought I had was a Maven plugin that can transform a war/ear file for you as part of a build.
Approaches
-
Eclipse Transformer
Investigate the use of the Eclipse Transformer (https://projects.eclipse.org/projects/technology.transformer) to translate the server, and the example applications to the Jakarta namespace.
-
???
Tasks Tracker
TBD: something will appear here soon