look again, the power is unlimited. Hello world search "1617f351e40040 1617f351e40041 program monkey ".
This article Github.com/niumoo/JavaNotes and programmer 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 long-term support version. This update does not bring many grammatical changes, but it also brings a lot of new practical features.
OpenJDK Java 16 download: https://jdk.java.net/archive/
OpenJDK Java 16 document: https://openjdk.java.net/projects/jdk/16/
This article belongs to the Java new feature tutorial , which will introduce the new features of each version of Java, you can click to browse.
<!-- more -->
1. JEP 347: Enable C++ 14 language features
This update is not closely related to Java developers. JEP 347 allows the use of C++ 14 language features in the C++ source code of the JDK, and gives specific instructions on which features can be used in HotSpot code.
Extended reading: enable C++ 14 language features
2. JEP 357: Migrating from Mercurial to Git
Prior to this, the OpenJDK source code was managed using the version management tool Mercurial. You can also view the historical version of the OpenJDK source code http://hg.openjdk.java.net/
But now that I have migrated to GIt, the main reasons are as follows:
- The version control metadata generated by Mercurial is too large.
- Mercurial-related development tools are relatively few, and Git has been seamlessly integrated in almost all mainstream IDEs.
- Mercurial-related services are relatively few, whether it is self-built hosting or service hosting.
In order to gracefully migrate to Git, OpenJDK did the following operations.
- Migrate all single-repository OpenJDK projects from Mercurial to Git.
- Keep all version control history, including tags.
- Reformat the submitted message according to Git's best practices.
- Created a tool to convert between Mercurial and Git hashes.
Extended reading: from Mercurial to Git
3. JEP 369: Migrate to GitHub
Consistent with the changes in JEP 357 from Mercurial to Git, after migrating version management to Git, I chose to host the Git repository of the OpenJDK community on GitHub. However, only JDK 11 and higher versions of JDK have been migrated.
4. JEP 376: ZGC Concurrent Thread Stack Processing
This change moves the ZGC thread stack processing from (Safepoints) to the concurrent stage.
If you forget what Safepoints are, you can review it.
We all know that before, when GC was needed, all threads needed to be paused in order to perform garbage collection. This pause time is called Stop The World .
In order to implement the STW operation, the JVM needs to select a point for each thread to stop running, this point is called safe points (Safepoints) .
Extended reading: JEP 376: ZGC Concurrent Thread Stack Processing
5. JEP 380: Unix domain socket channel
Add the UnixDomainSocketAddress.java class to support Unix domain socket channels.
Add Unix-domain socket to SocketChannel and ServerSocketChannel API.
Add enumeration information java.net.StandardProtocolFamily.UNIX.
6. JEP 386: Porting Alpine Linux
Apine Linux is an independent, non-commercial Linux distribution, it is very small, a container needs no more than 8MB of space, the minimum installation to disk only requires about 130MB of storage space, and it is very simple, while taking into account safety sex.
This proposal ported JDK to Apline Linux. Since Apline Linux is a lightweight Linux distribution based on musl lib, other Linux distributions that use musl lib on x64 and AArch64 architectures are also applicable.
Extended reading: JEP 386: Alpine Linux Port
7. JEP 387: Better Metaspace
Since the introduction of Metaspace, according to feedback, Metaspace often occupies too much off-heap memory, which leads to a waste of memory. Now the unused HotSpot class-metaspace memory returned a timely manner, thereby reducing the usage of Metaspace Space, and optimized Metaspace code to reduce subsequent maintenance costs.
8. JEP 388: Porting Windows/AArch64
Porting the JDK to the Windows/AArch64 architecture, Windows/AArch64 is already a popular demand in the end-user market.
9. JEP 389: External Connector API (Incubating)
This proposal allows Java code to call compiled machine code written in other languages (such as C, C++), replacing the previous JNI form.
However, this is still an incubating function. You need to add the --add-modules jdk.incubator.foreign
parameter to compile and run the Java code at runtime.
The following is an example of calling a C language function method and then outputting the running result.
- Write a C function to print a "hello www.wdbyte.com".
#include <stdio.h>
void printHello(){
printf("hello www.wdbyte.com\n");
}
- Compile the above code, and then output 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
- Write a 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();
}
}
}
- Java code compilation.
$ javac --add-modules jdk.incubator.foreign JEP389.java
警告: 使用 incubating 模块: jdk.incubator.foreign
1 个警告
- Java code execution.
$ java --add-modules jdk.incubator.foreign -Dforeign.restricted=permit JEP389.java
WARNING: Using incubator modules: jdk.incubator.foreign
警告: 使用 incubating 模块: jdk.incubator.foreign
1 个警告
hello www.wdbyte.com
Extended reading: JEP 389: External Linker API (Incubator)
10. JEP 390: Warning for value-based classes
An annotation has been added to identify the current value-based class. For example, the Optional class that prevents null pointers introduced by Java 8 has now been added with annotation identification.
@jdk.internal.ValueBased
public final class Optional<T> {
// ...
}
Further reading: for value-based classes
11. JEP 392: Packaging Tool
In Java 14, JEP 343 introduced a packaging tool, the command is jpackage
, which is also introduced in the article on new features in Java 14:
Use the
jpackage
command to package the JAR package into software formats supported by different operating systems.jpackage --name myapp --input lib --main-jar main.jar --main-class myapp.Main
The common platform format is as follows:
- Linux:
deb
andrpm
- macOS:
pkg
anddmg
- Windows:
msi
andexe
It should be noted that
jpackage
does not support cross-compilation, which means that it cannot be packaged into the software format of macOS or Linux system on the windows platform.
In Java 15, it continued to incubate, and now in Java 16, it has finally become an official feature.
The following is an example of packaging a simple Java Swing program into a software format supported by the current operating system, and then installing it on the current computer.
Write 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);
}
}
After compilation, a JAR file is created.
$ javac JEP392.java
$ java JEP392.java
$ jar cvf JEP392.jar JEP392.class
Package the generated JEP392.jar into a software package that conforms to the current platform.
$ ~/develop/jdk-16.0.1.jdk/Contents/Home/bin/jpackage -i . -n JEP392 --main-jar hello.jar --main-class JEP392
$ ll
-rw-r--r--@ 1 darcy staff 50M 10 28 20:34 JEP392-1.0.dmg
-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.java
ll
(I use MacOS, so the format is dmg) displayed after JEP392-1.0.dmg
After double-clicking this file, it can be installed like mac software. Other platforms are similar.
After installation, it can be started on the launch pad.
Different system installation positions are different:
- Linux:
/opt
- MacOS :
/Applications
- Windows:
C:\Program Files\
Extended reading: JEP 392: Packaging tool
12. JEP 393: External memory access (third incubation)
This proposal aims to introduce a new API to allow Java programs to safely and effectively access memory outside the Java heap. The relevant proposal was proposed as early as Java 14, and it was re-incubated in Java 15, and now it is re-incubated in Java 16.
The goals of this proposal are as follows:
- General: A single API should be able to operate on various external memory (such as native memory, persistent memory, heap memory, etc.).
- Security: No matter what kind of memory is manipulated, the API should not undermine the security of the JVM.
- Control: You can freely choose how to release the memory (explicit, implicit, etc.).
- Available: If you need to access external memory, the API should be
sun.misc.Unsafa
.
Extended reading: External memory access
13. JEP 394: instanceof pattern matching
The improvement instanceof
has been proposed in Java 14, and continues to be previewed in Java 15, and now it has become an official feature in Java 16.
Before, the following operations instanceof
if (obj instanceof String) {
String s = (String) obj; // grr...
...
}
The redundant type coercion, and now:
if (obj instanceof String s) {
// Let pattern matching do the work!
...
}
Extended reading: Java 14 new feature introduction-instanceof
14. JEP 395:Records
Record become an official function of Java 16. The following is an introduction to Record when Java 14 is introduced.
record
is a brand new type. It is essentially a final
class. At the same time, all attributes are final
. It will automatically compile public get
hashcode
, equals
, toString
etc., which reduces the amount of code writing.
Example: Write a Dog record class and define the name and age attributes.
package com.wdbyte;
public record Dog(String name, Integer age) {
}
Use of Record.
package com.wdbyte;
public class Java14Record {
public static void main(String[] args) {
Dog dog1 = new Dog("牧羊犬", 1);
Dog dog2 = new Dog("田园犬", 2);
Dog dog3 = new Dog("哈士奇", 3);
System.out.println(dog1);
System.out.println(dog2);
System.out.println(dog3);
}
}
Output result:
Dog[name=牧羊犬, age=1]
Dog[name=田园犬, age=2]
Dog[name=哈士奇, age=3]
This feature was previewed twice in Java 15 and officially released in Java 16.
15. JEP 396: Strongly encapsulate JDK internals by default
Java 9 JEP 261 introduced --illegal-access
control internal API access and JDK packaging options.
This JEP --illegal-access
option from allow to deny. With this change, JDK internal packages and APIs ( key internal API ) will no longer be opened by default.
The motivation of the JEP is to prevent third-party libraries, frameworks, and tools from using the internal APIs and packages of the JDK to increase security.
16. JEP 397: Sealed Classes preview
Sealed Classes is previewed again. The related functions have been introduced in the Java 15 new feature introduction article, and detailed usage demonstrations are given, so the introduction will not be repeated here.
Here is a quote:
We all know that if we want a class to be inherited and modified in Java, then we should use the final
keyword to modify the class. However, this mechanism of either inheritance or non-inheritance is not flexible enough. Sometimes we may want a certain class to be inherited by certain types, but it cannot be inherited at will. This is impossible. Java 15 tries to solve this problem by introducing the sealed
class, and sealed
can specify a subclass. In this way, this class can only be inherited by the specified class.
Moreover sealed
is transitive, and its subclasses must be modified with specified keywords, and can only be one of final
, sealed
, non-sealed
.
Extended reading: Java 15 new feature introduction
refer to
<end>
Hello world:) I am Alang, a first-line technical tool person, and write articles seriously.
1617f351e40ef5 likes likes 1617f351e40ef6 is a talent.
The article is continuously updated, and you can follow the public Program " or visit "Program Blog] (1617f351e40f84 https://www.wdbyte.com) ".
Reply [Information] There are various series of knowledge points and must-read books I prepared.
This article Github.com/niumoo/JavaNotes has been included, there are many knowledge points and series of articles, welcome to Star.
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。