Duke Takes His Last Tumble
Duke Takes His Last Tumble
Java has changed more in the past year than perhaps in its entire history, and more changes are coming. See what's being altered or removed in upcoming JDKs.
Join the DZone community and get the full member experience.Join For Free
FlexNet Code Aware, a free scan tool for developers. Scan Java, NuGet, and NPM packages for open source security and open source license compliance issues.
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.
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 centralized 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.
Published at DZone with permission of Simon Ritter , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.