Java 9 is here: Everything you need to know

Java 9—formally, Java Platform Standard Edition version 9—is finally here, and its Java Development Kit (JDK) is available for developers to download.

It has several important if controversial new features, but is also the last of the line for the old style of Java delivery.

Where to download the Java 9 JDK

Oracle has posted the Java SE 9 JDK and documentation for download by developers.

The key new features in Java 9

Debuting nearly three years after Java SE 8, Java SE 9 has several key architectural changes, as well as a host of improvements.

Java 9’s modularity is a game-changer

The new, controversial modularity capabilities, based on Project Jigsaw, are sure to pique the interest of cutting-edge Java shops that want to see what JDK 9 has to offer now, even if more-conservative shops decide to wait for modularity to mature.

Modularity—in the form of the Java Platform Module System—divides the JDK into a set of modules for combining at run, compile, or build time. Modularity has been called a “transitive” change, enabling understanding of dependencies across modules.

Java 9’s modularity is supposed to let developers more easily assemble and maintain sophisticated applications. Also, it should make Java better able to scale down to smaller devices while security and performance are improved.

The modularity aspects of Java 9 include application packaging, modularizing the JDK itself, and reorganizing source code into modules. The build system is enhanced to compile modules and enforce module boundaries at build time. JDK and Java Runtime Environment (JRE) images are restructured to handle modules. Also, JavaFX UI controls and CSS APIs are now accessible for modularity.

A host of configurations are supported; as a result, scalability, security, and application performance should be improved. Easier scaling of Java down to small devices is a key driver of the modular effort.

With modularity, developers will be better able to construct and maintain libraries and large applications for both Java SE (Standard Edition) and Java EE (Enterprise Edition). But during Java 9’s development Oracle, IBM, Red Hat, and others had big disagreements over exactly how to make such a radical change in the platform. The module system itself was rejected in May, only to be approved on a second vote in June, after progress was made.

Even with agreement among the major Java vendors, there remains controversy over whether modularity will do Java developers much good, with some experts saying yes and others saying no. Regardless, Java 9 is now modularized.

To make migration to modularized Java 9 easier, Java 9 allows illegal reflective access for code on the class path, used by the JRE to search for classes and resource files. This capability will be disallowed after Java 9.

Compiler improvements for Java 9 code

The Java 9 upgrade features several new capabilities for compiling code, chief among them being ahead-of-time (AoT) compilation. Still in an experimental phase, this capability enables compilation of Java classes to native code before being launched in the virtual machine. This feature is intended to improve startup time of both small and large applications, with limited impact on peak performance.

Just-in-time (JIT) compilers are fast, but Java programs have become so large that it takes a long time for the JIT to fully warm up, leaving some Java methods uncompiled and weakening performance. Ahead-of-time compilation is meant to address these issues.

But Dmitry Leskov, marketing director at Java technology vendor Excelsior, worries that the ahead-of-time compilation technology is not mature enough and wishes Oracle had waited until Java 10 for a more solid version.

Java 9 also offers phase two of Oracle’s smart compilation deployment. This feature involves improving the s javac tool’s stability and portability so it can be used in the JVM (Java Virtual Machine) by default. The tool will also be generalized so it can be used for large projects outside of the JDK. JDK 9 has also updated the javac compiler so it can compile Java 9 programs to run on some older versions of Java.

Another new—but experimental—compilation feature is the Java-level JVM Compiler Interface (JVMCI). This interface lets a compiler written in Java be used as a dynamic compiler by the JVM. JVMCI’s API provides mechanisms for accessing VM structures, installing compiled code ,and plugging into the JVM compilation system.

Writing a JVM compiler in Java should allow for a high-quality compiler that is easier to maintain and to improve than existing compilers written in C or C++. As a result, compilers written in Java itself should be easier to maintain and improve. Other, existing efforts to enable in-Java compilers include the Graal Project and Project Metropolis.

A new compiler control capability is intended to provide fine-grained and method-context-dependent control of JVM compilers, letting developers change the compiler control options in runtime with no performance degradation. The tool also enables workarounds for JVM compiler bugs.

REPL finally comes to Java 9

Java 9 features a read-eval-print loop (REPL) tool—another long-term goal for Java that is getting real in this version, after years of development under Project Kulia.

Called jShell, Java 9’s REPL interactively evaluates declarative statements and expressions. Developers can get feedback on programs before compilation just by entering some lines of code.

The command-line tool’s capabilities includes tab completion and the automatic addition of needed terminal semicolons. The jShell API allows jShell functionality in IDEs and other tools, although the tool itself is not an IDE.

