This is the first day of my participation in the Gwen Challenge in November. Check out the details: the last Gwen Challenge in 2021

Like and see, unlimited power. Wechat search “program ape Alang”.

This article Github.com/niumoo/Java… And program ape Alang blog has been included, there are many knowledge points and series of articles.

Java 16 was officially released on March 16, 2021. It is not a permanent support version, and it does not bring many syntax changes, but it does bring a number of new utility features.

OpenJDK Java 16 download: jdk.java.net/archive/

Its Java 16 document: openjdk.java.net/projects/jd…

This article is part of a series of tutorials on new Features in Java that cover the new features of each version of Java.

1. JEP 347: enable C++ 14 language features

This update is not particularly relevant to Java developers. JEP 347 allows the use of C++ 14 language features in JDK C++ source code, and gives specific instructions on what features can be used in HotSpot code.

Extended reading: enable C++ 14 language features

2. JEP 357: Migrate from Mercurial to Git

Previously, the OpenJDK source code was managed using the version management tool Mercurial. You can also view the OpenJDK source history at hg.openjdk.java.net/.

But now GIt is being migrated for the following reasons:

  1. Mercurial generated versioning metadata is too large.
  2. Mercurial development tools are few and far between, while Git is seamlessly integrated into almost all major ides.
  3. There are few Mercurial services, either self-hosted or service-hosted.

To gracefully migrate to Git, OpenJDK does the following.

  1. Migrate all single-repository OpenJDK projects from Mercurial to Git.
  2. Keep all version control history, including tags.
  3. Reformat submitted messages according to Git best practices.
  4. A tool was created to convert between Mercurial and Git hashes.

Migrate from Mercurial to Git

3. JEP 369: Migrate to GitHub

In line with JEP 357’s move from Mercurial to Git, the Git repository hosting the OpenJDK community on GitHub was chosen after the move of version management to Git. However, only JDK 11 and later versions have been migrated.

4. JEP 376: ZGC concurrent thread stack processing

This change moves ZGC thread stack processing from Safepoints ** to the concurrent phase.

If you forget what Safepoints are, review them.

As we all know, in The past, when GC was needed, all threads needed to be paused in order to do garbage collection, and this pause was called Stop The World.

To implement STW, the JVM needs to choose a point for each thread to stop running, which is called a safe point.

Extended reading: JEP 376: ZGC concurrent thread stack processing

5. JEP 380: Unix domain socket channel

Add UnixDomainSocketAddress. Java classes are used to support the Unix domain socket channel.

Add UNIX-Domain sockets to SocketChannel and ServerSocketChannel APIS.

Add information java.net.StandardProtocolFamily.UNIX enumeration.

6. JEP 386: Port Alpine Linux

Apine Linux is a standalone, non-commercial Distribution of Linux. It is very small, requiring no more than 8MB of space for a container, approximately 130MB of storage for a minimum installation to disk, and is very simple and secure.

This proposal ports the JDK to Apline Linux, and since Apline Linux is a lightweight Linux distribution based on Musl Lib, other Linux distributions using Musl Lib on x64 and AArch64 architectures are also available.

Additional reading: JEP 386: Alpine Linux Port

7. JEP 387: Better Metaspace

Since the introduction of Metaspace, according to feedback, Metaspace often takes up too much out-of-heap memory, resulting in memory waste. Unused HotSpot class-Metaspace memory can now be returned to the operating system in a more timely manner. This reduces the footprint of Metaspace and optimizes Metaspace code to reduce subsequent maintenance costs.

JEP 388: Porting Windows/AArch64

Porting the JDK to the Windows/AArch64 architecture, Windows/AArch64 has been a hot demand in the end user market.

9. JEP 389: External Connector API (Incubation)

This proposal lets Java code call compiled machine code written in other languages (such as C, C++) instead of the previous JNI form.

This is an incubator function, however, and you need to add the –add-modules JDK.incubator. Foreign parameter at runtime to compile and run Java code.

Here is an example of calling a C function method and then printing the results.

  1. Write a C function that prints a “hello www.wdbyte.com”.
#include <stdio.h>

void printHello(a){
	printf("hello www.wdbyte.com\n");
}
Copy the code
  1. Compile the above code and print it to the shared library hello.so
