What every Java developer needs to know about Java 9

Java 9 is slowly surfacing

Java 8 may only have been released a few months ago, but Oracle has already announced the first set of features that will be targeted for Java 9. On August 11th, Mark Reinhold, a Chief Architect for Java, made available an initial feature set to subscribers on the jdk9-dev mailing list.

The crop of features are being run under a relatively new process, known as Java Enhancement Proposals (JEP). This process allows new language and VM features to be prototyped and explored without the full weight of the normal Java standardization process, although the expectation is that suitable, successful JEPs would go on to formal standardization. There will, of course, be many other new features that will be introduced in Java 9, but in this post we are going to focus on two major enhancements — and examine how they relate to features added in Java 7 and 8.

New HTTP Client

The core support for HTTP in Java has not changed much since it was first introduced in Java 1.1 (way back in 1997). This is unfortunate for many reasons, not least of which is that HTTP has come to dominate over virtually every other protocol. This makes the original approach that Java took (which uses URLConnection to support multiple protocols) outdated and unnecessarily complex. The original API is also blocking and only implements HTTP 1.0, making it very expensive in terms of network overhead.

Of course, there have been some improvements in the 17 years since HTTP support was first added. One of the biggest came with Java 7 and the introduction of try-with-resources. This enables us to write code like this:


This snippet is now an extremely compact way to write a simple HTTP client. Unfortunately, the story isn’t all positive. If we want to have more control over the HTTP connection (e.g., by examining some of the headers as well as the HTTP payload), then we can write something like this:


This can’t be made to use try-with-resources because the URLConnection class does not implement the AutoCloseable interface, so variables of type URLConnection are not legitimate assignment targets for a try-with-resources clause. So whilst HTTP handling has improved, things are not as good as we might like. In the intervening years, many Java developers have started to use alternative HTTP libraries, such as those provided by Apache. These libraries are better in some respects, but none of them are perfect, andnone — as of the writing of this post — take advantage of Java 8 features (such as lambdas).

With all this in mind, the idea for a new HTTP API in the JDK core libraries seemed an obvious one. Some preliminary work was done as part of JDK 8, but there wasn’t enough time to finish it before the Java 8 ship date. While it would have been nice to have improved support with the current release, delaying until Java 9 means that we should be able to take advantage of the release of the new version of the HTTP protocol: HTTP/2. This major new release of HTTP (previously called HTTP/2.0) is expected to reach its final form by November 2014, in plenty of time for the Java 9 release schedule. We don’t know what the final syntax of the new Java 9 HTTP API will look like, but support for this new protocol is a major goal for the project.

You can find out more and follow the development of the API and supporting code on theJEP Page and the OpenJDK networking support mailing list.


Java has excellent support for XML and web services, but while XML may once have been the data format of choice, it has lost some of its shine in recent years. Instead, the world has increasingly moved towards JSON data delivered by simple web services that adhere to the REST style. In the EE 7 standard, there is some support for this technology. For example, consider this simple web service for initializing sessions with some authentication data:


The annotations are quite clear – this is a web service that will reside at a session relative to the application (or WAR file) root. It both produces (sends) and consumes (receives) JSON and expects to receive data via the HTTP POST method. There is some behind-the-scenes magic necessary to configure the mapping from Java objects to JSON, but these mappers are relatively straightforward to write and configure.

That’s all well and good for Java EE developers, but what about projects that are only using SE? Fortunately, Java 8 has a feature that is a huge help. This is the new JavaScript implementation, known as Nashorn. This replaces the older Rhino implementation (Nashorn is German for “Rhino”) with a modern, completely updated version of JavaScript. Nashorn is fully compliant with JavaScript standards and takes full advantage of the JVM. In addition, Nashorn features very tight two-way integration with Java. Let’s look at a simple example of how to use Nashorn to run a snippet of Javascript from a Java program:

This uses the script engine mechanism that was introduced with Java 6. However, it’s possible to run a Javascript REPL (Read-Eval-Print-Loop) on the console so that you can experiment with Nashorn directly. If you have Java 8 installed on your machine, and you have the bin directory of JAVA_HOME on your path, then from the console you can just type jjs and the REPL will come up:

This is all well and good, but it’s a fairly simple example. Let’s do something a bit more complex and look at how the integration with Java works. In particular, JavaScript functions are treated as essentially equivalent to lambda expressions. So we can write code like this:

That’s right – we took a JavaScript function and treated it as a lambda expression that was converted automatically to an instance of Callable. We then used the call() method that was on the resulting object.

Nashorn also provides full support for JSON via the expected parse() and stringify() methods, albeit at the cost of having to use JavaScript code in your programs alongside Java as illustrated below:

As well as the Nashorn route in Java 8, there’s also been the creation of JSR 353, which was released in May 2013 and was shipped as part of EE 7 (but did not make it into the Java SE 8 standard). Java 9 wants to improve on this by providing a modern, highly efficient API for handling JSON. Oracle hasn’t announced yet whether the new JSON API will build directly on top of JSR 353, but in the meantime, the page describing this new API for the JEP is at: http://openjdk.java.net/jeps/198; discussion can be found on the OpenJDK core libraries mailing list.

Modular source code

JDK source code will get reorganized into modules, the build system will get enhanced to compile modules, and module boundaries will be enforced at build time. “Project Jigsaw aims to design and implement a standard module system for the Java SE Platform and to apply that system to the platform itself and to the JDK. Its primary goals are to make implementations of the platform more easily scalable down to small devices, improve the security and maintainability, enable improved application performance, and provide developers with better tools for programming,” the JEP document says. Another project, Penrose, is looking into interoperability between Jigsaw and the OSGi component system for Java. Subsequent JEPs will modularise the Java Runtime Environment and JDK images and introduce a module system.

Process API updates

This will improve the API for managing operating system processes and is intended to overcome limitations of the current API that often forces developers to use native code. Java SE 7, the JEP notes, offers limited support for native operating system processes; the new API, though, needs to account for operating system differences, particularly on Windows. “The design of this API needs to accommodate possible deployment on smaller devices with different operating system models. It should also take into account environments where multiple Java virtual machines are running in the same operating system process,” the JEP document states.

Improve contended locking

The goal is to improve contended Java object monitors. The documentation says that “improving contended locking will significantly benefit real-world applications in addition to industry benchmarks such as Volano and DaCapo.”

Segmented code cache

This effort is intended to divide code cache into segments, each containing compiled code of a particular type, to improve performance and allow extensions.

Smart Java Compilation, Phase 2

This project is intended to improve the sjavac (Java programming language compiler) tool enabling it to be used by default in the JDK build and also to generalize it so it can be used to build large projects other than the JDK. “The current implementation has proved to be useful and does indeed improve build speed and allow for incremental builds. The quality of the code and stability of the tool as a whole, however, is not satisfactory and it is certainly not ready for public release,” the JEP document states.


Finally, as these APIs are sure to be favourites among Java User Groups, the creation of Adopt groups tracking these evolving projects is more-or-less certain. If you’re interested in participating then watch for an announcement letting everyone know when the group is ready for developers to join and start working with and testing the API as it matures.


This story, “Why developers should get excited about Java 9” was originally published by InfoWorld, but additions have been added .