The lack of a REPL has been cited as a reason for schools to move away from Java. (Languages such as Python and Scala have long had a REPL.) But Scala language founder Martin Odersky questions the usefulness of a REPL in Java, saying Java is statement-oriented whereas REPLs are expression-oriented.

Enhancements to the Streams API in Java 9

Streams in Java let developers  express calculations so that data parallelism can be efficiently exploited. The Stream capability in Java 8 is for processing data declaratively while leveraging multicore architectures.

In Java 9, the Streams API adds methods to conditionally take and drop items from Stream, iterate over Stream elements, and create a stream from a nullable value while expanding the set of Java SE APIs that can serve as Streams sources.

Code cache can be divided in Java 9

JDK 9 allows code cache to be divided into segments to improve performance and allow extensions such as fine-grained locking. The results should be improved sweep times due to specialized iterators skipping non-method code; separating non-method, profiled, and non-profiled code; and improving execution time for some benchmarks.

Better JavaScript backing in Java 9 via Project Nashorn

Project Nashorn, which provides a lightweight JavaScript runtime for Java, is being improved in JDK 9. Project Nashorn was an effort to implement a high-performance, but lightweight JavaScript runtime in Java, following up the Rhino project that was begun at Netscape. Project Nashorn was charged with enabling the embedding of JavaScript in Java applications. It provided Java with a JavaScript engine in JDK 8.

JDK 9 includes a parser API for Nashorn’s ECMAScript syntax tree. The API enables ECMAScript code analysis by IDEs and server-side frameworks without depending on Project Nashorn’s internal implementation classes.

HTTP/2 client API comes to Java 9

The beta HTTP/2 client API has come to JDK 9, implementing in Java the upgrade to the web’s core HTTP protocol. WebSocket is supported by the API as well.

The HTTP/2 API can replace the HttpURLConnection API, which has had problems, including being designed with now-defunct protocols, predating HTTP/1, being too abstract, and being hard to use.

Improved HTML5 and Unicode support in Java 9

In JDK 9, the Javadoc documentation tool is enhanced to generate HTML5 markup. The Unicode 8.0 encoding standard—which adds 8,000 characters, 10 blocks, and six scripts—is supported as well.

DTLS security API is added to Java 9

For security, Java 9 adds an API for DTLS (Datagram Transport Layer Security). The protocol has been designed to prevent eavesdropping, tampering, and message forgery in client/server communications. An implementation is provided for both client and server modes.

What Java 9 deprecates and removes

Java 9 deprecates or removes several features no longer in vogue. Chief among them is the Applet API, which is deprecated. It has gone out of style now that security-conscious browser makers have been removing support for Java browser plug-ins. The advent of HTML5 also helped bring about their demise. Developers are now guided to alternatives such as Java Web Start, for launching applications from a browser, or installable applications.

The appletviewer tool is being deprecated as well.

Java 9 also deprecates the Concurrent Mark Sweep (CMS) garbage collector, with support to cease in a future release. The intent is to speed up the development of other garbage collectors in the HotSpot virtual machine. The low-pause G1 garbage collector is intended to be a long-term replacement for CMS.

Meanwhile, garbage collection combinations previously deprecated in JDK 8 are removed in JDK 9. These include rarely used combinations such as Incremental CMS, ParNew + SerialOld, and DefNew + CMS, which added extra complexity to the garbage collector code base.

Java 9 also elides Java warnings on import statements, to help make large code bases clean of lint warnings. With these code bases, deprecated functionality often must be supported for some time, but importing a deprecated construct does not warrant a warning message if uses of the construct are intentional and suppressed.

Also removed in Java 9 is the ability to select the JRE at launch time via the Multiple JRE (mJRE) feature. The capability was rarely used, complicated the implementation of the Java launcher, and it was never fully documented when it debuted in JDK 5.

Oracle has removed the JVM TI (Tool Interface) hprof (Heap Profiling) agent, which has been superseded in the JVM. The jhat tool was removed as well, having been made obsolete by superior heap visualizers and analyzers.

Java 9 is the end of its line as new Java 9 line begins

You could say that Java 9 is going out with a bang, with all the new capabilities. Oracle recently revealed that Java 9 is the last of its kind, in terms of its designation and time elapsed between major releases.

From here on out, Java is planned to have a six-month release cadence, with the next major version, to be called Java 18.3, due March 2018, followed by Java 18.9 six months later.

Java’s new release cadence also means JDK 9 will not be designated as a long-term support release. Instead, the next long-term release will be Java 18.9.

Java’s faster release cadence means developers won’t have to wait as long for major releases.It also may mean that developers will skip Java 9 and its “immature” modularity features and wait six months for the new version, which would likely iron out any kinks, said Simon Maple, director of Java advocacy at Java tools vendor ZeroTurnaround.