Posted on

From javax.* to jakarta.*: A Simple Proof of Concept

Experiment with code that uses the new jakarta.* APIs.

Now that the Jakarta EE project is planning to release its next version (Jakarta EE 9), where the major change is the update of all its APIs to use jakarta.* instead of javax.* in the package names, and hence the issue of breaking binary compatibility, I decided to experiment a little bit with how code that uses javax.* APIs can be dynamically modified (without the need to recompile) so that it runs against the target jakarta.* namespace.

You may also like:  Jakarta EE and the Great Naming Debate

It would also be a good opportunity to learn more about Javassist, which I'll be using to do the renaming at the bytecode level. Note that this post is not intended to propose a solution to this problem of API compatibility. It simply shares experimentation related to the subject.

Posted on

Jakarta EE: A Clean Slate

The announcement that Jakarta EE cannot use the javax.* namespace is great news and provides Jakarta EE with a clean slate on which to build and innovate the future of Enterprise Java.

The Original Proposal

It had been envisioned that the javax.* and jakarta.* namespaces would coexist after Java EE 8 and, as it evolved, the jakarta.* namespace would be used for new features of exiting APIs and the innovation of new APIs. This would have ensured backward compatibility from the start. And overtime the use of jarkata.* would eclipse the old namespace, but never actually replacing javax.* namespace. So, forever more Enterprise Java developers would have to explain why there are two namespaces. A constent reminder of Enterprise Java’s past (something we are trying to move on from).