After six months of development, Oracle has announced the platform (Java Platform, Standard Edition 15), whose reference implementation is based on the open-source project OpenJDK. Java SE 15 maintains backward compatibility with previous releases of the Java platform, allowing all previously written Java projects to run without changes on the new version. Installation-ready builds of Java SE 15 (JDK, JRE, and Server JRE) for Linux (x86_64), Windows, and macOS. The reference implementation developed under the OpenJDK project is fully open under the GPLv2 license with exceptions from GNU ClassPath, allowing dynamic linking with commercial products.
Java SE 15 is classified as a release with a standard support duration, with updates being released until the next version. The long-term support (LTS) branch should use Java SE 11, which will receive updates until 2026. The previous LTS branch, Java 8, will be supported until December 2020. The next LTS release is scheduled for September 2021. It is worth noting that starting from Java 10, the project has transitioned to a new development process featuring a shorter cycle for new releases. New functionality is now developed in a continuously updated master branch, incorporating ready changes, from which stabilization branches for new releases are created every six months.
From :
- support for the EdDSA (Edwards-Curve Digital Signature Algorithm) signature creation algorithm ). The proposed EdDSA implementation is platform-independent, resistant to side-channel attacks (ensuring constant time for all computations), and outperforms existing ECDSA implementations written in C at the same level of security. For example, EdDSA using a 126-bit key demonstrates performance comparable to ECDSA with the secp256r1 curve and a 128-bit key.
- experimental support for sealed classes and interfaces that cannot be inherited, extended, or overridden by other classes and interfaces. Sealed classes also provide a more declarative way to restrict the usage of a superclass than access modifiers, based on explicitly listing subclasses that are permitted for extension.
package com.example.geometry;
public sealed class Shape
permits com.example.polar.Circle,
com.example.quad.Rectangle,
com.example.quad.simple.Square {…} - support for hidden classes that cannot be used directly by the bytecode of other classes. The main purpose of hidden classes is to be used in frameworks that dynamically generate classes at runtime and use them indirectly through . Such classes usually have a limited lifecycle, so maintaining them for access from statically generated classes is unjustified and will only lead to increased memory consumption. Hidden classes also allow avoiding the non-standard API sun.misc.Unsafe::defineAnonymousClass, which is slated for removal in the future.
- The Z Garbage Collector (ZGC) has been stabilized and is considered ready for widespread use. ZGC operates in a passive mode, minimizing pauses due to garbage collection as much as possible (the stop time when using ZGC does not exceed 10 ms) and can work with both small and huge heaps, ranging from several hundred megabytes to many terabytes.
- Stabilized and recognized as ready for widespread use
garbage collector , operating with minimal pauses (Low-Pause-Time Garbage Collector). Shenandoah was developed by Red Hat and is notable for using an algorithm that reduces stop times during garbage collection by performing cleaning in parallel with the execution of Java applications. The delays introduced by the garbage collector are predictable and do not depend on the heap size, i.e., for heaps of 200 MB and 200 GB, the delays will be identical ( 50 ms and usually fit within 10 ms); - Support for a new form of string literals has been stabilized and introduced into the language, allowing the inclusion of multiline text data in the source code without the need for character escaping and preserving the original text formatting in the block. The block is enclosed in three double quotes. For example, instead of the code
"\n\t\t" + "
\"Java 15 is here!\"
" +String html = "" +
"\n\t" + "" +
" " + "Java 15 is here!
" +
"\n\t" + "" +
"\n" + "";you can specify:
String html = """
<HTML>"Java 15\
Java 15
is here!"
API Legacy DatagramSocket. The old implementations of java.net.DatagramSocket and java.net.MulticastSocket have been replaced with a modern implementation that is easier to debug and maintain, as well as compatible with virtual threads being developed under the Loom project.
"""; - Loom To avoid potential compatibility issues with existing code, the old implementation has not been removed and can be activated using the option jdk.net.usePlainDatagramSocketImpl.
- A second experimental implementation has been proposed in the 'instanceof' operator, which allows immediately defining a local variable for referring to the checked value. For example, you can write 'if (obj instanceof String s && s.length() > 5) {.. s.contains(..) ..}' without explicitly defining 'String s = (String) obj'.
Previously:
if (obj instanceof Group) {
Group group = (Group) obj;
var entries = group.getEntries();
}Now it can be done without defining 'Group group = (Group) obj':
if (obj instanceof Group group) {
var entries = group.getEntries();
} - the second experimental implementation of the keyword “', providing a compact form for defining classes that allows avoiding explicit definitions of various low-level methods, such as equals(), hashCode(), and toString(), when the data is stored only in fields, the behavior of which does not change. When the class uses default implementations of the methods equals(), hashCode(), and toString(), it can do without their explicit definitions:
public record BankTransaction(LocalDate date,
double amount,
String description) {}This declaration will lead to the automatic addition of implementations for the methods equals(), hashCode(), and toString(), along with the constructor and methods that manage data changes (getter).
- the second preliminary version of the Foreign-Memory Access API, allowing Java applications to safely and efficiently access memory areas outside the Java heap, by manipulating new abstractions MemorySegment, MemoryAddress, and MemoryLayout.
- and the Biased Locking optimization technique, used in the HotSpot JVM to reduce overhead from locking, has been deprecated. This technique has become obsolete on systems with atomic instructions provided by modern CPUs and is too complex to maintain due to its intricacies.
- deprecated mechanism , which will be removed in one of the upcoming releases. It is noted that RMI Activation has been deprecated, relegated to an option since Java 8, and is rarely used in modern practice.
- JavaScript engine , which was deprecated in Java SE 11.
- ports for Solaris OS and SPARC processors (Solaris/SPARC, Solaris/x64, and Linux/SPARC). Removing these ports will allow the community to accelerate the development of new OpenJDK features without spending time maintaining Solaris and SPARC-specific details.
Source: opennet.ru
