Every few years, someone publishes a think piece declaring enterprise Java dead. And every few years, the global Java developer population grows, enterprises double down on their Java investments, and the ecosystem ships another major release that addresses exactly what critics said was missing. That pattern continues — but this time with a genuine twist.
Jakarta EE, the open-source successor to Java EE, has undergone a real transformation. What was once a slow-moving, committee-driven platform controlled by a single vendor is now an open, vendor-neutral ecosystem shipping meaningful updates on a predictable cadence. Jakarta EE 10, MicroProfile 6.0, and runtimes like Quarkus and Open Liberty have made enterprise Java competitive with anything in the cloud-native landscape.
This article covers what has actually changed, what Jakarta EE 10 brings to the table, how it compares to Spring Boot today, and why organizations running mission-critical systems on Java should pay attention. Whether you are maintaining a legacy Java EE system or evaluating Jakarta EE for a new project, this is the practical assessment you need.
A Brief History: From Java EE to Jakarta EE
Understanding where Jakarta EE stands today requires understanding how it got here. Java EE (Java Platform, Enterprise Edition) was the dominant enterprise application framework for nearly two decades, governed by Sun Microsystems and later Oracle through the Java Community Process (JCP).
The problem was pace. While Spring Boot and Node.js moved fast, Java EE releases slowed to a crawl. Java EE 8, released in September 2017, was widely seen as too little, too late. Oracle had effectively deprioritized the platform, and the enterprise Java community was frustrated.
In 2017, Oracle transferred Java EE to the Eclipse Foundation, and the platform was reborn as Jakarta EE. The transition was not seamless — the forced namespace change from javax.* to jakarta.* created real migration pain — but it accomplished something critical: it put enterprise Java's future in the hands of the community rather than a single corporation.
Since then, the trajectory has been upward. Jakarta EE 9 and 9.1 handled the namespace transition. And Jakarta EE 10, released in September 2022, delivered the first wave of genuine new features under Eclipse governance — one that directly addresses the cloud-native, developer-productivity, and modernization concerns that drove many teams toward Spring Boot in the first place.
What Jakarta EE 10 Brings to the Table
Jakarta EE 10 is not an incremental patch. It is a substantive release that modernizes the platform across multiple specifications. Here are the changes that matter most for teams building or maintaining enterprise applications.
Java SE 11 as the minimum, Java SE 17 as the recommended baseline
Jakarta EE 10 requires Java SE 11 as the minimum runtime and targets Java SE 17 as the recommended version. This is significant because it means the platform now embraces modern Java language features — records, sealed classes, pattern matching for instanceof, text blocks, and switch expressions. Enterprise applications no longer need to be written in a style that feels a decade old. With Java 21 on the horizon for September, the platform is well positioned to benefit from virtual threads and structured concurrency in future releases.
CDI Lite and build-time optimization
Contexts and Dependency Injection (CDI) has always been one of Jakarta EE's strongest specifications, but its reliance on runtime reflection made it a poor fit for ahead-of-time (AOT) compilation and GraalVM native images. CDI Lite, introduced in Jakarta EE 10, provides a build-time-oriented subset of CDI that supports native compilation without sacrificing the dependency injection model that enterprise developers rely on.
This matters because it closes the startup-time and memory-footprint gap between Jakarta EE and frameworks specifically designed for cloud-native deployment. Applications using CDI Lite can compile to native executables that start in milliseconds and consume a fraction of the memory of traditional application-server deployments.
Jakarta REST (JAX-RS) improvements
The Jakarta REST specification in version 3.1 includes enhanced support for Server-Sent Events, improved multipart form-data handling, and better alignment with modern HTTP semantics. The API is also more consistent with Java SE's CompletionStage for reactive-style programming, making it straightforward to build non-blocking REST endpoints without leaving the Jakarta EE ecosystem.
Jakarta Persistence (JPA) updates
Jakarta Persistence 3.1 adds support for UUID-based primary keys, additional numeric functions in JPQL, improved programmatic query building via the Criteria API, and better integration with modern Java types. These are incremental but practical improvements that reduce boilerplate and align the persistence layer with how Java developers write code today.
Jakarta Security enhancements
The security specification now includes built-in support for OpenID Connect, making it possible to integrate with identity providers like Keycloak, Auth0, and Azure AD using standard APIs rather than vendor-specific extensions. For teams building multi-tenant SaaS applications, this is a meaningful reduction in custom security plumbing.
Core Profile for lightweight microservices
Jakarta EE 10 introduced the Core Profile, a new platform profile specifically designed for microservices and cloud-native applications. It includes a focused subset of specifications — CDI Lite, Jakarta REST, JSON-P, and JSON-B — providing a lightweight entry point for teams that do not need the full platform. If you have used Spring Boot's minimal approach, the Core Profile is Jakarta EE's answer to the same need for lean, focused service development.
MicroProfile: The Cloud-Native Extension
Jakarta EE provides the core enterprise APIs. MicroProfile extends them for distributed, cloud-native systems. Understanding the relationship between the two is essential for any team evaluating enterprise Java today.
MicroProfile was created in 2016 as a response to Java EE's slow pace — a lightweight set of specifications for building microservices with enterprise Java. MicroProfile 6.0, the current release, aligns with Jakarta EE 10 and uses the jakarta.* namespace. Most modern runtimes support both.
Key MicroProfile specifications
- MicroProfile Config: Externalized configuration that works with environment variables, system properties, and custom config sources. Essential for twelve-factor applications deployed across multiple environments.
- MicroProfile Fault Tolerance: Retry policies, circuit breakers, bulkheads, fallbacks, and timeouts — the patterns you need to build resilient distributed systems. These are declarative annotations, not library-level code you wire manually.
- MicroProfile Health: Standardized health check endpoints that integrate with Kubernetes liveness and readiness probes. No custom controller needed.
- MicroProfile Metrics and Telemetry: Application-level metrics and distributed tracing integration. MicroProfile Telemetry aligns with OpenTelemetry, the emerging industry standard for observability.
- MicroProfile JWT Authentication: Token-based authentication for microservices using JSON Web Tokens. Standardizes how services validate and propagate identity in a distributed architecture.
- MicroProfile OpenAPI: Generates OpenAPI documentation from your JAX-RS endpoints automatically. Keeps your API documentation in sync with your code without manual specification maintenance.
The combination of Jakarta EE core APIs with MicroProfile extensions gives you a standards-based stack that covers everything from persistence and messaging to fault tolerance and observability — without locking you into a single vendor or runtime.
Jakarta EE vs. Spring Boot: An Honest Comparison
This is the question every Java architect faces. Spring Boot dominates mindshare, and for good reason — it is an excellent framework with a massive ecosystem. But the comparison is more nuanced than "Spring Boot is better" or "Jakarta EE is better." The right choice depends on your constraints, team, and long-term strategy.
| Factor | Jakarta EE 10 | Spring Boot 3.x |
|---|---|---|
| Governance | Open specification, Eclipse Foundation | VMware (single vendor) |
| Runtime portability | Multiple runtimes (Open Liberty, WildFly, Payara, Quarkus, GlassFish) | Embedded Tomcat/Jetty/Undertow (Spring-specific) |
| Cloud-native support | Strong via MicroProfile + Quarkus | Excellent (Spring Cloud ecosystem) |
| Developer productivity | Improved with CDI Lite, Core Profile; still more verbose | Excellent (auto-configuration, starters, Boot conventions) |
| Native compilation | Quarkus (excellent), Open Liberty (good) | Spring Native / GraalVM (maturing rapidly) |
| Ecosystem size | Smaller but growing | Largest in Java ecosystem |
| Enterprise adoption | Banks, government, insurance, telcos | Broad across all sectors |
| Long-term stability | Standards-backed, multi-vendor | Dependent on VMware's strategy |
| Learning curve | Steeper for newcomers | Easier due to convention-over-configuration |
| Migration path from Java EE | Direct (namespace change) | Requires rewrite of server/DI layer |
The debate between Jakarta EE and Spring Boot is not about which framework is technically superior. It is about which set of trade-offs aligns with your organization's needs. For vendor independence and long-term standards stability, Jakarta EE is the stronger choice. For rapid development velocity and ecosystem breadth, Spring Boot still leads. Many enterprises use both — and that is often the right answer.
When Jakarta EE is the right choice
- Vendor portability matters: Your organization requires the ability to switch application servers or cloud providers without rewriting application code. This is common in government, defense, and regulated industries.
- You have existing Java EE investments: Migrating a large Java EE codebase to Jakarta EE is fundamentally a namespace change. Migrating to Spring Boot is a rewrite. If you have hundreds of thousands of lines of Java EE code, Jakarta EE is the natural evolution path.
- Standards-based procurement: Some enterprise procurement processes require standards-based technology stacks. Jakarta EE specifications provide the formal standards that procurement teams need.
- Long-term stability over rapid innovation: If your application will run for 10 to 15 years, a multi-vendor standard is a safer bet than a single-vendor framework, regardless of how popular that framework is today.
When Spring Boot is the right choice
- Speed of development is the priority: Spring Boot's auto-configuration, extensive starter ecosystem, and opinionated defaults get you from zero to production faster than any Jakarta EE runtime.
- Greenfield microservices: For new, small services that need to ship quickly and iterate fast, Spring Boot's developer experience is hard to beat.
- Team familiarity: If your team already knows Spring, the switching cost to Jakarta EE rarely justifies the benefits unless you have a specific driver like vendor portability.
- Ecosystem breadth: Spring's integration ecosystem — Spring Security, Spring Data, Spring Cloud, Spring Batch — covers more use cases out of the box than Jakarta EE plus MicroProfile combined.
Migrating from Java EE to Jakarta EE
For organizations running Java EE applications — and there are millions of them worldwide — migration to Jakarta EE is not optional in the long term. Java EE 8 is the end of the line under Oracle's stewardship, and application servers are converging on Jakarta EE. The question is when and how to migrate, not whether.
The namespace problem
The single biggest migration hurdle is the package namespace change from javax.* to jakarta.*. Every import statement, every annotation, every API reference that uses javax.servlet, javax.persistence, javax.inject, or any other Java EE package must be updated. For a large codebase, this can mean tens of thousands of changes.
The good news is that this is a mechanical change, and tooling exists to automate most of it. The Eclipse Transformer, OpenRewrite recipes, and IDE refactoring tools can handle the bulk of the namespace conversion. The real complexity lies not in your code but in your dependencies — every third-party library that references javax.* packages needs a Jakarta-compatible version.
A practical migration strategy
- Audit your dependencies: Before touching any code, inventory every library and framework your application uses. Identify which ones have Jakarta-compatible versions and which ones need alternatives. This step alone can take weeks for large applications and is where teams building a legacy modernization playbook should start.
- Update your runtime: Move to a Jakarta EE 10-compatible application server. If you are on WebLogic, WebSphere, or JBoss EAP, check your vendor's Jakarta EE compatibility timeline. Many teams use this as an opportunity to evaluate lighter runtimes like Open Liberty or Quarkus.
- Run the namespace transformation: Use the Eclipse Transformer to convert your source code, bytecode, and configuration files. Run your full test suite after transformation and fix any issues the automated tools missed.
- Address breaking changes: Beyond the namespace change, Jakarta EE 10 removed some deprecated APIs and changed default behaviors. Review the migration guides for your specific specifications — Jakarta Faces, Jakarta Servlet, and Jakarta Security have the most significant behavioral changes.
- Modernize incrementally: Migration does not mean you have to adopt every new feature at once. Get your application running on Jakarta EE first, then selectively adopt new capabilities like CDI Lite, the Core Profile, or MicroProfile specifications based on where they deliver the most value.
The migration effort scales directly with codebase size and dependency complexity. Small applications (under 50,000 lines of code) can typically migrate in one to two sprints. Large enterprise systems with hundreds of modules and dozens of third-party dependencies should plan for two to six months. Either way, the cost of deferring this migration increases with every year — as Java EE-era libraries lose community support and security patches become harder to obtain.
Cloud-Native Jakarta EE: Patterns That Work
The stereotype of Jakarta EE as a monolithic, application-server-heavy platform is outdated. Modern Jakarta EE runtimes — particularly Quarkus and Open Liberty — are designed for exactly the same deployment targets as Spring Boot: containers, Kubernetes, and serverless platforms.
Quarkus: Jakarta EE reimagined for the cloud
Quarkus deserves special attention because it represents the most aggressive rethinking of how Jakarta EE applications should run. Built by Red Hat, Quarkus uses Jakarta EE and MicroProfile specifications as its programming model but implements them with a build-time optimization approach that produces:
- Native executables via GraalVM with startup times under 100 milliseconds
- Container images as small as 20 to 50 megabytes
- Memory consumption of 20 to 30 megabytes at rest — comparable to Go microservices
- Live reload during development that rivals interpreted languages
If your objection to Jakarta EE has been startup time, memory consumption, or deployment size, Quarkus eliminates those objections entirely while keeping the programming model you already know.
Patterns for cloud-native Jakarta EE
- CDI for dependency injection: Use CDI beans with appropriate scopes (@ApplicationScoped, @RequestScoped) instead of heavy EJB session beans. CDI Lite makes this compatible with native compilation.
- JAX-RS for APIs: Build REST APIs with Jakarta REST. Combine with MicroProfile OpenAPI for automatic documentation and MicroProfile JWT for token-based security.
- MicroProfile Config for environment management: Externalize all configuration. Use MicroProfile Config sources that read from environment variables, Kubernetes ConfigMaps, and secrets — the twelve-factor way.
- MicroProfile Fault Tolerance for resilience: Annotate your service calls with @Retry, @CircuitBreaker, @Timeout, and @Fallback. These declarative annotations provide the same resilience patterns that require explicit library integration in Spring.
- MicroProfile Health for orchestration: Implement @Liveness and @Readiness health checks that Kubernetes uses to manage your pod lifecycle. Standard, portable, and zero boilerplate.
- Jakarta Messaging for async communication: Use JMS or the newer Jakarta Messaging APIs for event-driven communication between services. For teams adopting Kafka or similar platforms, MicroProfile Reactive Messaging provides a standard programming model.
Why Enterprises Still Choose Jakarta EE
Despite Spring Boot's dominance in developer mindshare, Jakarta EE continues to be the foundation for a significant portion of the world's enterprise software. The reasons are practical, not nostalgic.
Vendor independence is a real requirement
In regulated industries — banking, healthcare, government, defense — the ability to switch technology vendors without rewriting application code is not a theoretical concern. It is a procurement requirement. Jakarta EE's specification-based approach means an application built on Open Liberty can be deployed on WildFly, Payara, or any other certified runtime. Try doing that with a Spring Boot application — it is technically possible but practically never portable in the same way.
Standards outlive frameworks
Enterprise applications have long lifecycles. A banking core system might run for 15 to 20 years. In that timeframe, frameworks rise and fall, companies get acquired, and open-source projects lose their maintainers. Standards-based specifications governed by a foundation with multiple contributing vendors provide a level of longevity that no single-vendor framework can guarantee.
This is not a hypothetical concern. Broadcom's pending acquisition of VMware — and by extension, Spring — has created genuine uncertainty in the Spring community about the framework's long-term direction and licensing. Jakarta EE's multi-vendor governance model is designed to prevent exactly this kind of single-point-of-failure risk.
The talent pool is larger than you think
Java remains the most widely used enterprise programming language globally. A significant portion of experienced Java developers have Jakarta EE (or Java EE) expertise. For organizations building distributed engineering teams, particularly with talent in South Asia, Eastern Europe, and Latin America, Jakarta EE skills are often easier to find than specialized Spring Cloud or reactive programming expertise.
Migration is cheaper than rewriting
For the millions of Java EE applications in production today, migrating to Jakarta EE is orders of magnitude less expensive than rewriting in Spring Boot, Kotlin, Go, or any other technology. The namespace change is mechanical. The programming model is the same. The deployment model is compatible. When you need to evolve a large Java EE system, the full-cycle development approach of migrating to Jakarta EE while incrementally modernizing is almost always the right answer.
What the Future Looks Like
Jakarta EE's roadmap beyond version 10 focuses on three areas that signal where the platform is heading:
- Tighter integration with MicroProfile: The long-discussed convergence of Jakarta EE and MicroProfile specifications continues. Expect more MicroProfile capabilities to be promoted into the core Jakarta EE platform in future releases, reducing the "which specification set do I need" confusion.
- Better developer experience: The community is working on a Jakarta Data specification to bring repository-pattern data access to the standard platform, along with reducing boilerplate across all specifications, improving annotation-based configuration, and making the platform feel as productive as Spring Boot for common use cases.
- Deeper cloud-native alignment: As enterprise applications move increasingly to Kubernetes and serverless environments, Jakarta EE specifications are evolving to support lightweight deployment models, faster startup times, and lower memory footprints through patterns like the Core Profile and CDI Lite.
The platform is also poised to benefit from Java SE's own evolution. Virtual threads (Project Loom), expected in Java 21 this September, and structured concurrency will have a profound impact on how Jakarta EE applications handle concurrency and resource utilization. Virtual threads alone promise to eliminate the need for reactive programming frameworks in many scenarios, simplifying the programming model dramatically.
Conclusion
Enterprise Java is not just surviving — it is evolving in ways that directly address the criticisms that drove developers toward other platforms. Jakarta EE 10 is a genuinely modern release. MicroProfile makes cloud-native development a first-class citizen. Runtimes like Quarkus have eliminated the performance objections. And the open governance model under the Eclipse Foundation provides the long-term stability that enterprise software demands.
That does not mean Jakarta EE is the right choice for every project. Spring Boot remains the faster path for greenfield microservices. Go and Rust are better choices for performance-critical systems programming. Node.js and Python dominate in specific niches. But for enterprise applications that need vendor portability, standards-based stability, and a clear evolution path from existing Java EE investments, Jakarta EE is the strongest it has ever been.
The practical advice: if you are running Java EE, start planning your Jakarta EE migration now. If you are choosing between Jakarta EE and Spring Boot for a new project, evaluate based on your specific constraints — not on blog posts declaring one framework "dead." And if you are building cloud-native Java applications, look seriously at Quarkus with MicroProfile — it changes the conversation entirely.
At DSi, our Java engineers work across both Jakarta EE and Spring ecosystems, helping teams modernize legacy systems, migrate from Java EE, and build cloud-native enterprise applications. Whether you need to evolve an existing Java EE system or architect a new Jakarta EE platform, our staff augmentation model puts experienced enterprise Java engineers directly on your team.
