Original | Java 13 will be released tomorrow, interpretation of the latest and newest features

Original | Java 13 will be released tomorrow, interpretation of the latest and newest features

△Hollis, a person with a unique pursuit of Coding△
Original | Java 13 will be released tomorrow, interpretation of the latest and newest features
This is Hollis’s 229th original sharing

Author l Hollis
Source l Hollis (ID: hollischuang)

In August 2017, the JCP Executive Committee proposed to change the release frequency of Java to once every six months. The new release cycle strictly follows the time point and will be released in March and September each year.
Currently, the progress of JDK 13 can be seen on the JDK official website. The latest version of JDK 13 will be released on September 17, 2019.
Original | Java 13 will be released tomorrow, interpretation of the latest and newest features

Currently, JDK13 is in the Release-Candidate Phase and will be officially released on September 17. At present, the features included in this version have all been fixed, mainly including the following five:

JEP 350, Dynamic CDS Archives
JEP 351, ZGC: Uncommit Unused Memory
JEP 353, Reimplement the Legacy Socket API
JEP 354: Switch Expressions (Preview)
JEP 355, Text Blocks (Preview)
Let’s introduce these five important features one by one.

1、Dynamic CDS Archives

This feature is extended on the basis of JEP310: Application Class-Data Sharing. The CDS in Dynamic CDS Archives refers to Class-Data Sharing.

So, what is this JEP310?

We know that when multiple JVMs are started on the same physical machine/virtual machine, if each virtual machine individually loads all the classes it needs, the startup cost and memory usage are relatively high. So the Java team introduced the concept of CDS. By sharing some core classes between each JVM, each JVM only needs to load its own application classes, which reduces the startup time. In addition, the core classes are shared, so the JVM's memory footprint is also decreased.

CDS can only act on classes loaded by Boot Class Loader, and cannot act on classes loaded by App Class Loader or custom Class Loader.

In Java 10, CDS is extended to AppCDS. As the name suggests, AppCDS can not only act on Boot Class Loader, but also App Class Loader and custom Class Loader, which greatly increases the scope of application of CDS. In other words, developing custom classes can also be loaded and shared by multiple JVMs.

The JEP310 included in Java 10 reduces memory footprint and improves startup time by sharing common class metadata across different Java processes.

However, in JEP310, the process of using AppCDS is still more complicated and requires three steps:

1、决定要 Dump 哪些 Class
2、将类的内存 Dump 到归档文件中
3、使用 Dump 出来的归档文件加快应用启动速度

This time, JEP 350 in JDK 13 has made some extensions on the basis of JEP310. It is allowed to dynamically archive classes at the end of the Java application execution. The archive classes will include all loaded application classes and library classes that do not exist in the default base layer CDS (class data-sharing) archive.

In other words, when AppCDS is used in Java 13, it is not so complicated.

2、ZGC: Uncommit Unused Memory

Before discussing this issue, I would like to ask a question. Will the memory released by the JVM GC be returned to the operating system?

How to dispose of memory after GC actually depends on different garbage collectors. Because returning the memory to the OS means adjusting the heap size of the JVM, this process is more resource intensive.

In JDK 11, Java introduced ZGC, a scalable low-latency garbage collector, but it was only experimental at the time. Moreover, the memory released by ZGC will not be returned to the operating system.
Original | Java 13 will be released tomorrow, interpretation of the latest and newest features

In Java 13, JEP 351 has once again enhanced ZGC, this time ZGC can return unused heap memory to the operating system. This feature was introduced because memory is a relatively expensive resource in many scenarios today. In the following situations, it is still necessary to return memory to the operating system:

  • 1. Containers that need to be paid based on usage
  • 2. An environment where applications may be idle for a long time and share or compete for resources with many other applications.
  • 3. The application may have very different heap space requirements during execution. For example, the heap needed during startup may be larger than the heap needed later during steady state execution.

3、Reimplement the Legacy Socket API

Replace the java.net.Socket and java.net.ServerSocket APIs with simpler and more modern implementations that are easy to maintain and debug.
The implementation of java.net.Socket and java.net.ServerSocket is very old, this JEP introduces a modern implementation for them. The modern implementation is the default implementation in Java 13, but the old implementation has not been deleted yet, you can use them by setting the system property jdk.net.usePlainSocketImpl.
Running a class that instantiates Socket and ServerSocket will display this debug output. This is the default (new):

