In this chapter, we will cover the following recipes:

• Installing JDK 18.9 on Windows and setting up the PATH variable
• Installing JDK 18.9 on Linux (Ubuntu, x64) and configuring the PATH variable
• Compiling and running a Java application
• What's new in JDK 18.9
• Using application class-data sharing

Every quest for learning a programming language begins with setting up the environment to experiment with our learning. Keeping in sync with this philosophy, in this chapter, we will show you how to set up your development environment and then run a simple modular application to test our installation. After that, we'll give you an introduction to the new features and tools in JDK 18.9. Then, we will compare JDK 9, 18.3, and 18.9. We'll end the chapter with a new feature introduced in JDK 18.3 that allows application-class-data sharing.

In this recipe, we will look at installing JDK on Windows and how to set up the PATH variable to be able to access the Java executables (such as javac, java, and jar) from anywhere within the command shell.

1. Visit http://jdk.java.net/11/ and accept the early-adopter license agreement, which looks like this:

2. After accepting the license, you will get a grid of the available JDK bundles based on the OS and architecture (32/64-bit). Click to download the relevant JDK executable (.exe) for your Windows platform.
3. Run the JDK executable (.exe) and follow the onscreen instructions to install JDK on your system.
4. If you have chosen all the defaults during the installation, you will find JDK installed in C:/Program Files/Java for 64 bit and C:/Program Files (x86)/Java for 32 bit.

Now that we have finished installing JDK, let's see how we can set the PATH variable.

The tools provided with JDK, namely javac, java, jconsole, and jlink, are available in the bin directory of your JDK installation. There are two ways you could run these tools from the Command Prompt:

1. Navigate to the directory where the tools are installed and run them, as follows:

      cd "C:\Program Files\Java\jdk-11\bin"
      javac -version

2. Export the path to the directory so that the tools are available from any directory in the command prompt. To achieve this, we have to add the path to the JDK tools in the PATH environment variable. The command prompt will search for the relevant tool in all the locations declared in the PATH environment variable.

Let's see how you can add the JDK bin directory to the PATH variable:

1. Right-click on My Computer and then click on Properties. You will see your system information. Search for Advanced system settings and click on it to get a window, as shown in the following screenshot:

2. Click on Environment Variables to view the variables defined in your system. You will see that there are quite a few environment variables already defined, as shown in the following screenshot (the variables will differ across systems; in the following screenshot, there are a few predefined variables and a few variables added by me):

The variables defined under System variables are available across all the users of the system, and those defined under User variables for <user name> are available only to the specific user.

3. A new variable, with the name JAVA_HOME, and its value as the location of the JDK 9 installation. For example, it would be C:\Program Files\Java\jdk-11 (for 64 bit) or C:\Program Files (x86)\Java\jdk-11 (for 32 bit):

4. Update the PATH environment variable with the location of the bin directory of your JDK installation (defined in the JAVA_HOME environment variable). If you already see the PATH variable defined in the list, then you need to select that variable and click on Edit. If the PATH variable is not seen, click on New.
5. Any of the actions in the previous step will give you a popup, as shown in the following screenshot (on Windows 10):

The following screenshot shows the other Windows versions:

6. You can either click on New in the first screenshot and insert the %JAVA_HOME%\bin value, or you can append the value against the Variable value field by adding ; %JAVA_HOME%\bin. The semicolon (;) in Windows is used to separate multiple values for a given variable name.
7. After setting the values, open the command prompt and run javac -version. You should be able to see javac 11-ea as the output. If you don't see it, it means that the bin directory of your JDK installation has not been correctly added to the PATH variable.

In this recipe, we will look at installing JDK on Linux (Ubuntu, x64), and how to configure the PATH variable to make the JDK tools (such as javac, java, and jar) available from any location within the Terminal.

1. Follow steps 1 and 2 of the Installing JDK 18.9 on Windows and setting up the PATH variable recipe to reach the downloads page.
2. Copy the download link (tar.gz) for the JDK for the Linux x64 platform from the downloads page.
3. Download the JDK by using $> wget <copied link>, for example, $> wget https://download.java.net/java/early_access/jdk11/26/BCL/jdk-11-ea+26_linux-x64_bin.tar.gz.

4. Once the download completes, you should have the relevant JDK available, for example, jdk-11-ea+26_linux-x64_bin.tar.gz. You can list the contents by using $> tar -tf jdk-11-ea+26_linux-x64_bin.tar.gz. You can even pipe it to more to paginate the output: $> tar -tf jdk-11-ea+26_linux-x64_bin.tar.gz | more.
5. Extract the contents of the tar.gz file under /usr/lib by using $> tar -xvzf jdk-11-ea+26_linux-x64_bin.tar.gz -C /usr/lib. This will extract the contents into a directory, /usr/lib/jdk-11. You can then list the contents of JDK 11 by using $> ls /usr/lib/jdk-11.

