From J2EE to Jakarta EE

Jakarta EE is a set of specifications: an open-source platform that offers a collection of software components and APIs (Application Programming Interface) for the development of enterprise applications and services in Java. During these last years, Jakarta EE has become one of the preferred frameworks for professional software enterprise applications and services development in Java.

There are probably dozens of such open-source APIs nowadays, but what makes Jakarta EE unique is the fact that all these specifications are issued from a process originally called JCP (Java Community Process), currently called EFSP (Eclipse Foundation Specification Process). These specifications, initially called JSR (Java Specifications Request) and now called simply Eclipse specifications, are issued from a consortium, bringing together the most important organizations in today's Java software development field, originally led by the JCP and now stewarded by the Eclipse Foundation.

Consequently, as opposed to its competitors where the APIs are evolving according to unilateral decisions taken by their implementers, Jakarta EE is an expression of the consensus of companies, user groups, and communities.

From J2EE to Java EE

Jakarta EE is probably the best thing that has happened to Java since its birth more than 20 years ago. Created in the early 2000s, the J2EE (Java 2 Enterprise Edition) specifications were an extension of the Java programming language known also as J2SE (Java 2 Standard Edition). J2EE was a set of specifications intended to facilitate the development of Java enterprise-grade applications. It was also intended to describe a unified and standard API, allowing developers to deal with complex functionalities like distributed processing, remote access, transactional management, security, and much more. They were maintained by the JCP as explained, and led by an executive committee in which Sun Microsystems, as the original developer of the Java programming language, had a central role.

The beginning of the year 2000 saw the birth of J2EE 1.2. This was the first release of what was about to be later called the "server-side" Java. That time was the epoch of the enterprise multi-tier applications that some people today describe as monoliths, having graphical user interfaces on their web tier, business delegate components like stateless EJB (Enterprise Java Beans), MDB (Message Driven Beans), and other remote services on the middle tier, and JPA (Java Persistence API) components on the data access tier. Clusters, load-balancers, fail-over strategies, and sticky HTTP sessions were parts of the de facto software architecture standard that every enterprise application had to meet. All these components were deployed on application servers like WebSphere, WebLogic, JBoss, Glassfish, and others.

From the year 2006 and ahead, Sun Microsystems decided to simplify the naming convention of the J2EE specifications, which were in their 1.4 version at that time, and, starting with the 5th release, to rename them as Java EE (Java Enterprise Edition). Similarly, the standard edition became Java SE (Java Standard Edition). This same year, Sun Microsystems was purchased by Oracle, who became the owner of both Java SE and Java EE. During this time, the JCP continued to produce hundreds of specifications in the form of JSRs covering all the enterprise software development aspects. The complete list of the JSRs may be found here.

Java EE was a huge success - a real revolution in Java software architecture and development. Its implementations, open-source or commercial products, were ubiquitous in the enterprise IT landscape. Oracle has inherited two of them: Glassfish, which was the open-source reference implementation by Sun Microsystems, and WebLogic, a commercial platform obtained further to the purchase of BEA.

But Oracle was and stays an RDBMS software vendor and, despite being the new owner of Java SE/EE as well as of Glassfish and WebLogic, the relationships with the Java and Java EE community were quite sharp. Consequently, Java SE became a commercial product available under a license and requiring a subscription while Java EE wasn't maintained anymore, and finished by being donated in 2017 to the Eclipse Foundation. Its new name was Jakarta EE.

From Java EE to Jakarta EE

With Jakarta EE, the server-side Java started a new life. It was first Jakarta EE 8, which kept the original namespace javax.*. Then came Jakarta EE 9, which was a hybrid release, as it used some original namespace prefixes together with the new ones jakarta.*. Finally, the current release, Jakarta EE 10, among other many novelties, provides a fully coherent new namespace. The new Jakarta EE 11 release is in progress and scheduled to be delivered in June 2024.

