New Features in Java 15
With the General Availability of Java 15 tomorrow (i. e) Sep 15th, 2020, Let’s start with the Java 15 release schedule and then explore each of the features at a high level.
Release Schedule:
2020/06/11 - Rampdown Phase One (fork from main line)
2020/07/16 -Rampdown Phase Two
2020/08/06 -Initial Release Candidate
2020/08/20 -Final Release Candidate
2020/09/15 -General Availability
New Features in Java 15:
1)Sealed Classes (Preview) -JEP360
2) Hidden Classes -JEP371
3) Records (Second Preview) -JEP384
4) Pattern Matching for instanceof (Second Preview) — JEP375
5) Foreign-Memory Access API (Second Incubator) -JEP383
6) ZGC: A Scalable Low-Latency Garbage Collector -JEP377
7) Text Blocks -JEP378
8) Shenandoah: A Low-Pause-Time Garbage Collector -JEP379
9) Edwards-Curve Digital Signature Algorithm (EdDSA) -JEP339
10) Remove the Nashorn JavaScript Engine -JEP372
11) Reimplement the Legacy DatagramSocket API -JEP373
12) Disable and Deprecate Biased Locking -JEP374
13) Deprecate RMI Activation for Removal -JEP385
14) Remove the Solaris and SPARC Ports -JEP381
Note: To use the preview features available in the jdk use –enable-preview option to enable
- Sealed Classes (Preview):
With jdk15 we have a new feature sealed classes, In java, inheritance is one of the oops concepts which give us flexibility like re-usability and allows our application classes to be designed according to the domain of the app. As there is a saying “with great power comes great responsibility”.so the developers should be careful about the way they model their classes and maintain their hierarchy, As often developers tend to forget when they are writing the class which and all subclass do this class can be inherited, if it was not taken care correctly the data can be exposed to any of its subclass or sub-sub classes indirectly. Today java provides limited set of tools in this area either make a class final, so it has zero subclasses, or make a class or its constructor package-private, so it can only have subclasses in the same package. A developer can’t restrict what are the subclasses can this parent class be extended.For example consider there is class Shape and there are some other classes like Square, Rectangle, DrawShape, DesignShape. if the developer wants to allow the shape classes to be only extended by Square and Rectangle but not with any other classes as its irrelevant to extend this class, today it’s not possible easily.
To address the problems stated above Sealed classes come into play, A sealed class or interface can be extended or implemented only by those classes or interfaces which are specified under permitted classes/interfaces.Though the name suggests as sealed classes it can also be applied to interfaces. In a sealed class the developer of the class(owner of the class)has the full control who are its subclasses, the class owner can specify this under the permitted list classes that can extend by this class.
For Example:
Java Grammer:
Sealed classes do come with the restriction :
->The sealed class and its permitted subclasses must belong to the same module, and, if declared in an unnamed module, the same package.
->Every permitted subclass must directly extend the sealed class.
->Every permitted subclass must choose a modifier to describe how it continues the sealing initiated by its superclass
To support sealed class the java.lang.Class has been enhanced with below 2 methods
-> java.lang.constant.ClassDesc[] getPermittedSubclasses()- Returns an array containing ClassDesc Objects
->boolean isSealed() — returns true if the given class or interface is sealed
2) Hidden Classes:
Hidden classes are intended for use by frameworks that generate classes at run time and use them indirectly, via reflection. These classes cannot be used directly by the bytecode of other classes. A hidden class may be defined as a member of an access control nest and maybe unloaded independently of other classes. The main motive of hidden classes is to provide a way to generate classes at runtime for example a lambda expression doesn’t translate into a dedicated class file at compile time but, rather, emits bytecode that dynamically generates and instantiates a class to yield an object corresponding to the lambda expression when needed. These classes have their own life-cycle and with hidden classes, it is now possible to Deprecate the non-standard API sun.misc.Unsafe::defineAnonymousClass, with the intent to deprecate it for removal in a future release.
In java7 Lookup API introduced that allows a class to obtain a lookup object that provides reflective access to classes, methods, and fields. In Java 9 Lookup API was enhanced the transmission capabilities of lookup objects by introducing the method Lookup::defineClass(byte[]). With Java 15 the Lookup API was further enhanced to support Hidden classes. A normal class is created by invoking ClassLoader::defineClass, a hidden class is created by invoking Lookup::defineHiddenClass. This causes the JVM to derive a hidden class from the supplied bytes, link the hidden class, and return a lookup object that provides reflective access to the hidden class. A hidden class is not discoverable by the JVM during bytecode linkage, nor by programs making explicit use of class loaders. Methods of hidden classes are not shown in stack traces by default. -XX:+UnlockDiagnosticVMOptions -XX:+ShowHiddenFrames.
3) Records (Second Preview):
Records are a new kind of type declaration in the Java language. Like an enum, a record is a restricted form of class. Records avoid the generation of boilerplate code for repetitive tasks (such as constructor,toString, hashcode, getter methods) of class attributes. Records were introduced with jdk14 as initial preview feature with jdk 15 we have now a second preview which brings us with some enhancements/changes to the compiler, JLS, and JVM.
For a more detailed explanation of Records refer to jdk 14
4) Pattern Matching for instanceof (Second Preview):
With Pattern Matching for instanceof we can avoid so boilerplate code where we used to check the instance of an object and create an instance for the same and use it for further operation with pattern matching this operation are done without writing much of the code. This feature was firstly introduced with jdk14 as an initial preview, with jdk 15 there are a couple of changes & fixes done to this feature.
For a more detailed explanation of Pattern Matching for instanceof refer to jdk 14
5) Foreign-Memory Access API (Second Incubator):
Foreign-memory access API would allow Java programs to safely and efficiently access foreign memory outside of the Java heap. Today there are a lot of third-party libraries like Ignite, mapDB, Memcached, and Netty’s ByteBuf API that are using foreign-memory to Avoid the cost and unpredictability associated with garbage collection especially when maintaining large caches and also allows Sharing memory across multiple processes. This was introduced with jdk14 as an initial preview feature, with jdk15 we see now some enhancements to this feature.
For a more detailed explanation of Foreign-Memory Access API refer to jdk 14
6) ZGC: A Scalable Low-Latency Garbage Collector:
With JDK 15 now ZGC Garbage Collector is been moved from an experimental feature to a product feature. ZGC was firstly introduced in JDK11 as an experimental feature and till now developer needs use -XX:+UnlockExperimentalVMOptions to access this feature now it’s not required to provide the jvm option.
7) Text Blocks:
A text block is a multi-line string literal that avoids the need for most escape sequences, automatically formats the string in a predictable way, and gives the developer control over format when desired. The main motive behind the text block was today when a developer wanted to have string literal value containing a snippet of HTML/XML/JSON etc.. today it requires significant editing with escapes and concatenation to get the desired format and compile the program but with text blocks in place, this becomes quite easy. This was first introduced as a preview feature in jdk13 and jdk 14 as a second preview, with jdk15 it’s now available as a product feature.
For a more detailed explanation of Text Blocks refer to jdk 13
8) Shenandoah: A Low-Pause-Time Garbage Collector:
Shenandoah GC was developed by Red hat and is available as open-source and firstly introduced in JDK12 as experimental. Shenandoah GC comes with executing concurrently each task thereby decreasing the pause time with this now the GC pause time doesn’t depend on the size of the heap whether its 2GB or 10 GB it’s the same. With JDK15 it’s now available as a product feature.
For a more detailed explanation of Shenandoah GC refer to jdk 12
9) 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.EdDSA will only be implemented in the SunEC provider.EdDSA is in demand due to its improved security and performance compared to other signature schemes and is already supported in many other crypto libraries such as OpenSSL and BoringSSL. This signature scheme is an optional component of TLS 1.3 but is one of only three signature schemes that are allowed in TLS 1.3. Some users may have EdDSA certificates and may have a strong preference to use EdDSA. These users will appreciate the ability to use EdDSA without having to use a third-party library.
10) Remove the Nashorn JavaScript Engine:
The Nashorn JavaScript engine was first incorporated into JDK 8 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 it became quite difficult for maintenance.so it was firstly deprecated for removal in Java 11 and now with jdk15 Nashorn JavaScript script engine and APIs, and the jjs tool has been completely removed.
11) Reimplement the Legacy DatagramSocket API:
The implementation of Datagram socket api’s in java.net.DatagramSocket and java.net.MulticastSocket package was introduced in JDK1.0 where the code was written in java and C.As its been written according to that period where IPV6 was in still development. with jdk 15 the reimplementation of the underlying java.net.DatagramSocket and java.net.MulticastSocket APIs with simpler and more modern implementations that are easy to maintain and debug. The new implementations will be easy to adapt to work with virtual threads, currently being explored in Project Loom.
12) Disable and Deprecate Biased Locking:
Biased locking is an optimization technique used in the HotSpot Virtual Machine to reduce the overhead of uncontended locking. It aims to avoid executing a compare-and-swap atomic operation when acquiring a monitor by assuming that a monitor remains owned by a given thread until a different thread tries to acquire it. Biased locking introduced a lot of complex code into the synchronization subsystem and is invasive to other HotSpot components as well. This complexity is a barrier to understanding various parts of the code and an impediment to making significant design changes within the synchronization subsystem. To that end, this is been disable and deprecated with jdk15 and will be removed completely in future releases.
13) Deprecate RMI Activation for Removal:
Distributed systems have been based on web technology for at least the past decade. Concerns about traversing firewalls, filtering requests, authentication, and security have all been addressed in the web services space. Lazy instantiation of resources is handled by load balancers, orchestration, and containers. None of these mechanisms is present in the RMI Activation model for distributed systems. There is vanishingly small usage of RMI Activation. There is no evidence of any new applications being written to use RMI Activation, and there is evidence that very few existing applications use RMI Activation. With jdk 15 Deprecated 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.
14) Remove the Solaris and SPARC Ports:
Removed the source code and build support for the Solaris/SPARC, Solaris/x64, and Linux/SPARC ports. These ports were deprecated for removal in JDK 14 with the express intent to remove them in a future release. Many projects and features currently in development such as Valhalla, Loom, and Panama require significant changes to CPU-architecture and operating-system-specific code. Dropping support for the Solaris and SPARC ports will enable contributors in the OpenJDK Community to accelerate the development of new features that will move the platform forward.
