JDK 14 reached General Availability on 17 March 2020. JDK 14 is a feature release of Java, and the plan is that it will receive security updates in April and July before being superseded by JDK 15.

It can be downloaded from the official Oracle page (commercial version) or from the open JDK page: https://jdk.java.net/14/ . Other vendors should also release their distributions in the next couple of days.

In this article, we will go through the changes that are coming with this version of Java.

Note that as of 21 of March IntelliJ idea still does not have production ready support for java 14 features so if you want to use them in your Intellj without getting any warnings, you will need to use early access builds. Eclipse released new version supporting Java 14 on 20th of March, but that release still does not support all features (like pattern matching for instance of)

Helpful NullPointerExceptions (Standard)

Probably one of the features of Java 14 that will help developers the most in their day to day work. By an analysis of the bytecode instructions of a program, in the future, the JVM should be able to show precisely which variable results in a zero value.

Example message looks like this:

Exception in thread "main" java.lang.NullPointerException: 
        Cannot assign field "lika" because "krajina" is null
    at Demo.main(Demo.java:8)

If the more complex statement City city = evropa.krajina.lika.gracac throws an NPE, the message would dissect the statement and pinpoint the cause by showing the full access path which led up to the null:

Exception in thread "main" java.lang.NullPointerException: 
        Cannot read field "lika" because "evropa.krajina" is null
    at Demo.main(Demo.java:12)

Remove the Concurrent Mark Sweep (CMS) Garbage Collector(Standard)

One of the most popular Garbage Collectors is finally being removed after being deprecated in Java 9.

This is something to have in mind if you are migrating from Java 8, or you have been ignoring deprecation warnings until now.

Successors to CMS have arisen including ZGC and Shenandoah. Until this version, ZGC was available only for Linux. With version 14 and jeps 364 and 365, ZGC should be available on Mac and Windows also.

Switch Expressions (Standard)

Switch expressions were first introduced in Java 12, got improvements in Java 13 as well as in Java 14 where it became a standard feature.

Switch expressions as we saw them in Java 13 are still supported:

String numberOfDays = switch (month) {
            case 2:
                yield "28";
            case 4, 6, 9, 11:
                yield "30";
            case 1, 3, 5, 7, 8, 10, 12:
                yield "31";
            default: throw new RuntimeException("Invalid month");        
};

Additionally, now we can write code using a new syntax that uses the -> operator instead of the colon. Using this operator eliminates the need for using yield, it is implicit. Still, if you want to have a code block for some case, you still need to use yield:

String numberOfDays = switch (month) {
    case 2 ->  "28";
    case 4, 6, 9, 11 -> "30";
    case 1, 3, 5, 7, 8, 10, 12 -> "31"
    default -> {
        System.out.println("Invalid month");
        yield "0";
    }
};

Other smaller standard updates:

• NUMA-Aware Memory Allocation for G1(Standard)
  Improve G1 performance on large machines by implementing NUMA-aware memory allocation.
• JFR Event Streaming(Standard)
  Expose JDK Flight Recorder data for continuous monitoring.
• Non-Volatile Mapped Byte Buffers(Standard)
  Add new JDK-specific file mapping modes so that the FileChannel API can be used to create MappedByteBuffer instances that refer to non-volatile memory.
• ZGC on macOS
  Port the ZGC garbage collector to macOS.
• ZGC on Windows
  Port the ZGC garbage collector to Windows.
• Deprecate the ParallelScavenge + SerialOld GC Combination
• Remove the Pack200 Tools and API

Preview and incubator features:

Preview and incubator features are prone to changes (as we saw with the evolution of switch expressions from Java 12 until becoming standard in Java 14). Also, they are not enabled by default, so we will not go into great detail investigating them.

In case you haven’t read previous articles difference between preview and incubator features is that preview features are almost complete language features ready to try out while incubating features are distributed in their own module prefixed with JDK.incubator and when incubating process is finished they will be moved to proper JDK module. A more detailed explanation of differences between preview, incubator and experimental features you can find here.

Pattern Matching for instance of (Preview)

The goal of this feature is to eliminate the need for casting when doing instance of.
Before we needed to cast an object after we determined it belongs to some type using instance of:

if (obj instanceof String) {
    String s = (String) obj;
    // use s
}

Now with a small addition to instance of we can immediately start using that object, without need for explicit casting

if (obj instanceof String s) {
    // can use s here
} else {
    // can't use s here
}

Records (Preview)

Records provide a compact syntax for declaring classes which are transparent holders for shallowly immutable data. Read more at https://dzone.com/articles/a-first-look-at-records-in-java-14

Text Blocks (Second Preview)

A text block is a multi-line string literal that avoids the need for most escape sequences, automatically formats the string in a predictable way, and gives the developer control over the format when desired. Read more at https://www.baeldung.com/java-text-blocks

Packaging Tool (Incubator)

Simple packaging tool, based on the JavaFX javapackager tool, that:

• Supports native packaging formats to give end users a natural installation experience. These formats include msi and exe on Windows, pkg and dmg on macOS, and deb and rpm on Linux.
• Allows launch-time parameters to be specified at packaging time.
• Can be invoked directly, from the command line, or programmatically, via the ToolProvider API.

