Java EE fact-checking with Java EE Guardian Werner Keil

Java EE Guardians speak bluntly: “Java EE was capable of doing things that are now called ‘Social Media’, ‘Cloud’ or ‘Internet of Things’ many years ago”

Hartmut Schlosser
Java EE Guardians
Werner Keil

Where does the future of Java EE lie? After Oracle reduced its activities concerning Java Enterprise 8, community members created a group called „Java EE Guardians“. What goals do these Guardians have? And where does Java EE 8 stand and what’s next?

In a series of interviews we asked members of the Java EE Guardians for the initiative‘s background and their interpretation of the current situation with Java EE. Our fourth Guardian is Werner Keil, DevOps Build Manager at Visteon Corporation, JCP EC member and JCP expert.

Java EE Guardians speak bluntly: Werner Keil

JAXenter: How would you describe the actual state of Java EE 8?

Werner Keil: Java EE 8 is in a very mixed state. JSON-B is the only one that recently filed a Public Review. Several others have reached the EDR status (Early Draft Review) while some are not even there. They had to undergo a Renewal Ballot as defined by “”; so far all JSRs proposed for Java EE 8 passed. When the Umbrella JSR for Java EE 8 (366) was filed, it wasn’t even aware of some ulterior JSRs in this space. The proposal points out:

– JCache (JSR-107)
– Java API for JSON Binding (JSR-367)
– Model View Controller (MVC) (JSR-371)

JSR-367 filed Public Review. Meanwhile, 371 had at least a second EDR and the Umbrella JSR — EDR1. JSR-107 was confirmed only days ago by one of its Spec Leads who has not even talked to the Umbrella EE 8 Spec Leads, so if Java EE 8 was to be pushed out in an “Ultra Light” version with these features and maybe HTTP 2.0 support plus aspects of CDI 2 (JSR-365), then JCache would likely risk “missing that train” once again. Critical features were left out of JSR-107; Transaction Support is one of them. It also isn’t well integrated with CDI since it started way before that and in its final version, it only targets a Desktop/SE environment. Integration with CDI among other EE features was not done at that time. This sounds inevitable, otherwise it would end up as a half-hearted, widely criticized and under-appreciated Java EE feature like Concurrency Utilities for Java EE in EE 7.

The “Java EE Guardians” are pretty much an equivalent to “Adopt-OpenJDK” which as of now remains the only “Adopt-“ effort Oracle still supports.

Many JSRs that address new features in high demand like Java EE Security (JSR-375) were not updated to join Java EE 8 with the EDR, although for example Oracle’s remaining Java EE Evangelist David Dalabasee brushed the topic during his JavaLand talk and even called it “Cloud relevant”.  “Cache” or JCache are not mentioned there either.

Java EE 8 (as mentioned here) was supposed to be released in the first half of 2017. That timeframe now collides with the “likely” time to expect Java SE 9 (so far it’s also “first half of 2017”). It is impossible to release both at the same time, even if Java EE 8 was already finished. Unlike Java SE 9, with plenty of Adopt-OpenJDK calls even before its final or at least stable condition, there is no signal that Oracle is going to revise the Java EE 8 roadmap.

JAXenter: You are a member of the new group called „Java EE Guardians“. What are the objectives of this group?

Werner Keil: The Java EE Guardians are pretty much an equivalent to the “Adopt-OpenJDK” initiative which as of now remains the only “Adopt-“ effort Oracle still supports. There have been some attempts of “Adopt-a-JSR” in the Java EE space, but they did not get very far in most cases or stopped before they could show any effect. The Java EE Guardians pretty much practice “Adopt-JavaEE” where Oracle and others have stopped.

Another comparison would be the “Agile Manifesto” signed by only 17 individual developers at first. Now there are at least 10.000 who signed it. Those 17 who initially signed the Agile Manifesto were unhappy with the state of software development and processes applied at that time. The “manifesto” of the Java EE Guardians is quite similar to the state of Java EE, the process and progress or the lack of it primarily at Oracle.

JAXenter: Why did you decide to participate in the Java EE Guardians?

