Cover: Luo Xiaoxi

Translator: Pan Pan

The new features in JDK 16 are coming in with a knife in their hand, even before the new features in JDK 8 are known.

Solemnly declare:

As you can imagine, the first venture to translate professional literature was particularly bad. General translation literature, especially the content in the field of technical expertise, involves many professional terms and common language in the industry, many words you cannot find in translation software, and most knowledge points and technologies are systematic, interrelated, multi-version iterative, historical reasons and so on. Therefore, you must be clear about the cause and effect of each technical point and the logical relationship, otherwise it takes time and energy to translate, because you keep reading the references to learn and figure out, but in fact in vain, because many of you still do not see the end. And the translation of the JDK 16 new feature literature content, is indeed difficult.

Therefore, the content of this translation is only for reference, I have done my best to translate and tidy up, if there are translation loopholes or let everyone have misunderstanding, please give understanding, and welcome to correct, exchange at any time.

preface

In March 2021, the next release of the Java upgrade will focus on raw classes, sealed classes, record classes, vector class interfaces, and ports for Windows ARM64 and Alpine Linux.

JDK 16 added value-based class warnings and sealing classes (second preview) as planning features, as well as a range of new features, from external linker apis, to pattern matching, to concurrent thread stack handling for garbage collection.

JDK 16 will be a standard Java version reference implementation following JDK 15, which was released on September 15. The proposed release is scheduled to enter the proposal freeze phase on December 10, 2020 and January 14, 2021, followed by two preview releases on February 4, 2021 and February 18, 2021. The production version is expected to be released on March 16, 2021.

Throughout the history of the JDK:

  • JDK 1.0
    • The 1996-01-23 release
  • JDK 1.1
    • The 1997-02-19 release
  • JDK 1.2
    • The 1998-12-04 release
  • JDK 1.3
    • The 2000-05-08 release
  • JDK 1.4
    • The 2002-02-13 release
    • Regular expressions, exception chains, NIO, logging classes, XML parsers, XLST converters
  • The JDK 1.5/5.0
    • The 2004-09-30 release
    • Autoboxing, generics, dynamic annotations, enumerations, variable-length arguments, traversal loops
  • The JDK 1.6/6.0
    • 2006-04 Provides dynamic language support, provides compilation API and satellite HTTP server API, improves JVM locking, synchronous garbage collection, and class loading
  • The JDK 1.7/7.0
    • The 2011-07-28 release
    • GI collector, enhanced call support for non-Java languages (JSR-292, updated class loading architecture
  • The JDK 1.8/8.0
    • The 2014-03-18 release
    • Lambda expressions, method references, default methods, new tools, Stream API, Date Time API, Optional classes, Nashorn, JavaScript engine
  • JDK 9.0
    • The 2017-09-21 release
    • JShell, immutable set Factory method, module system, HTTP protocol version 2.0, Process API/CompletableFuture API/Optional Class/Stream API enhancements, diamond operators for anonymous inner classes, default G1 garbage collector, try statement syntax improvements
  • JDK 10.0
    • The 2018-03-21 release
    • JIT compilers, local variable type references, data type sharing, parallel GC, root certificates, Javah tools, heap allocation
  • JDK 11.0
    • The 2018-09-25 release
    • Single-command Java file running, Lambda parameter local variable syntax, nested access control, dynamic class file constants, garbage collector misoperation, Removal of Java EE and CORBA modules, ChaCha20 and Poly1305 encryption algorithms, Aarch64 enhancement, ZGC trial, deprecation Nashorn JS engine
  • JDK 12.0
    • The 2019-03-19 release
    • JVM enhancements, Switch expressions, file mismatch() method, String new method Indent ()/ Transform ()/describeConstable()/resolveConstantDesc(), JVM constant API, Instanceof pattern matching
  • JDK 13.0
    • The 2019-09-17 release
    • Support for writing text blocks, Switch expression enhancements, refactoring legacy Socket apis, uncommitting unused memory, dynamic CDS archiving, Unicode 12.1 support, DOM and SAX factory support for namespaces
  • JDK 14.0
    • The 2020-03-17 release
    • Null pointer exception enhancement hints, Switch expressions (standard), Instanceof pattern matching (preview), Records classes (preview), text blocks (second preview), packaging tools (incubation), JFR event streams, ZGC (macOS and Windows support) ), external memory access API (incubation)
  • JDK 15.0
    • The 2020-09-15 release
    • Sealed classes (preview), Instanceof Pattern matching (second preview), Records classes (second preview), Text blocks (standard), Hidden classes, remove Nashorn JS engine, rebuild legacy DatagramSocket API, external memory access API (second incubation), deprecating RMI activation, removing Solaris and SPARC ports
  • JDK 16.0
    • 2020-12-10 First proposal freeze
    • 2021-01-14 The second proposal is frozen
    • 2021-02-04 Release first preview version
    • 2021-02-18 Release the second preview
    • 2021-03-16 Official release

