Java SE 9 boasts modularity, REPL, compiler improvements, and much more—but it is also the end of its line
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.
Oracle has posted the Java SE 9 JDK and documentation for download by developers.
Debuting nearly three years after Java SE 8, Java SE 9 has several key architectural changes, as well as a host of improvements.
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.
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.
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.
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.
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.
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.
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.
