Java EE in the Cloud and the Future of the JCP

In its ongoing effort to make its workings as transparent as possible, the Executive Committee (EC) of the Java Community Process (JCP) publishes the minutes of its meetings. The Aug. 9 minutes are online now, and though these kinds of documents tend to provide reliably dry reading, this one proved to be a real page turner for anyone interested in the future of Java EE. (Or would have been if it were, you know, printed on paper.)

A couple of things caught my eye: Anil Gaur, Oracle group vice president with responsibility for Java EE and WebLogic Server, reportedly gave a short presentation on Oracle's Java EE strategy. As recorded in the minutes, he talked about how enterprise programming styles are changing to focus on apps deployed in the Cloud via modular runtimes, and how "we," by which I'm presuming he meant Oracle, would like the future of Java EE to be "viable to the next generation of applications."

Elsewhere in the minutes, JCP Chair Patrick Curran reportedly talked about a meeting he'd had with Oracle execs "on the subject of relations between OpenJDK and the JCP." Curran reported that Mark Reinhold, chief architect of Oracle's Java Platform Group, "had argued that much of the process required by the JCP was duplicative and unnecessary, and that Mark had even suggested that Expert Groups added little value to OpenJDK's existing processes."

We've been hearing predictions like Gaur's that the future of enterprise Java is in the cloud for a while now, and I continue to hear about the uncertain future of the JCP. But felt the need for some elaboration, so I reached out to some Java EE mavens to see what they had to say.

EC member and London Java User Group leader Martijn Verburg attended that meeting (virtually). "I think Anil is echoing the overall market trend for cloud based applications and services, with a subset of that trend being microservices and serverless," he told me via e-mail. "That is, less and less applications will be developed for on premise, requiring the sort of transactions support and connectivity with traditional on-premise systems. For example, with today's Java EE you have standards for Batch processing, transactions, persistent messaging with JMS and so forth.... So that means Java EE needs to evolve and produce standards around service discovery, configuration, logging, JSON processing, and binding, etc., and be less about heavyweight messaging, transactions and so forth."

On the subject of the future of the JCP, he added that he expects it to be "alive and well for some time yet."

"I think the community at large wants to see standards around Java in order to make long terms plans based on the technology," he said, "so the JCP should remain, or some other standardization effort would, I think, naturally take its place."

I also heard from Mike Milinkovich, executive director of the Eclipse Foundation, another EC member listed among the attendees. "Java EE was originally designed for on-premise IT infrastructure," he said. "As more IT moves to public and private cloud infrastructures, Java EE needs to change. Enabling Java to support multi-vendor standards for elastic scalability and DevOps-style deployment models will be key to its future success."

He, too, felt the JCP had a few miles left on it. "I don't think the JCP is going anywhere," he said. "Open source is great, but OpenJDK only provides a single implementation. The team there is effectively building a single product, not a multi-vendor standard and an ecosystem. That may be inconvenient for some Java platform developers, but I am confident that Oracle's executive management understands how important the JCP is to the success of Java as a platform. Without the JCP there could be no WebSphere or JBoss or J9 or Zulu."

EC member Werner Keil, also on hand for the meeting, acknowledge the shift of Java EE 8 toward the Cloud, but argued that that change is not necessarily based on Oracle's recent interests. "Several members of the Java EE Umbrella [Expert Group] repeatedly asked for better support of what once was called 'multitenancy' (aka being able to serve multiple clients/tenants in the cloud more easily)," he said via e-mail. "It took until the Java EE 8 release train (or even beyond) to get those voices heard. Well, it also took till Java SE 8 to get lambdas and 9 to get modularity, first intended at least for Java SE 7."

On the JCP vs. OpenJDK question, Keil said: "Despite the 'Open' in its name, OpenJDK isn't more open than the Open Handset Alliance or .NET Foundation, while the JCP… is a vendor-neutral industry body…. To [paraphrase] Orwell, Oracle isn't 'more equal' than others in the JCP, while they're a lot more equal in OpenJDK. Not everything is rosy and efficient there, either. For example: Project Kona was announced during a BOF last year at JavaOne, and yet, as you can see from its repository, there has been no activity since before JavaOne, and some parts are even inactive for almost two years now."

I also touched base with Josh Juneau, a Chicago-based app developer, blogger and author. He wasn't at the EC meeting, but he's a thoughtful industry watcher who, like me, could read the minutes.

"The foundation of the JCP relies upon the community-centric approach that involves many different voices, and not just those of the big players," he said in an e-mail. "The community, including vendors, developers, and user groups alike, need to have the ability to help steer the direction of enterprise Java, because there are so many different pieces to the enterprise puzzle. One company cannot have all of the answers in this space, so if the JCP were taken out of the decision making and the evolution of Java EE in the future, I feel that it would make Java EE a less healthy platform for development. It would force the vendors and developers to change the way they did business based upon one company's idea of what the enterprise should look like. However, if Mark's statement was not addressing the removal of the JCP process, but rather a revision, then I could understand his position a bit more. Perhaps Mark has different ideas for how the process should be executed. That said, we need the JCP in place, whether in its current form or in a revised format, where the community still has just as much influence."

Surely everyone who reads this blog knows that the JCP is the group that certifies Java specifications, and the EC is charged with guiding "the evolution of Java." What might not be such common knowledge -- and what I want to acknowledge here -- is how hard the JCP has been working since Oracle acquired Sun Microsystems and took over the stewardship of Java to rework some of its knottier components. It started in late 2013 with Java Specification Request (JSR) 348, which was all about transparency, participation, agility, and governance. That JSR was approved without much fuss, and a year later, the JCP sought to merge two ECs -- the Java SE/Java EE committee and the ME committee -- under JSR 355. That plan was also approved.

Posted by John K. Waters on August 24, 2016