Foreign-Memory Access API (Incubator)

API that allows Java programs to safely and efficiently access foreign memory outside of the Java heap (like native memory, persistent memory, managed heap memory, etc.).

What’s new in Java 14 was originally published in HybridITSolutions on Medium, where people are continuing the conversation by highlighting and responding to this story.

In this article, we will cover changes that came with Java version 13.

Dynamic CDS Archives
This feature enhances the Application Class Data sharing which was introduced in Java 10. The idea behind this feature is to improve startup performance by creating class-data archive that JVM can reuse.
Read more at https://blog.codefx.org/java/application-class-data-sharing/

ZGC: Uncommit Unused Memory
The JEP 333: Z Garbage Collector is introduced in Java 11, it provides a short pause times when cleaning up heap memory. However, it didn’t return unused heap memory to the operating system, even when that memory has been unused for a long time.

This JEP enhanced the ZGC by returning unused heap memory to the operating system.

Reimplement the Legacy Socket API
The old default implementation of Socket API (PlainSocketImpl) dates back to java 1.0 and is really hard to debug and maintain. In Java 13 it is replaced with NioSocketImpl. If for some reason we need still to use PlainSocketImpl we can do it by passing -Djdk.net.usePlainSocketImpl to JVM.

Switch Expressions (Preview)
Switch expressions were introduced in Java 12 as a preview feature.
(Preview feature is a new concept introduced in Java 12. A preview language or VM feature is a new feature of the Java SE Platform that is fully specified, fully implemented, and yet impermanent.)
The impermanent nature of preview features can be seen through changes that came with Java 13. With Java 12 we could use break to return value from a switch expression. Now, break is no longer compiled and we should use yield.
Java 12:

String numberOfDays = switch (month) {
            case 2:
                break "28";
            case 4, 6, 9, 11:
                break "30";
            default:
                break "31";
        };

Java 13:

String numberOfDays = switch (month) {
            case 2:
                yield "28";
            case 4, 6, 9, 11:
                yield "30";
            default:
                yield "31";
        };

Note: switch expressions is still a preview feature and they can change more in the following versions.

Text Blocks (Preview)

This feature gives us a possibility to instantiate String as a text block.
Text blocks are surrounded with ””” (triple quotation marks).

The old way of writing text blocks:

String jsonExample ="{\n" +
                        \"region\":\"lika\"
                    "}\n";

The new way of writing text blocks:

String jsonExample = """
                      {
                        "region":"lika"
                      }
                     """;

What’s new in Java 13 was originally published in HybridITSolutions on Medium, where people are continuing the conversation by highlighting and responding to this story.

After Java 8: Part 5 — Java 12

In the previous article, we covered changes in Java 11. In this article, we will discuss changes in the language that came with version 12.

API Updates

New String Methods in preparation for raw strings

• String::indent

public String indent​(int n)

Adjusts the indentation of each line of this string based on the value of n, and normalizes line termination characters.

Parameters:n - number of leading white space characters to add or remove
Returns:string with indentation adjusted and line endings normalized

• String::transform

public <R> R transform​(Function<? super String,​? extends R> f) 

This method allows the application of a function to this string. The function should expect a single String argument and produce an R result.
Any exception thrown by f() will be propagated to the caller.

Type Parameters:R - class of the result
Parameters:f - functional interface to a apply
Returns:the result of applying the function to this string

Compact Number Format

