What to expect in Java 9’s JDK: More than modularity

Modularity, compilation, REPL, and more highlight the first major change to the Java Development Kit in more than three years

Credit: 422737

After multiple delays, Java 9, the first major upgrade to the standard edition of Java since March 2014, is due to arrive on September 21, in the form of Java Development Kit 9. The official proposal for JDK 9 lists roughly 90 new features; modularity is the major one, reconfiguring Java into a modular format in an effort that has gone on for years. But there are other improvements in areas such as compilation, code cache and JavaScript accommodations.

Here’s what to look for in JDK 9.

JDK 9’s Java Platform Module System

The Holy Grail of Java 9 features, modularity—in the form of the Java Platform Module System—is intended to enable the JDK to be divided 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.

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

A host of configurations will be supported; scalability, security, and application performance should be improved. Easier scaling of Java down to small devices is a key driver of the modular effort. The Java Platform Module System, a component of Project Jigsaw, will be implemented.

With modularity, developers will be better able to construct and maintain libraries and large applications for both Java SE (Standard Edition) and EE (Enterprise Edition). But Oracle, IBM, Red Hat, and others have had 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.

There remains controversy over whether modularity will do Java developers much good, with some experts saying yes and others saying no. Regardless, Oracle has pursued its efforts to modularize the platform.

Modularity already has delayed Java 9 on multiple occasions as Oracle has been trying to make migration to Java 9 easier, with a plan to allow 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.

Compilation in Java 9’s JDK

The Java 9 upgrade features several new capabilities for compiling code, chief among them being ahead-of-time 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.

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++. 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’s JDK will also update the javac compiler so it can compile Java 9 programs to run on some older versions of Java.

REPL finally comes to Java 9

Java 9 will feature 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 will include tab completion and the automatic addition of needed terminal semicolons. The jShell API will allow 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.

Segmented code cache in JDK 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. 

Java 9 supports more standards

Java 9 adds support for several standards.

The new HTTP/2 client API implements HTTP/2, the upgrade to the Web’s core HTTP protocol, and WebSocket, for browser-based interactive communications. The API can replace the HttpURLConnection API, whose problems include being designed with now-defunct protocols, predating HTTP/1, being too abstract, and being hard to use. However, the new HTTP/2 API will still be in beta stage when released in JDK 9.

JDK 9 also adds support for HTML5. The Javadoc API documentation tool is being enhanced to generate HTML5 markup.

Java 9 also will support the Unicode 8.0 encoding standard, which adds 8,000 characters, 10 blocks, and six scripts.

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 will be provided for both client and server modes.

JDK 9 gets more Project Nashorn JavaScript support

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 is set to include a parser API for Nashorn’s ECMAScript syntax tree. The API will enable ECMAScript code analysis by IDEs and server-side frameworks without depending on Project Nashorn’s internal implementation classes.

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 will be 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 will be 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 will deprecate 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 deprecated in JDK 8 will be 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 will elide 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 being 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 was never fully documented when it debuted in JDK 5.

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

Join the newsletter!

Error: Please check your email address.

More about CMSIBMOracleRed HatScalaTransportUnicode

Show Comments

Market Place

[]