Java is already a fully-grown adult in its own right more than two decades since its first release. With a stunning community of developers and wide adoption in a number of industries, the platform continues to evolve and keep up with the rest of the world in terms of performance, security, and scalability. We will begin our journey by exploring the most significant features introduced in Java 9, what are the biggest drivers behind them, and what more we can expect in subsequent developments of the platform, along with some of the things that did not make it in this release.
In this chapter, we will cover the following topics:
- Java 9 at 20,000 feet
- Breaking the monolith
- Playing around with the Java Shell
- Taking control of external processes
- Boosting performance with G1
- Measuring performance with JMH
- Getting ready for HTTP 2.0
- Encompassing reactive programming
- Expanding the wish list
You might be asking yourself--isn't Java 9 just a maintenance release with a set of features that did not make it into Java 8? There is plenty of new stuff in Java 9 that makes it a distinct version in its own right.
Inarguably, the modularization of the Java platform (developed as part of project Jigsaw) is the biggest piece of work that makes it successfully in Java 9. Initially planned for Java 8, but postponed, project Jigsaw is also one of the main reasons why the final release of Java 9 was further postponed. Jigsaw also introduces a few notable changes to the Java platform and is one of the reasons Java 9 is considered a major release. We will explore these features in detail in the subsequent chapters.
The JCP (Java Community Process) provides the mechanisms to turn a set of feature proposals (also known as Java Enhancement Proposals or JEPs) into formal specifications that provide the basis to extend the platform with new functionality. Java 9 is no different in that regard. Apart from the Jigsaw-related Java enhancement proposals, there is a long list of other enhancements that made it in Java 9. Throughout this book, we will discuss the various features in terms of logical groups based on the corresponding enhancement proposals, including the following:
- The Java Shell (also called JShell)--an interactive shell for the Java platform
- New APIs to work with operating system processes in a portable manner
- The Garbage-first (G1) garbage collector introduced in Java 7 is made the default garbage collector in Java 9
- Adding the Java Microbenchmark Harness (JMH) tool that can be used to run performance benchmarks against Java applications is included as part of the Java distribution
- Support for the HTTP 2.0 and WebSocket standards by means of a new client API
- Concurrency enhancements among which is the definition of the
Flow
class, which describes an interface for the reactive streams specification in the Java platform
Some of the initial proposals that were accepted for release 9 did not make it there and were postponed for a later release, along with other interesting things that developers may expect in the future.
You can download the JDK 9 distribution for your system from http://www.oracle.com/technetwork/java/javase/downloads/index.html, if you are eager to get your hands dirty before trying to move through the other chapters and experimenting with the newly introduced samples and concepts.
Over the years, the utilities of the Java platform have continued to evolve and increase, making it 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 CDC and Java ME was necessary. These, however, did not prove to be flexible enough for modern applications with varying requirements in terms of functionality provided by the JDK. In that regard, the need for a modular system came in as a viral requirement, not only to address modularization of the Java utilities (overall, more than 5000 Java classes and 1500 C++ source files with more than 25,0000 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 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 required to enable implementation of a module system in Java.
The module system itself has been developed under the name of project Jigsaw on the basis of which several Java enhancement proposals and a target JSR (376) were formed. Much was put in place to address the requirements of project Jigsaw--there was evidence of concept implementation with more features proposed than the ones that successfully made it into Java 9. Apart from that, a complete restructuring of the JDK code base has been 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 resolution of dependencies happen when the application is compiled. Moreover, installing and uninstalling a module as part of the JDK eliminates the need to include it as a dependency explicitly during compilation. Furthermore, loading of module classes is made possible through the existing hierarchy of classloaders (the bootstrap and the extension and system classloaders), although, there was a possibility of using custom module classloaders pretty much similar to the module classloaders of OSGI. The latter was, however, abandoned; we will discuss Java module classloading in more detail when we talk about the details of the module system in Java.
Additional benefits from the Java module system include enhanced security and performance. By modularizing the JDK and applications into Jigsaw modules, we 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. We have dedicated two detailed chapters to all of the preceding points, and to the topic of adopting Java 9 as well, which also requires a degree of understanding on the possible approaches to migrating existing projects to Java 9.
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 at 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 had still not made it on the priority features list for the earlier Java releases, until now, and it is out there and ready for use. 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. A full chapter is dedicated to discussing the details of the Java shell so that developers can make the best use out of it.
Up to JDK 9, if you wanted to create a Java process and handle process input/output, you had to use either the Runtime.getRuntime.exec()
method, which allows us to execute a command in a separate OS process and get a java.lang.Process
instance over which to provide certain operations in order to manage the external process, or use the new java.lang.ProcessBuilder
class with some more enhancements in regard to interacting with the external process and also create a java.lang.Process
instance to represent the external process. Both mechanisms were inflexible and also non-portable as the set of commands executed by the external processes were highly dependent on the operating system (additional effort had to be exerted in order to make the particular process operations portable across multiple operating systems). A chapter is dedicated to the new process API, providing developers with the knowledge of creating and managing 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 manually tune it, and in what scenarios? These, and several more questions regarding G1, will be discussed in a separate chapter.
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 performance of Java applications is not trivial, especially due to the fact that there is 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 Java Microbenchmark Harness 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 is included with the distribution of Java 9. If you have not added JMH to your toolbox yet, read the detailed chapter on the usage of JMH in the context of Java 9 application development.
HTTP 2.0 is the successor of 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 non-secure HTTP 1.1 connection. However, the API was considered difficult to maintain and further extended with the support for 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 new HTTP 2.0 client, along with the capabilities it provides, will be covered in a dedicated chapter.
Reactive programming is a paradigm used to describe a certain pattern for 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 addresses 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 a separate chapter.
Apart from all of the new stuff in JDK 9, a whole new set of features is expected in future releases of the platform. Among these are the following:
- Generics over primitive types: This is one of the features planned for JDK 10 as part of project Valhalla. Other language enhancements, such as value handles, are already part of Java 9 and will be introduced later in this book.
- Reified generics: This is another featured part of project Valhalla that aims to provide the ability to preserve generic types at runtime. The related goals are listed as follows:
- The foreign functional interface aims to introduce a new API to call and manage native functions. The API addresses some of the drawbacks of JNI and especially a lack of simplicity for use by application developers. The foreign functional interface is developed as part of project Panama in the JDK ecosystem.
- New money and currency API (developed under JSR 354) was initially planned for Java 9, but was postponed.
- New lightweight JSON API (developed under JSR 353) was also planned for Java 9, but postponed to Java 10.
These are just some of the new things one may expect in subsequent releases of the JDK. Project Penrose aims to bridge the gap between the module system in Java and the OSGi module system, and to provide different methodologies for interoperability between the two systems.
The Graal VM is another interesting research project that is a potential candidate for subsequent releases of the Java platform. It aims to bring the runtime performance of Java to dynamic languages such as JavaScript or Ruby.
A chapter dedicated to the future of JDK discusses all of these points in detail.
In this brief introductory chapter, we revealed the small universe of capabilities provided by JDK 9. The module system introduced in this release of the platform is indisputably a cornerstone in the development of Java applications. We also discovered that a number of other major features and changes are introduced in JDK 9 that deserve special attention and will be discussed in great detail in subsequent chapters.
In the next chapter, we will take a look at 26 internal changes to the Java platform.