Javax-to-Jakarta Tales from the Crypt

It’s now been almost five years since Oracle announced the donation of Java’s enterprise layer to the Eclipse foundation. It stipulated a name change, removing “Java”, ostensibly due to trademark issues. Eclipse chose “Jakarta” as the new name.

As Java programmers, we understand organizational boundaries of dependent modules are enforced via package names. How we reference them in our code.

For many years now we’ve had this durable base of auxiliary software coming from the platform and the 3rd parties that comprise its ecosystem. It’s free and shields us from the intricacies and accelerates development. Makes our job easier. The reason I continue to use Java.

The programming language itself factors into why we choose to use it too. Java ranks at or near the top, in my estimation. We’re not discussing theory or practice here and I’m not trying to convince you the platform’s viable.

Back to the main point. There’s a cost associated with using free software, despite the language in which it was written. Sometimes it changes. Always for reasons outside of our control. That means we must change our code to accommodate. The Jakarta migration requires that millions (billions?) of lines-of-code be changed. We’re talking about the biggest disruption to the Java ecosystem in its 27 years.

Not a rant-post and we’re not going over tactics here. That has all been covered elsewhere. I will point out that converting the code is simple. Just change the package imports and pull in the newer versions of the libs into whatever dependency mechanism is being used.

If you can find all of them. As of today, many affected suppliers have published Jakarta compatible releases, some are still working on it, while still others have it on their roadmap.

That’s quite remarkable actually and demonstrates the robustness of the ecosystem. It’ll handle it — eventually.

The runtime’s ready, with a logjam in the projects upstream. Until all of the projects we use have published their compatible packages, we can’t migrate. In turn projects dependent on us must wait until we publish our conversion, and so on. We can replace our non-compliant libraries (a ton of work) or wait.

What’s hanging in the balance is which Servlet container runs and which version of the JVM will be in use. Older code can’t run in newer containers and vice versa. There are ways to sidestep the compatibility restrictions. Conversion routines that modify the packaged bytecode so it works with the jakarta namespace. Can you say shim? For me, I’ll wait just a bit longer. Hope it doesn’t take too long.

Update

April 24, 2023

Many of the suppliers are getting their migrated packages released. For example, Spring 6, Apache CXF 4 and Tomcat 10. Yesterday, I was able to run tests inside of Apache Fortress Rest runtime using them. Soon, Apache Fortress will be able to release its packages supporting jakarta. The logjam is finally starting to break up!