Eclipse Moves to Make Jakarta EE, Formerly Java EE, More Open to Developers – InApps 2022

It’s been a long, strange road for Java Enterprise Edition (Java EE). Once the darling of enterprise application development, and the focal point of much of the innovation in the Java community, the framework and platform became stagnant, and emblematic of the technical debt it was designed to replace. Last year Oracle donated the code behind Java EE to the Eclipse Foundation, as a show of good faith to the community which had been seemingly neglected for so long.

In September of last year, Java EE 8 arrived at the same time as it was being donated to Eclipse. The platform’s latest features included a new API for JSON bindings, and support for server-sent events. And the code base also is getting a new name: Jakarta EE.

“What this is about is not just bringing Java EE to the Eclipse Foundation. This is about resetting the community, the processes, and the technology so that the Jakarta EE platform becomes what the next generation of developers want to use to build their applications,” said Mike Milinkovich, executive director of the Eclipse Foundation.

The new name originates in the Apache Foundation, where the Jakarta Project originated as a place where gaps in the open source Java ecosystem were filled. Back then, Jonathan Locke donated a package of regular expressions to the Apache Foundation, which was initially released in May of 2000 as Jakarta Regexp 1.0. Jakarta went on to include a number of other similar projects, but was eventually retired from the official list of active Apache Foundation projects in 2011. The new Jakarta has nothing to do with the older project, save for the shared name.

According to a FAQ on the new Jakarta Project, one of the large benefits of this new effort under the Eclipse banner is the fact that the governance model will be much more open to participants in the vendor community and beyond. “The main difference is that the governance model is now inherently multi-vendor. The Eclipse Foundation has a long track record of providing a level playing field for all interested parties to collaborate on technology.

The Java Community Process (JCP) did quite a good job in being open. However, it was ultimately controlled by Oracle, and its intellectual property rules gave the spec lead a distinct advantage relative to the other stakeholders. The Eclipse Foundation will ensure that the new specification and development processes for Jakarta EE will be open, vendor-neutral, and provide a level playing field for all participants,” reads the FAQ from the Eclipse Foundation.

“We’re seeing a significant increase in the number of developers working on these projects as a result of this move, which was very much the hoped for result when Oracle started this back last summer,” — Mike Milinkovich, Eclipse Foundation

Elsewhere on the Eclipse site, a FAQ from the initial Java EE 8 development project at Eclipse, Eclipse Enterprise for Java, promised a faster process behind Java EE after the move to Eclipse. “The industry has changed since the original Java EE process was created. Although Java EE is developed in open source with the participation of the Java EE community, often the process was not seen as being nimble, flexible or open enough, particularly when compared to other open source communities. This perception had grown in recent years, leading to public controversy and conflict. We felt it was time to address this feedback in a positive manner, and with the completion of Java EE 8, the timing is right,” read that FAQ.

Milinkovich said the open process provided by the Eclipse Foundation has already attracted new participants to the project. “We’re already seeing this in action because of the open and vendor-neutral Eclipse processes. As we are bringing these projects over to the Eclipse Foundation, we’re seeing developers from IBM, Oracle, Tomitribe and others put their names forward and become committers on these new projects. We’re seeing a significant increase in the number of developers working on these projects as a result of this move, which was very much the hoped-for result when Oracle started this back last summer,” said Milinkovich.

This all adds up to mean 2018 will be a year of rebranding for Java EE 8. The current umbrella project for all of Java EE 8 is now known as the Eclipse Enterprise for Java project. This EE4J project includes over 40 projects donated by Oracle. All of these projects will see their first official update sometime in Q3, when the Eclipse Foundation plans on doing its initial release.

Another key piece of the Java EE to Jakarta puzzle is the fate of the test compatibility kits, or TCK’s. These kits have long been a focus of strife for community members, and at least partially contributed to the decision to create the Apache Foundation’s Harmony Project back in 2005. That open source reimplementation of Java ran into problems when it came time to test against the TCKs to certify that the platform was in fact, Java compatible.

Those TCKs came with license restrictions that limited a tested platform to being used in desktop and server computers, only. Such restrictions lead to in-fighting in the Java Community Process which initially were supported heavily by Oracle. However, after the company purchased Sun Microsystems, it ceased endorsing a change to the TCK licenses.

Now that this whole mess is at least partially under the guidance of the Eclipse Foundation, those TCK licenses should no longer be an issue. Unfortunately, the damage has already been done: after Google based its Android platform initially on Harmony, it ballooned into the lawsuit which now threatens API replication across the industry.

That’s exactly the type of legal problem Milinkovich and the Eclipse Foundation are trying to make impossible by redirecting Java EE towards more open waters. The new governance process. While the original TCK issues were focused on Java SE, Milinkovich said that this donation and the inclusion of the TCKs themselves should help to assuage fears that such a legal dispute could arise in the Jakarta EE project.

“I think this is going to go a long way to addressing that issue for the EE developers and the EE ecosystem, but it doesn’t universally solve the problem for Java,” said Milinkovich.

Feature image via Pixabay.