There has been a tremendous amount of information, and a fair amount of disinformation, coming out over the last several months with regards to Java versioning, the effects of modularization, and how projects like Jetty may or may not respond to them. In light of that, we wanted to more comprehensively explain what we have seen thus far, where things are going, and what we are planning to do with Jetty. We are also interested in any feedback from our clients as to what their expectations might be as well as any trials and tribulations you might be having.
With that in mind, here we go!

Oracle’s new JDK Release Schedule

Oracle has published an updated JDK release schedule.
Oracle will make JDK 8 updates for critical bugs or security fixes publicly available until January 2019. After that, you need to purchase Oracle support for the JDK if you want to continue to use JDK 8 and receive the latest bugs and security fixes.
As part of their revamped Support Roadmap, Oracle has introduced the term “Long Term Support” for certain JDK releases. However, the term may be confusing, as it practically refers only to customers that purchase Oracle support for the JDK.
Therefore, if you don’t purchase Oracle support for the JDK, then:

• JDK 8 will be updated up to January 2019; after that, the supported JDK version will be JDK 11.
• JDK 9 will not be updated.
• JDK 10 will be updated up to September 2018; after that, the supported JDK version will be JDK 11.
• JDK 11 will be updated up to March 2019; after that, the supported JDK version will be JDK 12.
• JDK 12 will be updated up to September 2019; after that, the supported JDK version will be JDK 13.
• And so on.

In different words, those that did not purchase Oracle support for the JDK will have “Long Term Support” by moving to a new JDK version every 6 months.
Alternatively, it is possible to stay on JDK 11 for more than 6 months by purchasing Oracle support for the JDK, as outlined in the JDK release schedule linked above.

Oracle’s JavaFX Support

Oracle’s JavaFX support is outlined in this blog post.
JavaFX was previously bundled with the JDK, but starting in JDK 11 this will no longer be the case, and JavaFX will be available as a separate download.

Jetty and JDK versions

Jetty 9.4.x will be supported on publicly available releases of the JDK from JDK 8 or later. However, we strongly encourage Jetty users to keep pace with JDK releases, to benefit from critical bug fixes, security fixes and new features. At the time of writing Jetty 9.4.x already builds and runs on JDK 8, JDK 9, JDK 10 and early access builds of JDK 11.
JDK 11 will remove classes previously available in the JDK, as detailed in this issue on GitHub. Jetty does not need those classes, but often applications do.
Standalone Jetty users will have the choice of either adding the jars containing those classes to their applications (for example in the WEB-INF/lib directory of a web application) or to write a custom Jetty module that exposes those classes to all web applications deployed to Jetty.
Embedded Jetty users will need to add the jars containing those classes to the classpath.
If you have questions as to what jars are available for your specific need that may be removed we encourage you to reach out to us early!

Recommended JDK version migration plan

We strongly recommend to start planning an upgrade to a JDK version greater than 8 (at this time, JDK 10) right now. Moving from JDK 8 to JDK 11 in September 2018, when JDK 11 will be out, will likely be a too big of a change and too risky.
In particular, the update from JDK 8 to JDK 9 resulted in a possibly large number of incompatibilities, among which include:

• Removal of tools.jar
• Removal of JavaDB
• Removal of the endorsed directory mechanism
• Removal of the extension directory mechanism
• Classloading implementation changes
• A new Java version string scheme – leads to issues when parsing the Java version string
• Removal of non-critical internal APIs – for example sun.misc.Base64Decoder
• URLStreamHandler mechanism changes
• Removal of many (50+) JVM startup options – the JVM refuses to start if a removed option is specified on the command line
• New format for the JVM logging – big impact on GC logging