java -XX:+TraceClassLoading JEP353  | grep Socket
[0.033s][info   ][class,load] java.net.Socket source: jrt:/java.base
[0.035s][info   ][class,load] java.net.SocketOptions source: jrt:/java.base
[0.035s][info   ][class,load] java.net.SocketImpl source: jrt:/java.base
[0.039s][info   ][class,load] java.net.SocketImpl$$Lambda$1/0x0000000800b50840 source: java.net.SocketImpl
[0.042s][info   ][class,load] sun.net.PlatformSocketImpl source: jrt:/java.base
[0.042s][info   ][class,load] sun.nio.ch.NioSocketImpl source: jrt:/java.base
[0.043s][info   ][class,load] sun.nio.ch.SocketDispatcher source: jrt:/java.base
[0.044s][info   ][class,load] java.net.DelegatingSocketImpl source: jrt:/java.base
[0.044s][info   ][class,load] java.net.SocksSocketImpl source: jrt:/java.base
[0.044s][info   ][class,load] java.net.ServerSocket source: jrt:/java.base
[0.045s][info   ][class,load] jdk.internal.access.JavaNetSocketAccess source: jrt:/java.base
[0.045s][info   ][class,load] java.net.ServerSocket$1 source: jrt:/java.base

The sun.nio.ch.NioSocketImpl output above is the newly provided implementation.
If you use the old implementation is also possible (specify the parameter jdk.net.usePlainSocketImpl):

$ java -Djdk.net.usePlainSocketImpl -XX:+TraceClassLoading JEP353  | grep Socket
[0.037s][info   ][class,load] java.net.Socket source: jrt:/java.base
[0.039s][info   ][class,load] java.net.SocketOptions source: jrt:/java.base
[0.039s][info   ][class,load] java.net.SocketImpl source: jrt:/java.base
[0.043s][info   ][class,load] java.net.SocketImpl$$Lambda$1/0x0000000800b50840 source: java.net.SocketImpl
[0.046s][info   ][class,load] sun.net.PlatformSocketImpl source: jrt:/java.base
[0.047s][info   ][class,load] java.net.AbstractPlainSocketImpl source: jrt:/java.base
[0.047s][info   ][class,load] java.net.PlainSocketImpl source: jrt:/java.base
[0.047s][info   ][class,load] java.net.AbstractPlainSocketImpl$1 source: jrt:/java.base
[0.047s][info   ][class,load] sun.net.ext.ExtendedSocketOptions source: jrt:/java.base
[0.047s][info   ][class,load] jdk.net.ExtendedSocketOptions source: jrt:/jdk.net
[0.047s][info   ][class,load] java.net.SocketOption source: jrt:/java.base
[0.047s][info   ][class,load] jdk.net.ExtendedSocketOptions$ExtSocketOption source: jrt:/jdk.net
[0.047s][info   ][class,load] jdk.net.SocketFlow source: jrt:/jdk.net
[0.047s][info   ][class,load] jdk.net.ExtendedSocketOptions$PlatformSocketOptions source: jrt:/jdk.net
[0.047s][info   ][class,load] jdk.net.ExtendedSocketOptions$PlatformSocketOptions$1 source: jrt:/jdk.net
[0.048s][info   ][class,load] jdk.net.LinuxSocketOptions source: jrt:/jdk.net
[0.048s][info   ][class,load] jdk.net.LinuxSocketOptions$$Lambda$2/0x0000000800b51040 source: jdk.net.LinuxSocketOptions
[0.049s][info   ][class,load] jdk.net.ExtendedSocketOptions$1 source: jrt:/jdk.net
[0.049s][info   ][class,load] java.net.StandardSocketOptions source: jrt:/java.base
[0.049s][info   ][class,load] java.net.StandardSocketOptions$StdSocketOption source: jrt:/java.base
[0.051s][info   ][class,load] sun.net.ext.ExtendedSocketOptions$$Lambda$3/0x0000000800b51440 source: sun.net.ext.ExtendedSocketOptions
[0.057s][info   ][class,load] java.net.DelegatingSocketImpl source: jrt:/java.base
[0.057s][info   ][class,load] java.net.SocksSocketImpl source: jrt:/java.base
[0.058s][info   ][class,load] java.net.ServerSocket source: jrt:/java.base
[0.058s][info   ][class,load] jdk.internal.access.JavaNetSocketAccess source: jrt:/java.base
[0.058s][info   ][class,load] java.net.ServerSocket$1 source: jrt:/java.base

