techdoc

Java 15

created onJuly 16, 2022

general availability on 202-09-15

JEPs

new features

JEP state summary /remark
JEP 339: Edwards-Curve Digital Signature Algorithm (EdDSA) standard EdDSA has a better performance than the existing ECDSA implementation (which uses native C code) at the same security strength. This new signature scheme does not replace ECDSA.
JEP 360: Sealed Classes (Preview) preview allows the author of a class to specify which classes may extend the class. This allows for more fine grained control of inheritance hierarchies.
JEP 371: Hidden Classes standard hidden classes are classes that cannot be used directly by the bytecode of other classes. Hidden classes are intended for use by frameworks that generate classes at run time and use them indirectly, via reflection.
JEP 375: Pattern Matching for instanceof (Second Preview) second preview instanceof now saves you from explicit, verbose casts. see comments on ‘JEP 305: Pattern Matching for instanceof (Preview)'
JEP 377: ZGC, A Scalable Low-Latency Garbage Collector production the Z Garbage Collector changes from an experimental feature into a product feature. see comments on ‘JEP 333: ZGC: A Scalable Low-Latency Garbage Collector (Experimental)’
JEP 378: Text Blocks standard see comments on ‘JEP 355: Text Blocks (Preview)'
JEP 379: Shenandoah production a GC which reduces GC pause times by doing evacuation work concurrently with the running Java threads. Pause times are independent of heap size, the goal is to never interrupt the running program for more than a handful of milliseconds. see comments on ‘JEP 189: Shenandoah, A Low-Pause-Time Garbage Collector (Experimental)'
JEP 383: Foreign-Memory Access API (Second Incubator) incubator an API to allow Java programs to safely and efficiently access foreign memory outside of the Java heap. Applications include sharing memory across multiple processes, and serialization / deserialization of memory content by mapping files into memory (via, e.g., mmap).
JEP 384: Records (Second Preview) preview a new kind of restricted class for data containers without boiler code. see comments on ‘JEP 359: Records (Preview)'

JDK internal

JEP summary /remark
JEP 373: Reimplement the Legacy DatagramSocket API From JEP 373, Motivation: “The code base of the java.net.DatagramSocket and java.net.MulticastSocket APIs, and their underlying implementations, is old and brittle.”

deprecated

JEP summary /remark
JEP 374: Deprecate and Disable Biased Locking disable biased locking by default, and deprecate all related command-line options.
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.

removed

JEP summary /remark
JEP 372: Remove the Nashorn JavaScript Engine remove the Nashorn JavaScript script engine and APIs, and the jjs tool. The engine, the APIs, and the tool were deprecated for removal in Java 11.
JEP 381: Remove the Solaris and SPARC Ports remove 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.

some feature details

JEP 360: Sealed Classes (Preview)

The motivation behind sealed classes is to provide a more fine grained control of which classes may be permitted to extend a class. Traditional approaches to control class inheritance include:

  • declaring a class final
  • declaring a class package-private (friend)
  • declaring the contructor of a class package-private

This allows for either restricting the extension of a class to members of the same package or prohibiting any extension of the class in principle.

A sealed class can only be extended by classes or interfaces which the author of the class permitted to do so, i.e.:

package zone.codebase.geometry; public abstract sealed class Shape permits Circle, Square { ... }

The classes permitted to extend the superclass must be either located in the same package (for superclasses in unnamed modules) or in the same module.

package zone.codebase.geometry; public abstract sealed class Shape permits zone.codebase.polar.Circle, zone.codebase.rectangle.Square { ... }

If the classes permitted to extend the class are small, it may be convenient to declare them in the same class as their superclass. The compiler will then infer that those classes are permitted to extend the class and the keyword can be ommitted:

package zone.codebase.geometry; public abstract sealed class Shape { ... public class Circle { ... } public class Square { ... } }

Plans for future release include the ability to switch over the instance with type test patterns ( JEP 361: Switch Expressions and JEP 375: Pattern Matching for instanceof (Second Preview) ):

int getCenter(Shape shape) { return switch (shape) { case Circle c -> c.center() case Rectangle r -> r.center() case Square s -> s.center() }

the seal can be broken open by permitted classes

A sealed class imposes three constraints on its permitted subclasses. The subclass must:

  • belong to the same module as its superclass, and, if declared in an unnamed module, the same package.
  • directly extend the sealed class.
  • choose a modifier to describe how it continues the sealing initiated by its superclass:
    • may be declared final to prevent its part of the class hierarchy from being extended further.
    • may be declared sealed to allow its part of the hierarchy to be extended further than envisaged by its sealed superclass, but in a restricted fashion.
    • may be declared non-sealed so that its part of the hierarchy reverts to being open for extension by unknown subclasses. A sealed class cannot prevent its permitted subclasses from doing this.

Interfaces and Records

Sealed classes work well with interfaces and records and in the same fashion as classes.

JVM support for sealed classes

Sealed classes are recognized at runtime, which prevents unauthorized classes from extending sealed classes.

The class file of a sealed class has a PermittedSubclasses attribute which implicitly indicates the sealed modifier and explicitly specifies the permitted subclasses:

PermittedSubclasses_attribute { u2 attribute_name_index; u4 attribute_length; u2 number_of_classes; u2 classes[number_of_classes]; }

No matter whether the permitted subclasses are explicitly stated in the superclass or are inferred by the compiler, the permitted subclasses are explicitly included in the PermittedSubclasses attribute.

Reflection API

The following public methods will be added to java.lang.Class:

  • java.lang.constant.ClassDesc[] getPermittedSubclasses(), returns an array of java.lang.constant.ClassDesc objects representing all the permitted subclasses of the class if it is sealed, and returns an empty array if the class is not sealed.
  • boolean isSealed(), returns true if the given class or interface is sealed, false otherwise.

reference

OpenJDK JDK 15 Feature List and Schedule

JEP 360: Sealed Classes (Preview)

Java 15

© 2022 – 2024 Rudolf Held