Jakarta EE 11: Java 21, Cloud-Native, Enterprise Java

Jakarta EE 11 and Java 21: Is Enterprise Java Cool Again?

John: Hello everyone, and welcome back to the blog. Today, we’re diving into a topic that’s been a cornerstone of the software industry for decades, yet is currently experiencing a significant renaissance: Enterprise Java. Specifically, we’re looking at the brand new Jakarta EE 11 release and its powerful synergy with Java 21. It’s a major step forward, aiming to modernize a platform known for its robustness and scale.

Lila: Hi John! I’m excited to unpack this. I have to admit, when I hear “Enterprise Java,” my mind immediately goes to old-school, complex systems. A lot of developers from my generation might think the same. Is this release just putting a new coat of paint on an old machine, or is this something genuinely new and exciting for building modern, cloud-native applications?

John: That’s the million-dollar question, Lila, and precisely what we’re here to explore. The short answer is that this is far more than a simple paint job. The Eclipse Foundation, which now stewards the platform, is making a concerted effort to shed that legacy complexity. Jakarta EE 11 focuses heavily on two things modern developers care about most: developer productivity and performance, especially in a cloud context.

What Exactly Is Jakarta EE? A Quick Refresher

Lila: Okay, let’s start with the basics for anyone who’s new to this. When we say Jakarta EE, what are we talking about? Is it a framework? A library? A server?

John: It’s a great clarifying question. Jakarta EE (Enterprise Edition) is fundamentally a set of specifications. Think of it as a blueprint or a contract. It defines a collection of APIs (Application Programming Interfaces) for building large-scale, multi-tiered, and reliable server-side applications. It’s the successor to what was formerly known as Java EE (Java Platform, Enterprise Edition), which was managed by Sun Microsystems and later Oracle.

Lila: So it’s not something you can just download and run by itself? You need something that *implements* that blueprint, right?

John: Exactly. You need a “Jakarta EE compatible application server.” These are the concrete products that bring the specifications to life. Well-known examples include Eclipse GlassFish, Red Hat’s WildFly, and IBM’s Open Liberty. When you write your application code against the Jakarta EE APIs, the promise is that it can run on any of these compatible servers. This prevents vendor lock-in, which has always been a core tenet of the platform.

Supply Details: Who’s Behind Jakarta EE 11?

Lila: You mentioned the Eclipse Foundation took over from Oracle. Why did that happen, and who are the major players pushing this new release forward?

John: The transition happened back in 2017. Oracle, while still the steward of standard Java (Java SE), decided to move Java EE to an open-source foundation to foster more community-driven innovation. They chose the Eclipse Foundation, a well-respected neutral ground for open-source projects. This move led to the rebranding from “Java EE” to “Jakarta EE” due to trademark reasons. It also involved a significant technical change: the API package names moved from `javax.*` to `jakarta.*`, which was a major undertaking in the Jakarta EE 9 release.

Lila: So it’s a fully open, collaborative effort now. The provided info mentions big names like Microsoft, Red Hat, and IBM are involved. What’s their role?

John: They are key members of the Jakarta EE Working Group. Their involvement is crucial.

IBM and Red Hat are deeply invested. They develop their own compatible runtimes, Open Liberty and WildFly, respectively. Their engineers contribute code, shape the new specifications, and ensure the platform meets the needs of their enterprise customers.
Oracle is still involved, contributing to the specifications and ensuring alignment with the core Java platform.
Microsoft’s involvement is particularly interesting. They are working to ensure that Jakarta EE 11 applications run smoothly on their Azure cloud platform, including on services like Azure Kubernetes Service and App Service. This is a massive vote of confidence, signaling that Jakarta EE is a first-class citizen in the modern cloud ecosystem.

This collaboration is what gives the platform its strength and ensures that certified products are truly compatible and ready for production.

Lila: And speaking of certified products, what’s available for Jakarta EE 11 right now?