$ gcc -c -fPIC hello.c
$ gcc -shared -o hello.so hello.o
$ ll
total 128
-rw-r--r--  1 darcy  staff    76B 10 28 19:46 hello.c
-rw-r--r--  1 darcy  staff   776B 10 28 19:46 hello.o
-rwxr-xr-x  1 darcy  staff    48K 10 28 19:47 hello.so
Copy the code
  1. Write Java code that calls the printHello method of hello.so.
import jdk.incubator.foreign.CLinker;
import jdk.incubator.foreign.FunctionDescriptor;
import jdk.incubator.foreign.LibraryLookup;

import java.lang.invoke.MethodHandle;
import java.lang.invoke.MethodType;
import java.nio.file.Path;
import java.util.Optional;

public class JEP389 {

  public static void main(String[] args) throws Throwable {

      Path path = Path.of("/Users/darcy/git/java-core/java-16/src/com/wdbyte/hello.so");

      LibraryLookup libraryLookup = LibraryLookup.ofPath(path);

      Optional<LibraryLookup.Symbol> optionalSymbol = libraryLookup.lookup("printHello");
      if(optionalSymbol.isPresent()) { LibraryLookup.Symbol symbol = optionalSymbol.get(); FunctionDescriptor functionDescriptor = FunctionDescriptor.ofVoid(); MethodType methodType = MethodType.methodType(Void.TYPE); MethodHandle methodHandle = CLinker.getInstance().downcallHandle( symbol.address(), methodType, functionDescriptor); methodHandle.invokeExact(); }}}Copy the code
  1. Java code compilation.
$ javac --add-modules jdk.incubator.foreign JEP389.javaWarning: Use the incubating module: JDk.incubator. Foreign 1 warningCopy the code
  1. Java code execution.
$java --add-modules jdk.incubator.foreign -Dforeign.restricted=permit JEP389.javaWARNING: Using incubator modules: JDK. Incubator. Foreign WARNING: Use incubating modules: Jdk.incubator. Foreign 1 warning hello www.wdbyte.comCopy the code

Read more: JEP 389: External Linker API (Incubator)

10. JEP 390: Warnings for value-based classes

An annotation has been added to identify classes that are currently value-based, such as the Optional class introduced in Java 8 to prevent null Pointers.

@jdk.internal.ValueBased
public final class Optional<T> {
    // ...
}
Copy the code

Read More: Warnings about value-based classes

11. JEP 392: Packing tools

In Java 14, JEP 343 introduced the packaging tool with the command jPackage, as described in the Java 14 new features article:

Using the jpackage command, you can package JAR packages into software formats supported by different operating systems.

jpackage --name myapp --input lib --main-jar main.jar --main-class myapp.Main
Copy the code

Common platform formats are as follows:

  1. Linux: deb and rpm
  2. macOS: pkg and dmg
  3. Windows: msi and exe

Note that JPackage does not support cross-compilation, which means it cannot be packaged into macOS or Linux software formats on Windows platforms.

In Java 15, the incubation continued, and now in Java 16, it has finally become an official feature.

Here is an example of packaging a simple Java Swing program into a software format supported by the current operating system and installing it on your current computer.

Writing Java code

import javax.swing.*;
import java.awt.*;

public class JEP392 {

    public static void main(String[] args) {
        JFrame frame = new JFrame("Hello World Java Swing");
        frame.setMinimumSize(new Dimension(800.600));
        frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
        JLabel lblText = new JLabel("Hello World!", SwingConstants.CENTER);
        frame.getContentPane().add(lblText);
        frame.pack();
        frame.setVisible(true); }}Copy the code

After compiling, create a JAR file.

$ javac JEP392.java
$ java JEP392.java
$ jar cvf JEP392.jar JEP392.class
Copy the code

Package the generated jep392.jar into a package suitable for your current platform.

$~ / develop/JDK - 16.0.1. JDK/Contents/Home/bin/jpackage - i. -n JEP392 -- the main - jar hello. Jar - the main - class JEP392
$ ll-rw-r--r-- @1 darcy staff 50M 10 28 20:34 jep392-1.0.ddG-RW-r --r-- 1 darcy staff 864B 10 28 20:22 jep392.class -rw-r--r-- 1 darcy staff 1.0k 10 28 20:30 jep392. jar -rw-r--r-- 1 darcy staff 588B 10 28 20:22 jep392. JavaCopy the code