Werner Keil: I have always been a representative of the community and its interests no matter where I’ve been; in the JCP Executive Committee, where I’m now the longest-serving elected Individual or in Expert Groups like Java EE Umbrella from EE 6 to 8. I occasionally abstained or voted against JSRs or other aspects that seemed either premature or counterproductive. And I defended my choice, even when in some cases Oracle managers or others in a similar role tried to pressure me into voting “Yes”. Supporting the Java EE Guardians is a natural continuation of what I’ve done in the JCP and Open Source Community for all these years.

JAXenter: Do you think Java EE could be run exclusively by the community without Oracle’s involvement? 

Werner Keil: Based on the changes that came with like Renewal Ballots for slow or inactive JSRs, we saw that the first JSR to fail a Renewal Ballot had Oracle as Spec Lead. Another JSR previously led by Oracle, Portlet Bridge (JSR 329), had its Maintenance Lead transferred to Liferay. JSR 378 is led by Liferay and has Oracle as EG Member, so it withdrew from leading the JSR but has not completely abandoned this standard either. A vast majority of Java EE Guardians are JCP members, so in the worst case the EG could request the Spec Lead to be replaced.

I occasionally abstained or voted against JSRs or other aspects that seemed either premature or counterproductive.

From the viewpoint of dedicated people or companies who consider Java EE important or even crucial to their work, I’d say Java EE could be run by the community. Take the Portlet Bridge case — it doesn’t ban Oracle from taking part in it, but it would make things worse of Oracle decided to let go. There is of course existing contribution and IP involved, but as long as Oracle stays involved in JSRs of interest, it could delegate a limited number of engineers and allow the majority to remain in commercial projects — which is already the case right now.

JAXenter: And do you think Java EE should be run exclusively by the community? Would it bring the Java EE standard forward?

Werner Keil: If you refer to the Spec Lead role, the idea of allowing “the community” or its members to do it for a vast majority of Java EE JSRs including the Umbrella JSR is ok. Except for Java ME Embedded or the Process JSRs (, every new active JSR that has been finalized over the last two years or expects to be finalized before the end of 2016 has Spec Leads other than Oracle. JSR 107 had both Greg Luck and Oracle as Co-Spec Leads, but GitHub shows that Greg and even JCP Members that are not officially in the EG contributed to the codebase.

If we look at the single Java EE 8 JSR led by Oracle that filed Public Review, if others (including the Java EE Umbrella JSR) had multiple members of the community as their Spec Leads, we would see a whole lot more by now. Tomcat (initially developed at Sun) was donated to the Apache community. Some of the most popular build tools like Apache Ant and Maven started as byproducts of the Apache “Jakarta” project where Tomcat was first donated.

JAXenter: What is your personal view on the further development of Java EE?

Werner Keil: I developed a student portal with many features of today’s social networks (e.g. “likes”) using the first version of Tomcat 16 years ago. Or a “Smart Greenhouse” control with mobile device recognition running Tomcat 4 and 5 around two years later. Java EE (or then J2EE) was capable of doing things that are now called “Social Media”, “Cloud” or “Internet of Things” many years ago. I helped clients to replace their old, monolithic host-based applications with a microservice architecture on top of a Java EE 6 stack (as most commercial products only became Java EE 7 certified very recently). So you don’t need proprietary products or some “fancy new framework” that is only compatible with a tiny fraction of Java EE at most to run modern, flexible applications. In fact, for “Big Data” or IoT to really work across vendors, we’ll see an even stronger need for standards, otherwise there will only be “Small scattered Clouds” instead of “the Cloud”.

Java EE had the idea of modularity long before the JDK started to even think about it. Unfortunately the mindset and phantasy of most large players only got us the “Web Profile” so far, although it gave us the right idea.

I would imagine much finer grained profiles, e.g. one that just consists of CDI and JAX-RS for certain services or one that may only use JSON.

Thank you very much!


Hartmut Schlosser
Content strategist, editor, storyteller - as online team lead at S&S Media, Hartmut is always on the lookout for the story behind the news. #java #eclipse #devops #machinelearning #seo Creative content campaigns that touch the reader make him smile. @hschlosser

Inline Feedbacks
View all comments