JDK 11 is the next LTS release of the JDK (as defined by Oracle and being followed by everyone else). Although there are not a lot of developer-focused features, there’s a lot going on lower down in the JVM laying the groundwork for future more prominent features.
$ java -version java version "11.0.1" 2018-10-16 LTS Java(TM) SE Runtime Environment 18.9 (build 11.0.1+13-LTS) Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.1+13-LTS, mixed mode)
What are the features and enhancements in Java 11, and how will it be different from previous version and the change on the way we code. This post is basically a very short summary of each JEP as documented for JDK 11.
JEP 181: Nest-Based Access Control
JEP 181 introduce nests, an access-control context that aligns with the existing notion of nested types in the Java programming language. Nests allow classes that are logically part of the same code entity, but which are compiled to distinct class files, to access each other's private members without the need for compilers to insert accessibility-broadening bridge methods.
package com.dariawan.jdk11;
import java.lang.reflect.Method;
/**
* JEP 181: Nest-Based Access Control
*/
public class JEP181 {
public static class World1 {
private void sayHello(String name) {
System.out.println("from World1: Hello " + name);
}
}
public static class World2 {
public void sayHello() throws Exception {
final World1 world1 = new World1();
// this is working
world1.sayHello("Alice");
// this is not working before
// but working from java 11
try {
final Method m = World1.class.getDeclaredMethod("sayHello", String.class);
m.invoke(world1, "Beatrice");
}
catch (NoSuchMethodException nsm) {
throw new Exception("NoSuchMethodException thrown: " + nsm.getMessage());
}
catch (IllegalAccessException ex) {
throw new Exception("Cannot access sayHello through getDeclaredMethod", ex);
}
}
}
public static void main(String[] args) {
try {
new World2().sayHello();
}
catch (Exception ex) {
System.out.println("Exception: " + ex.getMessage());
}
}
}
/*
Output:
------
from World1: Hello Alice
from World1: Hello Beatrice
*/
Class JEP181 is called the top level type. In nests concept, JEP181 together with World1 and World2 are nestmates. Because they are nestmates, Worl2 can access the private method sayHello of nested class World1 (line 23), this is also applicable prior to Java 11. However, prior to Java 11, if you use reflection as in lines 28–29, it raises an IllegalAccessException. JEP181 solves this problem, thus using reflection here is not going to raise an exception and will work as excepted.
Two new attributes are defined for the class file format, NestHost and NestMembers. These changes are useful for other languages that support nested classes and are compiled to bytecodes.
JEP 309: Dynamic Class-File Constants
JEP 309 aims to extend the Java class-file format to support a new constant-pool form,CONSTANT_Dynamic. Loading a CONSTANT_Dynamic will delegate creation to a bootstrap method, just as linking an invokedynamic call site delegates linkage to a bootstrap method.
JEP 315: Improve Aarch64 Intrinsics
JEP 315 aims to improve the existing string and array intrinsics, and implement new intrinsics for the java.lang.Math sin, cos and log functions, on AArch64 processors.
JEP 318: The Epsilon Garbage Collector
JEP 318 aims to develop a GC that handles memory allocation but does not implement any actual memory reclamation mechanism. Once the available Java heap is exhausted, the JVM will shut down.
JEP 320: Remove the Java EE and CORBA Modules
JEP 320 aims to remove the Java EE and CORBA modules from the Java SE Platform and the JDK. These modules were deprecated in Java SE 9 with the declared intent to remove them in a future release - which is this Java 11.
The affected modules are:
- CORBA
- transaction
- activation
- xml.bind
- xml.ws
- xml.ws.annotation
JEP 321: HTTP Client (Standard)
JEP 321 standardize the incubated HTTP Client API introduced in JDK 9, via JEP 110, and updated in JDK 10. The HTTP Client API is now part of the Java SE 11 standard. The module name and the package name of the standard API is java.net.http.
The API provides high-level client interfaces to HTTP (versions 1.1 and 2) and low-level client interfaces to WebSocket. The main types defined are:
The API can be used synchronously or asynchronously.
package com.dariawan.jdk11;
import java.net.http.HttpClient;
import java.net.http.HttpClient.Version;
import java.net.http.HttpRequest;
import java.net.http.HttpResponse;
import java.net.http.HttpResponse.BodyHandlers;
import java.net.URI;
public class JEP321 {
public static void main(String[] args) throws Exception {
final HttpClient httpClient = HttpClient.newBuilder()
.version(Version.HTTP_2) // default
.build();
final HttpRequest request = HttpRequest.newBuilder()
.uri(URI.create("https://www.onlinefreeconverter.com/about"))
.GET() // default
.build();
final HttpResponse<String> resSync = httpClient.send(request, BodyHandlers.ofString());
System.out.println("Response: " + resSync.statusCode());
// System.out.println("Body: " + resSync.body());
httpClient.sendAsync(request, BodyHandlers.ofString())
.thenApply(HttpResponse::body)
.thenAccept(System.out::println)
.get();
}
}
JEP 323: Local-Variable Syntax for Lambda Parameters
For uniformity with local variables, JEP 323 allow var to be used when declaring the formal parameters of implicitly typed lambda expressions:
(var x, var y) -> x.process(y) // implicit typed lambda expression
But, some will point out that Lambda expressions already have type inference so the use of var would (in our case) be unnecessary. We could just as easily write the same code as:
(x, y) -> x.process(y) // implicitly typed lambda expression
One benefit of uniformity is that modifiers, notably annotations, can be applied to local variables and lambda formals without losing brevity:
(@Nonnull var x, @Nullable var y) -> x.process(y)
JEP 324: Key Agreement with Curve25519 and Curve448
JEP 327: Unicode 10
JEP 327 aims to upgrade existing platform APIs to support version 10.0 of the Unicode Standard.
Unicode 10.0 adds 8,518 characters, for a total of 136,690 characters. These additions include 4 new scripts, for a total of 139 scripts, as well as 56 new emoji characters.
The new scripts and characters in Version 10.0 add support for lesser-used languages and unique written requirements worldwide, including:
- Masaram Gondi, used to write Gondi in Central and Southeast India
- Nüshu, used by women in China to write poetry and other discourses until the late twentieth century
- Soyombo and Zanabazar Square, used in historic Buddhist texts to write Sanskrit, Tibetan, and Mongolian
- Syriac letters used for writing Suriyani Malayalam, also known as Garshuni and as Syriac Malayalam
- Gujarati signs used for the transliteration of the Arabic script into Gujarati by Ismaili Khoja communities
- A set of 285 Hentaigana characters used in Japan (historic variants of Hiragana characters)
- CJK Extension F (7,473 Han characters)
Important symbol additions include:
- Bitcoin sign
- 56 emoji characters (full list)
- A set of Typicon marks and symbols
For statistics regarding emoji associated with Unicode 10.0, see Emoji Counts.
JEP 328: Flight Recorder
Provide a low-overhead data collection framework for troubleshooting Java applications and the HotSpot JVM. Goals of JEP 328:
- Provide APIs for producing and consuming data as events
- Provide a buffer mechanism and a binary data format
- Allow the configuration and filtering of events
- Provide events for the OS, the HotSpot JVM, and the JDK libraries
There are two new modules for this: jdk.jfr and jdk.management.jfr
Flight Recorder can be started on the command line:
$ java -XX:StartFlightRecording ...
Recordings may also be started and controlled using the bin/jcmd tool:
$ jcmd <pid> JFR.start $ jcmd <pid> JFR.dump filename=recording.jfr $ jcmd <pid> JFR.stop
This functionality is provided remotely over JMX, useful for tools such as Mission Control.
JEP 329: ChaCha20 and Poly1305 Cryptographic Algorithms
JEP 329 aims to implement the ChaCha20 and ChaCha20-Poly1305 ciphers as specified in RFC 7539. ChaCha20 is a relatively new stream cipher that can replace the older, insecure RC4 stream cipher.
JEP 330: Launch Single-File Source-Code Programs
Enhance the java launcher to run a program supplied as a single file of Java source code, including usage from within a script by means of "shebang" files and related techniques.
JEP 330 eliminates the need to compile a single-file application, so now we can type
$ java HelloWorld.java
which is informally equivalent to:
$ javac -d <memory> HelloWorld.java $ java -cp <memory> HelloWorld
JEP 330 also provides ‘shebang’ support. A shebang file to invoke the Java launcher using source-file mode must specify the –source flag with the version of Java to use:
#!/path/to/java --source version
JEP 331: Low-Overhead Heap Profiling
Goals of JEP 331:
Provide a low-overhead way to get information about Java object heap allocations from the JVM that:
- Is low-overhead enough to be enabled by default continuously,
- Is accessible via a well-defined, programmatic interface,
- Can sample all allocations (i.e., is not limited to allocations that are in one particular heap region or that were allocated in one particular way),
- Can be defined in an implementation-independent way (i.e., without relying on any particular GC algorithm or VM implementation), and
- Can give information about both live and dead Java objects.
JEP 332: Transport Layer Security (TLS) 1.3
TLS 1.3 is a major overhaul of the TLS protocol and provides significant security and performance improvements over previous versions. Several early implementations from other vendors are available already. The goal of JEP 332 is to implement version 1.3 of the Transport Layer Security (TLS) Protocol RFC 8446, to remain competitive and keep pace with the latest standard.
JEP 333: ZGC — A Scalable Low-Latency Garbage Collector (Experimental)
JEP 333 introduce ZGC (Z Garbage Collector), a scalable low-latency garbage collector.
Goals of ZGC:
- GC pause times should not exceed 10ms
- Handle heaps ranging from relatively small (a few hundreds of megabytes) to very large (many terabytes) in size
- No more than 15% application throughput reduction compared to using G1
- Lay a foundation for future GC features and optimizations leveraging colored pointers and load barriers
- Initially supported platform: Linux/x64
JEP 335: Deprecate the Nashorn JavaScript Engine
JEP 335 aims to deprecate the Nashorn JavaScript script engine and APIs, and the jjs tool, with the intent to remove them in a future release.
The Nashorn JavaScript engine was first incorporated into JDK 8 via JEP 174 as a replacement for the Rhino scripting engine. When it was released, it was a complete implementation of the ECMAScript-262 5.1 standard.
With the rapid pace at which ECMAScript language constructs, along with APIs, are adapted and modified, the Java Team have found Nashorn challenging to maintain.
JEP 336: Deprecate the Pack200 Tools and API
JEP 336 aims to deprecate the pack200 and unpack200 tools, and the Pack200 API in java.util.jar.
Desson AriawanProgrammer