The architecture of the Java enterprise-grade services and applications continued to evolve under the Oracle stewardship, but the Java EE specifications were in a kind of status quo before becoming Eclipse Jakarta EE. The company didn't really manage to set up a dialogue with users, communities, work groups, and all those involved in the recognition and promotion of the Java enterprise-grade services. Their evolution requests and expectations weren't being addressed by the editor, who didn't seem interested in dealing with their new responsibility as the Java/Jakarta EE owner. In such a way that little by little, this has led to a guarded reaction from software architects and developers, who began to prefer and adopt alternative technological solutions to application servers.

Several kinds of solutions started to appear many years ago on the model of Spring, an open-source Java library, claiming to be an alternative to Jakarta EE. In fact, Spring has never been a true alternative to Jakarta EE because, in all its versions and millings (including but not limited to Spring Core, Spring Boot, and Spring Cloud), it is based on Jakarta EE and needs Jakarta EE in order to run. As a matter of fact, an enterprise-grade Java application needs implementations of specifications like Servlets, JAX-RS (Java API for RESTful Web Services), JAX-WS (Java API for XML Web Services), JMS (Java Messaging Service), MDB (Message Driven Bean), CDI (Context and Dependency Injection), JTA (Java Transaction API), JPA (Java Persistence API) and many others. Otherwise, Spring doesn't implement any of these specifications. Spring only provides interfaces to these implementations, relies on them, and, as such, is only a Jakarta EE consumer or client. So, Spring is a Jakarta EE alternative as much as the remote control is an alternative to the television set. Nevertheless, the marketing is sometimes more impressive than the technology itself. This is what happened with Spring, especially since the emergence of Spring Boot.

While trying to find alternative solutions to Jakarta EE and to remedy issues like the apparent heaviness and the expansive prices of application servers, certain software professionals have adopted Spring Boot as a development platform. And since they needed Jakarta EE implementations for even basic web applications anyway, as shown above, they deployed these applications in open-source servlet engines like Tomcat, Jetty, or Undertow. For more advanced features than just servlets like JPA or JMS, Spring Boot provides integration with Active MQ or Hibernate. And should these software professionals need even more advanced features, like JTA for example, they were going fishing on the internet for free third-party implementations like Atomikos. Additionally, in the absence of an official integration, they tried by themselves to integrate these features on their servlet engine, with all the risks that this entails.

Other solutions closer to real Jakarta EE alternatives have emerged as well, and among them, Netty, Quarkus, or Helidon are the best-known and most popular. All these solutions were based on a couple of software design principles like single concern, discrete boundaries, transportability across runtimes, auto-discovery, etc., which were known since the dawn of time. But because the software industry continuously needs new names, the new name that has been found for these alternative solutions is microservices.

More and more microservice architecture-based applications appeared during the next few years, at such a point that the word "microservice" became one of the most common buzzwords in the software industry. And in order to optimize and standardize the microservices technology, the Eclipse Foundation decided to apply to microservices the same process that was used in order to design the Jakarta EE specifications. Thus, the Eclipse MicroProfile was born.

The Eclipse MicroProfile is, like Jakarta EE, a group of specifications trying to inspire from several microservices existing frameworks such as Spring Boot, Quarkus, Helidon, and others, and to unify their base principles in a consistent and standard API set. Again, like Jakarta EE, the Eclipse MicroProfile specifications have to be implemented by software editors. While some of these implementations like OpenLiberty, Quarkus, Helidon, and others only concern the Eclipse MicroProfile specifications, some others like Wildfly, Red Hat EAP, Glassfish, or Payara are trying to do the splits and unify Jakarta EE and Eclipse MicroProfile in a consistent and unique platform.

Conclusion

As a continuation of its previous releases, Jakarta EE is a revolution in Java enterprise-grade applications and services. It retains the open-source spirit and is guided by collaboration between companies, communities, and user groups rather than commercial goals alone.