Why Spring Matters to Jakarta EE - and Vice Versa

Monopolies are never good for progress. The incentives for innovation are not there when there is no competition. Luckily, the Java ecosystem is extensive and vibrant with many competing and complementary technologies. This article focuses on enterprise Java and will look at the relationship between Spring and Jakarta EE.

History

Spring was created in 2003 as a lightweight alternative to address the complexity of the early versions of the J2EE specifications. Since then J2EE evolved to become Java EE, and then later Jakarta EE. Spring does not implement the Jakarta EE specifications on its own, but integrates with multiple individual specifications and implementations that are developed under Jakarta EE.

Comparison

Spring and Jakarta EE are often compared to each other and viewed as competing technologies. These comparisons often show bias toward one or the other and seldom give a truly objective picture. A more nuanced approach is to view them as complementary to each other, as they serve slightly different purposes.

• Spring is a framework that simplifies application development by offering cohesive modules and projects.
• Jakarta EE on the other hand is a specification, or a set of component specifications, that defines standard APIs for building enterprise applications. 

Technologies

Spring integrates with several of the Jakarta EE specifications and includes implementation of many of them seamlessly in Spring applications. The figure below gives an overview of which Jakarta EE specifications Spring integrates.

Jakarta Servlet is a core component of Spring. Spring Boot embeds a Servlet container in a cloud-friendly way. The default container embedded in an application generated with the Spring Initializr is Apache Tomcat. This can easily be changed to for example Eclipse Jetty, OpenLiberty, Undertow, or other Jakarta Servlet implementations.

The Spring WebSocket API extends the standard API provided by Jakarta WebSocket. The latest Jakarta WebSocket specification provides a standard request upgrade strategy that is used if a Spring WebSocket application is run in a container supporting Jakarta EE 10 or higher, such as Tomcat 10+ and Jetty 12+.

When a Jakarta Concurrency implementation is present, Spring detects this and is able to auto-adapt consistently.

When Spring detects the presence of the Jakarta JSON Binding API, the autoconfiguration will look for an implementation and make it available to the Spring application developer. The suggested implementation for Jakarta JSON Binding in Spring is Eclipse Yasson.

It works the same way for Jakarta Validation. When it is present, it will be automatically configured by Spring by pulling in Hibernate Validator as the implementation. The application developer will then be able to validate that data input complies with rules and limitations.

Most applications store and/or retrieve data in some way or another, and the vast majority of them do so with a relational database. This requires a way of mapping objects to relations. In Spring applications, this is mostly done with Hibernate ORM which is an implementation of Jakarta Persistence. The most popular approach for persisting data in Spring is to use Spring Data JPA. This technology will generate most of the boilerplate Jakarta Persistence code with all the most relevant CRUD methods available automatically. 

Spring Data is an excellent example of Jakarta EE taking inspiration from Spring. Jakarta Data is a new specification that is extensively inspired by Spring Data. This new specification will be a part of the upcoming Jakarta EE 11 release. Basing Jakarta Data on a proven technology such as Spring Data is an example of the code-first approach for developing specification under Jakarta EE at Eclipse Foundation.

 Spring Messaging provides a simplified use of the Jakarta Messaging APIs by using their template approach as JmsTemplate. Spring also offers a higher level messaging abstraction, so the developers do not need to work directly with the Jakarta Messaging APIs.

Transaction management in Spring is offered consistently throughout the framework across different transaction APIs with support for declarative transaction management as well as a simple programmatic API to handle complex transactions with, for example, Jakarta Transactions. 

Spring also supports the Jakarta Dependency Injection specification that was originally defined in JSR 330. This JSR was proposed and developed among others by developers of Spring Framework. Together with the support for Jakarta Annotations, this allows application developers to use these interchangeably with the Spring-specific mechanisms for dependency injection provided by Spring itself.

The Jakarta EE 9 Baseline

Spring Framework 6/Spring Boot 3 updated its baseline to Jakarta EE 9, which changed the namespace from javax* to jakarta.* for all specifications. This change certainly was an awakening for Spring developers who weren’t aware of the deep dependency Spring has on Jakarta EE. The migration from earlier versions of Spring includes changing Jakarta EE package names in addition to the Spring-related migration activities. 

Even if the baseline for Spring officially is Jakarta EE 9, many APIs from Jakarta EE 10 are already being pulled in and possible to use. That means that Spring developers that want to benefit the most from the Jakarta EE APIs should look at the newer versions of the specifications that are released. It is also a good idea to keep an eye on features that are planned for upcoming releases as these will be made available for Spring developers more or less automatically when they are picked up by the implementations Spring integrates with.

Summary

Jakarta EE matters to Spring since it provides standards for essential technologies that are embraced by the enterprise Java community with multiple implementations for developers to choose from. 

Spring matters to Jakarta EE because it complements the specifications, provides additional essential features, and helps developers in the evolving ecosystem for enterprise Java applications. It also takes inspiration from proven technologies when developing additions to, or entirely new specifications.

Having both these two approaches available for developers to choose from ensures a vibrant and competitive ecosystem for enterprise Java and cloud native Java development.