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.
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.
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.
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.
TBD: something will appear here soon