Java 15 features – text blocks, hidden classes, a foreign-memory access API, preview of sealed classes and second preview of records.

Java 15 features – text blocks, hidden classes, a foreign-memory access API, preview of sealed classes and second preview of records.

  • Dropping support for the Solaris and SPARC ports, JEP 381 bringing Projects and features currently in development such as Valhalla, Loom, and Panama one step closer.
  • Sealed classes bring Valhalla one step closer.
ReleaseRelease DateHighlights
Latest Build2020-07-22Early-Access Builds: build 33

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 of this JEP is an implementation of this scheme as standardized in RFC 8032. This new signature scheme does not replace ECDSA.

EdSSA implements the cryptographic signature using EdDSA. Its main purpose to increase performance and security. This is supported by many other crypto libraries like OpenSSL and BoringSSL.

360: Sealed Classes (Preview)

Enhance the Java programming language with sealed classes and interfaces. Sealed classes and interfaces restrict which other classes or interfaces may extend or implement them.

Oracle Engineer and Java Language Architect Brian Goetz designs the sealed class. According to him, “A sealed class or interface can be extending or implemented only by those classes and interfaces permitted to do so. The class can be sealed by putting a sealed modifier to its declaration.”

A sealed class or interface restricts other classes or interfaces to extend it. Sealed classes are useful to create secure hierarchies by decoupling accessibility from extensibility, allowing library developers to expose interfaces while still controlling all the implementations. This class works with records and pattern matching to support a more data-centric form of programming.

371: Hidden Classes

Hidden classes are not 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. A hidden class may be defined as a member of an access control nest, and maybe unloaded independently of other classes.

Whereas 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. The invoking program should store the lookup object carefully, for it is the only way to obtain the object of the hidden class.

372: Remove the Nashorn JavaScript Engine

The Nashorn JavaScript engine was first incorporated into JDK 8 via JEP 174 as a replacement for the Rhino scripting engine. When it was released, it was a complete implementation of the ECMAScript-262 5.1 standard.

Two JDK modules will be permanently removed:

§jdk.scripting.nashorn -- contains the jdk.nashorn.api.scripting and jdk.nashorn.api.tree packages.

§ -- contains the jjs tool.

373: Reimplement the Legacy DatagramSocket API

Replace the underlying implementations of the and 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. This is a follow-on to JEP 353, which already reimplemented the legacy Socket API.

374: Disable and Deprecate Biased Locking

JEP 374’s main goal is to Disable biased locking by default and deprecate all related command-line options related to it. Biased Locking brought a lot of complex code with JDK, older JDK more the legacy code, requires more cost to maintain and standing in the way of progress due to the difficulties of making direct changes to the code. Here JEP 374 is not removing the biased locking but jut disable and deprecate it. This will improve Java application performance.

375: Pattern Matching for instanceof (Second Preview)

 Pattern matching allows common logic in a program, namely the conditional extraction of components from objects, to be expressed more concisely and safely. This is a preview language feature in JDK 14 and this JEP proposes to re-preview the feature in JDK 15, with no changes relative to the preview in JDK 14, in order to gather additional feedback.

377: ZGC: A Scalable Low-Latency Garbage Collector

Z Garbage Collector is being changed from an experimental feature into a product feature. This was introduced in JDK 11 has long been an experimental feature. It has many enhancements like support for the windows and Mac OS platforms.

378: Text Blocks

JEP 355 was targeted to JDK in June 2019 as a preview feature. In JDK 14 to it is a preview feature through JEP 368. Feedback on JDK 14 suggested that text blocks were ready to become a standard feature.

379: Shenandoah: A Low-Pause-Time Garbage Collector

Shenandoah was integrated into JDK 12 by JEP 189. It was marked as experimental in order to match the status of other new GCs, notably Epsilon GC and ZGC. Now Shenandoah is ready to drop its experimental status in mainline JDKs, as was recently suggested for ZGC in JEP 377.

381: Remove the Solaris and SPARC Ports

The Solaris and SPARC Ports were deprecated for removal in JDK 14. And now in JDK 15 it will be removed. 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 to the OpenJDK Community to accelerate the development of new features that will move the platform forward.

 383: Foreign-Memory Access API (Second Incubator)

Introduce an API to allow Java programs to safely and efficiently access foreign memory outside of the Java heap.

 384: Records (Second Preview)

Records are preview feature of JDK 14 by JEP 359, This JEP proposes to re-preview the feature in JDK 15, both to incorporate refinements based on feedback and to support additional forms of local classes and interfaces in the Java language.

Record Enhance Java programming, which are classes that act as transparent carriers for immutable data. Records can be thought of as nominal tuples.

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.

The RMI Activation mechanism allows RMI-based services to export stubs whose validity exceeds the lifetime of a remote object or a JVM that contains it. With conventional (non-Activatable) RMI, a stub becomes invalid as soon as a remote object is destroyed. Recovering from this situation requires clients to implement complex error-handling logic. When a client invokes a method on an activatable stub, the RMI Activation service instantiates the remote object on-demand, alleviating clients of the burden of dealing with invalid stubs. This seems like a valuable mechanism, however, as described in the Motivation section, the amount of actual usage of RMI Activation is vanishingly small.

Thank you.

Leave a comment now