As of December 1, 2020, there are 15 formal proposals in JDK 16, with two more value-based class warnings and containment classes (second preview) still in the “targeted proposal” phase.

New features in Java 16 include:

It is recommended that the original wrapper class be specified as a value-based class, and it is not recommended to prompt the user to remove its constructor by prompting a new deprecation warning. False attempts to synchronize any value-based class instance in the Java platform are warned. Driving this effort is the Valhalla project, which is making major improvements to the Java programming model in the form of primitive classes. Primitive classes declare instances as unidentified and can be inlined or flattened representations, where instances can be freely copied between memory locations and encoded with the values of instance fields. The design and implementation of primitive classes in Java is now mature enough to expect some classes from the Java platform to be migrated to primitive classes in future releases. The classes that are scheduled to be migrated will be designed as value-based classes in the API specification.

As previewed in JDK 15, sealing classes and interfaces limits the classes and interfaces that can be extended or implemented. The goals of this initiative include allowing the creator of a class or interface to control the code responsible for implementing it, providing more declarative ways to restrict the use of superclasses than access modifiers, and supporting the future evolution of pattern matching by providing a foundation for pattern analysis.

By default, JDK internals are strongly encapsulated, with the exception of key internals such as misc.unsafe. Since JDK 9, the default allows users to choose to use loose strong encapsulation. As part of the Jigsaw project, the goals of this proposal include improving the security and maintainability of the JDK, and encouraging a gradual migration from direct use of internal elements to use standard apis, so that both developers and end users can easily upgrade to future versions of Java. This recommendation does have a major risk, namely that the existing version of Java code will not run. Developers are encouraged to use the JDEPS tool to identify JDK internal elements that depend on in their code and switch to standard alternatives when available. Developers can use existing distributions (such as JDK 11) to test existing code by using –illegal-access= WARN to identify internal elements accessed by reflection, –illegal-access= DEBUG to locate faulty code, And use –illegal-access=deny to test.

4, support static type of pure Java way to access native code external linker API. This interface is in the incubation phase in JDK 16, and along with the proposed external storage access interface, the external link program interface (API) will greatly reduce the error prone of binding local libraries in other ways. This initiative aims to provide interaction with C by replacing JNI (Java Native Interface) with a more advanced pure Java development pattern and, over time, It will be more flexible and adaptable to support other platforms (such as the 32-bit x86 architecture) and other external functions written outside C (such as those written in C++). Its performance will be superior to THAT of JNI.

5. Move ZGC (Extensible low-latency Garbage Collector) thread stack processing from safe point to concurrent phase. The goals of the program include removing thread stack processing from the ZGC safe point, making stack processing lazy, cooperative, concurrent, and incremental, removing all other single-thread root processing from the ZGC safe point, and providing a mechanism for other virtual machine subroutines to defer stack processing. ZGC is designed to make GC pauses and scalability issues in HotSpot a thing of the past. So far, GC operations that scale with heap size and meta-space size have been removed from safe point operations and moved to the concurrent phase, which includes marking, relocation, reference handling, class unloading, and most root handling. The only remaining GC security points are subset root processing and timed marker termination operations. These root processes include the Java thread stack and other thread roots, which are problematic because they scale with the number of threads. To eliminate these problems, per-thread processing (including stack scans) must be moved to the concurrent phase. With this plan, the throughput cost of raising latency will be negligible, and the time spent inside the ZGC safe point on a typical computer will be less than 1 millisecond.

6. The flexible metasspace feature returns memory occupied by unused HotSpot virtual machine-class metadata (metasspace) to the operating system more quickly, reducing the metasspace footprint and simplifying the metasspace code to reduce maintenance costs. There are a lot of out-of-heap memory usage problems in the meta space. The plan calls for a memory partition allocation scheme to replace the existing memory allocation mechanism, providing an algorithm to divide memory into multiple partitions to meet memory requests. This approach, already used in many places (e.g., the Linux kernel, etc.), will make it feasible to allocate memory in smaller chunks to reduce classloader overhead, and fragmentation will be reduced. In addition, from the operating system to the memory management area, memory memory will be used late, on demand, to reduce space taken up by loaders that start with large areas but don’t use them immediately or may not be able to fully utilize them. To take full advantage of the flexibility provided by partition allocation, arrange the meta-space memory into uniformly sized particles that can be committed and uncommitted independently of each other.