NumberFormat shortNF = NumberFormat.getCompactNumberInstance()`
String short = shortNF.format(2000);
System.out.println(short) 
// prints 2k

Locale and decimals are configurable of course. Also, it is possible to create a custom compact number pattern.

The Teeing Collector

In short, Teeing Collector is a Collector that merges the results of two other collectors. Every element passed to the resulting collector is processed by both downstream collectors, then their results are merged using the specified merge function into the final result.

Stream<Integer> numbers = Stream.of(1,2,3,4,5);
long avarage = numbers.collect(
	Collectors.teeing(
		Collectors.summingInt(Integer::valueOf), 
		Collectors.counting(), 
		(sum, count) -> sum/count
		)
	);
//avarage ==> 3

Files::mismatch

Checks if two files are the same.
Files.mismatch(Path.of("/file1"), Path.of("/file1"))
This method returns -1 if files are identical. Otherwise, it returns the position of first mismatching byte, or the size of the smaller file (in bytes) when the files are different sizes and every byte of the smaller file is identical to the corresponding byte of the larger file.

Switch Expressions

Switch expressions are the first “preview feature” in Java.
Preview feature is a new concept introduced in Java 12. A preview language or VM feature is a new feature of the Java SE Platform that is fully specified, fully implemented, and yet impermanent. It is similar to incubator modules. The difference is that incubator modules are referring to new APIs while, as already stated, preview features refer to a new language or VM features.
Enable incubator modules flag: --add-modules jdk.incubator.httpclient
Enable preview features flag: --enable-preview
In IntelliJ this can be done on: file/project structure/project language level and preferences/.../java compiler/additional command line parameters

Read more at https://blog.codefx.org/java/switch-expressions/
Note that, as stated, preview features are yet impermanent and can change.

Java Micro-benchmarking Harness JMH

It measures execution time for small code pieces. It can be used to compare alternatives or to prevent performance regressions.

Advantages of JMH compared to ancient System.currentTimeMillis approach:

• JMH Handles JVM warm-up
• Consistent reporting
• Multithreading support

Possible pitfalls of using JMH:

• Dead code elimination
• Other compiler optimizations
• Assumptions

JMH has been developed as part of open jdk long time ago. In Java 12, JDK team added JMH and created a set of around 100 testsuites in JDK, making JMH defacto standard micro-benchmarking suite.
Note that JMH is still a separate project. If you want to include it to your project have a look at:
Official project page
Example integration with spring boot

JVM Changes

G1 improvements

Promptly return unused committed memory. The main goal for this feature is to improve the G1 garbage collector to immediately return Java heap memory to the operating system when inactive. To achieve this goal G1 will during low application activity periodically generate or continue a concurrent cycle to check the complete Java heap usage.

This will trigger it to immediately return unused Java heap portions to the operating system. When under user control, there’s an option to perform a full GC to maximise the volume of memory returned.

Shenandoah

Shenandoah is an experimental, low-pause-time garbage collector which targets large heap applications. It is contributed by Red Hat, and for some reason Oracle excludes it from their Open JDK build.
According to Red Hat, pause times are no longer in direct proportion with the size of the heap. In theory, this means that a heap that’s 2 GB could have the same pause time as a heap that’s 200 GB. You can read more about Shenandoah at https://wiki.openjdk.java.net/display/shenandoah/Main

JVM Constants API

This is a Low-level JVM feature that can be helpful for tools that manipulate classes and methods.
Read more at https://cr.openjdk.java.net/~vromero/constant.api/javadoc.04/java/lang/invoke/constant/package-summary.html

After Java 8: Part 5 — Java 12 was originally published in HybridITSolutions on Medium, where people are continuing the conversation by highlighting and responding to this story.

After Java 8: Part 4 — Java 11

In the previous article, we covered changes in Java 10. In this article, we will discuss changes in the language that came with version 11.

Launching single source code file

JEP 330

Before Java 11 in order to run Java program, we would need to compile it first using javac and then run class file we got using java command.

With Java 11 we can run java program directly from source.
java Hello.java

The Java launcher will identify that the file contains Java source code and will compile the code into memory before executing it.
Parameters placed after the name of the source file are passed as parameters when executing the application.
Parameters placed before the name of the source file are passed as parameters to the Java launcher after the code has been compiled. This allows for things like the classpath to be set on the command line.
Parameters that are relevant to the compiler (such as the classpath) will also be passed to javac for compilation.

To further simplify things Java 11 comes with “shebang” support.

Just add shebang line at the beginning of your script:
#!/usr/bin/java --source 11
Make the script executable:
chmod +x ShebangDemo
And run it:
 ./ShebangDemo .

Demo

Removed Enterprise APIs

With the introduction of Java Platform Module System in JDK 9, it was possible to divide the monolithic rt.jar file into multiple modules. An additional advantage of JPMS is it is now possible to create a Java runtime that only includes the modules you need for your application, reducing the size considerably. With cleanly defined module boundaries, it is now simpler to remove parts of the Java API that are outdated. This is what this JEP does; the java.se.ee meta-module includes six modules that will no longer be part of the Java SE 11 standard and not included in the JDK. The affected modules are:

• JAXB
• JAX-WS
• JAX-WS Annotations
• CORBA
• JTA

More info in JEP 320

• Removed methods

Thread class lost destroy() and stop(Throwable)
Methods related to object finalizers have been removed

• JavaFX moved to OpenJFX
• Applets are finally removed
• Java Web Start is removed
• Nashorn has been deprecated

Language and library improvements

HTTP2 client is moved from the incubator module to java.net.

JDK 9 introduced a new API to provide support for the HTTP Client protocol (JEP 110). Since JDK 9 introduced the Java Platform Module System (JPMS), this API was included as an incubator module. (Incubator modules are intended to provide new APIs without making them part of the Java SE standard. Developers can try the API and provide feedback. Once any necessary changes have been made (this API was updated in JDK 10), the API can be moved to become part of the standard.)

The HTTP Client API is now part of the Java SE 11 standard. This introduces a new module and package to the JDK, java.net.http.
The main types defined are: HttpClient; HttpRequest; HttpResponse; WebSocket
The API can be used synchronously or asynchronously. The asynchronous mode makes use of CompletableFutures and CompletionStages

HttpClientDemo

Small library additions

• String::repeat()
• String::isBlank()
• String::strip()
• String::lines()
• Files::readString()
• Files::writeString()
• Upgrade from Unicode 8 to 10

Full list of API changes: https://gunnarmorling.github.io/jdk-api-diff/jdk10-jdk11-api-diff.html

Performance and security improvements

Epsilon GC

• No-Op experimental garbage collector. Handles memory allocation but does not implement any actual memory reclamation mechanism. Once the available Java heap is exhausted, the JVM will shut down
• To be used for apps with predictable, bounded memory usage; Short-lived programs and performance testing
• -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC

Z Garbage Collector

• Pause times under 10ms
• No pause time increase with heap size increase
• Scale to the multi-terabyte heap size
• Linux/x64 only
• -XX:+UnlockExperimentalVMOptions -XX:+UseZGC

TLS 1.3 is supported

• Legacy algorithms pruned
• All handshake messages except first are encrypted
• Elliptic curve algorithms in the base specification
• Not all of TLS 1.3 are implemented see more at JEP 332

Local-Variable Syntax for Lambda Parameters

JDK 10 introduced the Local-Variable Type Inference. Java 11 extends the use of this syntax to the parameters of Lambda expressions. Since Lambda expressions already have type inference, this feature is mostly used when we want to add an annotation to the Lambda parameter.
Simple example:

list.stream()
     .map((@Notnull var t) -> t.toLowerCase())
     .collect(Collectors.toList())

After Java 8: Part 4 — Java 11 was originally published in HybridITSolutions on Medium, where people are continuing the conversation by highlighting and responding to this story.

After Java 8: Part 3 — Java 10

This is the third in a series of articles about changes in Java ecosystem after version 8. In the previous article, we covered changes in java 9. In this article, we will discuss changes in the language that came with version 10.

Java 10 is released in March 2018, it is non LTS release with the end of support in September 2018 for Oracle Open JDK and Oracle JDK. It is the first release in the new 6 months release cycle and therefore contains only minor, incremental changes.

Local variable type inference

Java 10 introduced var as a reserved type name that can be used to initialise local variable without declaring it explicitly. The idea of var is to reduce boilerplate code and increase readability.

//declaring variable explicitly
BufferedWriter bufferedWriter = new BufferedWriter(new FileWriter("path/file"));

//using var
var someString = "someString";

At compile time, the compiler infers a type based on the initialisation statement.

//var after compilation 
String someString = "someString";

From Java 10, creating class or interface with name var is not possible because var is a reserved type name. However, class or interface with name Var (upper case ) can be created.

public class var {
    //compile error: var cannot be used for type declarations
} 
public class Var {
   //compiles successfully 
}

How var cannot be used in code:

• var cannot be used as a field type, method parameter type or constructor parameter type.
• Because var is a reserved type name, methods and fields can be named var

class SomeClass {
   private int var;
   public void var() {
   }   
 }

• var must be initialized

//compile error, var must be initialised
var x;

• var cannot be referenced to a null

//compile error, cannot infer type, var initialiser is null 
var x = null;

• var is not allowed in a compound declaration.

//compile error, cannot infer type
 var i, j =0;

• var cannot replace the type of lambda expression

var lambda = x -> x > 3

How to and how not to use war:

Think twice before using it. Does it really add to readability off your code?

If you decide to use it, here are some advices that can help you to use it better, and to annoy the person who will be doing maintenance of that code a little bit less:

• Choose a good variable name

var x = dbConnection.executeQuery(query);  //bad example

var users = dbConnection.executeQuery(query); //good example

• Use good initializer information

var user = get();  //bad example

var users = getUsers(); //good example

var user = getUser(); //good example

• Take care with <>

var users = new ArrayList<>();  //bad example - ArrayList<Object> is inferred

var users = new ArrayList<User>(); //good example - ArrayList<User> is inferred

• don’t use var for initialising anonymous object

var object = new Object(){} // the type of the object variable is Object$1 extends Object

object = new Object(); // won't compile, object type isn't compatible with Object$1 which is inferred type of the variable

• intersection types

var list = List.of(1, 2.0, "3");

// type => List<Serializable & Comparable<? extends Serializable & Comparable<?>>>

OrElseThrow

Java 8 introduced Optional API for preventing the NullPointerException by wrapping the object that we suspect may be null. Java 10 introduced orElseThrow() method which can be called on object type Optional and it will throw NoSuchElementException if object inside the Optional is null.

Optional<String> optional = Optional.empty();

optional.orElseThrow() // Will throw NoSuchElementException

APIs for creating unmodifiable collections

Java 10 added List.copyOf, Set.copyOf, Map.copyOf for creating the unmodifiable collection with copied instances of other collection

var cars = new ArrayList<String>(List.of("Opel", "Mercedes", "Toyota"));

var unmodifiableCarList = List.copyOf(cars);

unmodifiableCarList.add("Audi"); //Will throw UnsupportedOperationException

Difference between Collections.unmodifiableList(cars) and List.copyOf(cars)

var cars = new ArrayList<>(List.of("Opel", "Mercedes", "Toyota"));

var unmodifiableList = Collections.unmodifiableList(cars);

var unmodifiableCopiedList = List.copyOf(cars);
cars.add("Haudi");

System.out.println("Unmodifiable list: " + unmodifiableList);
System.out.println("Unmodifiable copied list: " + unmodifiableCopiedList);
/* 
      Output:
      Unmodifiable list: [Opel, Mercedes, Toyota, Haudi]
      Unmodifiable copied list: [Opel, Mercedes, Toyota]
 */

Also, unmodifiable collection can be created from stream using Collectors.toUnmodifiableList, Collectors.toUnmodifiableSet, Collectors.toUnmodifiableMap

var collectionFromStream = list.stream().collect(Collectors.toUnmodifiableList());
    
collectionFromStream.add("test"); //Will throw UnsupportedOperationException

Other improvements

• Graal As a result of JVM Compiler Interface introduced in java 9

Graal compiler is written entirely in java (unlike C1 and C2 compilers that are written in C). Since it uses JVM Compiler Interface to communicate with VM it can be used with both HotSpot VM as well as Graal VM. More about GraalVM and Graal Compiler: https://www.graalvm.org/ , https://github.com/oracle/graal/

-XX:+UnlockExperimentalVMOptions 
-XX:+EnableJVMCI 
-XX:+UseJVMCICompiler

• G1GC improvements

Mainly introduction of full parallel processing during a Full GC. This change won’t help the best-case performance times of the garbage collector, but it does significantly reduce the worst-case latencies.

• Thread-local handshakes

During serviceability operations, like collecting stack traces for all threads or performing garbage collections, when the JVM needed to pause one thread, it needed to stop them all. Sometimes, these are referred to as “stop-the-world” pauses. This was due to the JVM wanting to create a global safepoint from which all application threads could begin again once the JVM was done. In Java 10, though, the JVM can put an arbitrary number of threads into a safepoint, and threads may continue running after performing the prescribed “handshake”. The result is that if the JVM can pause just one thread at a time, whereas before it had to pause them all.

• Container awareness

Before java was not container aware. So, in case you had you java app running in Docker, and for some reason you didn’t set max heap size on app startup, JVM would allocate 1/4 of memory available on host. So, in case you had 10 docker containers running on the same host, and each of them taking 1/4 of available host memory things will go wrong quite fast.

Now, if you wish to have your app aware of space allocated to container where it runs, you should pass following params on startup:

-XX:+UseCGroupMemoryLimitForHeap
-XX:ActiveProcessorCount=xy

Where xy is number of processor cores that container is using.

• Alternative memory allocation

-XX:AllocateHeapAt=<path>

After Java 8: Part 3— Java 10 was originally published in HybridITSolutions on Medium, where people are continuing the conversation by highlighting and responding to this story.

After Java 8: Part 2 — Java 9

This is the second in a series of articles about changes in Java ecosystem after version 8. In the previous article, we covered changes in licensing and release cadence. In this article, we will discuss changes in the language itself that came with version 9.

Java 9

Java 9 is released in September 2017 and it is non LTS release, with the end of support scheduled for March 2018, it brought probably the biggest changes to Java ecosystem in the last 10 years.

Module system

A huge amount of credits for making Java 9 release with the biggest changes in the last 10 years go to the module system. It was initially planned for Java 7, but postponed for 8 and subsequently to 9. It is one of the biggest changes in Java ever, since it does not affect only language itself but also a compiler, VM, and Tooling.

Module system is a result of project Jigsaw. The first and main reason for this feature is to modularize JDK itself, make it maintainable again. Second (and to be honest a lot smaller) reason is to enable developers to modularize their own applications. Of course, modularizing applications is purely optional, but still, they run on modular JDK.
JDK becoming too large is the main motivation behind the module system. Now, there are more than 90 platform modules.

Migration

Easy unless:
1. You or some libs use JDK types that have been encapsulated.
They will still run, but they will not compile… This can change in the next versions. If you want, you can enforce encapsulation in runtime by passing the following flag to jvm: --illegal-access=deny You can bypass encapsulation at compile time by using -add-exports $moduleYouNeed/$packageYouNeed=$yourModule
This command line option exports $packageYouNeed of $moduleYouNeed to $yourModule. Code in $yourModule can hence access all public types in $packageYouNeed but other modules can not.
This option is available for the java and javac commands. Although it is for now not necessary for java command, since as stated app will still run. But again, this is something that can change in the future.

When setting $yourModule to ALL-UNNAMED, all code from the classpath can access that package. This is a preferred way to go when accessing internal APIs during migration to Java 9. Example:
javac --add-exports java.base/sun.security.x509=ALL-UNNAMED Main.java

If you have trouble migrating there is a handy tool shipped with JDK to help you. jdeps -jdkinternals target/classes/com/mbrkljac/javaaftereight/HttpClientDemo.class Using this tool you can check dependencies without running or compiling. It also suggests solutions for potential problems it finds.

2. You or some lib use types from non-default Java modules (java.se.ee) This can be mitigated using: javac --add-modules java.xml.bind Main.java and java --add-modules java.xml.bind Main

More info about jdeps: https://docs.oracle.com/javase/8/docs/technotes/tools/unix/jdeps.html

Module system implementation

Module has a name, it groups related code as well as resources and is fully self-contained.
Every module has a module descriptor which consists of:

• Module’s name
• Module’s dependencies (that is, other modules this module depends on)
• Packages it explicitly makes available to other modules (all other packages in the module are implicitly unavailable to other modules)
• services it offers
• services it consumes
• to what other modules it allows reflection
• …

A module descriptor is the compiled version of a module declaration that’s defined in a file named module-info.java. Module descriptor is stored in a file named module-info.class in the module’s root folder. Each module declaration begins with the keyword module, followed by a unique module name and a module body enclosed in braces, as in:

module modulename {}

The module declaration’s body can be empty or may contain various module directives like:

• requires. A requires module directive specifies that this module depends on another module — this relationship is called a module dependency. Each module must explicitly state its dependencies. When module A requires module B, module A is said to read module B and module B is read by module A. To specify a dependency on another module, use requires, as in:

requires modulename;

• requires transitive — implied readability. To specify a dependency on another module and to ensure that other modules reading your module also read that dependency — known as implied readability — use requires transitive, as in:

requires transitive modulename;

• exports and exports…to. An exports module directive specifies one of the module’s packages whose public types (and their nested public and protected types) should be accessible to code in all other modules. An exports…to directive enables you to specify in a comma-separated list precisely which module’s or modules’ code can access the exported package — this is known as a qualified export.
• uses. A uses module directive specifies a service used by this module — making the module a service consumer. A service is an object of a class that implements the interface or extends the abstract class specified in the uses directive.
• provides…with. A provides…with module directive specifies that a module provides a service implementation — making the module a service provider. The provides part of the directive specifies an interface or abstract class listed in a module’s uses directive and the with part of the directive specifies the name of the service provider class that implements the interface or extends the abstract class.
• open, opens, and opens…to. Before Java 9, reflection could be used to learn about all types in a package and all members of a type — even its private members — whether you wanted to allow this capability or not. Thus, nothing was truly encapsulated.
  A key motivation of the module system is strong encapsulation. By default, a type in a module is not accessible to other modules unless it’s a public type and you export its package. You expose only the packages you want to expose. With Java 9, this also applies to reflection, allowing runtime-only access to a package. An opens module directive of the form opens package
  indicates that a specific package’s public types (and their nested public and protected types) are accessible to code in other modules at runtime only. Also, all the types in the specified package (and all of the types’ members) are accessible via reflection.
• Allowing runtime-only access to a package by specific modules. An opens…to module directive of the form opens package to comma-separated-list-of-modules indicates that a specific package’s public types (and their nested public and protected types) are accessible to code in the listed modules at runtime only. All of the types in the specified package (and all of the types’ members) are accessible via reflection to code in the specified modules.
• Allowing runtime-only access to all packages in a module. If all the packages in a given module should be accessible at runtime and via reflection to all other modules, you may open the entire module, as in: open module modulename {// module directives}

The keywords exports, module, open, opens, provides, requires, uses, with, as well as to and transitive, are restricted keywords. They’re keywords only in module declarations and may be used as identifiers anywhere else in your code.

Cyclic dependencies are not supported.

Advantages:

• Security (Module can expose some of its packages, and encapsulate other)
• Reduced footprint
• Easy deprecation (In java 9, java.corba was removed)
• Future proof (Incubator modules jdk.incubator.httpclient)
• Improved performance — The JVM uses various optimization techniques to improve application performance. JSR 376 indicates that these techniques are more effective when it’s known in advance that required types are located only in specific modules.

JShell

https://docs.oracle.com/javase/9/jshell/JSHEL.pdf

JShell is a command line tool that provides interactive use of Java Programming Language elements. JShell is a REPL(Read -> type code; Eval -> execute code; Print -> see results; Loop -> interactively refine).
With it, we can enter program elements one at a time, immediately seeing the result and adjusting accordingly. It is mainly intended to be used to test out ideas, explore API’s as well as teaching.

Main features:

• It’s just plain java.
• You get code completion,
• it has built-in documentation.
• It is possible to incrementally create code inside of jshell. (variable can be declared later)
• It is possible to save and open snippets
• Snippets can be edited using an external editor
• JShell API enables IDE integration. (IntelliJ: Tools/JShell Console)

Library and Language Improvements

Java 9 comes with some small extensions to existing java libraries. There are no major changes like in java 8, changes in module system are big enough for themselves.

Collection factory methods

Old ways:

List<String> food  = new ArrayList<>();
food.add("Lamb");
food.add("Pork");
food.add("Beef");

List<String> food = Arrays.asList("Lamb")
List<String> food = new ArrayList<>()
List<String> food = Collections.emptyList()

New way:
List<String> food = List.of("Lamb", "Pork", "Beef")
Set<String> strings = Set.of("One", "Two")
Map<String, Integer> map = Map.of("One", 1, "Two", 2)
Those methods return immutable collections and are heavily optimized. Note that iteration order for Set and Map is not guaranteed. (It was not guaranteed before also, but with the old approach, the order was mostly consistent. Now, that is not the case.)

Stream API Improvements

Added methods:
static Stream<T> ofNullable(T t)

List<String> nullableList = getStringsPossibleNull();
//Old way

Stream strings = nullableList == null ? Stream.empty() : nullableList.stream();

//New way
Stream strings = Stream.offNullable(nullableList);

Stream<T> takeWhile(Predicate<? super T> predicate)
TakeWhile is similar to filter in the sense that it expects a predicate and returns a new stream consisting only of the elements that match the given predicate. In an ordered stream, takeWhile takes elements from the initial stream while the predicate holds true. Meaning that when an element is encountered that does not match the predicate, the rest of the stream is discarded.
If the stream is unordered, if some of the elements in the stream match the predicate (but not all) then the operation is nondeterministic and an arbitrary subset of matching elements is returned or removed. If all elements match the predicate, all input will be returned. If none matches, the empty stream will be returned.

jshell> Stream.of(2, 4, 5, 6 ,8)
    .takeWhile(n -> n % 2 == 0)
    .forEach(System.out::print);
// prints out: 24

jshell> Set<Integer> numbers = Set.of(2, 4, 5, 6 ,8);
numbers.stream()
    .takeWhile(n -> n % 2 == 0)
    .forEach(System.out::print);
//Prints out different result depending on how Set has been initialised

numbers ==> [2, 8, 6, 5, 4]
286

Stream<T> dropWhile(Predicate<? super T> predicate) dropWhile is the opposite of takeWhile. It drops the element until the first element that matches the predicate, and includes the rest in the result stream;

static Stream<T> iterate(T seed, Predicate<? super T> hasNext, UnaryOperator<T> next) Overloaded iterate method, added hasNext parameter which is used to determine when the Stream must terminate.

jshell> Stream.iterate(0, i -> i < 9, i -> i + 1)
  .forEach(System.out::print);
//Prints out: 012345678

New Collectors:

filtering

The Collectors.filtering is similar to the Stream filter(); it’s used for filtering input elements but used for different scenarios. The Stream’s filter is used in the stream chain, whereas the filtering is a Collector that was designed to be used along with groupingBy.

With Stream’s filter, the values are filtered first and then it’s grouped. In this way, the values which are filtered out are gone and there is no trace of it. If we need a trace then we would need to group first and then apply filtering which actually the Collectors.filtering does.

The Collectors.filtering takes a function for filtering the input elements and a collector to collect the filtered elements:

jshell> 
    List<Integer> numbers = List.of(1, 2, 3, 5, 5);
 
    Map<Integer, Long> result = numbers.stream()
      .filter(val -> val > 3)
      .collect(Collectors.groupingBy(i -> i, Collectors.counting()));
  
    result = numbers.stream()
      .collect(Collectors.groupingBy(i -> i,
        Collectors.filtering(val -> val > 3, Collectors.counting())));

flatMapping

The Collectors.flatMapping is similar to Collectors.mapping but has a more fine-grained objective. Both the collectors take a function and a collector where the elements are collected but flatMapping function accepts a Stream of elements which is then accumulated by the collector.

Additions to optional

• ifPresentOrElse
  public void ifPresentOrElse(Consumer<? super T> action, Runnable emptyAction)
  Example:
  Optional<String> value = Optional.of("someValue"); value2.ifPresentOrElse(v -> System.out.println(v), () -> System.out.println("empty"));
• or
  Used when we want to execute some other action that also returns an Optional.
  Prior to Java 9, the Optional class had only the orElse() and orElseGet() methods but both need to return unwrapped values.
  Java 9 introduces the or() method that returns another Optional lazily if our Optional is empty. If our first Optional has a defined value, the lambda passed to the or() method will not be invoked, and value will not be calculated and returned:
  Optional<String> result = value.or(() -> defaultValue);
• stream
  Added to achieve interoperability between Optional and Stream. Calling stream() on empty optional will result in an empty stream.
  Quite useful in combination with Stream.flatMap

List<Optional<String>> listOfOptionals = Arrays.asList(Optional.empty(), Optional.of("foo"),
 Optional.empty(), Optional.of("bar"));  
  
 // Java 8:

List<String> filteredList = listOfOptionals.stream()
   .flatMap(o -> o.isPresent() ? Stream.of(o.get()) : Stream.empty())
   .collect(Collectors.toList());

//Java 9:  
`List<String> filteredList = listOfOptionals.stream()
   .flatMap(Optional::stream)
   .collect(Collectors.toList());

