What do we have in Java 9?

Here we are. The piping hot Java 9 is now available to learn, test and apply.
Oracle has delivered the Java SE 9 JDK + documentation for developers to download.

To admit, the release of Java suffered delays a couple of times because of unreadiness of project Jigsaw modularity concept.

Mr. Reinhold

Mark Reinhold, Java chief architect at Oracle, stated that the delays of release were due to numerous rough spots primarily in the Jigsaw, and those roughnesses needed to be polished.

To recall, either Java 7 or Java 8 were delayed back in days, so developers all over the world were not surprised this time.

Nevertheless, the final release date was assigned to September 21, 2017. This time, developers were eagerly awaiting the day of release. The new Java, the JDK 9, presupposed to have over 90 new features on board, where the relentlessly discussed modularity is the major novelty.

For one thing, the developers all over the world were yearning for a list of features and instruments which from an objective point of view were a must have in the new Java.

Digging information about the mythical Holy Grail 9, we’ve found an interesting advertisement made by a developer.

We’ve found the wanted one, but, regretfully, it does not correspond to the indicated features.

Hence, no satisfaction. Sorry…

Let us talk of improvements and radical changes in the Java 9 that were introduced. The frequently discussed feature of Java 9, modularity, is a real game-changer, so it would be fair enough to start with the discussion of the main feature, the Java Platform Module System.

The JPMS is intended to give the JDK an option of being divided into a set of modules for combining at times of run, compile, and build.

With the help of modularity, the developers will get a chance to construct and support either libraries or reasonably large applications for both Java SE and EE.

The project Jigsaw is aimed to optimize new Java and make it flexible, powerful, and secure.

The Module in JDK 9.

As distinct from the regular jar file, which meant for JVM (Java Virtual Machine) only a code and asset store, the jar module contains a module-info class that provides:

• the name of the module;
• the information about the dependency modules that are needed for correct compilation and operation;
• the information about the packages that this module opens (exports);
• the list of services that the module supplies in runtime.

Now, if the class is expressed public, it does not mean, that it will be available for all of the modules. The public scope turns to be wider:

• public class in the exported package — is available to all modules that have this module in dependencies;
• public class in the package exported to a particular module — available only to the specified module;
• public class without package export — is available to all classes of this module.

Let us present an example of the module-info.java contents:

The represented module has the name com.example.samplemodule because it is defined to name the modules on packages to avoid conflicts.

It depends on modules com.example.sampleapp, java.httpclient and java.base (which is used for modules on a default base). Notably, java.httpclient will be a dependency for all modules using com.example.samplemodule.

Our module exports the packages com.example.samplemodule.model and com.example.samplemodule.spi, so all the public classes in these packages are available for other modules depending on it. The module uses com.example.samplemodule.spi.DataProvider for obtaining data from other modules. Moreover, it provides the settings for the service of another module, through the realization of the interface com.example.sampleapp.spi.SettingsProvider in the class com.example.samplemodule.ModuleSettingsProvider.

Next, after the brief module description, we would like to discuss the next generation JUnit, which is the JUnit 5. In addition, the comparative analysis of the 5th JUnit and 4th JUnit would be relevant and reasonable.

So, the following section will be dedicated to the comparative review.

One of the biggest differences between the latter programmer-friendly testing frameworks for Java is the architecture.

Whilst the JUnit 4 architecture is “all-in-one”, JUnit 5 has three separate modules, which are JUnit Platform, JUnit Jupiter, JUnit Vintage.

Let us look closer at these separate modules.

JUnit Platform serves as the base for launching testing frameworks on the JVM. This module defines the TestEngine API for developing a testing framework that runs on the platform.

JUnit Jupiter is that module that includes new features for writing tests and extensions in JUnit 5 such as new annotations and new assertions.

JUnit Vintage is the module that provides support for running JUnit 3 and JUnit 4 tests on the platform of the JUnit 5.

Now, let us parallelize the annotations and assertions of the JUnits 4 and 5.

Annotations.

Assertions.

As you can see, almost all the annotations are quite the same except for the assertAll and assertThrows, which exist in JUnit 5 only.

Despite the fact that the annotations are the same, there is the difference in position of optional assertion message parameter.

Let us take a closer look at these peculiarities.

JUnit 4

JUnit 5

The difference, represented in the code above, is that in JUnit 4, the optional assertion message is the First parameter, while in JUnit 5, the optional assertion message is the Last parameter applied for all assertion methods support it.

Compilers in Java 9.

Now, let us discuss the improvements of the compiler for the Java 9 code. The main improvement in code compilation is the ahead-of-time compilation (AoT).The AoT feature provides developers with a capability of compilation of Java classes to native code before launching in the virtual machine. This feature is aimed at improvement of startup time of both small and large applications.

To admit, the AoT feature is still in the experimental phase, and many experts, including Dmitry Leskov, marketing director at Excelsior, are worried about the readiness of the AoT.

Dmitry says, that it is not mature enough, and it would be better if Oracle had waited until Java 10, for AoT to be polished and refined.

The main reason for AoT implementation is that the Just-in-time (JIT) compilers leave some Java methods uncompiled while working with the large Java programs. So, the AoT compiler is designed to right the ship.

