This chapter and subsequent chapters feature Java 11. The Standard Edition (SE) of the Java platform can be downloaded from Oracle's official download site (http://www.oracle.com/technetwork/java/javase/downloads/index.html).

An integrated development environment (IDE) software package is sufficient. IntelliJ IDEA, from JetBrains, was used for all coding associated with this chapter and subsequent chapters. The Community version of IntelliJ IDEA can be downloaded from the site (https://www.jetbrains.com/idea/features/).

The first version of Java was released as Java 1 in 1996. Since then, there have been several incremental releases, each of which followed a feature-driven release model. Starting with Java 10, Oracle has implemented a new, time-based release model. In this section, we will look at the original model to provide a foundation to show how the Java platform evolved, and look at the new versioning model and why it matters.

Following the 1996 launch of Java 1, subsequent releases had the nomenclature of 1.1, 1.2, 1.3, and 1.4. With the release of 1.5, the Java platform was referred to as Java 5. Frequent updates were released for Java 5 until Java 6 was released followed by Java 7, Java 8, and Java 9.

The following table provides a condensed view of the Java release history until Java 9:

The release of Java 9 was a significant change to the Java platform and how each of the versions was numbered. With the post-Java 9 releases, Oracle decided to abandon their feature-based model, opting for a time-released model instead.

Java 9 was released in 2017 and two releases were scheduled for 2018. Those releases were Java 10 and Java 11. The version numbers for these post-Java 9 releases followed the YY.M format. So, with Java 10 released in March 2018, the version number was 18.3. Java 11, released in September 2018, has a version number of 18.9.

The general premise behind the new time-based release model is to have releases scheduled predictably and frequently. Here are the details:

• Feature releases: Issued every six months (each March and September)
• Update releases: Issued every quarter
• Long-term support release: Issued every three years

There are great gains to be had, from a developer's perspective, with this model. Developers no longer need to wait long for releases to the Java platform. More significant is the fact that no release will represent a major change to the platform of the kind that Java 9 was.

Unarguably, the modularization of the Java platform, developed as part of Project Jigsaw, was the greatest change introduced to the Java platform with Java 9. Initially planned for Java 8, but postponed, Project Jigsaw was one of the main reasons why the final release of Java 9 was itself postponed. Jigsaw also introduced a few notable changes to the Java platform and was one of the reasons Java 9 was considered a major release. We will explore these features in detail in subsequent chapters.

Apart from the Jigsaw-related Java enhancement proposals, there is a long list of other enhancements that made it in Java 9. This section explores the most significant features introduced in Java 9, specifically:

• Breaking the monolith
• Using the Java Shell
• Taking control of external processes
• Boosting performance with G1
• Measuring performance with Java Microbenchmark Harness (JMH)
• Getting ready for HTTP 2.0
• Encompassing reactive programming

Over the years, the utilities of the Java platform have continued to evolve and increase, making it into one big monolith. In order to make the platform more suitable for embedded and mobile devices, the publication of stripped-down editions, such as Java Connected Device Configuration (CDC) and Java Micro Edition (ME), was necessary. These, however, did not prove to be flexible enough for modern applications with varying requirements in terms of the functionality provided by the JDK. In that regard, the need for a modular system came in as a vital requirement, not only to address the modularization of the Java utilities (overall, there are more than 5,000 Java classes and 1,500 C++ source files with more than 250,000 lines of code for the HotSpot runtime), but also to provide a mechanism for developers to create and manage modular applications using the same module system as that used in the JDK. Java 8 provided an intermediate mechanism to enable applications to use only a subset of the APIs provided by the entire JDK, and that mechanism was named compact profiles. In fact, compact profiles also provided the basis for further work that had to be done in order to break dependencies between the various distinct components of the JDK. This breaking of dependencies was required to enable the implementation of a module system in Java.

The module system itself was developed under the name of Project Jigsaw, on the basis of which several Java enhancement proposals and a target Java Specification Request (JSR 376) were formed. A complete restructuring of the JDK code base was made, along with a complete reorganization of the JDK distributable images.

There was considerable controversy in the community as to whether an existing and mature Java module system, such as OSGi, should be adopted as part of the JDK, instead of providing a completely new module system. However, OSGi targets runtime behavior, such as the resolution of module dependencies, installation, uninstallation, starting and stopping of modules (also named bundles in terms of OSGi), custom module classloaders, and so on.

Project Jigsaw, however, targets a compile-time module system where the resolution of dependencies happens when the application is compiled. Moreover, installing and uninstalling a module as part of the JDK eliminates the need to include it explicitly as a dependency during compilation. Furthermore, the loading of module classes is made possible through the existing hierarchy of classloaders (the bootstrap, and the extension and system classloaders).

Additional benefits from the Java module system include enhanced security and performance. By modularizing the JDK and applications into Jigsaw modules, developers are able to create well-defined boundaries between components and their corresponding domains. This separation of concerns aligns with the security architecture of the platform and is an enabler of better resource utilization.

For a long time, there has been no standard shell shipped with the Java programming language to experiment with new language features or libraries, or for rapid prototyping. If you wanted to do this, you could write a test application with a main() method, compile it with javac, and run it. This could be done either in the command line or using a Java IDE; however, in both cases, this is not as convenient as having an interactive shell for the purpose.

Starting an interactive shell in JDK 9 is as simple as running the following command (assuming the bin directory of your JDK 9 installation is in the current path):

jshell

You may find it somewhat puzzling that an interactive shell has not been introduced earlier in the Java platform, as many programming languages, such as Python, Ruby, and a number of others, already come with an interactive shell in their earliest versions. However, this didn't make it on the priority features list until Java 9. The Java Shell makes use of a JShell API that provides capabilities to enable autocompletion or evaluation of expressions and code snippets, among other features. Chapter 6, Experimenting with the Java Shell, is dedicated to discussing the details of the Java Shell so that developers can make the best use of it.

Up to JDK 9, if you wanted to create a Java process and handle process input/output, you had to use one of the following approaches:

• The Runtime.getRuntime.exec() method, which allows us to execute a command in a separate OS process. Using this approach would require you to get a java.lang.Process instance over which to provide certain operations in order to manage the external process.
• The new java.lang.ProcessBuilder class, which has some more enhancements with regard to interacting with the external process. You would also need to create a java.lang.Process instance to represent the external process.

Both approaches were inflexible and also nonportable, as the set of commands executed by the external processes were highly dependent on the operating system. An additional effort had to be exerted in order to make the particular process operations portable across multiple operating systems. Chapter 9, Making Use of the Process API, is dedicated to the new process API, providing developers with the knowledge to create and manage external processes in a much easier way.

The G1 garbage collector was already introduced in JDK 7 and is now enabled by default in JDK 9. It is targeted for systems with multiple processing cores and a lot of available memory. What are the benefits of the G1 compared to previous types of garbage collectors? How does it achieve these improvements? Is there a need to tune it manually, and in what scenarios? These and several more questions regarding G1 will be discussed in Chapter 7, Leveraging the Default G1 Garbage Collector.

On many occasions, Java applications may suffer from performance degradation. Exacerbating the issue is a lack of performance tests that can provide at least a minimal set of guarantees that performance requirements are met and, moreover, the performance of certain features will not degrade over time. Measuring the performance of Java applications is not trivial, especially due to the fact that there are a number of compiler and runtime optimizations that may affect performance statistics. For that reason, additional measures, such as warm-up phases and other tricks, must be used in order to provide more accurate performance measurements. The JMH is a framework that incorporates a number of techniques, along with a convenient API that can be used for this purpose. It is not a new tool but was included with the distribution of Java 9. If you have not added JMH to your toolbox yet, read Chapter 8, Microbenchmarking Applications with JMH, to learn about the use of JMH in the context of Java application development.

HTTP 2.0 is the successor to the HTTP 1.1 protocol, and this new version of the protocol addresses some limitations and drawbacks of the previous one. HTTP 2.0 improves performance in several ways and provides capabilities such as request/response multiplexing in a single TCP connection, sending of responses in a server push, flow control, and request prioritization, among others. Java provides the java.net.HttpURLConnection utility that can be used to establish a nonsecure HTTP 1.1 connection. However, the API was considered difficult to maintain, an issue which was further complicated by the need to support HTTP 2.0 and, so, an entirely new client API was introduced in order to establish a connection via the HTTP 2.0 or the web socket protocols. The HTTP 2.0 client, along with the capabilities it provides, will be covered in Chapter 11, New Tools and Tool Enhancements.

Reactive programming is a paradigm used to describe a certain pattern for the propagation of changes in a system. Reactiveness is not built in Java itself, but reactive data flows can be established using third-party libraries, such as RxJava or Project Reactor (part of the Spring Framework). JDK 9 also addressed the need for an API that aids the development of highly responsive applications built around the idea of reactive streams by providing the java.util.concurrent.Flow class for the purpose. The Flow class, along with other related changes introduced in JDK 9, will be covered in Chapter 12, Concurrency Enhancements.