Jakarta EE 11 is certified, modern, and running on Open Liberty, WildFly, Payara, and GlassFish. It is past time to challenge the assumption that Spring is always the default.

Let’s be direct about something. If you ask a room full of Java developers which framework to use for a new enterprise service, the answer will almost universally be Spring Boot — usually without much deliberation. It is, at this point, almost reflexive. Spring Boot is fast to set up, well-documented, backed by a huge community, and it works. Nobody has ever been fired for choosing Spring Boot.

However, reflexes are not the same as reasoning. And in June 2025, Jakarta EE 11 reached general availability, fully certified on IBM Open Liberty, Red Hat WildFly, Payara Server Community, and Eclipse GlassFish — the four largest open-source application server runtimes in the ecosystem. It ships with a brand-new data access specification, first-class virtual thread support, CDI 4.1 as the unified programming model, and a modernized testing stack. At the same time, for the first time in eight years of Jakarta EE developer surveys, more developers reported using Jakarta EE (58%) than Spring (56%).

None of this means Spring is in trouble. It isn’t. But it does mean the conversation has changed. So let’s have it honestly.

1. What Jakarta EE 11 Actually Is in 2025

Before comparing, it is worth correcting a common misunderstanding. Many developers still picture Jakarta EE as “old Java EE” — heavyweight, XML-heavy, slow to deploy, and requiring a massive application server. That picture is at least a decade out of date, and Jakarta EE 11 makes the gap even wider.

Released in three stages — Core Profile in December 2024, Web Profile in March 2025, and the full Platform in June 2025 — Jakarta EE 11 introduces one entirely new specification and updates sixteen others. The platform now requires Java 17 as a minimum and delivers first-class support for Java 21, including virtual threads via the updated Concurrency specification. Moreover, the move to CDI 4.1 as the sole component model (retiring the old Managed Beans spec) finally gives Jakarta EE the unified, modern dependency injection story it previously lacked.

The Jakarta Data Specification: The Headline Feature

The most significant arrival in Jakarta EE 11 is Jakarta Data 1.0 — a brand-new specification that standardizes the repository pattern for data access. If that sounds familiar, it should: it is the same pattern that Spring Data popularized years ago, now built into the platform as a standard API. With Jakarta Data, you define a repository interface and the container implements it, dramatically reducing boilerplate compared to the DAO patterns that characterized older Java EE applications.

Jakarta Data in Plain Terms

Instead of writing implementation classes for every data access operation, you declare a typed repository interface. The runtime generates the implementation. Current implementations include Hibernate ORM 6.6, Eclipse JNoSQL 1.1.4, and the Open Liberty container itself — meaning you are not locked into a single ORM vendor.

Virtual Threads: First-Class Support, Finally

Jakarta EE 11 integrates Java 21’s virtual threads directly into the Jakarta Concurrency 3.1 specification. You can now configure a managed executor to use virtual threads simply by setting a boolean attribute in the @ManagedExecutorDefinition annotation. This is not an experimental workaround; it is a first-class, portable, spec-defined feature. Furthermore, as of Java 24, the main risk factors for virtual threads — synchronized block pinning and other edge cases — have been largely resolved, making this the right moment to lean in.

Everything Else That Changed

Beyond Jakarta Data and virtual threads, the platform cleaned house considerably. Managed Beans are gone, replaced entirely by CDI. All references to the Java SecurityManager (deprecated in JDK 17, permanently disabled in JDK 24) have been removed. Jakarta Persistence 3.2 adds SQL-like features including union, intersect, except, and cast, plus full Java Records support as @Embeddable types. The TCK was migrated from Apache Ant and TestHarness to JUnit 5 and Maven — which might sound like internal plumbing but meaningfully lowers the barrier for vendors to achieve certification.

Jakarta EE 11 — Key Specification Updates at a Glance

2. The Honest Side-by-Side

To be genuinely useful, a comparison between Jakarta EE 11 and Spring has to go beyond bullet points. Both platforms are comprehensive; neither is categorically superior. The question worth asking instead is: under which conditions does one make more sense than the other?

One nuance is worth adding here: the relationship between Jakarta EE and Spring is not actually adversarial under the hood. As InfoQ’s Jakarta EE 11 overview correctly points out, Spring itself depends on Jakarta EE specifications — Jakarta Servlet, Jakarta Persistence, Jakarta Transactions, and others. When you use Spring, you are already using Jakarta EE whether you realize it or not. The question, therefore, is whether you want the Jakarta EE container to handle those concerns directly, or whether you want Spring’s opinionated abstractions layered on top.

3. The Four Certified Runtimes: What You Get With Each

