JavaEE is dead, long live to the javax package!

If you missed it, Oracle didn't allow Eclipse to continue to use javax package for new API. A lot of blog posts had been written about it and most of them conclude that dropping javax package in favor of jakarta is the only sane way to go. Let's not conclude too quickly that it is the only option and take time to see what it means for Java ecosystem.

Technical challenges?

JavaEE/Jakarta main constraint is the backward compatibility. This is a very high constraint but also the only reason it is a good choice. By construction it abstracts concepts and vendors so it is by design a bit behind but the guarantee to work for years is a very high value for any company - and dev I should add. Being potentially broken because the company behind your beloved library decided to change all signature is a fear you can't have with JavaEE.

Side note: being a bit behind does not mean it is far behind, don't misinterpret my point. JavaEE is already reactive friendly but any code already written still runs.

This backward compatibility has two direct implications:

• Nothing is deleted: this can look like a very strong constraint when you check out the number of specifications but with profiles the platform can build lightweight execution environments (Full profiles which includes everything, Web profiles which includes half of the specifications and now Microprofile which is unofficial but still a profiles which includes a few cloud oriented specifications). This implication also means nothing in javax package will be deleted so this is not a change we care about.
• Assuming the mainstream package moves to jakarta instead of javax, javax will still be supported.

Same API, multiple packages

I will not redetail all the technical solutions to do that but assuming the API are 1-1, a java.lang.reflect.Proxy can support both API while it is created with both types. Similarly, a javaagent or a build time plugin can rewrite the application bytecode to move from one package to the other.

However this solution is not realistic. One of the first reaction of Apache Tomcat community when this opportunity was discussed was that some API could be dropped - getContentLength vs getContentLengthLong. This also means that moving the package, it will be tempted to rewrite some API to adjust that. This is as much exception rules to maintain and moreover test which is an gigantic work!

One realistic solution is also to have both API in dependencies and provided in the servers and the EE libraries to support both explicitly. This is not satisfying technically because half will likely be unused but this is a secured solution I rarely see mentionned. This would enable to add anything anywhere without any issue in terms of backward compatibility but this has the big drawback to pollute the completion in the IDE (more generally the tooling) if not well done. It also makes ambiguous on the user land which API to use - can depend its stack.

Javax is not JavaEE

The next issue renaming javax to anything else is that, being standard, javax is used by a lot of framework and probably more framework outside JavaEE than inside. Whereas it is trivial for a JavaEE container which is managed either at build time - Quarkus - or run time - like TomEE, Wildfly, ... - to use the previous part hack to handle both packages. However for all libraries which are embedded or set up at build time this is another game. The question there is: is it realistic to request all the java ecosystem to move to Jakarta/Eclipse? If we take Microprofile as an example, the Java ecosystem is more often using Zipkin/Brave than Microprofile Tracing, same for Metrics, etc... So yes Microprofile is more recent but is also not seen mainstream so not that quickly adopted. Javax was mainstream and integrated more quickly by libraries and even Spring Framework/Boot!

There also are softwares/libraries out there which have the constraint to support a stack and backward compatibility for years. Javax was a natural choice since it was aligned on that constraint but if javax moves to jakarta then this is no more the case and these libraries are stucked on older versions - don't forget they don't all run in environments where a javaagent or bytecode manipulation is an option.

The promise of a change of the main package is, in my opinion, the promise for dev to stick to javax for years and let jakarta be used by its own dev only.

Concretely, Apache Tomcat is already discussing the fact that javax would be supported until at least 2030. This means that most users will not move to jakarta before this date because they don't need to and their stack is not compatible with it so what would be the life of jakarta in the meantime?

Keep javax and just move forward?

Now if we try to be pragmatic and check wat can happen to the API, we can see that:

• A lot of spec is already very stable so changes will likely not occur and if they do a new class/enum/.... in a new package is acceptable.
• A lot of spec are just done and will likely not get updates but are still needed in several cases - do you think javax.inject will move? Probably not, changes would belong to CDI now.
• If new methods must be added, and since Oracle prevents to add anything in javax, Jakarta can add it in a new package but instead of duplicating what is needed from javax it can just "wrap" it. For instance, instead of adding a method to HttpServletRequest, it can create a jakarta.servlet.HttpServletContext with a getRequest() returning the javax instance. The only limited case is for enums but here, nobody will die to duplicate the enum when needed or create a new enum with a more precise semantic.

A political challenge finally?

Eclipse is not Oracle. This also means they can change the policy around JavaEE and therefore decide to break backward compatible statement and change API more or less often. However this is something which must be taken very seriously. Blog posts present that as "a new hope" but it is factually "a shutdown" of the platform in my opinion if it is done because the first act of Jakarta would be to drop what it was created for. This is why I see this issue with Oracle as a real chance for Eclipse and Jakarta community to proove they are strong and community centric and that Oracle can't change what the community owns.

I'd really like the opinions expressed on the internet are more user centric and not vendor centric. Most of the ones you can meet today about that change are done by vendors and indeed for them it is better to just switch of package (code will be cleaner, they can probably sell some support around the corner, and they fully decorrelate from Oracle).

Java is a success because the platform is strong and the ecosystem - the communities - is just enormous. Javax helped a lot to reached that state and isolating Jakarta from all the ecosystem sounds like a bad promise. That said, javax is not dead, with all the code relying on it today you can be sure it will not disappear in 2 years so let's wait the end of the discussion of Eclipse and cross fingers they do the community choice.

This is why I think that if JavaEE is dead, then long live to the javax package.