Hidden Classes, Sealed Classes, Text Blocks , Records, and EdDSA: JDK 15 has a lot of value.
As one of my favorite expressions says, there is a lot of rich chocolate goodness in Java 15 . The new version (released September 15, 2020) includes 14 important changes (JEPs) aimed at improving the JDK. This article provides a quick overview of new products based on the information contained in the JEP.
The 14 JEP can be divided into five groups. For a more detailed study, see the documentation for each of them.
New functionality that will take your breath away:
- JEP 339: Edwards Curve Digital Signature Algorithm (EdDSA)
- JEP 371: Hidden Classes
Additions to existing Java SE standard functionality:
- JEP 378: Text Blocks
- JEP 377: ZGC Garbage Collector
- JEP 379: Shenandoah - Low Pause Garbage Collector
Improvements to legacy Java SE functionality:
- JEP 373: Redesign of the deprecated DatagramSocket API
We are looking forward to new products:
- JEP 360: Sealed Classes (Preview)
- JEP 375: Pattern Matching for instanceof (Second Preview)
- JEP 384: Entries (Second Draft)
- JEP 383: External Memory Access API (Second Incubator Function)
Removal and termination of support:
- JEP 372: Nashorn JavaScript Engine
- JEP 374:
- JEP 381: Solaris SPARC
- JEP 385: RMI
,
Edwards Curve Digital Signature Algorithm ( JEP 339 ). I'll be the first to admit that the Edwards-Curve Digital Signature Algorithm (EdDSA) is a little beyond my knowledge of encryption. Okay, I don't know anything about it at all. However, this JEP is designed as a platform independent implementation of EdDSA with better performance than the existing C implementation, ECDSA.
According to the JDK documentation, EdDSA is a modern elliptic curve signature scheme that has several advantages over the existing ones in the JDK.
Implementation goals:
- The main purpose of this JEP is to implement the signature scheme as standardized in RFC 8032 . However, the new scheme does not replace ECDSA.
- - EdDSA , ECDSA . , EdDSA, Curve25519 ~126 , , ECDSA, secp256r1 ~128 .
- , . .
Now you know more than I do. Stay tuned for a Java Magazine article explaining EdDSA soon.
Hidden Classes ( JEP 371 ) are classes that cannot be invoked directly by the bytecode of other classes. They are intended to be used by frameworks that dynamically create classes at runtime and use them indirectly through a reflection mechanism. Dynamically generated classes may only be required for a limited amount of time, so keeping them for the lifetime of a statically generated class can unnecessarily increase memory footprint.
Dynamically generated classes are also undetectable. Finding such classes by name would be detrimental, as it undermines their purpose, which is that they are just an implementation detail of a statically generated class.
The release of the hidden classes lays the foundation for developers to stop using the non-standard API sun.misc.Unsafe :: defineAnonymousClass . Oracle intends to remove and remove this class in the future.
Additions to existing Java SE standards
The text blocks ( JEP 378 ) that came from Project Amber were finally released after two preliminary versions in JDK 13 and 14. The purpose of their creation was the desire of developers to reduce the difficulty of declaring and using multi-line string literals in Java.
Text blocks automatically format strings in a predictable way, but if that's not enough, the developer can take over the formatting. The second version of the preliminary functionality introduces two new escape sequences for handling newlines and spaces. For example, \ <line-terminator> explicitly suppresses the insertion of a newline character.
Previously, to print one long line of text, you would have to write like this:
Using \ makes the code easier to read:
The \ s escape sequence can prevent trailing spaces from being removed. Thus, the following text represents three lines, each of which consists of exactly five characters (in the middle line, corresponding to green, \ s is not used, because it already contains five characters).
The ZGC garbage collector ( JEP 377 ) was introduced in JDK 11 as an experimental feature. Now it has received official status. ZGC is a parallel, NUMA-enabled, scalable garbage collector with low garbage collection latency (less than 10 milliseconds even on multi-terabyte heaps). The average pause time, as tested by Oracle, is less than 1 millisecond, and the maximum is less than 2 milliseconds. Figure 1 compares the Java parallel garbage collector, G1, and ZGC, with the ZGC pause time increased by a factor of 10.
Figure 1. Comparison of garbage collector pause times
However, for many workloads, G1 (which is still the default) may be slightly faster than ZGC. Also, for very small heaps, such as those that are only a few hundred megabytes, the G1 can also be faster. Thus, you are advised to run your own tests with your loads to see which garbage collector to use.
Important: Since the ZGC is no longer experimental (included in the Oracle OpenJDK build and in the Oracle JDK), you no longer need to use -XX: + UnlockExperimentalVMOptions to activate it.
Shenandoah ( JEP 379) Is another variant of the garbage collector available in some OpenJDK builds. It has been experimental since JDK 12. Now, as with ZGC, XX: + UnlockExperimentalVMOptions is not required.
Modernization of legacy Java SE functionality
Reworking the deprecated DatagramSocket API ( JEP 373 ). Consider this basically a refactoring of some Jurassic code, as this JEP replaces the old, hard-to-maintain implementations of the java.net.DatagramSocket and java.net.MulticastSocket APIs with simpler, modern implementations that are easy to maintain and debug, and which will work with Project Loom virtual streams.
Since there is a lot of code that uses the old API (since JDK 1.0), the obsolete implementation will not be removed. In fact, a new JDK-specific system property, jdk.net.usePlainDatagramSocketImpl, configures the JDK to use a deprecated implementation if API refactoring causes problems in regression tests or in some cases.
We are looking forward to new products
Sealed Classes ( JEP 360 ). The first pre-production version created in Project Amber. Sealed classes and interfaces restrict their extension or implementation to other classes. Why is it important? A developer may want to manage code that is responsible for implementing a particular class or interface. Sealed classes provide a more declarative way than access modifiers to restrict the use of the superclass. For instance:
The purpose of sealing a class is to let the client code know which subclasses are allowed. After all, there may be use cases where the original definition of a class (or interface) is expected to be completely exhaustive, and where the developer does not allow it to be extended out of control - only explicitly specified classes can.
There are some restrictions for sealed classes:
- The sealed class and its permitted subclasses must be in the same module. If they are declared in an unnamed module, then they must be placed in the same package
- Every allowed subclass must directly extend the sealed class
- , , , — final, sealed nonsealed ( )
Pattern matching for instanceof ( JEP 375 ). The second preview is another development from Project Amber. The first preliminary version of the functionality was in Java 14 and there are no changes compared to that.
The goal is to improve Java through pattern matching for the instanceof operator. This allows you to more concisely and safely express the general logic in the program, namely the conditional extraction of components from objects. Let me refer you to Mal Gupta's excellent article " Pattern Matching for instanceof in Java 14 " as an example.
Entries ( JEP 384), second draft. Records are classes that act as transparent carriers of immutable data. The new JEP includes clarifications based on community feedback and supports several new additional forms of local classes and interfaces. Entries also come from Project Amber.
Records are an object-oriented construct that expresses a simple aggregation of values. Thus, they help programmers focus on modeling immutable data rather than extensible behavior. Records automatically implement data-driven methods such as equals and accessors. The entries also preserve long-standing Java principles such as nominal typing and migration compatibility. In other words, they make it easier to code and read classes that contain immutable data.
External Memory Access ( JEP 383 ) is the second incubator version of the API that allows Java programs to safely and efficiently access external memory outside the Java heap. The goal is to start replacing java.nio.ByteBuffer and sun.misc.Unsafe. It is part of the Panama project that improves communication between Java and other APIs.
The JEP aptly describes the need for this innovation as follows:
When it comes to accessing external memory, developers are faced with a dilemma - should they choose a safe, but limited (and possibly less efficient) path, such as the ByteBuffer API, or should they give up security guarantees and adopt a dangerous and unsupported Unsafe API?
This JEP introduces a secure, maintainable, and efficient API for accessing external memory. By providing a targeted solution to the problem of external memory access, developers will be freed from the limitations and dangers of existing APIs. They will also get better performance as the new API is designed from scratch with JIT optimizations in mind.
Removal and end of support
None of these decisions should be controversial.
Removal of the Nashorn JavaScript engine ( JEP 372 ). This engine, its API and jjs tool were deprecated in Java 11. It's time to say goodbye.
Disabling and Eliminating Reserved Locking ( JEP 374 ) removes the old optimization technique used in the HotSpot JVM to reduce the overhead associated with unchecked locking. This locking has historically resulted in significant performance improvements over conventional locking methods, but the performance gains seen in the past are much less obvious today. The cost of executing atomic instructions on modern processors has dropped.
Redundant locking has resulted in a lot of complex code, and this complexity prevents the Java development team from making significant changes to the synchronization engine. By disabling the lock, and leaving it up to the programmer to re-enable it, the Java team hopes to determine whether it would be wise to remove it entirely in a future release.
Removing Solaris and SPARC ports ( JEP 381 ). In this case, all source code specific to the Solaris operating system and SPARC architecture is removed. There is nothing more to say.
Exclude RMI activation for later uninstallation ( JEP 385). Simplifies Java by removing the obsolete part of calling remote methods that was optional in Java 8.
The use of RMI activation is reduced and reduced. The Java team sees no evidence that any new applications have been written using it, and there is evidence that very few existing applications use RMI activation. Searching various open source codebases found almost no mention of any APIs associated with it. There have been no reports of externally generated RMI activation errors for several years.
Supporting RMI activation as part of the Java platform has an ongoing maintenance cost. This adds complexity to RMI. You can remove RMI activation without affecting the rest of RMI. Removing it does not reduce Java's developer value, but it does reduce the JDK's long-term maintenance costs.
Conclusion
Java 15 continues its six-month release cycle and is a medium-sized release useful to most developers.