Taking the pulse of JavaOne: What we know so far about Java EE’s future and EE4J
The news out of JavaOne this year has been fairly big: Java EE is moving to the Eclipse Foundation. If you weren’t there, David Heffelfinger reports on what went down at JavaOne and how everyone took this monumental news.
JavaOne 2017 took place last week in San Francisco. Once again, I had the pleasure to be a speaker at the conference, sharing the stage with other great speakers such as David Delabassee, Java EE evangelist at Oracle; Ivar Grimstad, JCP spec lead and Expert Committee member; Gaurav Gupta, author of the excellent Jeddict NetBeans plugin; Steve Millidge, founder of Payara; Michael Nascimento Santos of the Brazilian SouJava Java User Group (JUG).
I was also part of a Java EE 8 panel organized by Elder Moraes of SOUJava and Oracle Cloud Evangelist, panelists included Adam Bien, Ed Burns, Ivar Grimstad, Steve Millidge, Reza Rahman, Antoine Sabot-Durand, Bruno Souza, Kevin Sutter, Ruslan Synytsky, and Edson Yanaga. I also attended several sessions by other great speakers at the conference, too many to name.
As always there was too much going on at the conference to be able to attend all the sessions, hands-on labs, hackergarten activities and meetings. Being heavily involved in the Java EE community, I tried to attend as many Java EE sessions and events as I could.
Java EE moves to Eclipse
The big Java EE related news at the conference was the move of Java EE to the Eclipse foundation, by and large, the Java EE community has welcomed the news. This effort is a very recent event and not all the details have been ironed out. There are many questions from the Java community and those involved in the transition from Oracle to the Eclipse foundation don’t have all the answers yet.
I tried to compile some of the most common concerns raised by the community and preliminary answers heard from those involved in the transition. Please keep in mind that nothing in this article should be taken as gospel, since nobody has definite answers yet, not Oracle, not the Eclipse foundation, not the Java EE community members involved in the transition. Your humble author has no inside knowledge, all I’m writing about here is based on public statements made by those involved in the transition and the Java EE community at large.
New name for Java EE?
Because of Intellectual Property (IP) concerns, Java EE will be renamed once the move to the Eclipse Foundation is complete. It was recently announced that Java EE would be renamed to “Eclipse Enterprise for Java”, the new acronym for the technology will be EE4J.
Many members of the Java EE community did not like the name, some were upset that the name was selected “behind closed doors”, without input from the Java EE community in general. A representative from Oracle explained that selecting a new name for a widely used technology such as Java EE is not a simple endeavor, the name needs to be catchy, it cannot be trademarked anywhere in the world, it should not spell anything inappropriate in any language, etc.
In short, naming is hard, and naming by a committee of thousands of developers is pretty much impossible. Additionally, Mike Milinkovich, Executive Director of the Eclipse Foundation, stated in a blog post that the name EE4J is the name of the top-level project at the Eclipse Foundation, the actual technology name may be different in the future.
SOUJava JUG leader and JCP member Bruno Souza stated that the EE4J name makes sense, since for Intellectual Property concerns the new name cannot start with the word “Java”, and the Eclipse Foundation trademark guidelines specify that, when referencing an Eclipse project, both the first and most prominent reference to the project be referenced as Eclipse [project name], for example, Eclipse Enterprise for Java. Prominent Java EE consultant Adam Bien also expressed his support for the new name.
I attended an EE4J panel at the conference in which the topic of naming came up. David Blevins, founder of Tomitribe, was one of the panelists. Although he didn’t state whether he likes the name or not, he stated that we should not focus so much on the name, and instead on what we can do with future versions of Java EE. He used a great analogy to illustrate his point, “I don’t care about the name of the band, I just care about the music”.
Although I agree with David Blevins regarding the fact that we have more important things to worry about than the name, I do have one concern about it that I would like to express here. “Eclipse” in “Eclipse Enterprise for Java” refers to the Eclipse Foundation. However, many in the larger Java community relate the word “Eclipse” to the Eclipse IDE. Having the word “Eclipse” in the name may cause some to perceive that this new effort is only available for users of the Eclipse IDE, which is definitely not the case.
As previously mentioned, the Eclipse Foundation trademark usage guidelines require the official name for all projects under its stewardship to have the name “Eclipse” prefixed to the name of their projects. Perhaps it would be better for the word “Eclipse” not be part of the acronym so as to avoid this situation. Antoine Sabot-Durand, CDI Spec Lead, suggested that the name be changed to “Eclipse Enterprise Environment for Java”. This would keep the EE4J acronym but remove the word “Eclipse” from it.
Java EE API package namespace concerns
Currently, package names for Java EE APIs use the javax top-level package. This means that all Java EE related classes and interfaces are in placed in java packages starting with javax, such as javax.ws.rs for JAX-RS and javax.persistence for JPA. The current plan is to keep existing Java EE technologies in the Java EE package namespace, but move new EE4J technologies to a yet to be determined new package namespace.
The javax package namespace implies that Java EE is an integral part of the Java language. Some prominent individuals in the Java EE community have expressed concerns that moving EE4J packages to a different package namespace may cause some to perceive EE4J as “just another framework”, and not an integral part of Java. Others expressed the opinion that the plan to keep existing APIs in the current namespace, and add new APIs to a new namespace is a good compromise.
Java community process stewardship of Java EE
Under Oracle’s stewardship, Java EE specifications are submitted to the Java Community Process (JCP). The JCP was formed by Sun Microsystems before being acquired by Oracle. It is a group of organizations and individuals who work together to propose and implement new features for the Java language as well as Java EE.
There were some questions regarding whether the JCP would continue to be the steward of Java EE after the move to the Eclipse Foundation. Some members of the Java EE community were very vocal in their desire to continue improving and updating Java EE through the JCP. They stated that the process has worked well in the past. Going through the JCP does not mean that Oracle has to lead the specifications. After all, Bean Validation and CDI Specifications are both led by Red Hat, not Oracle.
Other members of the Java Community are of the opinion that stewardship of Java EE should move away from the JCP after the move to the Eclipse Foundation is complete. Bruno Souza, a prominent member of the Java EE community and (perhaps ironically) a member of the JCP, stated that the JCP is the best mechanism we had to allow the community at large to contribute to what was essentially a proprietary set of specifications belonging to Oracle. He stated that now that Java EE is being completely open sourced, going through the JCP moving forward does not make sense anymore. He believes that Java EE should be moved to another standards body, perhaps within the Eclipse Foundation itself.
Other members of the community expressed concerns about the way intellectual property is handled by the JCP, stating that JCP rules strongly favor Oracle.
Oracle losing interest in Java EE?
Some in the Java community may perceive the donation of Java EE to the Eclipse Foundation as a sign that Oracle is losing interest in Java EE. As far as I can tell, there are no public statements from Oracle on this topic. However, prominent members of the Java EE community have stated that Oracle’s motivations do not matter. What matters is that the end result: open sourcing Java EE is a very positive outcome.
Technology compatibility kit and Java EE certification
Under Oracle’s stewardship, vendors of Java EE compliant application servers have to pass what is called a “Technology Compatibility Kit” (TCK). Java EE application vendors have to pay Oracle to get access to the TCK so that they can have their products certified as Java EE compatible. The TCK is not publicly available, which has caused problems for open source Java EE application servers in the past.
Although I haven’t personally heard any official public statements regarding TCK availability, based on the conversations going on at the moment, it is implied that the TCK will be freely available once the move to the Eclipse Foundation is complete. This will allow current application servers that haven’t passed the TCK to do so, as well as open the door to new Java EE implementations, since the barrier to becoming a Java EE certified product will be drastically lower.
Coexistence with MicroProfile
The MicroProfile initiative was started by a series of Java EE vendors and Java User groups over a year ago. The initiative was a response to the perceived lack of progress being made on Java EE 8 by Oracle. It was a way for organizations outside of Oracle to “take things into their own hands”, so to speak, and move Java EE forward without Oracle’s involvement.
Now that Java EE is moving to the Eclipse Foundation, some Java EE community members have expressed concerns that the MicroProfile initiative may become redundant or obsolete, since Oracle does not have as much control over Java EE as it did when it owned the technology. There are no definite answers about these concerns yet.
Mark Little of Red Hat stated that the decision on what to do with MicroProfile would have to be made by the MicroProfile and EE4J communities themselves. The Eclipse Foundation would not be dictating the outcome. David Blevins expressed his hope that the MicroProfile initiative can continue by becoming a subproject of EE4J. Then, the newer technologies could be added and experimented with in MicroProfile, before moving these technologies to EE4J once they mature.
While Java EE transitions to the Eclipse Foundation, there will certainly be a period of uncertainty. Some may adopt “wait and see” attitude and wait until the move succeeds before diving into contributing to the effort or developing applications against the new specifications.
Tomitribe founder David Blevins urged the Java EE community, in general, to get involved in the effort, and to not adopt a “wait and see” attitude. “If everyone waits and sees and does nothing, then nothing will happen”, he said. I strongly agree with this sentiment and I also urge the Java EE community to get involved with the effort. The first step is to join the EE4J community mailing list, available here.