java.time improvements

• long dividedBy(Duration divisor)
• Duration truncatedTo(TemporalUnit unit)
• static Clock systemUTC() -> can be accurate in nanoseconds depending on platform.
• Stream datesUntil(LocalDate endExclusive, Period step) && Stream datesUntil(LocalDate endExclusive)

Other small improvements

• Single underscore as an identifier is now illegal.
• Try-with-resources improvements With the old approach, a new variable was required:

public void doWithFileInputStream(FileInputStream fis) {
	try(FileInputStream fis2 =fis) {
		fis2.read();
	}
}

New approach:

public void doWithFileInputStream(FileInputStream fis) {
	try(fis) {
		fis.read();
	}
}

Note: in order to use a variable in try statement, it needs to be effectively final. Effectively final variable is variable that either has the final keyword or is not reassigned within the method.

• Private interface methods
• Javadoc is HTML5 compliant, Search is added, modules documentation also added https://docs.oracle.com/en/java/javase/12/docs/api/index.html
• Localization improvements. Unicode 8.0 support.
• JVM Compiler Interface

New APIs. Process API and Http2 API

Process API

java.lang.Process Represents native processes created from Java java.lang.ProcessHandle Represents any native process on the operating system

ProcessHandle.of(123)
ProcessHandle.info()
ProcessHandle.allProcesses() -> Returns a stream of a current snapshot of processes state…

