Java EE vs. Jakarta EE: When and why to make the move

TL;DR — the key takeaways

• Java EE (Enterprise Edition) has long been the standard platform for building enterprise Java applications.

• Its successor, Jakarta EE, continues that legacy under the Eclipse Foundation with modern governance, active community support, and a critical change: all APIs now use the jakarta.* namespace instead of javax.*.

• As Java EE reaches its end-of-life, migrating to Jakarta EE is essential for long-term compatibility, security, and innovation.

• This article outlines the key differences, why the change matters, and how to plan a successful migration.

As we speak, the Java Community is putting the finishing touches on the third and final stage: updating and transferring the specification documents to define the purpose of the API and how it is used. And when it’s all complete, all Java EE APIs will fundamentally change their package name to Jakarta EE.

What is the difference between Java EE and Jakarta EE?

To understand the impact of this switch, it's imperative to first understand the difference between Java EE and Jakarta EE. 

Java EE

Java EE, now Jakarta EE, was initially developed by Sun Microsystems before Oracle acquired the parent company in 2009. For the longest time, Java EE has been the standard for building enterprise-level applications in Java. Some of the specifications the framework provides for include messaging, enterprise Java beans, persistence, and web services. For nearly two decades, developers have consistently relied on these components to build robust, scalable, and fully maintainable enterprise applications.

Java EE’s well-defined architecture was the go-to choice for developers for almost a decade. In 2017, the Java Community decided unanimously to make fundamental changes to the once-revered development standard. The reason for this? Oracle’s stewardship of Java EE wasn’t exactly innovation-based, causing widespread frustration within the community.

Jakarta EE

What you’ve always known as Java EE will soon fully rebrand to Jakarta EE. Governed by the Eclipse Foundation, Jakarta EE is the successor to Java EE and, to some extent, Oracle’s attempt to quell community-wide frustration. It’s fundamentally a community-driven initiative with open-source innovation at its heart.

The all-important difference between the two frameworks is the namespace change. The javax.* namespace prominently used in Java EE has been replaced with jakarta.*. This update affects all enterprise Java APIs and requires changes to existing applications that use Java EE. It's not just a rebrand — it's the foundation for future development and innovation in enterprise Java.

To sum it up:

• Jakarta EE is the successor to Java EE.

• They both define standards for enterprise Java development.

• The main difference is the name and the namespace for the APIs.

When and why should a developer choose between Java EE and Jakarta EE?

As enterprise software development continues to evolve at an unprecedented pace, it’s vital for developers to weigh when best to migrate to Jakarta EE. Some factors to consider before making the big leap include:

Project requirements

Foremost, developers should consider the specific, nuanced requirements of their project. If the application is hugely dependent on legacy Java EE features that will soon be phased out or are still being replicated in Jakarta, it makes sense to hold off for now. Meanwhile, if the project is brand new and future-focused, Jakarta EE is the more logical pick as it’s more modern, is in active development, and has the full support of the Java Community behind it.

Application server support

Another decision driver should be support from application servers such as Payara, WildFly, and Open Liberty. Major application servers have already transitioned and now support Jakarta EE in its entirety. Consequently, many of them no longer support Java EE. If your enterprise application is built on an outdated Java EE version—say, J2EE—and you want to make the most of modern development tools and performance optimizations, moving to Jakarta EE is a no-brainer.

Community and innovation

The community supporting, contributing to, and fine-tuning Jakarta EE is growing rather rapidly. The Eclipse Foundation fosters a vibrant community of budding and experienced developers alike, all actively contributing to the future of Jakarta EE. It’s no longer as bleak and unpromising as it once was.

In contrast, Java EE has hit a dead end in terms of active development. Oracle all but stopped injecting resources into it, which means it’s now lacking on the innovation front. The focus is now entirely on Jakarta EE, and the goal is to make it a revolutionary open-source Java development platform. With robust and consistent support from the community, Jakarta EE is bound to keep receiving new capabilities and feature improvements. 

While there’s still some community support for and around Java EE, it’s scanty at best. Developers thinking long-term will find it almost unviable, and will find switching to Jakarta EE to be the far better solution.

Long-term support

Short-term, intermittent support might suffice for basic applications, but certainly not mission-critical enterprise applications. Without active, consistent support, these will ultimately crumble and leave an organization badly exposed.

Given that Jakarta EE is the future of Java EE, it’s expected to receive active, community-backed support in the long haul. With Java EE on the brink of total phase-out, migrating to Jakarta EE is the only way to guarantee access to regular updates, security patches, and new features. 

To sum it up:

• Jakarta EE is the successor to Java EE.

• They both define standards for enterprise Java development.

• The main difference is the name and the namespace for the APIs.

How does a developer move from Java EE to Jakarta EE?

That’s the big question. Like the project heads themselves found out, moving from Java EE to Jakarta EE is as complex as it is rewarding.

Here’s how to go about it:

1. Assess and plan

Take a step back and carefully evaluate your current application. Chances are good that some—or most—of the Java EE components and libraries it's using are compatible with Jakarta EE. For large applications, it’s equally important to assess whether the migration should happen all at once or in bit-sized, controlled phases.

2. Update libraries

The reason for this is simple: Jakarta EE is introducing a completely new namespace (jakarta.*). As such, developers must update all dependencies that rely on Java EE libraries.

The two major focus points here are:

• Updating pom.xml or build.gradle files (for Maven or Gradle-based projects) to reference Jakarta EE libraries.

• Swapping out javax imports for their corresponding jakarta imports.

3. Refactor code

This step is, quite simply, unskippable. Refactoring ensures code perfectly aligns with the newer, all-important changes in Jakarta EE APIs.

Avenues for consideration include: 

• Namespace changes: jakarta must replace javax across all codebases.

• Updated APIs: Some Java EE APIs have been deprecated in Jakarta EE, or in some cases, changed entirely. So, developers will need to spruce up their code to account for these changes.

4. Choose a Jakarta EE-compatible server

Only a few select Java EE application servers are fully compatible with Jakarta EE. For deployment, developers will have to select a Jakarta EE-compatible server. Popular options include:

• WildFly (formerly JBoss EAP)

• Payara (the successor to GlassFish)

• Open Liberty (from IBM)

• TomEE (Apache Tomcat’s Java EE variant)

5. Test thoroughly

As with any migration of a considerable magnitude, failure to test the new Jakarta-compliant code could possibly introduce bugs or recurring issues into your application environment. Functional tests, performance tests, and integration tests are all crucial for verifying the application’s behavior and performance.

Important Considerations

If we were to choose three no-brainer considerations for a seamless Java EE—Jakarta EE migration, it would be these:

• Complexity: The complexity of migration depends on the size and complexity of your application, along with dependencies.

• Testing: Thorough testing is often the difference between a successful migration and one that falls flat. 

• Phased Approach: For large applications, a phased approach makes the most sense. Not only does it significantly reduce risk, but it also makes the process a lot more manageable.

Upcoming release from Jaspersoft

At Jaspersoft, we’re constantly staying abreast of any and all changes in the Jakarta EE ecosystem. With version 10.0 releasing in the fall of 2025, we’re providing comprehensive support for Jakarta EE. We want developers to have compatibility with modern Java applications and frameworks while staying in the know about the latest trends and technology.

Please join our next roadmap webinar on Thursday, June 26. 

Related Resources