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.
- Visit http://jdk.java.net/11/ and accept the early-adopter license agreement, which looks like this:

- 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. - Run the JDK executable (
.exe
) and follow the onscreen instructions to install JDK on your system. - If you have chosen all the defaults during the installation, you will find JDK installed in
C:/Program Files/Java
for 64 bit andC:/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:
- Navigate to the directory where the tools are installed and run them, as follows:
cd "C:\Program Files\Java\jdk-11\bin"
javac -version
- 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 thePATH
environment variable.
Let's see how you can add the JDK bin directory to the PATH
variable:
- Right-click on
My Computer
and then click onProperties
. You will see your system information. Search forAdvanced system settings
and click on it to get a window, as shown in the following screenshot:

- 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.
- A new variable, with the name
JAVA_HOME
, and its value as the location of the JDK 9 installation. For example, it would beC:\Program Files\Java\jdk-11
(for 64 bit) orC:\Program Files (x86)\Java\jdk-11
(for 32 bit):

- Update the
PATH
environment variable with the location of the bin directory of your JDK installation (defined in theJAVA_HOME
environment variable). If you already see thePATH
variable defined in the list, then you need to select that variable and click onEdit
. If thePATH
variable is not seen, click onNew
. - 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:

- You can either click on
New
in the first screenshot and insert the%JAVA_HOME%\bin
value, or you can append the value against theVariable value
field by adding; %JAVA_HOME%\bin
. The semicolon (;
) in Windows is used to separate multiple values for a given variable name. - After setting the values, open the command prompt and run
javac -version
. You should be able to seejavac 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 thePATH
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.
- 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.
- Copy the download link (
tar.gz
) for the JDK for the Linux x64 platform from the downloads page. - 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
.
- 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 tomore
to paginate the output:$> tar -tf jdk-11-ea+26_linux-x64_bin.tar.gz | more
. - 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
.
- Update the
JAVA_HOME
andPATH
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.
- 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.
- 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()); } }
- We will now create a module named
com.packt
. To create a module, we need to create a file namedmodule-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; }
Note
We will explain modules in detail in Chapter 3, Modular Programming. But this example is just to give you a taste of modular programming and to test your JDK installation.
The directory structure with the preceding files is as follows:

- 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
- 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 existingget()
method - New APIs for creating unmodifiable collections: The
List.copyOf()
,Set.copyOf()
, andMap.copyOf()
methods of thejava.util
package and new methods of thejava.util.stream.Collectors
class:toUnmodifiableList()
,toUnmodifiableSet()
, andtoUnmodifiableMap()
(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 aString
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 twoCharSequence
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 theString
class: Returns aString
value composed ofcount
times repeated in theString
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 theString
class: Returnstrue
if theString
value is empty or contains only white spaces, otherwisefalse
. In our example, we have contrasted it with theisEmpty()
method, which returnstrue
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 theString
class: Returns aStream
object that emits lines extracted from the sourceString
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 sourceString
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 ajava.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 thejava.util.regex.Pattern
class, which creates an object of thejava.util.function.Predicate
functional interface, which then allows us to test aString
value for matching the compiled pattern. In the following example, we test whether aString
value starts with thea
character and ends with theb
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
, andjava.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.
- 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
On a Windows system, it is placed in the following folder:
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.
- 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.
- 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.
- 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. - 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.
- 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.