Demo:
ProcessHandleInfoDemo ProcessHandleDestroyDemo

HttpClient API

Supports HTTP/2 and WebSocket
Caveat: incubator module (They can change, and are not by default part of jdk.)
In order to use it pass following flag: --add-modules jdk.incubator.httpclient

Reactive Streams (Flow API)

• Not meant as end-user API
• Stream data with support for backpressure
• Vendor-neutral specification (www.reactive-streams.org)
• Flow API: interfaces added to JDK
• Interoperability for reactive projects like RxJava, Akka Streams
• HttpClient implements Publisher/Subscriber interfaces
• java.util.concurrent.Flow support is implemented in RxJava 2, Spring 5, Akka Streams

StackWalker API

Old way:
StackTraceElement[] stackTrace = Thread.getStackTrace()

• Low performance
• No guarantee all stack elements are returned
• No partial handling possible

New way:

StackWalker walker = StackWalker.getInstance();
walker.forEach()

Demo:
StackWalkerDemo

Performance and security improvements

G1 Garbage Collector

GC combinations deprecated in Java 8 were removed. CMS Collector is deprecated

• G1 (garbage first) garbage collector is introduced in java 6 and is now default when JVM is running in server mode (as opposed as running in client mode)

To read more about server vs client JVM: https://javapapers.com/core-java/jvm-server-vs-client-mode/