7. Enable C++ 14 language features to allow the use of C++ 14 features in JDK C++ source code and provide specific guidance on the features allowed in HotSpot virtual machine code. With JDK 15, we know that the language features used by C++ code in the JDK are limited to the C++ 98/03 language standard. Since JDK 11, the source code has been upgraded to support building with newer versions of the C++ standard. This includes the ability to build using the latest version of the compiler that supports the functionality of the C++ 11/14 language. This proposal does not recommend changes to the style or usage of C++ code used outside of HotSpot, but some build-time changes are necessary to take advantage of the features of the C++ language, depending on the platform compiler.

The vector API for the incubation phase is the JDK.incubator. Vector module provided in the JDK to express the best hardware instructions for vector computation ———— compilation on the supported CPU architecture. To achieve better performance than equivalent scalar computations. The vector API provides a mechanism for writing complex vector algorithms in Java, vectorized using pre-existing support in the HotSpot VIRTUAL machine along with a set of user models to make them more predictable and robust. The goals of the proposal include providing a clear and concise API to express a range of vector computations, achieving platform independence by supporting multiple CPU architectures, and providing reliable runtime compilation and performance on both X64 and AArch64 architectures. Elegant degradation is also a goal, in which vector computation is gracefully degraded and still works if it is not fully represented as a sequence of hardware vector instructions at runtime, either because some instructions are not supported by one architecture or because other CPU architectures are not supported.

Port the JDK to Windows/AArch64. With the release of new server-level and consumer AArch64 (ARM64) hardware, plus demand reasons Windows/AArch64 has become an important platform. While the migration itself is almost complete, the focus of the proposal is on integrating the ports into the mainline JDK library.

Port the JDK on the X64 and AArch64 architectures to Alpine Linux and other Linux distributions that use MUSL as their primary C library. Musl is a Linux implementation of the standard library functionality described in the ISOC and Posix standards. Alpine Linux is widely used in cloud deployments, microservices, and container environments due to its smaller image size. The Docker container image for Linux is smaller than 6MB. Let Java work out of the box in this setup and allow Tomcat, Jetty, Spring, and other popular frameworks to work in the native environment. By using **jlink ** to reduce the size of the Java runtime, users can create a smaller image to run a specific application.