One of Jakarta EE’s structural advantages is that no single vendor owns the runtime. If Open Liberty’s pricing model changes, you can move to WildFly. If Payara’s roadmap diverges from yours, GlassFish is there. That kind of genuine portability is rare in the enterprise software space. Here is a quick overview of what each certified runtime brings to Jakarta EE 11.

Full Platform certification (covering all 30 specifications) is still pending for several vendors at the time of writing. However, the Core Profile — seven specifications targeting microservices and AOT compilation — and the Web Profile — 23 specifications covering the vast majority of practical web application development — are already certified and production-ready.

4. Jakarta Query: The Next Piece Already Taking Shape

While Jakarta EE 11 is the current story, it is genuinely worth understanding where the platform is heading, because the roadmap directly addresses one of the most legitimate criticisms of Jakarta EE: fragmented query languages. Until now, Jakarta Persistence used JPQL, while Jakarta Data used its own JDQL, and NoSQL databases used entirely separate APIs. Each required different mental models for essentially the same kind of query logic.

“Jakarta Query has the potential to be the most breaking change in Jakarta EE 12, just as Jakarta Data was the defining innovation of Jakarta EE 11. A single, unified query language that bridges relational and non-relational databases is no small step.”— Otávio Santana, Jakarta EE contributor & Eclipse JNoSQL lead, DZone September 2025

Jakarta Query 1.0, planned for Jakarta EE 12 (targeted GA July 2026), defines a single object-oriented query language — the Jakarta Common Query Language (JCQL) — that works across Jakarta Persistence, Jakarta Data, and Jakarta NoSQL. It extracts the common subset of JPQL and JDQL into one place, making string-based and restriction-based queries complementary tools within the same framework rather than competing paradigms. Gavin King, the creator of Hibernate and a driving force behind both Persistence and Data specs, is leading this work, which gives it significant credibility. The Milestone 2 release in January 2026 already shows CDI 5.0, Jakarta Persistence 4.0, and Jakarta Validation 4.0 aligning around this unified model.

Targeted for H1 2026, Jakarta EE 12 will require Java 21 as a baseline and support Java 25 at runtime. Key new specs include Jakarta Query 1.0, Jakarta NoSQL 1.1, and Jakarta MVC 3.1. Work is also underway on Jakarta Agentic AI — a vendor-neutral API set for building and deploying AI agents on enterprise Java. The community is already calling EE 12 the “Data Age” release.

5. When Jakarta EE Is the Right Call

Spring Boot is genuinely excellent for a wide range of scenarios, and nothing in this article argues otherwise. However, there are specific situations where defaulting to Jakarta EE instead is not just defensible — it is the better engineering decision. Let’s go through them clearly.

1. Vendor Neutrality Is a Contractual or Regulatory Requirement

Government projects, financial institutions, and healthcare systems in many jurisdictions require that software be portable across vendors and not tied to any single company’s proprietary APIs. Jakarta EE is governed by the Eclipse Foundation — an independent non-profit — and the specifications are developed through a multi-vendor process. Spring, by contrast, is controlled by Broadcom following its acquisition of VMware. Its APIs are proprietary to the Spring Framework, and while the framework is open source, the direction is set by a single corporate owner. For procurement officers and compliance teams, that distinction is not trivial.

2. Long-Lived Systems That Outlast Frameworks

Enterprise systems in banking, logistics, and government often have twenty-year lifespans. When a system runs that long, the framework you chose at inception will inevitably go through ownership changes, license updates, deprecation cycles, and breaking upgrades. Jakarta EE’s specification-first model means that your code is written against a standardized API, not a vendor’s proprietary abstraction. If WildFly is eventually discontinued, your application can run on Open Liberty or Payara without rewriting the business logic. That portability has real financial value over a decade-long maintenance window.

3. You Are Already on a Jakarta EE Server

This one is practical and often overlooked. If your organization is running Open Liberty or WildFly for existing applications, adding Spring Boot creates a second runtime footprint, a second security patching cadence, and a second set of operational skills your DevOps team needs to maintain. Starting a new service using the Jakarta EE APIs your infrastructure already supports is operationally simpler and cheaper than it looks on a feature comparison chart.

4. The Broadcom Risk Is Real for Large Enterprises

Since Broadcom’s acquisition of VMware, the enterprise Java community has watched VMware’s enterprise customers absorb significant licensing price increases. While Broadcom has stated publicly that Spring Boot will remain open source, the track record of commercial acquirers changing licensing terms for adjacent products is not reassuring. As a result, several large enterprises began evaluating Jakarta EE as a strategic hedge — not because Spring Boot had failed them, but because they preferred not to be in a position where a future Broadcom pricing decision could strand their codebase.

