It’s time to change the specification names…
When we first moved the APIs and TCKs for the Java EE specifications over to the Eclipse Foundation under the Jakarta EE banner, we kept the existing names for the specifications in place, and adopted placeholder names for the open source projects that hold their artifacts. As we prepare to engage in actual specification work (involving an actual specification document), it’s time to start thinking about changing the names of the specifications and the projects that contain their artifacts.
Why change? For starters, it’s just good form to leverage the Jakarta brand. But, more critically, many of the existing specification names use trademarked terms that make it either very challenging or impossible to use those names without violating trademark rules. Motivation for changing the names of the existing open source projects that we’ll turn into specification projects is, I think, a little easier: “Eclipse Project for …” is a terrible name. So, while the current names for our proto-specification projects have served us well to-date, it’s time to change them. To keep things simple, we recommend that we just use the name of the specification as the project name.
With this in mind, we’ve come up with a naming pattern that we believe can serve as a good starting point for discussion. To start with, in order to keep things as simple as possible, we’ll have the project use the same name as the specification (unless there is a compelling reason to do otherwise).
The naming rules are relatively simple:
- Replace “Java” with “Jakarta” (e.g. “Java Message Service” becomes “Jakarta Message Service”);
- Add a space in cases where names are mashed together (e.g. “JavaMail” becomes “Jakarta Mail”);
- Add “Jakarta” when it is missing (e.g. “Expression Language” becomes “Jakarta Expression Language”); and
- Rework names to consistently start with “Jakarta” (“Enterprise JavaBeans” becomes “Jakarta Enterprise Beans”).
This presents us with an opportunity to add even more consistency to the various specification names. Some, for example, are more wordy or descriptive than others; some include the term “API” in the name, and others don’t; etc.
We’ll have to sort out what we’re going to do with the Eclipse Project for Stable Jakarta EE Specifications, which provides a home for a small handful of specifications which are not expected to change. I’ll personally be happy if we can at least drop the “Eclipse Project for” from the name (“Jakarta EE Stable”?). We’ll also have to sort out what we’re going to do about the Eclipse Mojarra and Eclipse Metro projects which hold the APIs for some specifications; we may end up having to create new specification projects as homes for development of the corresponding specification documents (regardless of how this ends up manifesting as a specification project, we’re still going to need specification names).
Based on all of the above, here is my suggested starting point for specification (and most project) names (I’ve applied the rules described above; and have suggested tweaks for consistency by strike out):
- Jakarta
APIsfor XML Messaging - Jakarta n
Architecture forXML Binding - Jakarta
API forXMLbasedWeb Services - Jakarta Common Annotations
- Jakarta Enterprise Beans
- Jakarta Persistence
API - Jakarta Contexts and Dependency Injection
- Jakarta EE Platform
- Jakarta
API forJSON Binding - Jakarta Servlet
- Jakarta
API forRESTful Web Services - Jakarta Server Faces
- Jakarta
API forJSON Processing - Jakarta
EESecurityAPI - Jakarta Bean Validation
- Jakarta Mail
- Jakarta Beans Activation
Framework - Jakarta Debugging Support for Other Languages
- Jakarta Server Pages Standard Tag Library
- Jakarta EE Platform Management
- Jakarta EE Platform Application Deployment
- Jakarta
API forXML Registries - Jakarta
API forXML-based RPC - Jakarta Enterprise Web Services
- Jakarta Authorization
Contract for Containers - Jakarta Web Services Metadata
- Jakarta Authentication
Service Provider Interface for Containers - Jakarta Concurrency Utlities
- Jakarta Server Pages
- Jakarta Connector Architecture
- Jakarta Dependency Injection
- Jakarta Expression Language
- Jakarta Message Service
- Jakarta Batch
- Jakarta
API forWebSocket - Jakarta Transaction
API
We’re going to couple renaming with an effort to capture proper scope statements (I’ll cover this in my next post). The Eclipse EE4J PMC Lead, Ivar Grimstad, has blogged about this recently and has created a project board to track the specification and project renaming activity (as of this writing, it has only just been started, so watch that space). We’ll start reaching out to the “Eclipse Project for …” teams shortly to start engaging this process. When we’ve collected all of the information (names and scopes), we’ll engage in a restructuring review per the Eclipse Development Process (EDP) and make it all happen (more on this later).
Your input is requested. I’ll monitor comments on this post, but it would be better to collect your thoughts in the issues listed on the project board (after we’ve taken the step to create them, of course), on the related issue, or on the EE4J PMC’s mailing list.
Published on Java Code Geeks with permission by Wayne Beaton, partner at our JCG program. See the original article here: Renaming Java EE Specifications for Jakarta EE Opinions expressed by Java Code Geeks contributors are their own. |
