Why Java Developers Continue to Rely on Jakarta EE

Over the past year, the Eclipse Foundation spoke to leading Java developers around the world to discuss why they rely on Jakarta EE and the unique benefits of using Jakarta EE technologies. Their input is captured in our white paper, which describes the important advantages Jakarta EE offers today and for the future.

Download the Jakarta EE white paper!

They’re Looking Ahead, Not Back

With Jakarta EE’s long history as Java EE, it’s sometimes easy for developers to dismiss the technology as yesterday’s approach. But Jakarta EE technologies are embedded, and relied upon, in a way no other technologies are. Here are some examples you might not be aware of:

  • Apache Tomcat implements several Jakarta EE specifications
  • Eclipse Jetty is a certified implementation of Jakarta Servlet 5.0
  • Spring Boot embeds Eclipse Jetty or Apache Tomcat as a runtime


Open Specifications Bring Important Advantages

One of the advantages every one of the developers raised was the value of the specification-based approach to technologies in Jakarta EE.

The clear boundary between fully tested specifications and underlying implementations means developers can easily switch between the implementations with minimal impact on the application code. This agility saves considerable time, effort, and money when changes are required.

Jakarta EE Provides a Unique Combination of Features and Functions

The developers also described a combination of strategic and technical advantages that aren’t available in any other platform. Some of the main Jakarta EE benefits they noted include:

  • Stability and backward compatibility. Jakarta EE provides a mature and proven foundation for innovation that allows organizations to fully leverage the investments they’ve already made in enterprise Java applications.
  • Architectural flexibility. Organizations can support cloud-based microservices architectures, as well as traditional, monolithic architectures. They can also seamlessly incorporate newer technologies, such as MicroProfile, Docker containers, and Kubernetes orchestration.
  • Speed and simplicity. A Jakarta EE application can be set up with significantly less configuration compared to other frameworks.
  • Development and deployment freedom. Developers can use any Jakarta EE-compatible runtime, and they can implement and blend whichever aspects of the application server are needed to leverage Jakarta EE capabilities in a modern and efficient way.
  • Longevity. The open, vendor-neutral, and community-driven approach at the Eclipse Foundation ensures applications developed using Jakarta EE will remain relevant and usable over the long term.

Get the Full Story

These insights are just a few of the reasons leading Java developers remain committed to Jakarta EE. For the complete story, download the white paper.

Visit the Jakarta EE website to learn more about Jakarta EE and explore the Jakarta EE specifications.

2 thoughts on “Why Java Developers Continue to Rely on Jakarta EE

  1. JEE was and is mainly used by financial institutions. Jakarta is replacing JEE but a small part of the battle field has been taken by Spring Boot micro-apps started in a container like Docker. Of course we can start Jakarta-based solutions in a container too and do the same job pretty fast! Who will be the winner for the backend Java? I do not know but we have to remember that JCRs and servlet standards were firstly defined by JEE RI implementations so i am guessing Jakarta will get on speed very much soon because of being a bit closer to RI implementatons for various JSRs. I think also this ‘stability’ will start playing main role soon.

    Thanks Ivar for your contribution to Jakarta and Happy Easter Ivar. I did not wish all the best for the New Year 2021 because I was a bit sick:-(

    Can you share some news on your blog about JavaOS, Java on Java (jvm written in Java) and service discovery concepts of Jakarta?

    1. “JEE was and is mainly used by financial institutions.”
      No – JavaEE was used by service providers whose Java applications were required to scale well beyond single instances. If you’ve ever booked a hotel room or a flight somewhere odds are your booking was done on a JavaEE application communicating with a bunch of other JavaEE applications.

Leave a Reply to Mariusz Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.