Thoughts about Jakarta EE future without 'javax'
This week Mike Milinkovich announced that Oracle and the Eclipse Foundation agreed that the javax package cannot be evolved by Jakarta EE community and Java trademarks cannot be used in Jakarta EE specifications. How critical is it to Jakarta EE community? Can Jakarta EE survive without javax namespace? Here are my thoughts about it.
For sure, it would be much better to evolve existing APIs in javax packages without any restrictions. But we have what we have and I am not going to do complaining and blaming here. There were reasons to do it this way. On the other hand, finally, the uncertainties with Java trademarks are gone. It's very important because Jakarta EE progress is not blocked anymore. Javax package restrictions draw a clear line separating Java EE and Jakarta EE, separating past and future. Javax becomes a legacy. All innovations will belong to jakarta namespace. Now it's clear that javax packages cannot be modified and community needs to find a way how to evolve specifications. And there are some options how it can be done. We need to maximize compatibility with Jakarta EE 8 for future versions without stifling innovation. It's what Jakarta EE Spec Committee agreed on.
In my opinion the best would be to make a big-bang javax->jakarta package rename to untie the community hands and allow modifications and APIs evolution. It will break the backwards compatibility which was always an important part of Java EE platform and we should not forget about it. There are thousands of Java EE applications and it won't be wise to remove backwards compatibility requirements. A good option is to create a special backwards compatibility profile in Jakarta EE platform. This profile should contain a frozen Java EE 8 APIs and will allow to run Java EE 8 applications on future versions of Jakara EE Platform. This profile can be optional to allow new potencial Jakarta EE vendors concentrate only on innovations, but I am sure that all big players such Oracle and IBM will support it anyway.
This kind of solution is not new for the industry. For example, in 2006 Sony released PlayStation 3 system which used new architecture and was not compatible with the previous PlayStation 2 system on the hardware level. They solved it by adding PS2 chip to the first versions of PS3 consoles allowed to run PS2 games on it.
Another sample is a process of changing CPU in Apple Macintosh computers from PowerPC to Intel. They provided a simulator allowing running PowerPC application on new Intel based computers for some limited time until most of the applications migrated to the new platform.
How the backwards compatibility can be implemented technically? One of the obvious and straightforward solutions is supplying two implementations: one is supporting javax and and another supporting jakarta. Javax implementations are already exist as part of Java EE 8. Jakarta implementations can be created by forking javax implementations and make necessary modifications.
Another way is patching application binaries at runtime or build time. Runtime solution can be accomplished using JavaAgent and build time via tooling and build plugins.
To simplify migration to jakarta package on the source level, the community may think of creating IDE plugins replacing javax with jakarta the clever way with one click.
I am working in different Jakarta EE committees and see the intention of participants to remain committed to Jakarta EE work, finish Jakarta EE 8 and push it forward to provide a robust, compatible and innovative enterprise platform.
About the Author