The jEP392-1.0.dmg (I’m using MacOS, so the format is DMG) displayed after LL is the result of packaging.

Double-click on this file to install it as MAC software. Other platforms are similar.

After installation, it can be started from the boot console.

Different system installation positions are different:

  • Linux:/opt
  • MacOS:/Applications
  • Windows: C:\Program Files\

Read more: JEP 392: Packaging tools

12. JEP 393: External Memory Access (third incubation)

This proposal aims to introduce new apis that allow Java programs to access memory outside of the Java heap securely and efficiently. The proposals were first proposed in Java 14, re-incubated in Java 15, and are now being incubated again in Java 16.

The objectives of this proposal are as follows:

  1. Generality: A single API should be able to operate on a variety of external memory, such as native memory, persistent memory, heap memory, and so on.
  2. Security: No matter what memory you operate on, the API should not compromise the security of the JVM.
  3. Control: You can freely choose how to free memory (explicit, implicit, etc.).
  4. Available: If you need to access external memory, the API should besun.misc.Unsafa.

Extended reading: external memory access

13. JEP 394: Instanceof Pattern Matching

Improvements to Instanceof were proposed in Java 14, continued to be previewed in Java 15, and are now an official feature in Java 16.

Previously, using instanceof required the following:

if (obj instanceof String) {
    String s = (String) obj;    // grr.... }Copy the code

Redundant type cast, and now:

if (obj instanceof String s) {
    // Let pattern matching do the work!. }Copy the code

Read more: New Java 14 features – Instanceof

14. JEP 395: Records

Record became an official feature of Java 16, and here’s what you can learn about Record in Java 14.

Record is a completely new type. It is essentially a final class, and all properties are final qualifiers. It automatically compiles public Get HashCode, Equals, toString, and other methods, reducing code writing.

Example: Write a Dog Record class that defines the name and age properties.

package com.wdbyte;

public record Dog(String name, Integer age) {}Copy the code

Use of Record.

package com.wdbyte;

public class Java14Record {

    public static void main(String[] args) {
        Dog dog1 = new Dog("Sheepdog".1);
        Dog dog2 = new Dog("Field Dog".2);
        Dog dog3 = new Dog("Husky".3); System.out.println(dog1); System.out.println(dog2); System.out.println(dog3); }}Copy the code

Output result:

Dog[name= sheepdog, age=1] Dog[name= pastoral Dog, age=2] Dog[name= husky, age=3]Copy the code

This feature was previewed in Java 15 and released in Java 16.

JEP 396: Strongly encapsulates JDK internals by default

Java 9 JEP 261 introduced the — illegal-Access option to control internal API access and JDK packaging.

This JEP changes the default mode of the –illegal-access option from allow to deny. With this change, JDK internal packages and apis (except for key internal apis) will no longer be opened by default.

The motivation behind the JEP is to prevent third-party libraries, frameworks, and tools from using JDK internal apis and packages, increasing security.

16. JEP 397: Sealed Classes Preview

Sealed Classes: Sealed Classes: Sealed Classes: Sealed Classes: Sealed Classes: Sealed Classes: Sealed Classes: Sealed Classes: Sealed Classes: Java 15

Here’s a quote:

We all know that in Java, if we want a class that cannot be inherited or modified, we should use the final keyword to modify the class. However, this either inheritable or not inheritable mechanism is not flexible enough, and sometimes we might want a class to be inheritable by certain types, but not arbitrarily, which is not possible. Java 15 attempts to solve this problem by introducing the sealed class, which can be subclassed by sealed. This class can be inherited only by the specified class.

In addition, sealed is transitive. Its subclasses must be final, sealed, or non-sealed, and must use the specified keyword.

Read more: Introduction to new Java 15 features

reference

  1. Openjdk.java.net/projects/jd…
  2. Docs.oracle.com/en/java/jav…

After < >

Hello world:) I’m Aaron, a tech tool guy on the front line.

The likes are all talented, not only handsome and good-looking, but also good to talk.

The article is updated continuously, you can follow the public account “program ape Alang” or visit “program ape Alang blog” (www.wdbyte.com).

I have prepared a series of knowledge points and must-see books.

This article Github.com/niumoo/Java… Welcome to Star!