The future of Java: How Jakarta EE will unfold under Eclipse

The open source tools organization wants to adopt Docker, NoSQL, and Kubernetes in enterprise Java, while standardizing on Maven and Jenkins

The newly released "strawman" technical vision for the Eclipse Foundation’s enterprise Java platform, now called Jakarta EE, focuses on portable cloud-native application deployment as well as Java 9 modularity. The project would operate on a one-year release schedule.

The vision touches on several facets of the approach Eclipse wants to take with enterprise Java.

Quick technology adoption

In the document, the Eclipse EE4J (Enterprise Edition for Java)’s Project Management Committee decreed it expects cloud innovation from various open source communities to be quickly adopted into the platform. Technologies cited as examples include:


Other development languages also will be looked upon for innovation. The committee issued a call for projects implementing Jakarta EE-related APIs to join the Jakarta project.

Annual releases

The recommended one-year release schedule applies to the Jakarta EE platform overall. For components, Eclipse recommends a “3+1” yearly schedule, in which there is one major release per year synchronized with the platform, plus three quarterly minor releases.

Java 9 modules

Although the first release of Jakarta EE will be based on JDK (Java Development Kit) 8, which predates modules, projects should start preparing for JDK9, which supports modules, and subsequent releases of standard Java. Steps advised include:

  • Adding automatic-module-name in MANIFEST.MF.
  • Provide a correct if possible.

Backward compatibility

Backward compatibility has been a strength for some Java EE adopters and a weakness for others. Eclipse seeks a way to ensure that those who require backward compatibility can rely on it while others can move forward with quicker releases that may ignore compatibility with previous versions of Jakarta EE. Eclipse recommends extracting old and rarely used technologies and putting them in optional modules; users can decide whether to use them.

Soft dependencies

Eclipse also advises thinking carefully before adding dependencies. Components depending on "half the world" are not suitable for microservices development, the document states.


API projects should have a TCK (technology compatibility kit) tests repository. This effort will not be trivial, Eclipse warns. Projects must use the same standard mechanism for a TCK, to avoid a situation where different projects use different frameworks, presenting a challenge in running tests.

Maven build system

Although some older EE4J projects use Ant, Maven is the de facto build system for Java projects. It may be worth the time to invest in “mavenization,” Eclipse advises. Other advice related to Maven include:

  • Projects should use default Maven directory structures and build processes that do not rely on Ant.
  • Project builds should produce standard Maven artifacts.
  • Recommended versions of Maven and plugins should be used.

Jenkins CI

For continuous integration, the official build tool is Jenkins. Some projects already have started with Travis-CI, but Eclipse wants projects to use Jenkins.

Copyright © 2018 IDG Communications, Inc.

How to choose a low-code development platform