In the above results, the old implementation java.net.PlainSocketImpl was used.

4、Switch Expressions (Preview)

Switch expressions were introduced as a preview feature in JDK 12. JEP 354 modified this feature by introducing a yield statement to return values. This means that the switch expression (return value) should use yield, and the switch statement (not return value) should use break.
In the past, it was more troublesome for us to return content in switch. The general syntax is as follows:

int i;
switch (x) {
    case "1":
        i=1;
        break;
    case "2":
        i=2;
        break;
    default:
        i = x.length();
        break;
}

The following syntax is used in JDK13:

int i = switch (x) {
    case "1" -> 1;
    case "2" -> 2;
    default -> {
        int len = args[1].length();
        yield len;
    }
};

or

int i = switch (x) {
    case "1": yield 1;
    case "2": yield 2;
    default: {
        int len = args[1].length();
        yield len;
    }
};

After this, there is one more keyword in switch to jump out of the switch block, that is, yield, which is used to return a value. The difference with return is that return will jump out of the current loop or method directly, while yield will only jump out of the current switch block.

5、Text Blocks (Preview)

The Raw String Literals feature was introduced in JDK 12, but it was abandoned before release. This JEP is similar in the sense of introducing multi-line string literals (text block).
A text block, a text block, is a multi-line string literal, which avoids the need for most escape sequences, automatically formats the string in a predictable manner, and lets the developer control the format when needed.
We used to copy a text string from outside to Java, it will be automatically escaped, such as the following string:

<html>
  <body>
      <p>Hello, Hollis</p>
  </body>
</html>

Copy it to the Java string, it will show the following content:

"<html>\n" +
"    <body>\n" +
"        <p>Hello, Hollis</p>\n" +
"    </body>\n" +
"</html>\n";

That is, it is automatically escaped. Such a string does not look very intuitive. In JDK 13, the following syntax can be used:

"""
<html>
  <body>
      <p>Hello, Hollis</p>
  </body>
</html>
""";

Use """ as the beginning of the text block to match the ending character, and you can place multi-line strings in it without any escaping. It looks very refreshing. For
example, common SQL statements:

String query = """
    SELECT `EMP_ID`, `LAST_NAME` FROM `EMPLOYEE_TB`
    WHERE `CITY` = 'INDIANAPOLIS'
    ORDER BY `EMP_ID`, `LAST_NAME`;
""";

It looks more intuitive and refreshing.

6. Summary

The above are the five features included in JDK13. The two new features that can change the coding style of developers are mainly Text Blocks and Switch Expressions, but these two features are still in the preview stage.
Moreover, JDK13 is not an LTS (long-term support) version. If you are using Java 8 (LTS) or Java 11 (LTS), you do not need to upgrade to Java 13 for the time being.
Original | Java 13 will be released tomorrow, interpretation of the latest and newest features

Reference materials:
https://openjdk.java.net/projects/jdk/13/
https://metebalci.com/blog/what-is-new-in-java-13/
https://www.jianshu.com /p/890196bf529a

Dynamic black notes

The series of articles
on the road to becoming a god of Java engineers are in the GitHub update, welcome to follow, welcome to star.
Original | Java 13 will be released tomorrow, interpretation of the latest and newest features
Facing Java Issue 262: How does volatile solve the problem of order?
In-depth Concurrency Issue No. 009: What is the Java memory model?

  • MORE | More exciting articles-
  • Stop writing code with Else statements!
  • How to identify second-force Internet companies! ?
  • Make your IDEA easy to use to fly configuration
  • Programmers use Internet cafes to mine and earn hundreds of millions of dollars~!

If you like this article,
please press
Original | Java 13 will be released tomorrow, interpretation of the latest and newest features
and hold the QR code and follow Hollis. Forward it to the circle of friends. This is my greatest support.
Good article, I am reading ❤️

Guess you like

Origin blog.51cto.com/13626762/2544321