In a very interesting webinar streamed live as part of the recent JConference, Antoine Sabot-Durand talked about "hostility" between J2EE/Jakarta and Spring and the differences between them from decades ago to the recent times.

Antoine is a Java Champion. He is also the CDI 2. 0 spec lead, involved in Microprofile and various projects linked to CDI ecosystem development and thus Jakarta EE.

His talk was called "Has the J2EE vs Spring Infinity War reached an End Game? A short history of Java for the enterprise" and was driven by his recurrent observation, when wearing his recruiter hat, that most Junior developers were familiar only with Spring, ignoring J2EE altogether. While that didn't pose a hurdle for being hired, it still looked off in that J2EE, and its later incarnation Jakarta, are an integral part of the Java ecosystem, and ignoring that part while completely living in the Spring world didn't paint the full picture.

This gave rise to further misconceptions regarding J2EE/Java EE/Jakarta -  outdated, complex, or only used in Enterprise environments. While this might have been the case in the past, but it doesn't hold true nowadays as you'll discover by reading on.

Nevertheless, the fact is that Spring does use parts of the Jakarta specification, for instance in JPA, hence devs actually utilize the specs under the covers without having a clear understanding of the origin of the technology. This impedes them from being more efficient in their work.

The talk goes to compare the two technologies, offering a great historical rundown on the matter, and concludes by pondering whether this competition was a war after all.

I'll make a high level summary of the talk, enriching it with personal commentary.

So let's take it from the beginning, starting with Spring's introduction to the Java world back in 2003 with version 1.0.

Spring was invented exactly due to J2EE's issues, mainly with EJB, and was quickly heralded as "what J2EE should have been". It sported a better and consistent programming model, loose coupling and underneath the covers employed the proxy design pattern by which it was creating proxy classes that made heavy use of Reflection.

The war had begun. . .

J2EE fought back with Java EE 5 and EJB 3, RIP J2EE. This new version would bring loose coupling too, as well as the use of Annotations and easier integration particularly with Web applications. So EJB3+Web apps paved the way to the CDI spec.

Although it was the answer to Spring Core, CDI came a bit too late, plus it was just an engine without an ecosystem. Then came the Microservices era, when the Spring Boot magic was invented, back in 2014, to target Microservices amongst other uses. The problem: it was strongly opiniated. Then Java EE became Jakarta EE.

The Eclipse Foundation, in answer to Spring Boot, launched Microprofile in 2021 providing specs for making Microservices. Microprofile drew heavily on four Jakarta EE specifications – Jakarta RESTful Web Services, Jakarta Contexts and Dependency Injection, Jakarta JSON Binding, and Jakarta JSON Processing. The war had now shifted between Microprofile and Spring Boot.

Talking about specs, Jakarta EE 10 is the first release that updates the core specifications since Java EE 8 and underpins many infrastructure technologies:

• Apache Tomcat implements four Jakarta EE specifications — Jakarta Servlet, Jakarta Standard Tag Library, Jakarta WebSocket, and Jakarta Authentication.
  
  
• Spring Boot embeds Apache Tomcat, Eclipse Jetty, or Undertow as a runtime.
  
  
• Eclipse Jetty implements the Jakarta Servlet, Jakarta Server Pages, and Jakarta WebSocket specifications.

For Spring that means taking advantage of the new APIs, access to the latest web containers such as Tomcat 10.1, Jetty 11, Undertow 2.3 and the latest persistence providers such as Hibernate ORM 6.1. Ah, yes and migrating from javax to the jakarta namespace.

Not far ahead, the war moved onto the Cloud era, the current era.
Jakarta announced its presence here too by introducing a new profile. A profile is a configuration of the Jakarta EE platform targeted at a specific class of applications. Until now Jakarta EE had two profiles - Full and Web.

The Web Profile comprises of a set of specifications focused on typical Web Applications involving components such as REST, Servlet, JSON, JPA, Security, Faces. The Full profile comprises of a set of specifications focused on WebServices, Messaging, EJB and more.

For the purposes of the Cloud, a new profile is now being introduced, the Core Profile. It is a profile specifically aimed at lightweight runtimes that are optimized for running cloud-native Java Microservices with a focus on enabling implementations that make use of ahead-of-time compilation.

There was also a new player in town, Quarkus which implemented Microprofile but was easy to pick up if one was used to doing work with Spring Boot, since it came AOT-ready. Quarkus was perfect for running operations on the Cloud since it avoided the heavy use of Reflection that Spring Boot was utilizing at runtime.

Spring's answer to that was Spring native, the cloud native framework which could work its magic not at runtime but emitting static code utilizing AOT as well.

So this is where we are currently are in this age-old war. In wrapping up the conversation, however, Antoine questioned whether this is really a War we are talking about. In the end, the fierce competition between Spring and Jakarta profited the whole Java ecosystem; they brought it up to par, and even beyond, with ecosystems that had capitalized on Java's late entry into the Microservices and Cloud native era.

More Information

Has the J2EE vs Spring Infinity War reached an End Game? A short history of Java for the enterprise

Related Articles

Quarkus 2.7.1 Released - Why Quarkus?

A New Era For Spring

Jakarta EE 10 - A New Era For Java On The Cloud

Microsoft Goes All Out On Java

To be informed about new articles on I Programmer, sign up for our weekly newsletter, subscribe to the RSS feed and follow us on Twitter, Facebook or Linkedin.

Comments

Make a Comment or View Existing Comments Using Disqus

or email your comment to: comments@i-programmer.info