What Will an Open Source Java EE Mean? – InApps Technology 2022

When Oracle’s software evangelist, David Delabassee, announced via blog post that Oracle is considering passing Java EE on to an open source foundation, the news kicked off a mountain of otherwise stoic and silent voices all chiming in about the future of this long-forgotten platform of old.

Not ten years ago, the Java Enterprise Edition was still a big part of the way large enterprises wrote and ran Java applications. And that still remains true to a certain extent today.  Even just four years ago Oracle managed to release a major update for the platform in Java EE 7. Now, Java EE 8’s release is just around the corner at Oracle OpenWorld, bringing with it such long-awaited features as an API for JSON binding, JCache, and support for server-sent events.

The cadence of Java EE releases has slowly been slipping since it was originally released as Java Professional Edition in 1998. Releases occurred every year until version 1.4, which took two years. Then, Java EE 5 (1.5) took three years to arrive, a pattern which continued until the arrival of Java EE 7.  In 2010, Oracle acquired Sun Microsystems, the original developer of the technology. Now, it would seem, under Oracle’s watch, four-year releases are the norm.

That is if Oracle continues to oversee the project entirely. The Delabassee blog post would seem to indicate this lengthening cycle could be broken, however. If Oracle does follow through with its idea of donating Java EE, its reference implementation, and the Test Compatibility Kits (TCK) to an open source foundation, it can only improve the state of the platform as a whole, which has largely been relegated as a legacy platform in today’s cloudy world.

The outside world has moved far beyond Java EE, which is now a bit of a legal mine field, and considered far too bulky for most microservices applications.

The primary reason for the sluggish movement of Java EE could be attributed to the Java Community Process (JCP) as well as it could be attributed to Oracle itself. The Java Community Process has, for many years, been a slow-moving body with a modicum of internal, structural strife. When Oracle took over the JCP, its chair Patrick Curran undertook the difficult task of revising the organization’s policies and procedures by using its existing structures to approve those changes.

Some change has occurred, but as an example of how complex and long-term some of these problems can be, the JCP still has not solved its TCK licensing issues. These arose over 10 years ago when Android was beginning to take shape. The TCK is used to confirm compatibility of a Java implementation, and Google’s original Android Dalvik engine was built using non-TCK-tested software, some of which was derived from the Apache Harmony project, an open source implementation of Java lead by Geir Magnusson.

Harmony irritated Sun Microsystems, and before Oracle had even acquired Sun, it too was complaining about the restrictive licensing of the TCK. That license stipulated that, essentially, any tested implementation could only be used on a server or desktop computer. Mobile devices, appliances, and embedded systems were notably left out, ensuring that Java implemented for those systems outside of, say, Java ME (Mobile Edition) could not be said the be officially compatible with mainstream Java.

These are the roots of the Oracle lawsuit with Google, which expanded to encompass many other areas of Java technology licensing. It should be noted that while Oracle was in favor of modifying the TCK licenses before it owned Sun Microsystems, it has now had many years to change the wording and has not done so. It has also continued to litigate over Java, gaining rulings in the process that threaten all of the software through the potential to bring complex licensing requirements to API re-implementations.

This is the sort of baggage that comes with the JCP and its process. Curran and the executive committee of the JCP have worked to open the process and bring in more participants, but the outside world has moved far beyond Java EE, which is now a bit of a legal mine field, and considered far too bulky for most microservices applications.

That’s not to say there isn’t a need for a better Java EE and more improvements to the platform. Indeed, thousands, if not tens of thousands of enterprise applications remain in use with Java EE forming their back end. Allowing these applications to better work with JSON, JavaScript and microservices would certainly be helpful.

That’s why Red Hat, IBM, Tomitribe, and others have worked together to create Microprofiles.io. This group of Eclipse projects is aimed at making Java EE more amenable to use in microservices environments: because if a legacy application can be transformed to a microservice in its own natural environment, things are easier for everyone involved.

John Clingan, senior principal product manager at Red Hat, said that an open source Java EE could quicken the pace of innovation around the aging platform. “Java EE had this relatively steady, measured pace, evolving in the JCP. Oracle has defined a statement of intent, and we’re on board with that statement of intent to move to an open source foundation. It has the potential to make Java EE much more agile and responsive to the movement of the industry, at the pace the industry wants to move at,” said Clingan.

When asked why he thought Oracle would make this move now, Clingan said, “I think it gets back to the changing nature of the industry. If you look at what’s happened to Node.js, it’s gone to a foundation. From a Microprofile perspective, we decided to do that via a foundation, and I think it just seems to be a natural decision for language runtimes or platforms. The current trend is to open it up and make them more collaborative. To be honest, managing Java EE is a rather large investment by an organization, so I think they want to give the opportunity for a broader community to participate,” said Clingan.

It all comes back to velocity, said Clingan, and this is why Microprofiles were created. “What we wanted to do was deliver functionality into the hands of developers more quickly, instead of taking the time to build a specification, building it out over years and then delivering it at the end. We were hoping to take a much more open source approach. Let’s iteratively define specifications, get them in developer’s hands sooner rather than later,” said Clingan.

This speaks to a larger problem in the Java EE ecosystem, as well: one of day-to-day velocity for developers. Without a constantly updating Java EE, enterprise applications can end up locked out of the newest revolutions: from containers to microservices. This is, in fact, why Microprofiles were created: to aid in the adaptation of Java EE applications to the microservices world. Traditionally, Java EE development has been cumbersome and requires great deals of XML and configuration, the antithesis of a fast-moving, lightweight, and modular system like Node.js.

The OpenJDK has long gone after this issue with Project Jigsaw, an effort to modularize Java that has been something of a point of contention within the JCP, garnering thumbs down from major vendors like Red Hat and IBM. At issue is the deeply entangled core bits of Java and the fact that much of the work on Jigsaw has been headed by Oracle’s own Mark Reinhold, a fact that perhaps leaves a bad taste in the mouths of Oracle’s competitors. That Java SE issue aside, Java EE could also use some modularization and slimming.

Said Clingan, “The Java SE 9 modularity is a complete orthogonal issue. We’re going to have to address it. Java EE 8 is almost released, and it does not try to tackle modularity whatsoever. What’s most likely going to happen is when Java EE is moved into an open source foundation, I think the broader Java EE community, all the folks involved for a couple a decades, whether it’s the Java EE Guardians, the Microprofile folks, or just EE developers, in general, are going to have to define that as part of an open source project.”

Red Hat is a sponsor of InApps Technology.

Feature image by Cole Mader on Unsplash.