The new features and changes in Java 15

The most common application platform and coding language in the world, Java 15 (Java SE 15) has been released on 15 September 2020. Few significant feature highlights of JDK 15 include a foreign-memory access API, text blocks, previews of sealed classes, records, the Z Garbage Collector, pattern matching, and hidden classes. The version Java 15 is just a short-term release and will be supported by Oracle Premier Support for until the arrival of JDK 16. The next Long-Term Support release, JDK 17, is to be supported by Oracle for eight years. Software developers and coders can now refer JDK 15 to get an idea of what will be in JDK 17. Java 15 also includes Java Development Kit 15 (JDK 15) open-source.

The changes and new features in OpenJDK 15 include the following:

• To let Java programs efficiently and safely access foreign memory outside of the Java heap, the second incubator of a foreign-memory access API is included. This API is capable of operating on different kinds of foreign memory, such as managed heap, native, and persistent. Many Java programs can access foreign memory, such as Map DB as well as Ignite. The foreign-memory access API would help to share memory across processes, avoid the unpredictability and cost associated with garbage collection, and deserialize or serialize memory content by mapping files onto memory. However, the API of Java 15 is not able to provide a satisfactory solution for accessing foreign memory currently. But with this latest proposal, the foreign-memory access API can't undermine the safety of the JVM. Even though this feature is going through an earlier incubator phase in the case of JDK 14, refinements are provided in JDK 15.

• Build support for Linux/SPARC, Solaris/x64, and Solaris/SPARC ports. In the new version of Java 15, there is a removal of source code which was deprecated for removal in JDK 14. Many features and projects in development such as Panama, Valhalla, and Loom require significant changes to operating system-specific code as well as CPU-architecture. Contributors to the OpenJDK community will be able to accelerate the development of new features by dropping support for SPARC and Solaris ports. Apart from that this will help to move the platform forward. In recent years, the Intel and Linux OS processors have been superseding both SPARC and Solaris.

• Cryptographic signatures are added based on the EdDSA or Edwards-Curve Digital Signature Algorithm. Being a modern elliptic curve scheme, EdDSA has several advantages over the existing signature schemes of JDK. Only the SunEC provider will be implementing the EdDSA. Due to its improved performance and security, EdDSA is in great demand compared to all other signature schemes. Furthermore, crypto libraries such as BoringSSL and OpenSSL already support EdDSA.

• A preview of sealed classes: These sealed classes along with interfaces, restrict which other interfaces or classes may implement or extend them. The goals of this feature include providing a more declarative way compared to access modifiers to ensure the restriction of the use of a superclass. Apart from this, a preview of sealed classes allows the author or coder of an interface to control the code that is responsible for implementing it. Another goal of this feature is to underpin the exhaustive analysis of patterns to support future directions in pattern matching.

• Disabling of biased locking by default: Java 15 deprecates all command-line options related to biased locking. The main aim of a preview of sealed classes is to analyze the need for providing a continued support of the legacy synchronization optimization of biased locking. This legacy synchronization optimization very costly-to-maintain. Biased locking finds its applications in HotSpot virtual machine in reducing the overhead of uncontended locking. The performance benefits of biased locking features are generally less evident nowadays. However, some Java applications experience a regression in performance with the disabling of biased locking.

• Records: These are included in a second preview version in JDK 15. Records act as transparent carriers for immutable data. The goals of adding records or classes in Java 15 include helping developers to focus on modeling immutable data rather than extensible behavior and devising an object-oriented construct to express a simple aggregation of values. Moreover, this feature aims at preserving longstanding Java principles such as migration compatibility and nominal typing. Also, records help to automatically implement data-driven methods such as equals and assessors. Records are often considered as nominal tuples.

• Following a preview in JDK 14, the second preview of pattern matching for 'instance of' is introduced in Java 15. Pattern matching facilitates the conditional extraction of components from objects and common logic in a program. The components can be expressed more concisely and easily using this feature. To enable safety and brevity, languages such as C# and Haskell have embraced pattern matching.

• Reimplementation of the legacy DatagramSocket API: Simpler and more modern implementations now replace the underlying implementations of the java.net.MulticastSocket and java.net.datagram.Socket APIs. The new implementations are easy to maintain and debug. Besides, they work with virtual threads that are currently being explored in Project Loom. The current implementations such as java.net.MulticastSocket and java.net.datagram Socket date back to JDK 1.0. Using this feature, the programmers are now able to follow-up to JDK Enhancement Proposal 353 that has reimplemented the legacy Socket AP. Apart from this, the current implementation of MulticastSocket works towards reconciling of IPv6 and IPv4 in ways that are difficult to maintain.

• Hidden classes: These classes are utilized by frameworks that generate classes during the runtime. Besides, frameworks also use them indirectly through reflection. The bytecode of other classes cannot use these classes directly. A hidden class can be unloaded independently of other classes and can be defined as a member of an access control nest. The proposal enables a standard API to define hidden classes that have a limited lifecycle and are not discoverable. Also, it would improve the efficiency of all languages on the JVM. Frameworks that are outside and inside the JDK are capable of dynamically generating classes that could instead define hidden classes. Apart from this, numerous languages that are built on the JVM rely on dynamic class generation for efficiency as well as flexibility. The goals of this proposal include: supporting the extending of access control nest with non-discoverable classes; ensuring frameworks have the flexibility to define as many classes as needed by offering support for aggressive unloading of non-discoverable classes; deprecate the non-standard API, misc. Unsafe::defineAnonymousClass; Another goal is to allow frameworks to define classes as non-discoverable implementation details of the framework. This will make sure that these classes are not discovered through reflection nor linked against by other classes. However, the Java language is not changed as a result of this proposal.

• The ZGC or Z Garbage Collector graduates from an experimental feature to a product: ZGC becomes a scalable and low-latency garbage collector when integrated into JDK 11. Since Java's developers decided that a feature of this complexity or size should be brought in gradually and carefully, ZGC was introduced as an experimental capability. Several improvements have been added since then. These improvements include uncommitting of unused memory, multi-threaded heap pre-touching, support for class-data sharing to improved NUMA awareness, and concurrent class unloading. Besides, there is an increase in the maximum heap size from four terabytes to 16 terabytes now. In applications that involve massive amounts of data like machine learning, ZGC addresses performance concerns. Hence the users can ensure that the processing of data will not be subject to long pauses or unpredictability because of garbage collection. Platforms supported include macOS, Windows, and Linux.

• Text blocks: These are previewed in both JDK 13 and JDK 14. Moreover, these text blocks are intended to simplify the task of writing Java programs. Text blocks have made it very easy to express these strings that usually span several lines of source code. Furthermore, they avoiding escape sequences in common cases. The multi-line string literal of a text block successfully avoids the need for most escape sequences. Apart from that, it offers the developer control over the format when desired and automatically predictably formats the string. One of the major goals of the text blocks proposal is to enhance the readability of strings in Java programs. These strings denote code written in non-Java languages. Another aim is to support migration from string literals. This is achieved by stipulating that any new construction can interpret the same escape sequences, express the same set of strings as a string literal, and be manipulated in the same fashion as a string literal. To manage newline control and explicit white space, OpenJDK developers might be adding escape sequences.

• Removal of Nashorn: This was debuted in JDK 8 in March 2014. The OpenJDK 15 proposal calls for removing the jjs command-line tool used to invoke Nashorn as well as the Nashorn APIs.

• RMI Activation mechanism Deprecation: The RMI Activation mechanism is considered as an obsolete part of RMI. Further, RMI Activation imposes an ongoing maintenance burden and No other part of RMI will be deprecated.