John: The list is growing. Upon release, Eclipse GlassFish was certified for the full Platform specification. For the more lightweight profiles, we have several certified products already:

For the Core Profile: IBM Open Liberty, Red Hat WildFly, Payara Platform Community Edition, and the Fujitsu Software Enterprise Application Platform.
For the Web Profile: Eclipse GlassFish has also been certified.

The expectation is that this list will expand rapidly as other vendors update and certify their products.

The Technical Mechanism: What’s New Under the Hood?

Lila: Okay, let’s get into the code. You said the focus is on productivity and performance. What are the key technical features in Jakarta EE 11 that deliver on that promise? I’ve heard a lot of buzz around “Jakarta Data” and “Virtual Threads.”

John: You’ve hit on the two biggest headliners. Let’s start with Jakarta Data. For years, a common criticism of Java EE was the verbosity of its data access layer, JPA (Java Persistence API). While powerful, it often required writing a lot of boilerplate code for simple operations.

Lila: You mean writing the same `find`, `save`, `delete` methods over and over again for different entities?

John: Precisely. Jakarta Data introduces a standardized “repository pattern,” which developers familiar with frameworks like Spring Data will recognize immediately. Essentially, you define an interface for your data entity, extend a base repository like `CrudRepository`, and the platform provides the implementation for all the basic CRUD (Create, Read, Update, Delete) operations automatically. This drastically reduces boilerplate, minimizes errors, and lets developers focus on business logic rather than persistence plumbing.

Lila: That sounds like a huge quality-of-life improvement. So what about the other headliner, the support for Java 21 and its Virtual Threads?

John: This is arguably the most significant performance enhancement. Traditionally, in Java, each incoming request on a server would be handled by a dedicated operating system thread. These threads are heavyweight and limited in number. If you have thousands of concurrent users, you can quickly run out of threads, leading to performance bottlenecks.

Lila: So that’s why we talk about “thread pools” and tuning them, right?

John: Yes. But Java 21’s Virtual Threads, a feature from Project Loom, changes the game. Virtual Threads are lightweight threads managed by the Java Virtual Machine (JVM), not the operating system. You can create millions of them without breaking a sweat. For a Jakarta EE application, this means you can handle a massive number of concurrent requests with very little overhead. An application that used to choke under a few thousand users can now potentially scale to tens of thousands with minimal code changes. Jakarta EE 11’s concurrency specifications have been updated to embrace and leverage this, which is a massive win for scalability.

Other Key Technical Enhancements

Lila: Beyond those two, what other changes should developers be aware of?

John: There are several important “under the hood” modernizations.

Modernized TCK: The TCK (Technology Compatibility Kit) is the test suite that vendors must pass to certify their products as Jakarta EE compatible. It has been modernized to use JUnit 5 and Maven. This makes it easier for the community to add new tests and for vendors to run them, ultimately improving compatibility and accelerating platform evolution.
CDI Enhancements: CDI (Contexts and Dependency Injection) is the glue that holds Jakarta EE applications together. The latest version, CDI 4.1, brings several enhancements, including a new “Lite” mode that allows for build-time discovery of beans, which can improve startup times and reduce memory footprint, perfect for microservices and serverless functions.
Java Records Support: Java 17 introduced Records, which are immutable data carriers that eliminate a ton of boilerplate code for classes that just hold data. Jakarta EE 11 now has broader, more consistent support for using Records throughout its specifications, like in Jakarta REST for JSON payloads, further improving developer productivity.
Deprecations and Removals: Good platform evolution isn’t just about adding things; it’s also about removing old cruft. Jakarta EE 11 formally deprecates older, less-used specifications like Managed Beans (its functionality is better served by CDI). It also removes support for the outdated Java SE Security Manager, paving the way for more modern security practices.

Team, Community, and Getting Involved

Lila: It’s clear this is a community-driven effort. For a developer who’s intrigued by these changes, how can they get involved? Is the community welcoming to newcomers?

