Java EE 8, which will sport HTTP 2.0 and HTML5 capabilities, is supposed to be ready by mid-2017. But some Java partisans have their doubts about this time frame, so they've formed two groups to enhance Java EE on their own, outside of the jurisdiction of Oracle and the formal JCP (Java Community Process).

The two groups are Java EE Guardians and MicroProfile.io, which plans to build extensions to accommodate microservices in Java EE. Count Red Hat and IBM as contributors to MicroProfile.io. Payara, which has built a drop-in replacement for the open source GlassFish Java EE application server that Oracle has reduced its attention to, is participating as well.

Don't call the external Java efforts a fork

Java EE Guardians and MicroProfile both shy away from the term "fork" to describe their efforts. "A complete fork in the pure open source sense for Java EE is far too risky from a legal standpoint," said Reza Rahman, leader of Java EE Guardians and a former Java EE evangelist at Oracle. "What can be done is re-create APIs from scratch without using any of the existing Java EE APIs. That's both hard and very regrettable because Java EE APIs are so pervasive."

"A fork is a strong word. I wouldn't use the word 'fork'," agreed Rich Sharples, Red Hat's senior director of product management for the company's app platforms business group.

MicroProfile, he said, plans to augment Java EE with an initial baseline of microservices capabilities around Jax-RS (Java API for RESTful Services), CDI (Contexts and Dependency Injection), and Java API for JSON Processing, which marshals REST calls back into Java. "We're trying to get working implementations of the MicroProfile -- not just one, but from multiple vendors -- by September, by JavaOne," the annual Java technical conference held in late September, Sharples said.

MicroProfile's work, he said, would be complementary to the Java platform, leveraging the same technologies and standards but in a manner geared for building microservices and decomposing existing applications into microservices. Red Hat sees microservices as critical for enterprise development, and Sharples questions how Java EE can keep up with the changes needed to accommodate the concept given its slow pace of development under Oracle and the JCP.

Java EE Guardians also is considering developing EE features on its own. "What we are seriously thinking about is whether to make an effort at advancing the features that are supposed to be in Java EE 8, whether it makes sense to advance those features through open source outside of the JCP," Rahman said.

Features under consideration cover security, Java Message Service, and Jax-RS. HTTP 2 also could be developed, but this capability would be hard to implement separate from the JCP, since it is directly dependent on Java servlet API, Rahman said. Java EE Guardians would like to avoid moving ahead outside the JCP, so it'll wait about a month before deciding whether to proceed on its own, he added.

"There's a feeling of a lack of leadership," said MicroProfile participant Sharples. Oracle's involvement, he said, has tailed off. "We've seen very little detail about what Java EE 8 would look like." Oracle is in charge of many of the Java specifications, Sharples noted, so Java EE "really can't move forward without Oracle's investment."

Even a member of the JCP Executive Committee, which oversees revisions to the platform, vouches for Oracle's neglect. "Judging simply by the facts, that out of 12 Java EE 8 JSRs (Java Specification Requests) -- including JCache, which is a roll-over from EE 7 if included -- only one new JSR has recently filed [for] public review," said Werner Keil.