Duke Takes His Last Tumble

JDK 11

Click here for more info on the rapid release cadence of the JDK

When Java was first released, the world was a very different place. This was 1995, and the Internet and World Wide Web were still very much in their infancy. When James Gosling and John Gage demonstrated the WebRunner browser (as it was then called) running a Java applet that could rotate a molecule, the world changed. Suddenly, the web went from having only static content with hypertext links to a dynamic, interactive system.

From tiny acorns, mighty oak trees grow (if you’ll excuse the pun) and that’s precisely what we’ve seen with the web. Almost every aspect of our lives from information access to banking to social interaction now takes place through the Internet and the web. What we experience through the browser has changed beyond all recognition.

Although fundamentally the same as when it was launched, Java has changed significantly too. Generics, Streams and Lambdas are just a few of the language changes. There are over four thousand more classes in the core libraries, and we finally have a module system. The JVM has one more bytecode than it did when it was launched, doesn’t need to pause for garbage collection (if you use Zing) and can JIT compile code to run faster than some natively compiled code.

I also think it’s fair to say Java has changed more in the last six months than in the previous ten years: the module system, a new release cadence and an entirely new scheme for update availability.

The changes continue.

Last week, Oracle announced that, as part of their goal of eliminating differences between the Oracle JDK binary and one built from the OpenJDK source, a number of features would disappear in JDK 11. These fall into two areas, both related to Java on the desktop.

The first change is that the JavaFX modules (there are currently eight) will no longer be included with the Oracle JDK. JavaFX dates back to 2007, when it was announced at JavaOne, using a new scripting language rather than standard Java. This did not prove popular, so a reboot was attempted, rewriting JavaFX as a set of class libraries. Personally, I love JavaFX and have written a number of demos using it. With the addition of 3D support a few years ago it is a comprehensive set of libraries that enable cross-platform user interface code to be developed in Java. The reality is, however, that it occupies something of a niche in this area. Most developers use HTML5 and JavaScript, which can deliver complex application functionality through the browser. All without the need for any plugins or special libraries. JavaFX is already has its own open source project called OpenJFX; the hope is that decoupling it from the JDK will allow it to progress at its own pace. I hope that doing this leads to greater success for JavaFX.

The second change is that there will be no more support for Applets, which means the browser plugin, will cease to be part of the JDK. Browser vendors have made it harder and harder to enable Java, due to the number of security issues that the plugin has had. Because of the popularity of HTML5 and JavaScript for browser-based applications, nobody is developing new Applets. A few people do still use Applets: I believe there are some banking applications and they seem to be used for internal systems by a number of enterprise customers.

Related to Applets, and also disappearing in JDK 11, is Web Start. This was an interesting idea that combined the best qualities of Applets and applications. Using a Java Network Launch Protocol (JNLP) file, you could download an application to your PC and have an icon created on the desktop for double-click startup. When you launched the application, it would check with the configured server to see if any jar files needed updating and download them if necessary. Sadly, this never really caught on either but again; there are still a few diehard users out there. One thing that is not clear from either the Oracle blog entry or the Java Client Roadmap Update whitepaper is whether the javapackager command will continue to be included. I checked the early build of JDK 11, but this still includes appletviewer and javaws, so I don’t think, because javapackager is still there, that it will necessarily be in the GA of JDK 11.

This leads us to the question of how you should deploy Java applications in this brave new world? The answer is to take advantage of the Java Platform Module System (JPMS) and the jlink command. The power of jlink is that you can quickly build a Java runtime that is tailored to your application, only including the modules required. This minimises the space required and makes the runtime suitable for both desktop and server (especially microservice-based applications). With JPMS, all you need to specify for jlink is the module containing your main entry point, and the tool will figure out the module dependency graph for you. No need to specify everything explicitly.

With the rapid release cadence of the JDK now in full swing, it becomes much more logical to move away from a centralised Java runtime for all applications on a particular machine to embedding the application modules in their own runtime. In addition, by decoupling the application from a shared Java runtime, any updates can be dealt with on an application-by-application basis providing simplification and greater flexibility for deployment.

For ISVs, this becomes the obvious way to deliver Java software. By removing the reliance on a separately installed JDK, they can eliminate the need to resolve issues connected to customers not having the exact version required to support a given version of their software. The ISV retains control of the runtime and ensures the whole package is tested and verified as a single entity, ready for use by customers.

I don’t think this is the end of major changes for Java. Let’s see what happens next.

© Azul Systems, Inc. 2018 All rights reserved.