Two days after the release of JDK 10, Mark Reinhold, chief architect of the Java Platform Group at Oracle, proposed a schedule for the JDK 11 GA release:
- June 28: Rampdown Phase One (fork from main line)
- July 19: All Tests Run
- July 26: Rampdown Phase Two
- August 16: Initial Release Candidate
- August 30: Final Release Candidate
- September 25: General Availability
So far, the JEPs targeted to be included in JDK 11 are:
- JEP-309: Dynamic Class-File Constants
- JEP-318: Epsilon: An Arbitrarily Low-Overhead Garbage Collector
- JEP-320: Remove the Java EE and CORBA Modules
- JEP-323: Local-Variable Syntax for Lambda Parameters
The JDK 11 early access builds were available almost a month before the release of JDK 10. Reinhold tweeted:
These JDK 11 builds include JEP 320 (Remove the Java EE & CORBA Modules), so they're smaller: Nine fewer modules, 22 fewer megabytes #jdk11
JEP-320: Remove the Java EE and CORBA Modules
The restructuring of Java SE 9 included support for Java EE and CORBA modules, but they were immediately deprecated for future removal as per JEP 277.
The Java EE modules are a web services stack that have been available in the JDK since the release of Java SE 6 as a convenience for Java developers:
- JSR-224: Java API for XML-Based Web Services (JAX-WS)
- JSR-222: Java Architecture for XML Binding (JAXB)
- JSR-925: JavaBeans activation Framework (JAF)
- JSR-250: Common Annotations for the Java Platform
It was determined that the JDK no longer needed to support these modules as they have evolved over the past 12 years and are readily available in third-party sites such as Maven Central.
The CORBA modules, available in the JDK since 1998, will also be removed since most modern applications don't use CORBA technology. As a result, Oracle has decided that continued support for CORBA is no longer cost effective.
The full list of modules scheduled to be removed in JDK 11 is:
java.xml.ws(JAX-WS, plus the related technologies SAAJ and Web Services Metadata)java.xml.bind(JAXB)java.activation(JAF)java.xml.ws.annotation(Common Annotations)java.corba(CORBA)java.transaction(JTA)java.se.ee(Aggregator module for the six modules above)jdk.xml.ws(Tools for JAX-WS)jdk.xml.bind(Tools for JAXB)
The risks in removing these modules were acknowledged and documented in JEP 320. For Java EE modules in particular:
Applications will not compile or run if they rely on "out of the box" support in the JDK for Java EE APIs and tools. These applications will experience binary and source incompatibilities when migrating from JDK 6, 7, or 8, to JDK 9 or a later release
Another risk of removing the Java EE modules is that applications which already migrated from JDK 6, 7, or 8, to JDK 9, will not start if they use the command line flag
--add-modules java.se.ee,--add-modules java.xml.bind, etc.
CORBA applications that rely on RMI-IIOP, the javax.activity package, or the endorsed CORBA APIs will not compile or run.
Aleksey Shipilëv, principal software engineer at Red Hat, recently tweeted that the SPECjbb2015 benchmark is broken on Java 10+ due to the JAXB module being removed with JEP 320. The suggested fix was to include the JAXB dependency:
<dependency>
<groupId>javax.xml.bind</groupId>
<artifactId>jaxb-api</artifactId>
<version>2.3.0</version>
</dependency>
New Java SE Release Cadence
The new Java release cadence is in full swing with the release of JDK 10 six months after JDK 9 and with JDK 11 still scheduled for release in September 2018. Developers, who had become accustomed to waiting multiple years for new versions of Java, may now find themselves with mild culture shock due to the new release cadence.
The official Java Twitter account recently tweeted a photo to explain the new release cadence:
There has been some recent buzz in the Java community about the new release cadence. Daniel Fernández, founder and lead developer at Thymeleaf, recently tweeted:
2016: "Java is doomed! It evolves so slowly! Every good idea takes ages to be available!"
2018: "Java is doomed! It evolves too quickly! Nobody will be able to keep pace!"
Some interesting responses to Fernández's tweet included:
"Kotlin?"
"What will be in 2020? Java is doomed! I can't live my life without it! My home is fitted everywhere with Java. What power in that small coffee cup. It's controlling my home including my movements."
"Java is doomed because they focus on completeness instead of simplicity"
"The lesson here is that change is less of a problem than the (phase(d)) transition itself...in fact this seems to be a recurring issue with everything in life and computer science."
"I saw someone complaining that Java 10 shouldn't have been released until the IDEs were updated to support it. Like the chicken and the egg problem, except the chicken already exists and is supposed to wait for an egg to appear."
"2016 complainers: let's use JavaScript instead (YOLO). 2018 complainers: the same 2016 complainers who switched to JavaScript now switching back to Java because YOLO is hard to maintain."
"Java is doomed because of Oracle."
Time will tell how this new release cadence will affect the Java community.
Resources
- Java Version History as listed in Wikipedia
- The Future of JavaFX and Other Java Client Roadmap Updates by Donald Smith (March 7, 2018)
- Duke Takes His Last Tumble by Simon Ritter (March 15, 2018)
- The Incredible Shrinking Java Platform by Simon Ritter (March 21, 2018)