As with any new version of the JDK, this release was packed with a lot of great new features. Of course, what is most appealing will vary based on your needs, but we'll focus specifically on a handful of these new features that are most relevant to the projects we'll build together. First up is the most significant, the Java Module System.
Despite being a solid, feature-packed release, Java 8 was considered by a fair number to be a bit disappointing. It lacked the much anticipated Java Platform Module System (JPMS), also known more colloquially, though not quite accurately, as Project Jigsaw. The Java Platform Module System was originally slated to ship with Java 7 in 2011, but it was deferred to Java 8 due to some lingering technical concerns. Project Jigsaw was started not only to finish the module system, but also to modularize the JDK itself, which would help Java SE scale down to smaller devices, such as mobile phones and embedded systems. Jigsaw was scheduled to ship with Java 8, which was released in 2014, but it was deferred yet again, as the Java architects felt they still needed more time to implement the system correctly. At long last, though, Java 9 will finally deliver this long-promised project.
That said, what exactly is it? One problem that has long haunted API developers, including the JDK architects, is the inability to hide implementation details of public APIs. A good example from the JDK of private classes that developers should not be using directly is the com.sun.*/sun.* packages and classes. A perfect example of this--of private APIs finding widespread public use--is the sun.misc.Unsafe class. Other than a strongly worded warning in Javadoc about not using these internal classes, there's little that could be done to prevent their use. Until now.
With the JPMS, developers will be able to make implementation classes public so that they may be easily used inside their projects, but not expose them outside the module, meaning they are not exposed to consumers of the API or library. To do this, the Java architects have introduced a new file, module-info.java, similar to the existing package-info.java file, found at the root of the module, for example, at src/main/java/module-info.java. It is compiled to module-info.class, and is available at runtime via reflection and the new java.lang.Module class.
So what does this file do, and what does it look like? Java developers can use this file to name the module, list its dependencies, and express to the system, both compile and runtime, which packages are exported to the world. For example, suppose, in our preceding stream example, we have three packages: model, api, and impl. We want to expose the models and the API classes, but not any of the implementation classes. Our module-info.java file may look something like this:
module com.packt.j9blueprints.intro {
requires com.foo;
exports com.packt.j9blueprints.intro.model;
exports com.packt.j9blueprints.intro.api;
} This definition exposes the two packages we want to export, and also declares a dependency on the com.foo module. If this module is not available at compile-time, the project will not build, and if it is not available at runtime, the system will throw an exception and exit. Note that the requires statement does not specify a version. This is intentional, as it was decided not to tackle the version-selection issue as part of the module system, leaving that to more appropriate systems, such as build tools and containers.
Much more could be said about the module system, of course, but an exhaustive discussion of all of its features and limitations is beyond the scope of this book. We will be implementing our applications as modules, though, so we'll see the system used--and perhaps explained in a bit more detail--throughout the book.
In prior versions of Java, developers interacting with native operating system processes had to use a fairly limited API, with some operations requiring resorting to native code. As part of Java Enhancement Proposal (JEP) 102, the Java process API was extended with the following features (quoting from the JEP text):
- The ability to get the pid (or equivalent) of the current Java virtual machine and the pid of processes created with the existing API.
- The ability to enumerate processes on the system. Information on each process may include its pid, name, state, and perhaps resource usage.
- The ability to deal with process trees; in particular, some means to destroy a process tree.
- The ability to deal with hundreds of subprocesses, perhaps multiplexing the output or error streams to avoid creating a thread per subprocess.
We will explore these API changes in our first project, the Process Viewer/Manager (see the following sections for details).
As was done in Java 7, the Java architects revisited the concurrency libraries, making some much needed changes, this time in order to support the reactive-streams specification. These changes include a new class, java.util.concurrent.Flow, with several nested interfaces: Flow.Processor, Flow.Publisher, Flow.Subscriber, and Flow.Subscription.
One change that seems to excite a lot of people isn't a language change at all. It's the addition of a REPL (Read-Eval-Print-Loop), a fancy term for a language shell. In fact, the command for this new tool is jshell. This tool allows us to type or paste in Java code and get immediate feedback. For example, if we wanted to experiment with the Streams API discussed in the preceding section, we could do something like this:
$ jshell
| Welcome to JShell -- Version 9-ea
| For an introduction type: /help intro
jshell> List<String> names = Arrays.asList(new String[]{"Tom", "Bill", "Xavier", "Sarah", "Adam"});
names ==> [Tom, Bill, Xavier, Sarah, Adam]
jshell> names.stream().sorted().forEach(System.out::println);
Adam
Bill
Sarah
Tom
Xavier This is a very welcome addition that should help Java developers rapidly prototype and test their ideas.