6. Update the JAVA_HOME and PATH variables by editing the .bash_aliases file in your Linux home directory:

      $> vim ~/.bash_aliases
      export JAVA_HOME=/usr/lib/jdk-11
      export PATH=$PATH:$JAVA_HOME/bin

Source the .bashrc file to apply the new aliases:

      $> source ~/.bashrc
      $> echo $JAVA_HOME
      /usr/lib/jdk-11
      $>javac -version
      javac 11-ea
      $> java -version
      java version "11-ea" 2018-09-25
      Java(TM) SE Runtime Environment 18.9 (build 11-ea+22)
      Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11-ea+22, mixed 
      mode)

In this recipe, we will write a very simple modular Hello world program to test our JDK installation. This simple example prints Hello world in XML; after all, it's the world of web services.

You should have JDK installed and the PATH variable updated to point to the JDK installation.

1. Let's define the model object with the relevant properties and annotations that will be serialized into XML:

        @XmlRootElement
        @XmlAccessorType(XmlAccessType.FIELD) 
        class Messages{     
          @XmlElement 
          public final String message = "Hello World in XML"; 
        }

In the preceding code, @XmlRootElement is used to define the root tag, @XmlAccessorType is used to define the type of source for the tag name and tag values, and @XmlElement is used to identify the sources that become the tag name and tag values in the XML.

2. Let's serialize an instance of the Message class into XML using JAXB:

public class HelloWorldXml{
  public static void main(String[] args) throws JAXBException{
    JAXBContext jaxb = JAXBContext.newInstance(Messages.class);
    Marshaller marshaller = jaxb.createMarshaller();
    marshaller.setProperty(Marshaller.JAXB_FRAGMENT,Boolean.TRUE);
    StringWriter writer = new StringWriter();
    marshaller.marshal(new Messages(), writer);
    System.out.println(writer.toString());
  } 
}

3. We will now create a module named com.packt. To create a module, we need to create a file named module-info.java, which contains the module definition. The module definition contains the dependencies of the module and the packages exported by the module to other modules:

    module com.packt{
      //depends on the java.xml.bind module
      requires java.xml.bind;
      //need this for Messages class to be available to java.xml.bind
      exports  com.packt to java.xml.bind;
    }

The directory structure with the preceding files is as follows:

4. Let's compile and run the code. From the hellowordxml directory, create a new directory in which to place your compiled class files:

      mkdir -p mods/com.packt

Compile the source, HelloWorldXml.java and module-info.java, into the mods/com.packt directory:

      javac -d mods/com.packt/ src/com.packt/module-info.java
      src/com.packt/com/packt/HelloWorldXml.java

5. Run the compiled code using java --module-path mods -m com.packt/com.packt.HelloWorldXml. You will see the following output:

<messages><message>Hello World in XML</message></messages>

Don't worry if you are not able to understand the options passed with the java or javac commands. You will learn about them in Chapter 3, Modular Programming.

The release of Java 9 was a milestone in the Java ecosystem. The modular framework developed under Project Jigsaw became part of Java SE release. Another major feature was the JShell tool, which is a REPL tool for Java. Many other new features introduced with Java 9 are listed in the release notes: http://www.oracle.com/technetwork/java/javase/9all-relnotes-3704433.html.

In this recipe, we will enumerate and discuss some of the new features introduced with JDK 18.3 and 18.9 (Java 10 and 11).

The Java 10 release (JDK 18.3) started a six-month release cycle—every March and every September—and a new release numbering system. It also introduced many new features, the most significant of which (for application developers) are the following:

• Local variable type inference that allows the declaration of a variable using the reserved var type (see Chapter 15, The New Way of Coding with Java 10 and Java 11)
• Parallel full garbage collection for the G1 garbage collector, which improves worst-case latencies
• A new method, Optional.orElseThrow(), that is now the preferred alternative to the existing get() method
• New APIs for creating unmodifiable collections: The List.copyOf(), Set.copyOf(), and Map.copyOf() methods of the java.util package and new methods of the java.util.stream.Collectors class: toUnmodifiableList(), toUnmodifiableSet(), and toUnmodifiableMap() (see Chapter 5, Streams and Pipelines)
• A default set of root Certification Authorities, making OpenJDK builds more appealing to developers
• A new Javadoc command-line option, --add-stylesheet, provides support for the use of multiple stylesheets in the generated documentation
• Extending the existing class-data sharing feature to allow application classes to be placed in the shared archive that improves startup time and reduces the footprint (see the Using application class-data sharing recipe)