The main problem is that many of these issues may impact your application and all the libraries your application depends on. Your application may not perform classloading, or lookup the system property “java.version”, but the libraries your application depends on may do so. Most of the issues listed above will only manifest at runtime, perhaps while executing an if statement branch that may only be entered under rare conditions.
The changes listed above impact not only the development of your applications but also their build and their deployment. In some cases, development and deployment are the responsibility of different departments throughout a company, and it may take time to coordinate the changes.
The best approach for the development side is to update both your build tools (for example, Maven and Maven Plugins) and your library dependencies to their latest versions.
After that, it is a process of trial and error to make sure that your application works correctly in every possible scenario. A good test suite helps tremendously in this case, as you will be able to test most if not all of your code.
The update from JDK 9 to JDK 10 should instead be really smooth, typically just a matter of updating the JDK: if your application works in JDK 9, most probably will work in JDK 10 without changes. The update from JDK 10 to JDK 11 may again have issues because of the classes removed from JDK 11, as discussed above.
In light of the large number of changes that happened with JDK 9, and considering that the changes may affect your application and the libraries your application depends on (which you may need to update, or ask their maintainers to update), and further considering that the changes affect the build, development and the deployment of your applications, we strongly suggest that you start planning for these changes right now, as putting it off any longer may be too late. If you cannot finish the migration from JDK 8 to JDK 11 by January 2019, you risk running on an outdated JDK 8 release that may contain critical bugs or security issues.

JDK Vendors

Since OpenJDK is an open source project, many vendors have licensed the Java Test Compatibility Kit (TCK) and will produce OpenJDK builds that have passed the TCK and therefore are suitable for production use.
Among these vendors there are:

• Oracle
• RedHat (https://access.redhat.com/articles/1299013)
• Azul Systems (https://www.azul.com/products/zulu-and-zulu-enterprise/)
• London Java Community (LJC) (https://www.infoq.com/news/2018/03/AdoptOpenJDKMar18)

These vendors, excluding LJC, will offer free OpenJDK builds that are TCK-tested for the current JDK version and commercial support for previous JDK versions.
Azul System has nicely summarized both Oracle’s and their own support plans for JDK 8 through JDK 19 in the graphs at this page.
LJC is providing free OpenJDK builds that are TCK-tested at this page: https://adoptopenjdk.net/. LJC “support” is just to build and TCK-test the tags of the OpenJDK project.
For example:
You decide to use JDK 9; the current version is JDK 10; a JDK security issue is discovered. Then:

• The issue will be fixed in the OpenJDK 10 project and a new OpenJDK 10 tag will be created.
• Oracle will issue a new micro version of JDK 10 (e.g. 10.0.2).
• LJC will provide an OpenJDK 10 build for the newly created OpenJDK 10 tag.
• If the issue is backported to OpenJDK 9 (and a new OpenJDK 9 tag created), then:
  • Oracle will not provide any support (will ask you to move to JDK 10.0.2)
  • Azul will provide a JDK 9 build, but only to its paying customers
  • LJC should provide a free OpenJDK 9 build for the newly created OpenJDK 9 tag.

JakartaEE and JavaEE

In addition to the efforts by Oracle to plot a more rapid release environment for the JDK, they have donated the entire JavaEE platform to the Eclipse Foundation. JavaEE has been subsequently rebranded as JakartaEE and is currently under the process of being migrated and re-released with the same version number. That is JavaEE 8 will be released as JakartaEE 8 once that migration process has been completed. One interesting note is there is as this point no API changes nor functionality changes for JakartaEE 8 which will carry with it the same minimal JDK 8 version.
A point of interest, Webtide has members who are serving as co-leads on both the Servlet and Websocket specifications as well as Architecture Council representation within the Foundation itself.

What everything means!

The Jetty team has already, and will continue to, do the work of migrating and making sure the Jetty code base is compatible with the most up-to-date JDK versions. In addition, we will endeavor to support the minimal version of JDK that is required for the forthcoming JakartaEE specifications. As new JDK versions are released, we are constantly updating and reviewing them to guarantee Jetty remains stable and ready for consumption.
This means that for now, it is our intention to support JDK 8, 9, 10, and 11 for Jetty 9.4.x releases. We have yet to begin Jetty 10.0.x releases due in large part to the upheaval associated with the JakartaEE code donation coupled with this relatively new accelerated JDK release schedule. We anticipate a different approach to new Jetty 10.0.x releases as they relate to JDK releases but nothing is set in stone in this regard. One approach may be to support the minimal version required by the JakartaEE version and the most current two JDK releases. It seems an untenable situation to pledge support for a minimal version like JDK 8 and every version of the JDK between official LTS versions (JDK 11 through JDK 17!).
Regardless, we are always available to assist our clients with any questions or migration issues may come across related to this situation. If you have internal plans for how you intend to update JDK versions in the future or expectations on how Jetty will interact with future JDK releases we encourage you to share with us to help manage expectations.