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())