Thoughts on the Jakarta EE Package Name Change

The Eclipse Foundation announced that Jakarta EE cannot continue to use the javax package name. Apparently, this comes with the fact that while Java EE is based on this name, no further modifications are allowed to classes or packages starting with that name.

While this is certainly bad news, for me, the bad news already started when it was announced that Jakarta EE can’t use the javax name for new specifications and sub-packages. That would have already meant continuing to evolve a platform that becomes more inconsistent over time.

Given the situation we’re in, I think it makes sense to make a clear cut and migrate to the proposed jakarta name.

This certainly means a huge impact for the whole Java ecosystem, everything that bases on any Enterprise API, not only the standards themselves. How to tackle that reasonably?

I believe the most important goal is to minimize the impact for the users, that is, developers out there. I see two major changes that have to be made, besides the code usage in projects.

Any runtimes that know and handle EE APIs, e.g. application servers, have to adapt and switch to the new name. They will have to implement some functionality to live with both javax and jakarta, very likely simultaneously, simply because they have to. There’s too much code out there that won’t be migrated to base on either javax or jakarta fashion. In the real world, there are legacy projects, tons of libraries and dependencies, binaries for which no source exists, and much more. We need a way to tell a runtime to just live with both, at least temporarily, or in specific compatibility profiles. There are already proposals on how to do that, including Bytecode manipulation and other black magic. I’ve talked to IBM engineers that this is also the way Liberty will go. For me, making life easier for developers has the highest importance.

The second big impact will be for frameworks, libraries, and tooling built around Enterprise Java that import something with javax contained in Java EE. At least once some new functionality is introduced, they will have to switch. If they want to ensure that their project still works under Jakarta EE, even without a “compatibility runtime,” they’ll have to switch too. I think a clean cut is to offer the current Java EE APIs, under both Java EE, with javax, and Jakarta EE with jakarta. This would be needed for both the platform (javaee-api) and individual specifications such as JAX-RS. The projects, then, have an easy control, via their resolved dependencies, which one to use, and can swap their imports accordingly. If Jakarta EE makes a clean cut, for example, switching only to the jakarta namespaces in the next release, say 9, or 8.1, but keeping everything else similar to Java EE 8, this makes it easier for projects to switch.

TL;DR

In my opinion, the Jakarta EE ecosystem should:

• Minimize the impact for the users, that is developers
• Make runtimes support both javax and jakarta, at least temporarily or in a compatibility profile
• Make a clean cut to switch the package names in Jakarta EE platforms and individual standards, without switching any other functionality