• An experimental just-in-time compiler, Graal, can be used on the Linux/x64 platform
• A clean garbage-collector (GC) interface that makes it simpler to add a new GC to HotSpot without perturbing the current code base and makes it easier to exclude a GC from a JDK build
• Enabling HotSpot to allocate the object heap on an alternative memory device, such as an NVDIMM memory module, specified by the user
• Thread-local handshakes, for executing a callback on threads without performing a global VM safepoint
• Docker awareness: JVM will know whether it is running in a Docker container on a Linux system and can extract container-specific configuration information instead of querying the operating system
• Three new JVM options, to give Docker container users greater control over the system memory

See the full list of Java 10's new features in the release notes: https://www.oracle.com/technetwork/java/javase/10-relnote-issues-4108729.html.

We will discuss the new features of JDK 18.9 in more detail in the next section.

We have picked a few features that we feel are the most important and useful for an application developer.

Epsilon is a so-called no-op garbage collector that basically does nothing. Its use cases include testing for performance, memory pressure, and the virtual machine interface. It also could be used for short-lived jobs or the jobs that do not consume much memory and do not require garbage collection.

We discussed this feature in more details in the recipe Understand Epsilon, a low-overhead garbage collector recipe in Chapter 11, Memory Management and Debugging.

JDK 18.9 standardizes the incubated HTTP API client introduced in JDK 9 and updated in JDK 10. Based on CompleteableFuture, it supports nonblocking requests and responses. The new implementation is asynchronous and provides a better traceable data flow.

Chapter 10, Networking, explains this feature in more detail in several recipes.

A local-variable syntax for lambda parameters has the same syntax as a local-variable-declaration using the reserved var type introduced in Java 11. See the Using local variable syntax for lambda parameters recipe in Chapter 15, The New Way of Coding with Java 10 and Java 11, for more details.

The Z Garbage Collector (ZGC) is an experimental low-latency garbage collector. Its pause times should not exceed 10 ms and there should be no more than 15% application throughput reduction compared to using the G1 collector. ZGC also lays a foundation for future features and optimizations. Linux/x64 will be the first platform to get ZGC support.

There are several additions to the standard Java API:

• Character.toString(int codePoint): Returns a String object representing the character specified by the provided Unicode code point:

var s = Character.toString(50);
System.out.println(s);  //prints: 2

• CharSequence.compare(CharSequence s1, CharSequence s2): Compares two CharSequence instances lexicographically. Returns the difference between the position of the second parameter and the position of the first parameter in the ordered list:

var i = CharSequence.compare("a", "b");
System.out.println(i);   //prints: -1

i = CharSequence.compare("b", "a");
System.out.println(i);   //prints: 1

i = CharSequence.compare("this", "that");
System.out.println(i);   //prints: 8

i = CharSequence.compare("that", "this");
System.out.println(i);   //prints: -8

• The repeat(int count) method of the String class: Returns a String value composed of count times repeated in the String source value:

String s1 = "a";
String s2 = s1.repeat(3); //prints: aaa
System.out.println(s2);

String s3 = "bar".repeat(3);
System.out.println(s3); //prints: barbarbar

• The isBlank() method of the String class: Returns true if the String value is empty or contains only white spaces, otherwise false. In our example, we have contrasted it with the isEmpty() method, which returns true if, and only if, length() is zero:

String s1 = "a";
System.out.println(s1.isBlank());  //false
System.out.println(s1.isEmpty());  //false

String s2 = "";
System.out.println(s2.isBlank());  //true
System.out.println(s2.isEmpty());  //true

String s3 = "  ";
System.out.println(s3.isBlank());  //true
System.out.println(s3.isEmpty());  //false

• The lines() method of the String class: Returns a Stream object that emits lines extracted from the source String value, separated by line terminators – \n, \r, or \r\n:

String s = "l1 \nl2 \rl3 \r\nl4 ";
s.lines().forEach(System.out::print); //prints: l1 l2 l3 l4 

• Three methods of the String class that remove leading space, trailing space, or both from the source String value:

String s = " a b ";
System.out.println("'" + s.strip() + "'");        // 'a b'
System.out.println("'" + s.stripLeading() + "'"); // 'a b '
System.out.println("'" + s.stripTrailing() + "'");// ' a b'

• Two Path.of() methods that construct a java.nio.file.Path object:

Path filePath = Path.of("a", "b", "c.txt");
System.out.println(filePath);     //prints: a/b/c.txt

try {
    filePath = Path.of(new URI("file:/a/b/c.txt"));
    System.out.println(filePath);  //prints: /a/b/c.txt
} catch (URISyntaxException e) {
    e.printStackTrace();
}

• The asMatchPredicate() method of the java.util.regex.Pattern class, which creates an object of the java.util.function.Predicate functional interface, which then allows us to test a String value for matching the compiled pattern. In the following example, we test whether a String value starts with the a character and ends with the b character:

