This article is more than 1 year old

Reactive? Serverless? Put to bed? What's next for Java. Speak up, Oracle

Less is more, from EE to SE

The future of Java Enterprise Edition is on many developers' minds. After the community came to the conclusion that the platform’s progress has come to a standstill, a plethora of initiatives has arisen with the goal of encouraging Oracle to pick up the work on Java EE 8 again.

It's time to take inventory.

The bone of contention was Josh Juneau’s unsparing analysis of concrete activities in the Java EE specifications since 2015 in April this year. As an Expert Group Member of JSRs 372 (JavaServer Faces 2.3) and 368 (Java Message Service 2.1), he took a close look at Oracle's participation in the development by examining mailing lists and GitHub activities.

His findings supported the previous suspicion of the community: According to his numbers, Oracle's participation effectively stopped in November, 2015.

A first Early draft for the umbrella JSR 366 for Java EE 8 was planned for the first quarter of 2015 and the final version was announced for the third quarter 2016. In June 2015, Oracle announced a shift of about half a year. This was partly still welcomed by the community and viewed as an opportunity for a more active and sustainable participation.

The bottom line is that all Oracle-led specifications have been on pause for eight months. Depending on the scope and interpretation of the Oracle's announced shift, work could still be well under way for the first half of 2017. The recent Register interview with Oracle spokesperson Mike Moeller came just in time for Java-watchers. He joined Oracle at the end of 2015 from Marketo and has a clear cloud focus.

According to Moeller: "Oracle is committed to Java and has a very well defined proposal for the next version of the Java EE specification – Java EE 8 – that will support developers as they seek to build new applications that are designed using micro-services on large-scale distributed computing and container-based environments on the Cloud."

His statements, however, raise quite a few questions.

He begins by talking about Java in general but immediately follows up with a Java EE 8 reference. Is he referring to Java SE, really Java EE or both? This is seamlessly followed by references to microservices and distributed applications in the cloud. Hasn’t there already been a first attempt for cloud in Java EE 7 that got shifted away quickly?

Moeller continues: "Oracle is working closely with key partners in the Java community to finalize the proposal and will share the full details with the broader Java community at JavaOne in September."

And thus the Community breathes a sigh of relief and starts anticipating JavaOne. But what does this all really mean? Which possible outcomes or Java EE 8 might we imagine based on Moeller’s comments?

Java EE 8 as maintenance release

Assuming Moeller was not sure what he was saying, and the second part of the above-cited sentence contains a healthy mix of product half-knowledge, then it might be assumed that he actually meant that Oracle is still supporting and driving Java EE 8.

Some statements on expert group mailing lists, for example the Java Persistence API mailing list, suggest that planning for Java EE 8 didn’t contain fundamental changes and many specifications will only produce a so-called maintenance release.

This would lead to a version 8 with only a couple of new features and minor updates rather than fundamental changes. That would align with a specification request (JSR 366) that doesn’t even list, for example, JSR 107 (JCache) or one of the most discussed new additions – MVC 1.0.

In order to achieve the short development-timeframe target, less than a year remains to get this done. Java EE 7 needed 13 months from early draft to final release. Looking at today’s defined scope for Java EE 8 it seems as if the changes are manageable. It is perhaps the least exciting variant of the future, but it is also probably the most likely.

Focusing on Moeller’s second quote, about working with key partners in the Java community on a new proposal, the possibility remains that Java EE 8 will be completed without Oracle. What could easily be achieved by changing the specification lead on the umbrella JSR has significant legal implications.

Rereading the JCP Process Document reveals that Oracle reserves the final veto right for all Java platforms. Getting around this in Java EE 8 would probably require a radical change in the JCP or optionally additional contracts with the still unspecified "key partners”.

Oliver Gierke says that licensing reasons are a significant impediment to this scenario. This is certainly nothing that could not be worked out with contracts. Whether this would be a one-time exception for Java EE 8 or a complete handover for the future developments, no one knows. But in principle, the question remains as to why Oracle should wish to hand off the future of a central platform to someone else.

Java EE 8 is Java SE + Cloud APIs (serverless)

Moeller’s comments, when it comes to cloud and distributed systems, suggest it could be time to wave goodbye to the application server itself and an extensive collection of reference implementations and to put on some "lightweight" Java SE. This would tie in with Gartner’s prediction that traditional application platforms are dead.

In its literature, on the Java Cloud Service Oracle already bandies about terms like managed servers and scaling. Perhaps the service will soon be able to understand the Java EE APIs, just without the underlying application server. In general this would make sense. The APIs are well known and used by many developers. Detaching the API from the implementation and offering a new, simpler runtime in the cloud, is a logical step.

Red Hat’s separate Micro-Profile will probably also shift in this direction. This is where the new Serverless hype comes in handy, too. Java EE 8 could quickly lean toward something like Amazon's Lambda architecture.

This is unlikely to happen in just a year - unless Oracle has already steered the available resources which were subtracted from Java EE 8 back onto this path.

The remaining fundamental question, then, is how such a dramatic change of strategy could be developed "in the dark", without a Java expert group or even the JCP taking part in it. Even though this approach looks very modern and future-proof, its feasibility is certainly the biggest question.

Java EE 8 as 'reactive'

Another option is that Java EE leans towards another standard or framework - such as Spring. That could see Oracle buy EMC-VMware cloud spin out Pivotal. It is, after all, a relatively small fish for somebody the size of Oracle to snap up. Spring would change the core direction into reactive principles with Spring 5.

If Java EE is not overly suited for modern application requirements, Spring would be an understandable step to take. Spring already implements many Java EE APIs and thus could make it much easier to base Java EE on the thinner Java SE base. And, Spring Boot is already clearly focused on micro services. It is Apache-licensed and an easy fit for a new JSR or even a Reference Implementation (RI).

Oracle isn’t known to be the most generous open source donor and defining Spring Boot or even broader parts of the ecosystem as open source reference implementation for a Java EE 8 Micro Edition sounds too transparent and open.

Bottom line, none of the above alternatives is likely to generate enthusiasm for Java EE 8. The most realistic is certainly the maintenance release scenario. The most future-proof one would be the serverless cloud one.

Both Oracle Java EE specification leads have said before that standards are not meant to innovate but to standardize experiences from the field. Perhaps we will get a big surprise at Java One in September, with Oracle emphasizing its commitment to the platform by visibly resuming its activities and visionary leadership.

Whatever the outcome, the limitations of centralized application platforms in implementing modern business requirements can hardly be denied. A half-hearted modernization at this point will simply result in a half-hearted solution. ®

Markus Eisele is a Java champion, a former Java EE 7 Expert Group member, Deputy Head of the Java Community DOAG, co-founder of Java land, an established speaker at Java conferences around the world and a well-known figure in the enterprise Java community. He works for Lightbend, Inc. This article originally appeared, in German, at heise.

More about

TIP US OFF

Send us news


Other stories you might like