It was announced today that we in the Jakarta EE community would not be able to modify the javax namespace. When I heard that statement uttered for the first time, I was certain I heard wrong.
I asked several questions hoping for more positive news with better options in the future. No, it was exactly what I heard. Many of you know me as a positive voice in the community, but even my calm demeanor was cracked. Several visceral statements left my mouth and at one point during the meeting I recall using the word asinine.
Transitioning through the stages of grief and into acceptance was impossible without some hope for the future. I didn’t sleep well that night, but awoke with some ideas. Others had the same experience. Slowly we began collectively rebuilding the industry in our minds. The old dream was gone, what we needed was a new hope.
In efforts to help everyone make the transition, here are some things that bring me new hope for a new dream.
Everything is jakarta
As originally envisioned, existing code would be under javax and modifications would be allowed with some restrictions. Code that had to be outside those restrictions would have been in the jakarta namespace. The way this would have played out is that an API like CDI, for example, would start 100% javax and slowly become some mix of javax and jakarta as it grew. Some specifications may have seen very little impact, some a lot. The line would have been decided by an unchangeable legal agreement we would never be able to read, but would have to intimately know.
Every new developer in our ecosystem would have to have learned the answer to the question, “what’s the deal with this mixed javax and jakarta namespace thing? Why are some CDI classes in javax and some in jakarta and how do I know which or where to look?” In 2 years time, the mix for Jakarta EE as a whole probably would have been around 80% javax and 20% jakarta.
The new rule is easy. If the specification API classes will be modified in any way, the specification’s API will be moved entirely to the jakarta namespace. Which specifications are moved and when is a discussion we need to have as a community, but I suspect in 2 years time it will be 80% jakarta and 20% javax.
We were never going to have complete freedom over javax. This recent change ultimately means that we can no longer stretch the reality of that over 10 years and must deal with it now, immediately. In many ways it is a blessing in disguise. Some challenges we would have had to have faced are gone. We do now have new challenges.
Backwards compatibility is possible
The largest challenge is how to not leave behind the 20 years of applications written under the javax namespace. We need these to still run on new servers that have switched over to the jakarta namespace. Making this possible is going to involve some form of bytecode manipulation, which may sound severe, but in reality is how the majority of Java EE and Jakarta EE works anyway. Have you ever wondered how the magic of JPA is even possible? You write a class, hand it to the server and somehow data flows in and out of it using code you can’t see and didn’t write. All the bytecode to do that is generated and either put directly into your class or on top of your class, or both.
Nearly everything created in Java EE after 2006 uses some form of bytecode creation or manipulation. It’s the dirty little secret and a favored trick of the industry and why there was such a huge uproar over removal of sun.misc.Unsafe. For a Jakarta EE implementation to migrate your bytecode from javax to jakarta is “more of the same.” There will be some challenges, but it is ultimately how everything works anyway.
The “Quarkus” investment timeline will move up
Our industry started doing source code generation at deploy time. This was 1999 through 2003. It was a very heavy process. We didn’t have Maven 2 or Gradle yet. Everything was still very early stages, so that approach was very painful. We shifted to bytecode generation from 2003 till now and most of that is done at runtime on startup. Quarkus is really the first to shift back to generation at deploy time, or build time, showing us all how amazing it can be. As an industry we’ve poked at bytecode generation/manipulation at deploy or build time, but not close to the level Quarkus has taken it.
A healthy disruption Quarkus brings to our industry is forcing us all to transition into deploy-time and build-time generation. This does require a huge investment, however. This impossible-to-avoid javax to jakarta migration will require vendors to make a big investment in the exact place it needs to make anyway to catch up to Quarkus. The reality is this unfortunate legal restriction on javax will force the industry to do something it needed to do anyway, invest in deploy-time bytecode enhancement, and very likely bring us more “Quarkuses” 1 to 2 years sooner.
If only we had IDE experts to help source migration
There is still the question of migrating source code. Not much needs to be said there other than it is a fortunate twist that the entire Jakarta EE effort is in the same foundation as the Eclipse Java IDE. Help is right around the corner. All good Java IDEs already have fantastic ability to refactor applications, including changing packages. This is slightly different as you won’t be changing the package of your own code, so IDEs will have to do some work. However it is not impossible and I predict extremely strong support for the migration.
Free at last
While all of this is a huge change from what we had imagined, all new challenges come with new benefits. We have strong incentive to make investment where we needed to make it anyway. We’re surrounded by fantastic IDEs. We are saving ourselves from some potentially awkward mixing of javax and jakarta. And most importantly, every scrap of everything in the jakarta namespace will be community owned, free from external licensing and trademark restrictions.
It will be tough, but ultimately we’re being forced to free ourselves. On the other side, what we do is truly up to us.
