Java version of the new discovery: JDK15 14 new features and changes

Java Development Kit 15 Oracle's implementation of the next version of Java SE (Standard Edition), entered the release candidate phase in early August. Highlights of JDK 15 include blocks of text, hidden classes, external memory access APIs, and previews of sealed classes and records.

New features and changes to OpenJDK 15 include:

1) Out-of-memory access API (foreign-memory API)

The second incubator of the Out-of-Memory Access API, which enables Java programs to securely and efficiently access external memory outside the Java heap. T his API can manipulate various types of external memory, such as native, persistent, and managed heaps. T here are many Java programs that access external memory, such as Ignite and MapDB T he API will help avoid the costs associated with garbage collection and the unpredictability associated with sharing memory across processes and serializing and deserializing memory content by mapping files to memory. T he Java API does not currently provide a satisfactory solution for accessing external memory. B ut in the new proposal, the API should not compromise the security of JVM In JDK 14 this feature is going through an early incubation phase and improvements are available in JDK 15

2) Preview of sealed classes

Like interfaces, sealed classes limit the ability of other classes or interfaces to extend or implement them. The goal of this feature includes allowing the author of a class or interface to control which code is responsible for implementation, providing more choices than restricting access modifier declarations using superclasses, and supporting the future development of pattern matching by supporting a thorough analysis of patterns.

3) Related supported deletions

Remove source code and build support for Solaris/SPARC Solaris/x64 and Linux/SPARC ports, which are not approved for removal in JDK 14 but can be removed in a future release. M any of the projects and features under development, such as Valhalla, Loom, and Panama, require significant changes to accommodate CPU architecture and operating system-specific code. A bandoning support for Solaris and SPARC ports will enable contributors to the OpenJDK community to accelerate the development of new features that will drive the platform forward. In recent years, Solaris and SPARC have been replaced by Linux operating systems and Intel processors.

4) Record structure

A record is a transparent carrier class that acts as immutable data and is included in the second preview version of JDK 15 after it was first debugged as an early preview in JDK 14. T he goal of the plan includes designing an object-oriented structure that expresses a simple aggregate value, helping programmers focus on modeling immutable data rather than extending behavior, automating data-driven approaches such as equals assess and assessors and preserving long-standing equals such as nominal types and migration compatibility in Java. Records can be considered nominal tuples.

5) Digital signature algorithm

Encrypted signatures based on the Edwards-Curve digital signature algorithm (EdDSA-Edwards-Curve Digital Signature Algorithm). EdDSA is a modern elliptical curve scheme with the advantages of existing signature schemes in JDK. EdDSA will only be implemented in SunEC providers. EdDSA is a concern because of its higher security and performance than other signature schemes. It is already supported in encryption libraries such as BoringSSL OpenSSL

6) Update implementation of sockets

Re-implement the legacy DatagramSocket API by replacing the underlying implementations of java.net.MulticastSocket API APIs with simpler, more modern DatagramSocket API java.net.datagram.Socket New implementation:

1. Easy to debug and maintain;

2. Collaborate with the virtual threads being explored in Project Loom.

The new plan is a follow-up to JDK Enhancement Proposal 353 which re-implements the legacy socket API. T he current implementations of java.net.datagram.Socket and java.net.MulticastSocket can be traced back to JDK 1.0, when IPv6 was still under development. As a result, the current multicast socket implementation attempts to reconcile ways that IPv4 and IPv6 are difficult to maintain.

7) Disable bias/bias locking

Bias locking is disabled by default and all relevant command-line options are deprecated. T he goal is to determine whether legacy synchronization optimization, which continues to support the high maintenance costs of bias locking, is used by HotSpot virtual machines to reduce the overhead of non-competitive locking. Although some Java applications may experience performance degradation after disabling biased locks, the performance improvement in favor of locks is generally not as noticeable as before.

8) instanceof pattern match

This is the second preview, previously the first preview in JDK 14. P attern matching allows common logic in a program, primarily conditional extraction of components from objects, to be expressed more precisely. Languages like Haskell and c# already include pattern matching because of its simplicity and security.

9) Hidden classes

A class that cannot be used directly by bytecodes of other classes is used for the framework that generates classes at runtime and uses classes indirectly through reflection. H idden classes can be defined as members of access control nesting and can be unloaded independently of other classes. T he proposal will improve the efficiency of all languages on the JVM by supporting a standard API to define hidden classes that are not discoverable and have a limited life cycle. T he internal and external frameworks of the JDK will be able to dynamically generate classes that define hidden classes. M any languages built on JVM rely on dynamic class generation for flexibility and efficiency. T he objectives of this proposal include allowing the framework to define classes as undiscoverable framework implementation details so that they cannot be linked by other classes or discovered by reflection; S upports extending access control nesting with non-discoverable classes; I t also supports proactive unloading of undiscoverable classes, so the framework has the flexibility to define multiple classes as needed. A nother goal is to deprecation non-standard API misc.Unsafe::defineAnonymousClass to be removed in a future release. In addition, the Java language does not change as a result of this recommendation.

10) ZGC productization

Under this proposal, the ZGC-Z Garbage Collector will be upgraded from an experimental feature to a product. I ntegrated into JDK 11, released in September 2018, ZGC is a scalable, low-latency garbage collector. Z GC was introduced as an experimental feature because Java developers decided that this scale and complexity should be introduced carefully and gradually. S ince then, many improvements have been added, from concurrent class offloading, unused memory decommissioning, support for class data sharing, to improved NUMA awareness and multithreaded heap preprocessing. I n addition, the maximum heap size increases from 4TB to 16TB. Supported platforms include Linux Windows and MacOS

11) Block of text

Both JDK 14 and JDK 13 preview blocks of text designed to simplify the task of writing Java programs by simplifying the expression of strings that span several lines of source code while avoiding escape sequences in common cases. A block of text is a multi-line string text that avoids using most escape sequences, automatically formats strings in a predictable manner, and gives developers control over formatting when needed. O ne of the recommended goals of the block of text is to enhance the readability of strings in Java programs that represent code written in non-J Java languages. A nother goal is to support the migration of string text by specifying that any new construct can represent the same set of strings as string text, interpret the same escape sequence, and operate in the same way as string text. OpenJDK developers want to add escape sequences to manage explicit spaces and line breaks.

12) LPT GC is officially available

Shenandoah Low Pause-time garbage collector will become a production feature and will no longer be in the experimental phase. It was integrated into JDK 12 a year ago.

13) Delete Nashorn

Nashorn which debuted in jdk8 in March 2014, was removed because it was eliminated by technologies such as GraalVM OpenJDK 15 proposes to remove Nashorn APIs and jjs command line tool used to invoke Nashorn

14) RMI Activation enters the non-recommended period

RMI activation mechanisms are not recommended for future deletion. T he RMI activation mechanism is an outdated part of the RMI and has been optional since Java 8. T he RMI activation mechanism increases the ongoing maintenance burden. Other parts of the RMI will not be deprecated.

Earlier access to JDK 15 can be found java.jdk.net website. J DK 15 will be a short-term feature release that will be supported for six months based on Oracle's six-month release cycle. T he next LTS-long-term support version is JDK 17, which is expected to be released in September 2021 and will receive several years of support. The current LTS version is JDK 11, which will be released in September 2018.

The above is W3Cschool编程狮 about the java version of the new discovery: JDK15 14 new features and changes related to the introduction, I hope to help you.