Pattern pattern = Pattern.compile("^a.*z$");
Predicate<String> predicate = pattern.asMatchPredicate();
System.out.println(predicate.test("abbbbz")); // true
System.out.println(predicate.test("babbbz")); // false
System.out.println(predicate.test("abbbbx")); // false

There are quite a few other changes introduced in JDK 18.9:

• The Java EE and CORBA modules are removed
• JavaFX is separated and removed from the Java standard libraries
• The Pack200 and Unpack200 tools and the Pack200 API in util.jar are deprecated
• The Nashorn JavaScript engine, along with the JJS tool, are deprecated with the intent to remove them in the future
• The Java class file format is extended to support a new constant pool form, CONSTANT_Dynamic
• Aarch64 intrinsics are improved, with the implementation of new intrinsics for the java.lang.Math sin, cos, and log functions, on Aarch64 processorsJEP 309—Dynamic Class-File Constants
• Flight Recorder provides a low-overhead data-collection framework for troubleshooting both Java applications and the HotSpot JVM
• The Java launcher can now run a program supplied as a single file of Java source code, so these programs can run directly from the source
• A low-overhead heap profiling, providing a way to sample Java heap allocations, is accessible via JVM Tool Interface
• Transport Layer Security (TLS) 1.3 increases security and improves performance
• Support of Unicode version 10.0 in the java.lang.Character, java.lang.String, java.awt.font.NumericShaper, java.text.Bidi,java.text.BreakIterator, and java.text.Normalizer classes

Read the Java 11 (JDK 18.9) release notes for more details and other changes.

This feature has existed in Java since Java 5. It was extended in Java 9 as a commercial feature by allowing not only bootstrap classes but also application classes to be placed in the archive shared by JVMs. In Java 10, this feature became part of the open JDK. It decreases startup time and, when several JVMs are running on the same machine with the same application being deployed, reduces memory consumption.

The advantages of loading classes from the shared archive became possible for two reasons:

• The classes stored in the archive are preprocessed, which means that the JVM memory mapping is stored in the archive too. It reduces the overhead of class-loading when a JVM instance starts.
• The memory region can even be shared between the JVM instances running on the same computer, which reduces overall memory consumption by eliminating the need to replicate the same information in each instance.

The new JVM functionality allows us to create a list of classes to be shared, then use this list to create a shared archive, and use the shared archive to fast-load archived classes into memory.

1. By default, JVM can create an archive using the list of classes that comes with JDK. For example, run the following command:

java -Xshare:dump

It will create the shared archive as a classes.jsa file. On a Linux system, this file is placed in the following folder:

/Library/Java/JavaVirtualMachines/jdk-11.jdk/Contents/Home/lib/server

C:\Program Files\Java\jdk-11\bin\server

If this folder is accessible by the system admin only, run the command as an admin.

Please notice that not all classes can be shared. For example, the .class files located in the directory on the classpath and classes loaded by custom class loaders cannot be added to the shared archive.

2. To tell the JVM to use the default shared archive, use the following command:

java -Xshare:on -jar app.jar

The preceding command maps the content of the archive at a fixed address. This memory-mapping operation may occasionally fail when the required address space is not available. If that happens when the -Xshare:on option is used, the JVM exits with an error. Alternatively, the -Xshare:auto option can be used, which just disables the feature and loads the classes from the classpath if the shared archive cannot be used for whatever reason.

3. The simplest way to create a list of loaded application classes is by using the following command:

java -XX:+UseAppCDS -XX:DumpLoadedClassList=classes.txt -jar app.jar

The preceding command records all the loaded classes in the classes.txt file. If you would like to make your application load faster, stop the JVM just after the application has been started. If you need it to load certain classes faster but these classes are not loaded at the application startup automatically, make sure that the use cases that require these classes are executed.

4. Alternatively, you can manually edit the classes.txt file and add/remove any classes you need to put in the shared archive. Create this file once automatically and see the format. It is a simple text file that lists one class in each line.
5. Once the list is created, use the following command to generate the shared archive:

java -XX:+UseAppCDS -Xshare:dump -XX:SharedClassListFile=classes.txt -XX:SharedArchiveFile=app-shared.jsa --class-path app.jar

Notice that the shared archive file has a name other than classes.jsa, so the default shared archive is not overwritten.

6. Use the created archive by executing the following command:

java -XX:+UseAppCDS -Xshare:on -XX:SharedArchiveFile=app-shared.jsa -jar app.jar

Again, you can use the -Xshare:auto option to avoid an unexpected exit of the JVM.

The effect of the shared archive usage depends on the number of classes in it and other particulars of the application. So, we recommend you experiment and test various configurations before committing to a certain list of classes in production.