11, [provide record class, as immutable data transparent carrier. Record the class name can be thought of as tuples. Record class preview in JDK 14 and 15 in the JDK. This is in response to complain about Java too long stiff. The goal of the program including said to design a simple collection value of the constructor of the object oriented, Helps developers focus on modeling immutable data rather than extending behavior, automates data-driven methods (such as Equals and Accessors), and preserves longstanding Java principles, such as nominal typing.

12, The addition of UNIX-Domain socket channels, where UNIX-Domain (AF_UNIX) socket support was added to the socket channel and server socket channel API in the Nio. Channels package. The plan also extends the inherited channel mechanism to support UNIX-Domain socket channels and server socket channels. Unix-domain sockets are used for interprocess communication on the same host. They are similar to TCP/IP sockets in most respects, except that they are addressed by file system pathnames instead of IP addresses and port numbers. The goal of the new feature is to support all the functionality of the UNIX-Domain socket channel common to Unix platforms and Windows. The UNIX-Domain socket channel will be identical to the existing TCP/IP channel in terms of read/write behavior, connection setup, server acceptance of incoming connections, and multiplexing with other non-blocking alternative channels in the selector. Unix-domain sockets are more secure and efficient than TCP/IP loopback connections for local, interprocess communication.

External memory access API that allows Java programs to securely access external memory outside the Java heap. The external memory access API, previously incubated in JDK 14 and JDK 15, will be incubated again and improved in JDK 16. Improvements include more explicit roles between MemorySegments and MemoryAddresses interfaces. The goals of the proposal include providing an API that can run on a variety of external storage, including native, persistent media, and managed heap storage. The API does not pose a threat to vm security. The motivation for the proposal is to give many Java programs access to external storage, such as Ignite, Memcached, and MapDB. Unfortunately, the Java API doesn’t have a satisfactory solution for accessing external storage.

14. Pattern matching for the instanceof operator was previewed in JDK 14 and JDK 15, and will be finalized in JDK 16. Pattern matching enables a cleaner and safer expression of general logic in a program, that is, conditionally extracting components from objects.

15. Provide a tool called JPackage for packaging Java applications independently. Jpackage was introduced as an incubation tool in JDK 14 and is still in the incubation phase in JDK 15. By JDK 16, JPackage will be in production, supporting a native package format to provide a natural installation experience for users and allowing boot-time parameters to be specified at package time. Supported formats include MSI and EXE on Windows, PKG and DMG on MacOS, and Deb and RPM on Linux. The tool can be invoked directly from the command line or programmatically. The new packaging tool addresses the situation where many Java applications need to be installed on the native platform in a globally available manner, rather than simply placed on the classpath or module path. Therefore, it is necessary to provide installable packages suitable for the native platform.

Migrate the OpenJDK source repository from Mercurial to Git. Promoting this effort has advantages in several ways: in terms of the size of the versioning system metadata, in terms of the tools available, and in terms of hosting.

Move to GitHub. This change is based on moving the OpenJDK source repository from Mercurial to Git, where the JDK 16 repository will appear on popular code sharing sites. The Mercurial JDK and JDK-Sandbox transition to Git, GitHub and Skara was completed on September 5 and is now available to users.

An early test version of JDK 16 for Linux, Windows, and MacOS is available for download at jdk.java.net. Like JDK 15, JDK 16 will be a short-term release with only six months of support. JDK 17, scheduled for September 2021, will be a long term support (LTS) release with several years of support. The current long-term support (LTS) release is JDK 11, released in September 2018.

conclusion

Believe that a lot of enterprises or individuals, are still using the JDK 8 this maintenance release for a long time, the latest maintenance is JDK version 11 for a long time, estimated using group is not much more special, because for business/personal version upgrade cost is too big, we need more is often system can steady safe operation, Even if you have to sacrifice some performance. Since JDK8, the Java language has become more and more aggressive and inclusive, version upgrade speed and cycle is extremely amazing, now just a few years, has been JDK 16, so I am particularly optimistic about Java in the future market share and the continued extension of technical capabilities, come on, Java.

References

[1] the JDK 16: www.infoworld.com/article/356…

[2] the JDK 15: www.infoworld.com/article/353…

[3] based on the value of the type of warning proposal: openjdk.java.net/jeps/390

[4] Valhalla project: openjdk.java.net/projects/va…

[5] based on the value of the class: docs.oracle.com/en/java/jav…

[6] sealed class: openjdk.java.net/jeps/397

[7] JDK internal structure is strongly encapsulation: openjdk.java.net/jeps/396

[8] the Jigsaw project: openjdk.java.net/projects/ji…

Alternative version: [9] standard wiki.openjdk.java.net/display/JDK…

[10] external links application API: openjdk.java.net/jeps/389

[11] ZGC (scalable low-latency) garbage collector thread stack processing: openjdk.java.net/jeps/376

[12] elastic dimension function: openjdk.java.net/jeps/387

[13] 14 c + + language features: openjdk.java.net/jeps/347

[14] c + + 14: www.infoworld.com/article/260…

[15] the incubation phase vector API: openjdk.java.net/jeps/338

[16] transplanted JDK into Windows/AArch64 platform: openjdk.java.net/jeps/388

[17] JDK transplanted to Alpine Linux: openjdk.java.net/jeps/386

[18] jlink: openjdk.java.net/jeps/282

[19] provides record categories: openjdk.java.net/jeps/395

[20] – Domain Unix socket channels: openjdk.java.net/jeps/380

[21] external memory access API: openjdk.java.net/jeps/393

[22] pattern matching: openjdk.java.net/jeps/394

[23] provides a tool called jpackage, used to separate packaging Java applications: openjdk.java.net/jeps/392

[24] JDK 14: www.infoworld.com/article/343…

[25] its source code repository from Mercurial migration to Git: openjdk.java.net/jeps/357

[26] migration to making: openjdk.java.net/jeps/369

16 [27] JDK source warehouse will appear in the popular code sharing website: www.infoworld.com/article/356…

[28] jdk.java.net: jdk.java.net/16/

[29] JDK 11: www.infoworld.com/article/326…

BIU ~ the article continues to update, wechat search “Pan Pan and his friends” the first time to read, there are surprises at any time. This article will be included on GitHub github.com/JavaWorld, hot technology, framework, surface, solution, we will be the most beautiful posture in the first time, welcome Star.