John: Absolutely. The move to the Eclipse Foundation was all about opening the doors. The entire process is transparent. Specification documents, discussions, and code development happen on public mailing lists and GitHub repositories. The best place to start is the official Jakarta EE website (jakarta.ee). From there, you can find links to the community calendar, mailing lists, and the GitHub organizations.

Lila: So you can actually read the debates about new features and even propose changes yourself?

John: Yes. You can start small by reporting issues, helping with documentation, or participating in discussions. If you have expertise in a certain area, you can contribute to the TCKs or even a specific API’s development. It’s a meritocratic environment where good ideas and contributions are valued, regardless of who you are or who you work for.

Use-Cases and Future Outlook: Is Jakarta EE Relevant in 2025?

Lila: Let’s talk about the big picture. Where does Jakarta EE 11 fit in the modern development landscape? Is it still for the giant monolithic applications of the past, or can it compete in the world of microservices and serverless?

John: That’s the key shift in perception that this release is trying to drive. While Jakarta EE is still an excellent choice for robust, mission-critical monoliths—think banking systems, insurance platforms, and large e-commerce backends—it has been strategically evolving for the cloud-native world. The introduction of Profiles, like the Core Profile and Web Profile, was a huge step. The Core Profile, for instance, provides a minimal set of APIs perfect for building lean microservices.

Lila: So you can pick and choose just the parts you need, leading to smaller, faster applications?

John: Exactly. Combine that with the build-time optimizations from CDI Lite and the incredible scalability offered by Java 21’s Virtual Threads, and you have a platform that is genuinely competitive for high-performance microservices. The focus on standard APIs also means you can build a service and have confidence that it will run consistently across different cloud environments, which is a huge benefit for multi-cloud or hybrid-cloud strategies.

Competitor Comparison: Jakarta EE vs. The World

Lila: The elephant in the room for many Java developers is Spring, particularly Spring Boot. It’s incredibly popular and also focuses on developer productivity. If a developer is starting a new project today, why would they choose Jakarta EE 11 over Spring Boot?

John: That’s a fair and critical comparison. Spring Boot has done a phenomenal job of simplifying Java development and has a massive, vibrant community. The choice often comes down to a philosophical difference.

Standards vs. De Facto Standards: Jakarta EE is built on open, vendor-neutral standards developed by a committee of multiple companies. Spring is primarily driven by a single company, VMWare. If your organization values multi-vendor support and long-term stability guaranteed by a standards body, Jakarta EE has a strong appeal.
Pace of Innovation: Historically, Spring has often innovated faster, introducing features that later get standardized in Jakarta EE. However, with the new, more agile process at the Eclipse Foundation, Jakarta EE is closing that gap.
The Ecosystem: With Jakarta EE, you choose your runtime (WildFly, Open Liberty, etc.) separately from your code. With Spring Boot, the framework and the embedded server are more tightly integrated. Some prefer the clear separation of concerns in the Jakarta model.

Jakarta EE 11, with features like Jakarta Data, is directly answering the productivity challenge posed by Spring Data. The choice is no longer as clear-cut as it once was. Developers now have two excellent, but different, options for modern enterprise Java.

Lila: What about non-Java competitors? Things like Node.js, Go, or Python with Django/FastAPI?

John: The Java ecosystem as a whole competes very favorably. The JVM is a masterpiece of engineering, offering unparalleled performance, monitoring, and stability for long-running applications. With innovations like Virtual Threads and the GraalVM native image compiler (which many Jakarta EE runtimes support), Java is shedding its reputation for being slow or memory-hungry. For complex, high-stakes enterprise applications, the maturity, security, and massive talent pool of the Java world, now supercharged by Jakarta EE 11 and Java 21, make it an incredibly compelling choice.

Risks, Cautions, and Migration Paths

Lila: It all sounds very positive, but what are the potential downsides or risks? If a company is running an old Java EE 6 or 7 application, is migrating to Jakarta EE 11 a walk in the park?