Another new, but also experimental compilation feature is the JVMCI, the Java-level JVM Compiler Interface. The JVMCI lets a compiler written in Java be used as a dynamic compiler by the JVM. Its API provides developers with mechanisms, that grant access to VM structures, install the compiled code, and plug into the JVM compilation system.

This, consequently, should allow writing a topnotch compiler, that is easy to improve and maintain. Compilers, written in Java will excel the existing C and C++ written compilers.

Read-eval-print-loop is finally in Java!

To recall, the REPL tool was the long-term goal for Java, and now, it is real in the version 9.

Java 9’s REPL bears the name jShell and is destined to interactively evaluate declarative statements and expressions. This gives developers a possibility to get feedback on programs before compilation by dint of entering some lines of code.

Now, the capabilities of the command line include the tab completion and the automatic addition of the required terminal semicolons.

JDK 9 Flow API and Process API.

Probably, you have already read information about the Reactive-Streams interfaces in the upcoming Java 9, but we would like to take a closer look.

The Reactive-Streams under the parent class java.until.concurrent.Flow enable a new standard interoperation between the future libraries built on top.

Reactive programming is about processing an asynchronous stream of data items, where applications react to the data items as soon as they occur.

Reactive programming is more memory efficient since the data is processed as streams comparing to iterating over the in-memory data.

Moreover, RP gives developers a bunch of bells and whistles, which provide the following conveniences:

• a simpler and more readable code;
• a stronger focus on business logic;
• memory efficiency;
• an omni-purpose tool providing capabilities to solve any kind of problem.

In the outcome, the reactive programming echoes in the responsive, resilient, elastic and stable systems.

The essence of the FLOW API can be characterized by Pull+Push programming models. Through using the Flow API, the application requests for “N” items, which provokes the publisher to push “N” items to the Subscriber.

Talking of process enhancements in the new JDK, we would like to mention, that there are several new methods to the abstract Process class allowing identification direct child or descendent processes, obtain a completable future for reception of asynchronous notification when the Process exits, obtain the Process Identifier (PID), etc.

The Process API enhancements are a really welcome addition to Java and is really appreciated by the developers. The new additions give us much more control over the running and spawned processes comparing to the older Javas. Moreover, the introduced improvements offer a better story when it comes to developing automated tooling for deploying and upgrading the runtime.

To find out more and learn new methods, you can visit JEP 102 page.

Stream API improvements and changes.

In the new version, there will be at least four methods java.util.Stream. Just like the stream, they will all be standard. The most important methods are dropWhile and takeWhile methods.

If you are familiar with the Scala language or functional programming, you will definitely recognize these methods.

The simplest application of the stream can be represented as follows:

HTTP/2 client API has come to JDK 9.

The beta version of the HTTP/2 client API has been implemented into the Java Development Kit 9. It is designed to upgrade the web’s core HTTP protocol. It can replace the HttpURLConnection API, which had problems and is hard to use. The new API is represented in the package “java.net.http”. It supports either synchronous or asynchronous operation modes.

The new API is available at the official Oracle page in the docs section.

Now, let us represent an example of an HTTP/2 client:

In addition, the JDK 9 is better placed against the Java 8 in terms of the improved HTML5 and Unicode support. The Javadoc documentation tool in JDK 9 is improved to generate HTML5 markup. The Unicode 8.0 standard, supported by Java 9, adds 8,000 characters, 10 blocks, and 6 scripts.

As to security, Java 9 has an API for Datagram Transport Layer Security. This protocol is designed to prevent eavesdropping, interference, and other security issues. It is available either for client or server modes.

New Garbage Collector in Java 9.

The default garbage collector GC is being changed in Java 9 from the parallelGC to the G1GC. What does it mean?

The G1GC, the Garbage-First collector, is the concurrent multi-threaded garbage collector.

It works alongside the app threads and is constructed to provide a short and predictable pause times while achieving the high throughput.

The Garbage-First, instead of splitting the heap into three big regions, divides it into the set of equal ones. Importantly, certain subsets of regions are still assigned roles.

The live data and its amount in each region are tracked, so when the collection is triggered the G1GC starts to clear the most “garbage first”.

Through this action, the G1GC attempts to free as much space, as it is possible. Additionally, the Garbage-First GC compacts the heap during the performed collections, eliminating the eventual fragmentation issues.

Finally, let us talk about what Java 9 is deprived of.

It is obvious, that some of the new tools and features become extremely popular and stay, while the rest come to the point when they are out-of-vogue and needless.

The first thing, which is deprecated, is the Applet API. The reason for this is that security-conscious browser makers have been depriving the support for Java browser plugins.

The appletviewer tool is deprecated also, so you will no longer have an ability to use it in Java 9.

As we have already mentioned, the new Garbage Collector was implemented into the new JDK, so, we can label the CMS GC as “deprecated” and out-of-vogue.

Other noteworthy deprecated features are Java warnings on import statements, the ability to select the JRE at launch time through the mJRE (MultipleJRE) feature, the JVM Tool Interface, Heap Profiling Agent, and the jhat tool.

For some reasons, we are sure, that these tools and features will not be missed by the developers.

At the end of the day, the Java 9 offers a bale of convenience and performance. Though the major changes are not perfectly polished yet, their refinement will waste little time.

The next major version of the JDK 9 is going to be released in March 2018 and will be called Java 18.3, and Java 18.9 six months later. This also means that Java 9 is not the long-term support release, instead, the Java 18.9 will be the one to have the long-term support.