Framework Preference by Scenario (2025 Developer Survey Context)

6. When Spring Is Still the Right Call

Equally, there are scenarios where Spring Boot remains the more pragmatic choice — and saying otherwise would be dishonest.

Speed of development on greenfield projects: Spring Boot’s convention-over-configuration approach, its Initializr scaffolding, and its embedded server model genuinely do reduce time to first deployable artifact. A 2025 Baeldung benchmark found Spring Boot starts up 35–40% faster than comparable Jakarta EE deployments in containerized environments — a meaningful advantage in microservices architectures where horizontal scaling and frequent restarts are common.

Ecosystem breadth: Spring’s ecosystem — Spring Data, Spring Security, Spring Cloud, Spring AI, Spring Batch, Spring Integration — is unmatched in scope. If you need tight integrations with Kafka, Redis, AWS, Kubernetes health checks, or the growing family of AI/LLM libraries, Spring has first-party support for all of them today. Jakarta EE, while catching up rapidly, does not yet match that breadth.

Talent availability: The Stack Overflow Developer Survey 2025 found that 47% of developers feel most confident using Spring Boot for modern web applications, versus 18% preferring Jakarta EE. Hiring is easier. Onboarding is faster. Community answers on Stack Overflow are more plentiful. These are real operational factors.

This article is not arguing that Spring Boot is bad or overrated. It is arguing that the decision deserves actual deliberation rather than reflex. For many teams and many projects, Spring Boot is genuinely the right choice. The goal is to make sure Jakarta EE 11 gets a fair seat at the table during that conversation.

7. Verify the Certifications Yourself

If you want to check which runtimes are currently certified for Jakarta EE 11 — or any other Jakarta EE version — the Eclipse Foundation maintains an official compatibility list. The page is updated continuously as new vendors complete the TCK process. The following shell command will fetch and display the latest compatibility entries if you have curl installed on Linux or macOS:

Check the official Jakarta EE compatibility page (requires curl — standard on macOS and most Linux distributions):

curl -s "https://jakarta.ee/compatibility/download/" | grep -o 'Jakarta EE [0-9]*[^"]*' | sort -u

Alternatively, simply navigate to jakarta.ee/compatibility/download/ in your browser. There you will find the full, up-to-date list of certified implementations organized by profile and version.

To check if you already have a Jakarta EE 11 compatible runtime installed locally (works with any JDK-based server):

java -version
# Then check your server version separately, e.g. for WildFly:
# ./standalone.sh --version
# For Open Liberty:
# ./bin/server version

Runtime Check

The three commands above require only a standard JDK and the respective runtime. No special dependencies. java -version works on any OS; the server-specific commands run from the server’s installation directory on Linux, macOS, or Windows.

8. Jakarta EE 11 Specifications: What Is Standard, What Spring Reimplements

One of the most important points in this debate is that many Spring features are built on top of Jakarta EE specifications. The table below maps key capabilities to whether they exist as Jakarta EE standards, as Spring’s own abstractions, or as both.

9. What We Have Learned

The honest summary is this: the “just use Spring” assumption was reasonable for most of the 2010s. Jakarta EE (then Java EE) was slow-moving, XML-heavy, and out of step with the cloud-native world. Spring Boot filled that gap brilliantly, and it deserves every bit of the market position it holds.

However, that rationale is now at least five years out of date. Jakarta EE 11 ships with CDI 4.1 as a unified programming model, Jakarta Data 1.0 as a standardized repository pattern, first-class virtual thread support, Java Records integration, and a modernized TCK. It is certified on four actively maintained runtimes. And for the first time, more developers report using Jakarta EE than Spring — a milestone that reflects genuine ecosystem momentum, not just legacy inertia.

Furthermore, the governance picture has shifted. The Eclipse Foundation is an independent non-profit. Broadcom is a commercial acquirer with a track record of license restructuring. For large enterprises planning decade-long system lifespans, that difference is not academic.

None of this makes Spring Boot the wrong choice. For greenfield microservices, for teams that need Spring’s ecosystem breadth, for projects where startup speed and cloud-native tooling are the primary concerns — Spring remains excellent. But for regulated industries, for teams already on Jakarta EE runtimes, for organizations that value vendor neutrality as a hard requirement, and for projects where long-term portability matters more than short-term development speed, Jakarta EE 11 deserves to be evaluated on its current merits — not on a ten-year-old reputation.

The right question is not “Spring or Jakarta EE?” It is “what are we actually optimizing for?” Answer that honestly, and the right choice usually becomes clear.