Java EE 8 dissected: Favorite features, missing features, the way forward
Java EE 8 is here! One of the reasons why this release is special has to do with its future — from now on, it will function under the stewardship of the Eclipse Foundation. We talked with David Heffelfinger about his favorite features, the features he would have liked to see in Java EE 8 and more.
JAXenter: Java EE 8 has just been released. What is your favorite feature?
David Heffelfinger: So many new features, hard to pick just one. I really like the new Security API, security was one thing that was not as portable as I would have liked in previous versions of Java EE, the new Security API will solve this problem. JSON-B, which seamlessly creates JSON strings from Java objects and back, is also a welcome addition, in previous versions of Java EE, we either had to code this manually or had to rely on third-party libraries.
JAXenter: Are there features you would have liked to see in Java EE 8 but were not included?
David Heffelfinger: Original plans for Java EE 8 included a new version of the Java Message Service (JMS), the current version was released back in 2013, and it doesn’t take advantage of newer Java language features such as lambda expressions or the stream API, it also doesn’t integrate very well with Contexts and Dependency Injection (CDI). I was involved with the JMS expert group and there were some very interesting new ideas for JMS being proposed. Unfortunately, due to conflicting priorities and scheduling constraints, the plan to update JMS was dropped from Java EE 8.
JAXenter: Java EE technologies will be moved to the Eclipse Foundation. What are the benefits of an open source Java EE? Was Oracle’s decision to move Java EE technologies to an open source foundation a good one?
David Heffelfinger: The benefit of moving Java EE to a foundation is that no single company has too much control over the specification, making Java EE more accessible to other organizations or individuals that want to contribute to Java EE. Oracle’s decision to donate Java EE to the Eclipse Foundation has been almost universally praised by the Java EE community.
JMS was dropped from Java EE 8.
JAXenter: How will the community benefit from the move?
David Heffelfinger: The community will be able to have a more hands-on approach on shaping future Java EE versions. The risk of a single Java EE steward losing interest in the technology and preventing updates is also greatly mitigated.
JAXenter: We did a quick survey and found that our readers wanted to see Java EE under the stewardship of the Apache Software Foundation. Do you think Eclipse Foundation is a better choice?
David Heffelfinger: Either foundation would have been an excellent choice, I think Eclipse may be slightly better suited for Java EE since they already host the MicroProfile initiative, which includes a number of Java EE vendors and Java user groups, but I wouldn’t have been upset if Java EE had been donated to Apache instead.
The Java EE Guardians have been asking for ideas on what the new name should be, “Java Open Extensions” (JOE) seems to be a popular choice.
JAXenter: There will be no Java EE anymore — since Oracle-led Java EE technologies will be relicensed, that means Java EE will have a different name. What name would you prefer?
David Heffelfinger: I don’t have a strong opinion on what the new name should be. Naming projects presents some challenges that may not be obvious, for example, the name must not be trademarked anywhere in the world. Any catchy name that is not trademarked by anyone would be fine with me. Having said that, the Java EE Guardians have been asking for ideas on what the new name should be, “Java Open Extensions” (JOE) seems to be a popular choice.
JAXenter: Should Java EE and Eclipse MicroProfile be merged?
David Heffelfinger: Java EE as a standard has to be conservative regarding what technologies are added to it. Adding “the latest and greatest” technologies carries the risk of these technologies losing popularity shortly after they are added to the standard. If this happens then it is very hard to remove these technologies from the standard, as not to break backwards compatibility.
I think MicroProfile and Java EE can co-exist, MicroProfile can be more aggressive adding technologies to its stack, then whatever new technologies stick around for the long haul can be incorporated in future versions of the Java EE standard.