Important commands to remember for tuning G1:

--XX:MaxGCPauseMillis=200
--XX:+G1EnableStringDeduplication

Concurrent Mark Sweep Heap structure:

G1 Heap structure:

G1 Heap allocation:

Read more: https://www.oracle.com/technetwork/tutorials/tutorials-1876574.html

String performance

• Compact strings
• Lower memory usage without any code changes.
• Strings in Java are internally represented by a char[] containing the characters of the String. And, every char is made up of 2 bytes because Java internally uses UTF-16. If a String contains a word in the English language, the leading 8 bits will all be 0 for every char, as an ASCII character can be represented using a single byte.
• As of Java 9, strings are stored as byte[] and not as char[]
• Final field coder is added. This field preserves information about encoding.
• If encoding is LATIN1, single byte will be used to represent every char. In the case of UTF16, 2 bytes will be used.
• This leads up to 15% less memory consumption.

/**
        * The identifier of the encoding used to encode the bytes in
        * {@code value}. The supported values in this implementation are
        *
        * LATIN1
        * UTF16
        *
        * @implNote This field is trusted by the VM, and is a subject to
        * constant folding if String instance is constant. Overwriting this
        * field after construction will cause problems.
        */
       private final byte coder;

Concatenation of Strings

Before java9:

String nemaRajaBez = "rodnoga " + "kraja";

