Java 15 New Features

Java 15 (Java SE 15) and Java Development Kit 15 (JDK 15) has been Generally Available (GA) on 15 September 2020. Java 15 offers some exciting new features, preview features, and incubator features. For us, it's a very interesting showcases, leading to build-up for Java 17, the next LTS version which will be release in September 2021, exactly one year from now. To give it a try, you can download JDK15 from AdoptOpenJDK website. After you install it or setup your environment, to check your Java version:

Without further ado, let's check new features and improvements introduced in this release.

JEP 339 covers the implementation of Edwards-Curve Digital Signature Algorithm (EdDSA) algorithm, based on RFC 8032. EdDSA is a modern cryptographic signature scheme that has several advantages over the existing (JDK) signature schemes, with expectedly faster performance than the existing ECDSA implementation.

JEP 360 enhance the Java programming language with sealed classes and interfaces. This new feature (still in preview): sealed classes and interfaces provides a way to restrict the implementation or inheritance of a class or interface. This feature introducing explicit restriction, does not change how the final keyword or package-private mechanisms working.

A class or interface is sealed by applying the sealed modifier in its declaration, then at the end using permits keyword to specifies all classes that are permitted to extend this sealed class

In below example, we will declared a sealed class Robot, and permits class RobotVacuumCleaner to extend:

When it compiled (with --enable-preview option), it's successfully compiled:

But when we introduce another class RobotLawnMower which not part of Robot's permits list:

When this is compiled, you will get a compilation error because RobotLawnMower is not permitted to extend from Robot:

You notice several new keywords: sealed, non-sealed, permits. To getting more about Sealed Class, please check special article about this preview feature.

JEP 371 introduces “hidden classes”, that invisible and cannot be used directly by the bytecode of other classes. This type of class will be used by frameworks that generate classes at run time and use them indirectly, via reflection.

JEP 372 aims to remove The Nashorn JavaScript engine and APIs that were marked as deprecated since Java 11. Two modules will be removed:

• jdk.scripting.nashorn: module that provides the implementation of Nashorn script engine and the runtime environment for programs written in ECMAScript 5.1.
• jdk.scripting.nashorn.shell

The Nashorn JavaScript Engine was added in JDK 8 in order to replace the Rhino scripting engine, a push to support more dynamic languages in the JVM. But in the recent development, the focus for multi-language support has moved to GraalVM, besides there has been little interest from developers to maintain Nashorn beyond JDK 14.

After reimplementation of Socket and ServerSocket API’s with JEP 353 in Java 13, the next replacement is the implementations of DatagramSocket and MulticastSocket APIs with JEP 373.

The legacy implementations of two APIs used for UDP network communication:

• java.net.DatagramSocket
• java.net.MulticastSocket

Will be will be marked as deprecated and eventually removed in a future version, and replaced with more modern implementations that will also be easier to maintain (and debug). The new implementation will be default and the old implementation will be available by using jdk.net.usePlainDatagramSocketImpl to true (or no value).

JEP 374 is another “clean up”, to disable Biased locking (an optimization technique used in the HotSpot Virtual Machine) by default and deprecate all command-line options related to it. It can be enabled by using -XX:+UseBiasedLocking.

Biased locking benefited older, legacy applications that use the early Java collection APIs like Hashtable and Vector, which synchronize on every access. It's also hint for developers, to change older APIs with non-synchronized collections like HashMap and ArrayList.

JEP 375 is the continuity of the work done in Java 14 (by JEP 305). This is the second preview. To refresh your mind about this enhancement in Java 14, please visit Java 14 - Pattern Matching for instanceof (JEP 305).

JEP 377 bring Z Garbage Collector that introduced in JDK 11 as a product feature. Many features and enhancements have been made to ZGC since its first appearance as part of the JDK, and this GC has long been an experimental feature. Although now ZGC is a production feature, the default GC is remains G1.

Text Blocks first came as preview feature in JDK 13 (through JEP 355). During the release of JDK14, this feature had a second preview (through JEP 368) with two additional escape sequences. With JEP 378, Text Blocks now is a standard feature.

Related article for Text Blocks: Java 13 - Text Blocks (JEP 355)

Similar like ZGC, JEP 379 bring Shenandoah GC (another experimental feature since Java 12) as a product feature.

Support for Solaris/SPARC, Solaris/x64, and Linux/SPARC ports is deprecated since Java 14, removed in this release is the goal of JEP 381.

Foreign-Memory Access API is available as an incubating module in Java 14. JEP 383 brings this incubating API feature back for a second round.

JEP 384 proposes to re-preview the Records feature which were launched as JEP 359 in Java 14. This second preview aims to incorporate refinements based on feedback and to support additional forms of local classes and interfaces in the Java language.

Related article for Records: Java 14 - Records Preview Feature (JEP 359)

Based on JEP 385, RMI Activation mechanism is deprecated and will be removed in the future release. This changes will not affect other parts of RMI.