X
Business

​Where does Java in the enterprise go from here?

Oracle recently freed J2EE, aka Java EE. Now known as Jakarta EE, enterprise Java's new manager the Eclipse Foundation is revealing its plans for the popular middleware platform.
Written by Steven Vaughan-Nichols, Senior Contributing Editor

Containers, microservices, and serverless may be all the rage in new-style enterprise software development circles. Gartner may have declared Jakarta Enterprise Edition (JEE), formerly J2EE, to be a legacy platform, but more than 10 percent of the most popular websites are still powered by JEE.

If the Eclipse Foundation, the group now directing JEE's future, has its way though, JEE may live on in the cloud. You can teach an old programmer new tricks.

Shifting JEE from Oracle to Eclipse hasn't been easy. Mike Milinkovich, the Eclipse Foundation's executive director, wrote, "The Eclipse Enterprise for Java (EE4J) top-level project has been created, and thirty-nine projects established. We don't yet have all of the source code moved over, but you can follow the steady progress on the project status page."

That hasn't stopped the EE4J from looking to the future. Based on a survey of JEE developers, Milinkovich announced the EE4J Project Management Committee "has published a strawman technical vision for JakartaEE for community review and feedback."

In other words, this vision of Java's enterprise future is not a work set in stone. It's a work in progress.

For starters, the EE4J wants to transform JEE into a cloud-native Java platform. In general, "Jakarta EE's mission is more frequent releases, lowered barriers to participation, and putting the community back into the platform."

These will all be welcome changes. Java programmers have long been angry at Oracle for ignoring the Java Community Process (JCP). In theory, the JCP should have been like the open-source method, with developers calling the shots along with Java's corporate owners, Sun and Oracle. In practice, the companies ran the show. Under Eclipse, the developers will get their say in as well.

That starts with this roadmap. Milinkovich is encouraging programmers to help set the roadmap rather than just agree to this first draft.

That's not to say the corporations won't get their say. They will. Besides the new JEE's first members -- Oracle, IBM, and Red Hat -- others have joined. The new JEE members include Fujitsu, Payara, Tomitribe Microsoft, Pivotal, and SAP.

Looking ahead, the EE4J wants to bring Docker containers, Istio service mesh, Kubernetes container orchestration, and NoSQL databases into JEE. These will be "quickly adopted into new versions of the platform to help developers create portable cloud-native applications."

The EE4J also wants to get JEE ready for Java 9. The first versions will still be based on Java 8.

Other older programming frameworks and tools will be depreciated more quickly. For example, the Ant build system will be replaced by Java's de facto standard build system, Maven. Other programs will also be considered for retirement.

As the committee states, "Backwards compatibility has always been a strength for Java EE for many adopters but at the same time a weakness for others, particularly as it often appears to throttle the pace of innovation. We need a way to ensure that those who require backwards compatibility, often for years, can rely upon it whilst others can move forward with quicker releases that may ignore compatibility with previous versions of Jakarta EE."

The EE4J would also prefer that developers use soft dependencies rather than hard ones. That is, they're discouraging the use of components, which depend on half of the world because they're not suitable for microservices development. Instead, programmers should use a "modular approach allowing users to include only functionality needed in their application while maintaining platform consistency."

JEE technical leadership also sees "tests to be a very important part of every project". Therefore, "Specifications and APIs should be designed the way that applications using them can be easily tested."

This works hand-in-glove with their deserve to see JEE programs that can be used with Jenkins continuous integration. That said, some projects are already using Travis-CI, but Eclipse prefers Jenkins.

Last, not least, JEE will see an annual release cadence. For components the recommendation is 3+1 yearly cadence, where one major release is synchronized with the Platform release with three quarterly minor releases.

So, if I were you, I wouldn't write off JEE. Java may not be cool, but with these changes and a mountain of legacy programs waiting to be converted from three-tier application frameworks to cloud-based models, JEE may well outlive us all.

Related Stories:

Editorial standards