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:
I think most of us agree that Jakarta Authentication is far more easy to remember than The Java Authentication Service Provider Interface for Containers.
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.
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.
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
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.