Jakarta EE 8: The new era of Java EE explained

Jakarta EE 8: The new era of Java EE explained

Java EE is a fantastic project. However, it was created in 1999, under the name of J2EE, and is 20 years old, which means it also faces challenges in keeping pace with enterprise demands.

Now, Java EE has a new home and a new brand. The project was migrated from Oracle to the Eclipse Foundation, and it is called Jakarta EE, under the Eclipse Enterprise for Java (EE4J) project. The Eclipse Foundation released Jakarta EE 8 on September 10, and in this article, we’ll look at what that means for enterprise Java.

Java EE was a very strong project that was widely used in many kinds of enterprise Java applications and many big frameworks, such as Spring and Struts. Developers may have questioned its features and evolving processes, but looking at its high usage and time in the market, its success is undeniable. Nonetheless, the enterprise world doesn’t stop, and new challenges emerge all the time. The speed of change has increased, with new technologies such as cloud computing being developed to provide better solutions, and Java EE needed to keep pace as well.

Jakarta EE goals

The Java ecosystem has a new focus on cloud computing, and Jakarta EE is key to that approach. Jakarta EE’s goal is to accelerate business application development for cloud computing (cloud-native applications), working with specifications developed by many vendors. This project is based on Java EE 8, and its specifications, Technology Compatibility Kits (TCKs), and Reference Implementations (RI) were all migrated from Oracle to the Eclipse Foundation.

To evolve these specifications for cloud computing, however, we cannot work with the same processes used on Java EE, because they are too slow for current enterprise challenges. Thus, the Eclipse Foundation’s first action was to change the process to evolve Jakarta EE.

The Jakarta EE 8 has the same set of specifications from Java EE 8 with no changes in its features. The only change is the new process to evolve these specifications. With this, Jakarta EE 8 is a milestone in Java enterprise history, as it inserts these specifications in a new process to boost the specifications to a cloud-native application approach.

Everything you need to grow your career.

With your free Red Hat Developer program membership, unlock our library of cheat sheets and ebooks on next-generation application development.

SIGN UP

Jakarta EE specification process

The Jakarta EE Specification Process (JESP) is the new process will be used by Jakarta EE Working Group to evolve Jakarta EE. The JESP is replacing the JCP process used previously for Java EE.

The JESP is based on the Eclipse Foundation Specification Process (EFSP) with some changes, which are covered on the project page. Here are the changes:

  • Any modification to or revision of this Jakarta EE Specification Process, including the adoption of a new version of the EFSP, must be approved by a Super-majority of the Specification Committee, including a Super-majority of the Strategic Members of the Jakarta EE Working Group, in addition to any other ballot requirements set forth in the EFSP.
  • All specification committee approval ballot periods will have the minimum duration as outlined below (notwithstanding the exception process defined by the EFSP, these periods may not be shortened)
    • Creation Review: 7 calendar days;
    • Plan Review: 7 calendar days;
    • Progress Review: 14 calendar days;
    • Release Review: 14 calendar days;
    • Service Release Review: 14 calendar days; and
    • JESP Update: 7 calendar days.
  • A ballot will be declared invalid and concluded immediately in the event that the Specification Team withdraws from the corresponding review.
  • Specification Projects must engage in at least one Progress or Release Review per year while in active development.

The goal of JESP is to be as lightweight as possible, with a design that is closer to open source development and that keeps code-first development in mind. With this, the JESP promotes a new culture focusing on experimentation to evolve these specifications based on knowledge gained through that experimentation.

Jakarta EE 9

Jakarta EE 8 is focused on updating its process to evolve, and the first updates in features will come in Jakarta EE 9. The main update expected in Jakarta EE 9 is the birth of the Jakarta NoSQL specification.

Jakarta NoSQL is a specification aimed at easing integration between Java applications and NoSQL databases, promoting a standard solution to connect them with a high level of abstraction. This feature is fantastic. It’s also a big step in getting the Java platform closer to a cloud-native approach, because NoSQL databases are widely used in cloud environments and improvement is expected. The Jakarta NoSQL is based on Eclipse JNoSQL, which will be its reference implementation.

Another update expected in Jakarta EE involves namespace. Basically, Oracle gave the Java EE project to the Eclipse Foundation, but Oracle still holds the trademark. This means the Eclipse Foundation cannot use Java or javax in the project name or namespace for new features of Jakarta EE. Thus, the community is discussing transitioning to the jakarta.* namespace. You can read the discussion thread here.

Conclusion

Jakarta EE 8 marks a new era in the Java ecosystem; it gets the important Java EE project working under an open source process and paves the way for needed improvements. Although this Jakarta EE version comes without feature updates, it opens the gate to new features to come in the future. So, we’ll see many solutions based on specifications for cloud development in the next versions of Jakarta EE.

Share