We’ve been waiting a long time for Project Jigsaw’s arrival. Now that it’s almost here, we have even more to look forward to with talented developers in the Java community proposing a new feature that will take advantage of the mechanisms being built to support Jigsaw.
TL;DR: A new JDK Enhancement Proposal (aka JEP 11) introduces playground incubator modules that target experimental features to either be adopted and standardized in the next version or Java, or to otherwise be removed quietly from the JDK. The first feature to be introduced as a part of this project is Java’s HTTP/2 Client.
Many questions immediately come to mind. Simple ones like, what are the actual logistics of this, will there be more than one feature per module, etc.? And more complicated ones, like what does this mean for dependencies, will this cause fragmentation of the Java Platform?
Let’s not waste any time in getting to the answers.
— OverOps (@overopshq) August 16, 2017
The Impact of Modular Java
Introducing modularity to Java is something that’s been discussed since at least 2008, when Mark Reinhold proposed modularization of the Java Platform as a possibility in Java 7. Nine years later, we’re expecting Java modules to be a transformative part of the upcoming Java 9 release.
With the release of Project Jigsaw, Java’s module project, not only will we have a good alternative to getting stuck in Classpath or JAR Hell but already new feature proposals are surfacing that depend on the mechanisms of the module system. Incubator Modules are one example of an enhancement proposal that fully takes advantage of the modular system in order to introduce a new Java capability (or, many new Java capabilities depending on how you look at it).
What is an Incubator Module?
Upon hearing of incubator modules, it’s possible that the first thing that pops into your mind is Project Amber which was introduced in early 2017 as an incubator for productivity-oriented Java language JEPs like Local Variable Type Inference (JEP 286) and Enhanced Enums (JEP 301). Incubator modules are similar but for APIs in a different stage of development. Whereas Project Amber is a project that will allow the OpenJDK Community to prioritize the maturation of selected proposals, incubator modules aim to enable enhancement of proposals with the input of a wider audience as part of new JDK Release Projects. Incubating features are ones that are not yet standardized and could benefit from further experience in order to either be proven or disproven.
Incubator modules will put unfinished APIs in the hands of developers as changes and adjustments are made. Ultimately, a new JEP will be crafted to reflect these changes or otherwise it will removed from the Platform entirely. Although each incubator module will correspond to a single incubating feature, if a new JEP is created, the promoted API can be integrated into an existing standard module rather than to another individualized one.
The lifetime of these incubating modules will be strictly limited to a single release cycle. So, for example, incubating APIs released with Java 9 in September must be standardized and finalized in Java 10, or else removed from the JDK.
Goals and Motivation
The basic goals of Incubator Modules, stated in JEP 11, is to enable the OpenJDK Community to distribute non-final APIs with JDK Release Projects. As Chris Hegarty, Oracle’s team member responsible for creating incubator modules, writes, “many Java SE Platform or supported, JDK-specific APIs would benefit from spending a period of time in a JDK Release Project prior to being standardized in the JCP or otherwise being deemed stable.”
The benefits will be similar, but more impactful, than those reaped from Early Access (EA) releases of the newest Java Platform version. Stated specifically in the JEP is the gained ability for features to receive feedback from a wider audience than just the OpenJDK Community.
HTTP/2 Makes Debut as Incubator Module
For more than 15 years, HTTP/1.1 was ruling the Web and Java’s HttpURLConnection API provided decent support. With the standardization of HTTP/2, though, the time has come for an update to the legacy HttpURLConnection API.
While originally slated for complete integration in Java 9, the HTTP/2 Client API will be introduced as the first incubator module in Java 9. The three main implications of the HTTP/2 Client being implemented as an incubator module are:
1. It won’t be included in the SE Platform
2. It will be in the jdk.incubator namespace rather than java.net
3. It won’t resolve by default at runtime (this is true for all incubator modules)
Some notable goals for the API include compatibility with HTTP/2 (obviously), being friendly towards lambda expressions and other new language features, and support for basic and common authentication methods. Along with the dozen or so other goals listed in the proposal is that standardization in the SE Platform in Java 10 will be achieved through the additional experience gained from wider exposure as an incubating API.
Aside from the HTTP/2 Client API, jlink (JEP 282) is also expected to be refactored into an incubator module in the future. Keep an eye out for a more in-depth look at HTTP/2 Client in the coming months, and subscribe below to get a notification when it’s live!
Fragmentation and Dependency Issues
Amid remarks that incubator modules will cause fragmentation issues, Brian Goetz dismisses concerns claiming that, “fragmentation isn’t really an issue since incubator modules are, by their nature, self-fragmenting to start with.” While it makes sense that developers would be concerned about using APIs that can change or outright disappear without notice, those who don’t want to incorporate a package defined by a potentially volatile feature simply won’t use them. This is similar to the tendency for most developers to wait for the General Availability (GA) Release of a new Java version rather than starting to use the Early Access (EA) Release.
Dependency issues are another big question when considering the use of incubating APIs. It specifically states in the proposal that, “An incubating feature need not be retained forever in the JDK Release Project in which it was introduced, nor in every release of downstream binaries derived from that Release Project.” Modular applications will be allowed to specify direct and transitive dependencies on incubator modules, but use of these APIs may need to be refactored in the case that significant change are made during incubation. This is simply a risk that developers will need to acknowledge from the start.
As with just about any other feature proposal that’s introduced to the Java Platform, the community has mixed feelings. While some are excited at the prospect of being able to get earlier access to new features, other are concerned about the implications that such a capability will have:
— Martijn Verburg (@karianna) December 6, 2016
I can see one of these “incubator modules” easily becoming part of a mission critical component in production, despite repeated warnings. https://t.co/jC8q9xrb8U
— Luke deGruchy (@LukeRdeGruchy) December 2, 2016
Soon, incubator modules will be bringing new Java features to the masses earlier than ever before. Despite understandable concerns about the hazards of using APIs that are subject to change or removal, the ability to experiment with new features and provide actionable feedback is almost certain to be beneficial to Java. Java is plagued by constant complaints about how this or that feature could be better, and now, Java users will have the chance to give this input before features are released in the Java SE Platform.
Anyways, to make a long story short, use incubator modules if you’re interested in early access to new features and sharing feedback about what works and what doesn’t. Just be aware that, at the very least, you’ll have to change your import statements when the API is finalized and standardized, and more adjustments will be required if the API is changed drastically or removed entirely.
One Last Thing
Implementing incubator modules is a move by the OpenJDK Community to see how users interact with features and what breaks or doesn’t work before it causes serious problems in the SE Platform. It’s more or less a form of testing in production. We all know that no matter how many tests you put your code through, new problems and exceptions are bound to come out when it’s pushed to production. So, why not try to get that information before permanent changes are made.
We don’t have the answer for building Java features that the whole community will be happy with (does such a thing even exist?), but we can reveal the root cause of all caught and uncaught exceptions in production. That’s what our mission is here at OverOps, to show developers when, where, and why code breaks in production.