The feature list is taken from the OpenJDK JDK 15 project page.
- JEP 339: Edwards-Curve Digital Signature Algorithm (EdDSA)
- JEP 360: Sealed Classes (Preview)
- JEP 371: Hidden Classes
- JEP 373: Reimplement the Legacy DatagramSocket API
- JEP 374: Disable and Deprecate Biased Locking
- JEP 375: Pattern Matching for instanceof (Second Preview)
- JEP 377: ZGC: A Scalable Low-Latency Garbage Collector
- JEP 378: Text Blocks
- JEP 379: Shenandoah: A Low-Pause-Time Garbage Collector
- JEP 381: Remove the Solaris and SPARC Ports
- JEP 383: Foreign-Memory Access API (Second Incubator)
- JEP 384: Records (Second Preview)
- JEP 385: Deprecate RMI Activation for Removal
JEP 339: Edwards-Curve Digital Signature Algorithm (EdDSA)
EdDSA is a modern elliptic curve signature scheme that has several advantages over the existing signature schemes in the JDK.The primary goal is to cover the implementation of EdDSA algorithm. This is not a replacement of ECDSA. It will be implemented as a platform-independent code and it will have a similar performance with the same security strength ECDSA algorithm which is implemented natively.
JEP 360: Sealed Classes (Preview)
Sealed types are classes or interfaces that impose restrictions on which other classes or interfaces may extend or implement them.This JEP provides a way to restrict the implementation or inheritance of a class or interface, thereby creating a sealed class or interface. In this way we can provide more explicit restrictions than using final or package-private mechanisms.A new keyword “permit” is introduced for this purpose which allows us to implement this.
JEP 371: Hidden Classes
This introduces “hidden classes”.As we know hidden classes are classes which can not be used directly by the bytecode of other classes. Hidden classes which are invisible to JVM but can be loaded from their bytecode dynamically and then they can be used by their reference (through reflection.). A hidden class can be defined as a member of the access control nest and can be unloaded independently of other classes.
JEP 373: Reimplement the Legacy DatagramSocket API
After the reimplementation of Socket and ServerSocket API with JEP 353 in Java 13, this JEP will replace the implementations of DatagramSocket and MulticastSocket APIs. However, they will not replace the existing implementations (in DatagramSocketImpl and platform specific concrete implementations).Replace the underlying implementations of the java.net.DatagramSocket and java.net.MulticastSocket APIs with simpler and more modern implementations that are easy to maintain and debug. The new implementation is going to be easy to adapt to work with virtual threads, currently being used in Project Loom. This is a follow-on to JEP 353, which already reused the legacy Socket API. The new implementation is going to be the default and the old implementation can be used by using jdk.net.usePlainDatagramSocketImpl property.
JEP 374: Disable and Deprecate Biased Locking
The benefits of Biased Locking is brought less impact with modern computers.Because of that it will be disabled by default and deprecated. It can be enabled by using -XX:+UseBiasedLocking.
JEP 375: Pattern Matching for instanceof (Second Preview)
As we know pattern matching for instance was first a preview feature (JEP 305) in Java 14. This is the second preview. It does both a test (instanceof?), casting (of the object to mentioned class) and a local variable declaration as given below:
$ jshell –enable-preview
| Welcome to JShell — Version 15-ea
| For an introduction type: /help intro
jshell> var s = “openjdk”
s ==> “openjdk”
jshell> if (s instanceof String s) System.out.println(“it is a string”)
if (s instanceof String s) System.out.println(“it is a string”)it is a string
JEP 377: ZGC: A Scalable Low-Latency Garbage Collector
ZGC is a trial feature since Java 11, now it becomes a product feature.This JEP does not prefer to change the default GC, which remains G1.
JEP 378: Text Blocks
The experiments with multi-line strings started with JEP 326 in Java 12 and continued on Java 13, then with JEP 368 in Java 14 and continued. The final result is a permanent feature.
A text block is opened with “”” and closed with “””. So you can use “ without escape. Text blocks can also contain line terminators, so it becomes a multi-line string.
Here is an example from JEP 378 page.
Using “one-dimensional” string literals
String html = “\n” +
” \n” +
” \n” +
Using a “two-dimensional” block of text
String html = “””
JEP 379: Shenandoah: A Low-Pause-Time Garbage Collector
Shenandoah GC is an experimental feature since Java 12, now it enhanced as a product feature.This JEP does not prefer to change the default GC, which remains G1.And this JEP does not mention to change the Shenandoah development process, which will continue to support both the latest JDK and popular LTS/STS JDKs.
JEP 381: Remove the Solaris and SPARC Ports
Support for Solaris on SPARC and x64 and Linux on SPARC is removed. Many projects and features currently in development such as Valhalla, Loom, and Panama require remarkable changes to CPU-architecture and operating-system specific code. Dropping support for the Solaris and SPARC ports will allow contributors in the OpenJDK Community to accelerate the development and performance of new features that will move the platform forward.
JEP 383: Foreign-Memory Access API (Second Incubator)
This API was previously delivered as an incubating module in Java 14. This JEP comes with some changes to this API and it will be still delivered as an incubator module.
JEP 384: Records (Second Preview)
This is the second preview of Records which were launched as JEP 359 in Java 14 as a preliminary view feature.
Devise an object-oriented construct that expresses a simple aggregation of values.
Help programmers to focus on modeling immutable data rather than extensible behavior.
Automatically implement data-driven methods such as equals and accessors.
Preserve long-standing Java principles such as nominal typing and migration similarity.
JEP 385: Deprecate RMI Activation for Removal
Deprecate the RMI Activation mechanism for future removal. RMI Activation is an obsolete part of RMI that has been optional since Java 8. No other part of RMI will be deprecated.