1. Introduction
Ever heard of Java EE? How about Java 2EE, J2EE, or now Jakarta EE? Actually, these are all different names for the same thing: a set of enterprise specifications that extend Java SE.
In this short article, we’ll describe the evolution of Java EE.
2. History
In the first version of Java, Java enterprise extensions were simply a part of the core JDK.
Then, as part of Java 2 in 1999, these extensions were broken out of the standard binaries, and J2EE, or Java 2 Platform Enterprise Edition, was born. It would keep that name until 2006.
For Java 5 in 2006, J2EE was renamed to Java EE or Java Platform Enterprise Edition. That name would stick all the way to September 2017, when something major happened.
See, in September 2017, Oracle decided to give away the rights for Java EE to the Eclipse Foundation (the language is still owned by Oracle).
3. In Transition
Actually, the Eclipse Foundation legally had to rename Java EE. That’s because Oracle has the rights over the “Java” brand.
So to choose the new name, the community voted and picked: Jakarta EE. In a certain way, it’s still JEE.
*New name announced
This is still an evolving story, though, and the dust hasn’t completely settled.
For example, while Oracle open-sourced the source code, they did not open-source all the documentation. There’s still a lot of discussion over this matter because of legal issues that make it tricky to open-source documentation related to, for example, JMS and EJB.
It’s not clear yet if new Eclipse Foundation documentation will be able to refer to the originals.
Also, curiously, the Eclipse Foundation can’t create any new Java packages using the javax namespace, but it can create new classes and subclasses under the existing ones.
The transition also means a new process for adding specifications to Jakarta EE. To understand it better, let’s take a look at what that process was like under Oracle and how it changes under the Eclipse Foundation.
4. The Future
Historically, in order for a feature to make it into “EE”, we needed three things: a specification, a reference implementation, and tests. These three things could be provided by anyone in the community, and an Executive Committee would decide when these were ready to add to the language.
To better understand the past process, let’s take a closer look at what JSRs, Glassfish, and the TCK are and how they embodied new EE features.
We’ll also get a glimpse of what to expect in the future.
4.1. The JCP and Now, the EFSP
In the past, the process by which a new EE feature was born was called the Java Community Process (JCP).
Java SE still uses the JCP today. But, since EE has changed its ownership, from Oracle to the Eclipse Foundation, we have a new and separate process for that. It’s the Eclipse Foundation Specification Process (EFSP) and it’s an extension of the Eclipse Development Process.
There are some important differences, though, mostly around “Transparency, Openness, Shared Burden and Vendor Neutrality”. The EFSP organizers, for example, envision collaborative working groups that are vendor-neutral, a certification process that is self-service, and an organization that operates and governs as a meritocracy.
4.2. JSRs
In the JCP, the first step to adding a feature to EE was to create a JSR or Java Specification Request. The JSR was a bit like the interface for an EE feature. The JCP Executive Committee reviewed and approved a completed JSR, and then JSR contributors would code it up and make it available to the community.
A good example of this was JSR-339 – or JAX-RS – which was originally proposed in 2011, approved by JCP in 2012 and finally released in 2013.
And while the community could always weigh in while a specification was under discussion, time showed that an implementation-first approach – like in the case of JSR 310, java.time, and Joda Time – tended to create more widely-accepted features and APIs.
So, the EFSP reflects this code-first view in its stated goal: “EFSP will be based on hands-on experimenting and coding first, as a way to prove something is worthy of documenting in a specification.”
4.3. Glassfish
Then, as part of the JCP, a JSR needed a reference implementation. This is a bit like the class that implements the interface. A reference implementation helps developers of compatible libraries or other organizations that want to create their own implementation of the spec.
For Java EE features, the JCP used Glassfish for its reference implementations.
And while this centralization on Glassfish simplified the discovery process for implementers, that centralization also required more governance and had a tendency to favor one vendor over another.
Hence, the EFSP doesn’t require a reference implementation, but instead only a compatible implementation. Simply put, this subtle change makes so that implementations inside of a central architecture, like Glassfish, won’t be inadvertently preferred by the foundation.
4.4. TCK
Finally, the JCP required that EE features be tested through the Technology Compatibility Kit, or TCK.
The TCK was a suite of tests to validate a specific EE JSR. Simply put, in order to comply with Java EE, an application server needs to implement all of its JSRs and pass all the tests on the designated TCK.
Not much changes here. Oracle open-sourced the TCK as well as the EE JSRs. Of course, all future documents and the TCK will be open-source.
5. Conclusion
Java EE has certainly evolved a lot during those years. It’s nice to see it continuing to change and improve.
There are many challenges ahead, so let’s hope for a smooth transition.