As Wayne Beaton wrote about in his blog Renaming Java EE Specifications for Jakarta EE, the process of renaming the Java EE specifications as a part of the path towards Jakarta EE 8 has started.
Naming is hard and changing names that we have become attached to is even harder. Most of us also have this inherent feeling that change is bad and should be avoided. At the same time, we live in this ever-changing industry where embracing change is, not only a mantra but also a requirement to survive. Add to this, that some of the names we are talking about in this context are pretty bad. Some of them so long that we have to google the acronym to be able to describe what it actually abbreviates. Some of the acronyms we are using daily aren’t even acronyms, but more of an artificially created letter combination following some sort of standard. A couple of examples:
Jakarta Authentication
I think most of us agree that Jakarta Authentication is far more easy to remember than The Java Authentication Service Provider Interface for Containers.
Jakarta REST
Think about Jakarta REST versus Java™ API for RESTful Web Services. I don’t think anyone ever uses the long name, but rather the abbreviation/acronym JAX-RS. Which isn’t even an acronym! It is just some collection of letters to fit into the JAX-* naming standard used by Sun back in the J2EE days.
Jakarta Messaging
The Java™ Message Service specification covers create, send receive and read messages. So it is much more than just a message service. In this case, Jakarta Messaging would be a much more descriptive name.
Participate!
We have created an issue in each of the specification GitHub projects as well as a Specification Project Renaming board in EE4J GitHub organization to track the process
Final Thoughts
I am positive to renaming the specifications even if it is a lot of work and may seem like an unnecessary use of resources. It is an opportunity to fix something to the better in one go and this is probably the perfect time to do it.
Are the acronyms part of the reflection scope?
If yes, it would also be useful when choosing the specification name proposals, to eventually check that there will be no ambiguity in the possible acronyms, for example with:
– “Jakarta Common Annotations” and “Jakarta Connector Architecture”, if I suppose that Jakarta will be acronymed only with letter “J”, will result in: “JCA” Vs “JCA”. Maybe to solve the problem we shoud use JCAn and JCAr or another predefined convention / nomenclature (recursive acronyms, simple abbreviation , Shortcut, pronounced acronyme [type taken from en.wikipedia.org/wiki/Acronym])
– “Jakarta Authentication” and “Jakarta Authorization”, JA Vs JA or JAuth Vs JAuth are also ambiguous (maybe we can use synonym for one of them, like “identification” instead of “authentication” and something like “access”, “permission” or “credential” in place of “authorization”)
In the same way:
– Will the acronym of Jakarta will be “J”, “JK” or something else, if it’s “J”, for example with JSF, how will we know if the abbreviation refer to Java Server Faces or Jakarta Server Faces?
– Will the numbering of major version/release remain continuous with the previous implementation or will it be reset? JSF 2.X will be clearly recognized as the implementation piloted by Oracle/JavaEE and JSF 3.x the one under Eclipse/jakartaEE
My personal hope is that the new simple naming scheme will make acronyms superfluous.