Would result in:

6:  new           #4      // class StringBuilder
9:  dup
10: invokespecial #5      // Method StringBuilder."<init>"
13: aload_1	          // String rodnoga
14: invokevirtual #6      // Method StringBuilder.append:(LString;)LStringBuilder;             
17: aload_2		  // String kraja
18: invokevirtual #6      // Method StringBuilder.append:(LString;)LStringBuilder;

21: invokevirtual #7      // Method StringBuilder.toString:()LString;
....

Java 9:

6: aload_1		  // String rodnoga           
7: aload_2		  // String kraja
.....
8: invokedynamic #4, 0    // InvokeDynamic #0:makeConcatWithConstants:
                          // (LString;LString;)LString;

BootstrapMethods:
   0: #19 invokeStatic StringConcatFactory.makeConcatWithConstants:
     (… , … , LMethodType; , LString; , … ) LCallSite;
     Method arguments:
        #20 \u0001\u0001

The reason to change the compiler now in this way is, from the project description, to “enable future optimizations of String concatenation without requiring further changes to the bytecode emitted by javac.”. Dynamic method invocation is an ideal solution for that challenge, as it delays method implementation to the runtime. The developers of the Java runtime can then improve the implementation of the factory class, without all other developers needing to recompile their projects.

https://www.guardsquare.com/en/blog/string-concatenation-java-9-untangling-invokedynamic

Serialization

There are numerous vulnerabilities related to serialization. Java 9 tries to address this by adding a new interface to filter data before deserializing.

interface ObjectInputFilter {
	Status checkInput(FilterInput filterInput);
	enum Status {
		UNDECIDED,
		ALLOWED,
		REJECTED;
	}
}

ObjectInoutStream::setObjectInputFilter -> per stream
ObjectInputFilter.Config.setSerialFilter -> for all streams

Alternatively, you can filter incoming serialization data without adding or changing code. For this, you can use jdk.serialFilter system property. This property is backported to Java 6/7/8

maxbytes=n; maxarray=n; maxdepth=n;
com.hybrid.dto.; (All types from this package can be serialized)
!com.someoneelse.; (No types from this package can be serialized)

Further reading:

https://docs.oracle.com/javase/9/whatsnew/toc.htm

After Java 8: Part 2 — Java 9 was originally published in HybridITSolutions on Medium, where people are continuing the conversation by highlighting and responding to this story.