John: The migration path is the most significant challenge. The “big bang” change from `javax.*` to the `jakarta.*` namespace, which happened in Jakarta EE 9, is a major hurdle. It’s not a simple find-and-replace; it requires careful dependency management and thorough testing. The Eclipse Foundation provides a tool called the “Eclipse Transformer” to help with this, but for large, complex codebases, it’s a significant project.

Lila: So for new projects, it’s great, but for existing ones, it requires careful planning?

John: Precisely. Another risk is the perception lag. As we discussed at the beginning, many developers still view Enterprise Java as old and clunky. It will take time and success stories from Jakarta EE 11 to change that mindset. Developers need to be willing to look past their preconceptions and evaluate the platform on its current merits.

Expert Opinions and Analysis

Lila: What is the industry saying? The press releases are always glowing, but what’s the real takeaway from the experts at places like Microsoft and Red Hat?

John: The consensus is one of genuine momentum. When a company like Microsoft’s VP of Product for Azure Developer Experience, Scott Hunter, publicly highlights their collaboration to support Jakarta EE 11 runtimes, it’s not just marketing fluff. It’s a strategic decision. It means their enterprise customers are asking for it, and they see it as a key platform for cloud development. Similarly, the deep involvement from IBM and Red Hat shows that the companies at the heart of enterprise software believe this is the path forward. The key message is that Jakarta EE is no longer just maintaining legacy systems; it is now a platform for building the *future* of cloud-native Java applications.

Latest News and The Roadmap Ahead

Lila: Jakarta EE 11 just launched in late June. What’s next on the roadmap?

John: The community is already looking ahead. The plan is for a new major release approximately every two years. The next target is Jakarta EE 12, tentatively scheduled for 2026. A key goal for that release will be to support the next Long-Term Support (LTS) version of Java, which will be JDK 25, expected in September 2025. This commitment to staying current with the core Java platform is crucial for keeping the enterprise stack modern and performant.

Frequently Asked Questions (FAQ)

Is Java EE dead?

John: No, but the name is. Java EE has evolved into Jakarta EE. It’s alive and well, and innovating faster than ever under the stewardship of the Eclipse Foundation.

What’s the difference between Jakarta EE and Java SE?

John: Java SE (Standard Edition) is the core Java platform—the language, the JVM, and the core libraries. Jakarta EE is a set of specifications built *on top* of Java SE, designed specifically for building large-scale, server-side enterprise applications.

Do I have to use Java 21 with Jakarta EE 11?

John: No. Jakarta EE 11 has been verified to work with both Java 17 and Java 21, which are the two most recent Long-Term Support (LTS) releases. This gives organizations flexibility. However, to take advantage of key features like Virtual Threads, you will need to run on Java 21.

Is Jakarta EE free to use?

John: Yes, the Jakarta EE specifications themselves are open and free. The compatible application servers that implement them come in various forms. Many, like Eclipse GlassFish, WildFly, and Open Liberty, are open-source and free to use. Some vendors also offer commercial versions with enterprise support.

Is it difficult to learn Jakarta EE?

Lila: I’ll take this one! From what we’ve discussed, it seems like if you’re a Java developer, the barrier to entry is lower than ever. With features like Jakarta Data simplifying persistence and CDI handling a lot of the wiring, it seems much more approachable. The focus on standards means the skills you learn are portable across different products, which is a great career investment.

Conclusion and Related Links

John: Well said, Lila. To wrap up, Jakarta EE 11 is a landmark release. It’s a clear signal that enterprise Java is not only relevant but is actively being shaped into a top-tier platform for modern, cloud-native development. By embracing Java 21’s most powerful features and focusing relentlessly on developer productivity, it presents a compelling, standards-based alternative in the Java ecosystem.

Lila: It feels like a great time for developers to give it a fresh look, especially if their last experience was with the older Java EE. The platform has clearly evolved.

Our Mission

Design. Strategy. Brand.

About Us