The following overview explains what has changed in JDK15 compared to its predecessor JDK14 and what new features you can look forward to:
Foreign Memory Access API
An additional incubator of a so-called foreign-memory access API should ensure that Java applications can access foreign memory, i.e. memory outside the Java heap, safely and efficiently. The API should be compatible with all common storage formats (native, persistent, managed heap). The goal of the whole is to improve the previously very costly and unpredictable operations - especially in connection with the garbage collector, shared memory and serializability. The security of the Java Virtual Machine is not compromised.
Sealed classes
In JDK15 you will find a preview of the sealed classes. Together with interfaces, sealed classes should offer the possibility to restrict which classes the sealed class may implement or extend, besides the common access modifiers (public, private, package private, etc.). One of the goals here is to give the author of a class or interface control over which code is responsible for the implementation. Your can read the detail here.
Solaris and SPARC Ports
Already in Java14 the Solaris and SPARC ports were marked as obsolete - with the goal to remove them completely in the future. With the release of JDK15, the next logical step in the process will be implemented: the Solaris and SPARC specific source code will be removed and documentation and code comments will be revised.
Motivation for the implementation of such a change will seemingly come from the "bigger" projects of the Java ecosystem. Especially the projects Valhalla, Loom and Panama bring changes to OS specific and CPU architecture code. The removal of Solaris and SPARC will make sure that the development of these projects can be pushed faster.
Records
So-called records should serve as transparent carriers of immutable data. Additionally, an object-oriented solution for the aggregation of data shall be designed. These should support the programmer in his work and direct his focus on modeling, not managing, the data.
Edwards-Curve Digital Siganture Algorithm(EdDSA)
Digital signatures are to be implemented using the Edwards-Curve Digital Siganture Algorithm (EdDSA). EdDSA is to be seen as an extension of the system and will not replace any existing feature.
Hidden classes
Hidden classes are classes that offer the possibility that their byte code cannot be used directly by other classes. Their purpose will therefore be primarily the use in frameworks, which generate classes at runtime and use them indirectly (by reflection).
Rhino JavaScript Engine
Two modules, which were already marked as obsolete with the release of Java 11, are to be removed. These are the following modules:
- jdk.scripting.rhino
- jdk.scripting.rhino.shell
DatagramSocket API
The goal of this innovation is to improve the API of the two modules java.net.DatagramSocket and java.netMulticastSocket with regard to maintenance and debugging. The current implementation can be traced back to Java version 1.0 and consists of a mixture of Java and C code. Due to the new features, the "legacy" version will still be preserved.
Deactivation of Biased Locking
For features that bring particularly complex code into the JDK, such as biased locking, the costly maintenance and development of these features can quickly get in the way of other innovations in development.
With the release of JDK 15, biased locking will be deactivated and marked as obsolete.
Pattern Matching for "instanceof
Pattern Matching for instanceof returns for a second preview round. It was planned to collect user feedback in the second preview round and to extend the feature with the functionality of deconstruction patterns. This plan was discarded and the feature will be available in its current state for the time being. The extensions will be added continuously. Text Blocks
The text blocks introduced with the release of Java JDK13 seem to be ready to be included as a feature in the JDK after the two previous preview rounds.
Garbage Collectors
ZGC: A Scalable Low-Latency Garbage Collector (Production)
The Z Garbage Collector was introduced as an experimental feature with the release of JDK11. The reason for this is the idea that a feature of this size and complexity should be introduced into the system with caution and iteratively. Many changes and improvements have ensured that ZGC is integrated into the system with JDK15 as a full production feature.
Shenandoah: A Low-Pause-Time Garbage Collector (Production)
Similar to the ZGC, the Shenandoah GC was introduced with the JDK12 as an experimental feature. Again, improvements have ensured that the Garbage Collector is included as a production feature.