Java SE 11: The Great Removal

Java SE 11 has been released, with fairly few minor new features. That’s not surprising as Java 11 receives long-term support in Oracle’s new release cadence, so its main purpose is to stabilize the major changes from the previous short-term versions. The bigger issue with Java 11 is what it removes, as well as an important license change. The Java Champions have put together a long article that describes the new licensing options, release roadmap, and third-party alternatives. More on the license below, but let’s first summarize the removals from the JDK itself as detailed in the JDK Migration Guide.

• No more separate JRE download. This makes sense from a size perspective, as the JDK shrank from 390 MB (Oracle’s executable installer for Windows) to a mere 151 MB, or 178 MB for the OpenJDK ZIP archive. By comparison, Oracle’s Java SE 10 JRE executable installer for Windows was already over 100 MB.
• The entire deployment stack is gone, including Java applets and Applet Viewer, Web Start, browser plug-in, Java Control Panel with automatic updates, javaws and javapackager.
• Likely because the deployment stack is gone, the JDK is now only available in English, Japanese, and Simplified Chinese. Seven other previously supported (European) languages were dropped.
• The Lucida fonts (Sans, Bright, Typewriter) are no longer included. Font rendering now exclusively uses preinstalled operating system fonts, unless you ship your own fonts with your application.
• All remaining Java EE and Corba modules are gone, along with related tools. Some APIs are still available on the dedicated Java Enterprise Edition website.
• Java Mission Control has been open-sourced and was consequently removed from the JDK.
• And of course JavaFX has been split off. More on that below.

Lastly, while the Nashorn JavaScript engine was not yet removed it has been deprecated because Oracle found it “challenging to maintain” given the rapid pace of JavaScript language changes.

You Must Use OpenJDK

Oracle’s Java SE 11 download page highlights its “substantially different” license agreement, and they aren’t kidding. The old license for Java SE 10 permitted any use for “running programs” as well as redistribution, excepting only embedded platforms. The new license explicitly prohibits “any data processing or any commercial, production, or internal business purposes other than developing, testing, prototyping, and demonstrating” applications, plus redistributing any part of JDK 11 to anyone other than “contractors.”

So you may not use Oracle’s JDK 11 to actually run programs unless you have a contract with Oracle. Donald Smith explicitly calls the new license “commercial” if you had any doubt. Everyone else must now use the GNU GPL licensed OpenJDK build. Annoyingly, this is only a ZIP file with no installer, and currently has no installation instructions either – the provided link unhelpfully only covers Oracle’s executable installer.

This is a serious problem for distributing Java applications to non-developers. You either somehow get them to install OpenJDK, or you bundle everything you need from the JDK into a local JRE that comes with your application. Annoying, but consistent with Oracle’s removal of the entire deployment stack. They are clearly no longer interested in supporting end users directly. That’s all up to application developers now.

Addendum 2018-09-28 — Note that there are other JDKs than Oracle’s and the official OpenJDK build. Trisha Gee gives an overview of the situation with links to alternative options. Stephen Colebourne has also written extensively on the subject.

Farewell to JavaFX

A while ago Oracle decided to decouple JavaFX – never formally a part of Java SE anyway – and instead reinvest in AWT/Swing which finally got high DPI support among others. JavaFX is now maintained as an independent project on the OpenJFX website. While I don’t have any great concern about the future of JavaFX itself, its separation is problematic for end-user applications in the same way as the OpenJDK distribution format. OpenJFX offers three platform-specific ZIP files of about 40 MB each. Unfortunately they have to be platform-specific, as JavaFX has its own native rendering pipelines plus custom WebKit builds to power its WebView class.

So, if you intend to distribute OpenJFX applications to end users you have the OpenJDK problem all over again. You either give them even more complicated instructions on how to install that second ZIP file, or you link tens more megabytes into platform-specific distribution packages. Worse and unlike with OpenJDK, you now have this problem even if your users are actually Java developers themselves, as you can no longer assume they have JavaFX.

JavaFX seems to be most popular for in-house enterprise applications where all this doesn’t matter. However, it matters a lot to the tiny open-source applications I’ve been using JavaFX for. Their downloads are generally about one (!) MB each, so there’s no way I’m bloating them up with OpenJDK/FX bundling. Assuming an OpenJDK installation or giving instructions for one is bad enough. Doing the same for OpenJFX is out of the question.

Fortunately I don’t need any advanced JavaFX features; I’m mainly using it because it had high DPI support long before Swing. Now that Swing is the one framework that both supports high DPI and still ships with the JDK, the choice for me is clear. I’ll be porting my existing Java GUI applications to Swing while remaining on Java 10, and will only update to Java 11 once that process is complete.