For teams building enterprise Java applications, the choice between Jakarta EE (formerly Java EE) and Spring is one of the more consequential architecture decisions a team makes, and one of the most frequently re-litigated. Both are mature and production-proven, and both carry reputations that have not kept pace with what each platform looks like today. Judging the current specification instead of a decade-old rumor is what makes the choice defensible.
Two Philosophies, One History
Spring’s first Apache-licensed release shipped in June 2003, built on the ideas Rod Johnson laid out the year before in Expert One-on-One J2EE Design and Development: dependency injection and aspect-oriented programming as a lighter answer to J2EE’s XML-heavy, server-locked complexity. Two decades later, Spring Boot, Spring Cloud, Spring Security, Spring Data, and Spring Batch have grown into the ecosystem most new enterprise Java development defaults to.
Jakarta EE, the standard Spring was originally reacting against, has moved a long way from that J2EE-era reputation. Jakarta EE 10 added a Core Profile purpose-built for cloud-native and MicroProfile-based development, alongside CDI 4.0 and the Jakarta REST 3.1 update to JAX-RS. The old complaint that Java EE is heavyweight is a claim about J2EE, not about the current specification.
How to Choose
Neither platform is universally right for a genuinely greenfield decision. It comes down to what the team actually needs.
| Choose Spring Boot when… | Choose Jakarta EE when… |
|---|---|
| Rapid greenfield development matters more than standards portability | Standards compliance and portability across certified vendors (Open Liberty, WildFly, Payara) are a real requirement, contractual or otherwise |
| The team wants convention-over-configuration and a wide integration ecosystem (databases, brokers, cloud providers) | The industry carries formal certification obligations, common in financial services, defense, and healthcare |
| New microservices are being built from scratch, with no existing investment to protect | The team already has CDI, JAX-RS, and JPA expertise, and an existing application server estate to protect |
| A gentler on-ramp for developers new to enterprise Java is the priority | Long-running, multi-application processes with shared connection pooling and transaction management fit the deployment model better than one JAR per service |
The two ecosystems are converging rather than diverging. Spring increasingly supports Jakarta EE APIs, and MicroProfile brought Spring Boot’s microservice patterns to Jakarta EE. Many organizations run both, Spring Boot for new services and Jakarta EE application servers for the estate that already works, and treat the boundary as an operational decision rather than a permanent allegiance.
When the Existing Estate Doesn’t Need to Choose At All
The table above assumes a genuinely greenfield decision. Most enterprise teams are not greenfield. They already run a Jakarta EE estate, and the pressure they are actually under is a modernization mandate that gets handed down as “rewrite it in Spring Boot.”
That mandate is worth pricing before it gets accepted. Independent analysis of 142 verified Java EE to Spring Boot migration projects puts the median cost at $1.2 million per portfolio over an 18-month timeline, with a 30 percent chance of running over budget or schedule. Most of what that rewrite targets, containers, fast startup, cloud density, is the deployment shape, not the business logic underneath it.
Azul Payara reaches the same deployment shape through a runtime change instead of a rewrite. The existing .war deploys to the Payara version that matches the application’s current namespace and specification unchanged, so the javax to jakarta rewrite a version mismatch would otherwise force never enters the picture.
Rakuten Card has run its credit card processing middleware on Azul Payara since 2017 at 99.9999 percent availability, with no production stoppage, which is the operational argument for staying on a supported Jakarta EE runtime instead of budgeting a portfolio-wide rewrite. Pricing is transparent per-vCore, and the JDK, Azul Core, is a separate Azul product, so the JDK and the application server come from one vendor rather than two.
If AI is the actual reason modernization is on the table, Jakarta EE 11 on Azul Payara Server 7 adds Jakarta Concurrency 3.1 and Jakarta Data 1.0, the two specifications that bring container-managed virtual threads and vector storage inside the existing CDI container, with no separate Python service to stand up. That capability arrives with the step-up to Payara 7; it is not a day-one claim on Payara 5 or 6.
The standards-portability argument for Jakarta EE was never only theoretical. It is also the argument for checking whether the runtime underneath the standard is earning its keep.
