The third LTS version of JDK JDK17 is here

Introduction

JDK17 was released in September 2021. JDK17 is the latest LTS version. The so-called LTS version is the version that can get at least eight years of product support. From JDK8 in 2014, to JDK11 in 2018, to JDK17 in 2021.

At the same time, Oracle has also adjusted the release period of the LTS version, from the previous three years to the current two years, which means that the next LTS version will be JDK21, wow!

So what if it is not the LTS version? The non-LTS version will only receive six months of product support. So everyone should use the LTS version.

Well, let's take a look at the new features in JDK17.

New features in JDK17

In general, JDK17 provides 14 optimization points or change points. We will explain them one by one.

New features in language

The only new language feature of JDK17 is JEP 409: Sealed Classes.

Sealed Classes is a concept introduced in JDK15, which indicates which classes are allowed to inherit from a certain class:

public sealed class SealExample permits Seal1, Seal2{
}

public non-sealed class Seal1 extends SealExample {
}

public final class Seal2 extends SealExample {
}

final means that Seal2 can no longer be inherited. Non-sealed means that any class inheritance can be allowed.

Optimization of the core library

JDK17 has 4 optimizations to the JAVA core library.

• The first one is: JEP 306: Restore Always-Strict Floating-Point Semantics

What is this? To put it simply, the previous hardware architecture consumes a lot of resources when performing calculations with strict floating-point semantics. This was intolerable when the hardware level was not high a long time ago.

So after JDK1.2, the floating-point semantics have been fine-tuned, and the default strict floating-point semantics have been modified.

But now it is 2021, and the hardware level has been developing rapidly, so the modification introduced before is no longer necessary and was abandoned in JDK17.

• The second one is: JEP 356: Enhanced Pseudo-Random Number Generator

There is a class java.util.Random that specifically generates random numbers in the JDK, but this class generates pseudo-random numbers.

JDK17 has enhanced this class, providing a RandomGenerator interface to provide a unified API for all pseudo-random numbers.

RandomGenerators provides methods such as ints, longs, doubles, nextBoolean, nextInt, nextLong, nextDouble and nextFloat to generate corresponding random numbers.

The RandomGenerator interface includes 4 sub-interfaces, namely:

SplittableRandomGenerator: Provides split and splits methods, allowing users to generate a new RandomGenerator from an existing RandomGenerator.

JumpableRandomGenerator: Expands the jump and jumps methods of RandomGenerator, allowing users to skip a certain number of random numbers.

LeapableRandomGenerator: Expands the leap and leaps methods of RandomGenerator, allowing users to skip a large number of random numbers.

ArbitrouslyJumpableRandomGenerator: Extends LeapableRandomGenerator, allowing users to specify random numbers to skip.

At the same time, classes such as Random, ThreadLocalRandom and SplittableRandom have been refactored.

• The third is JEP 382: New macOS Rendering Pipeline

This is optimized specifically for Mac, using the latest Apple Metal API to achieve 2D rendering of JAVA.

• The fourth is JEP 415: Context-Specific Deserialization Filters

A very dangerous usage in JDK is deserialization, because you don’t know whether the deserialized object is a dangerous object. In order to solve this problem, a deserialization filter was introduced in Java 9 to perform deserialization. Verify the data flow before conversion.

However, this stream-based filter has several limitations. This method cannot be extended, and it is difficult to update the filter after the code is released. It also cannot filter the deserialization operations performed by third-party libraries in the application.

To solve these problems, JEP 290 also introduces a JVM-scope deserialization filter, which can be set through API, system properties, or security properties. However, this kind of static filter is often not suitable for complex applications with multiple execution contexts, because different contexts may require different filter conditions.

JDK17 improves the filtering method of JDK9, and you can configure context-specific deserialization filters in the JVM scope.

Support new platforms

• JEP 391: macOS AArch 64 Port

The Mac M1 chip has been released for a long time, and there is no reason why JDK does not support it. This JEP is to let JDK17 support the native Apple’s new Arm 64 architecture.

Preview features

• JEP 406: Pattern Matching for switch (Preview)

This new feature allows pattern matching in the switch.

We know that in the previous preview function, there is already pattern matching, but pattern matching is used in the instance of statement, as shown below:

// Old code
if (o instanceof String) {
    String s = (String)o;
    ... use s ...
}

// New code
if (o instanceof String s) {
    ... use s ...
}

But if instanceof is too much, it will also cause trouble:

static String formatter(Object o) {
    String formatted = "unknown";
    if (o instanceof Integer i) {
        formatted = String.format("int %d", i);
    } else if (o instanceof Long l) {
        formatted = String.format("long %d", l);
    } else if (o instanceof Double d) {
        formatted = String.format("double %f", d);
    } else if (o instanceof String s) {
        formatted = String.format("String %s", s);
    }
    return formatted;
}

The best way is to convert the above code into a switch:

static String formatterPatternSwitch(Object o) {
    return switch (o) {
        case Integer i -> String.format("int %d", i);
        case Long l    -> String.format("long %d", l);
        case Double d  -> String.format("double %f", d);
        case String s  -> String.format("String %s", s);
        default        -> o.toString();
    };
}

This is the pattern matching in switch.

• JEP 412: Foreign Function and Memory API (Incubator)

In JDK14 and 15, the JDK can already call code that does not belong to the JVM and access the memory space that is not under the jurisdiction of the JVM. This new feature has been enhanced in JDK17.

Imagine that in the future, JDK can natively support calling APIs in non-Java languages. Isn't it great?

• JEP 414: Vector API (Second Incubator)

Vector was introduced in JDK16. Can make vector calculation faster. The calculation of loop traversal can be simplified with Vector.

Other changes

Some other changes such as encapsulation of the API used inside the JDK, the abandonment of Security Manager, Applet API and RMI, etc., will not be introduced here.

Summarize

JDK17 is an LTS version, and it also provides a lot of excellent new features, so I don’t have to use it!

This article has been included in http://www.flydean.com/27-jdk17-new-features/

The most popular interpretation, the most profound dry goods, the most concise tutorial, and many tips you don't know are waiting for you to discover!

Welcome to pay attention to my official account: "Program those things", know technology, know you better!