“This is the 14th day of my participation in the Gwen Challenge in November. Check out the details: The Last Gwen Challenge in 2021.”

Introduction to the

In September 2021, JDK17 was released, which is the latest LTS release. An LTS release is one that has at least eight years of product support. From JDK8 in 2014 to JDK11 in 2018 to JDK17 in 2021.

Oracle has also changed the LTS release age from three years to two years, which means the next LTS release will be JDK21. Wow!

What if it’s not the LTS version? The non-LTS version will only have six months of production support. So let’s stick with the LTS version.

Let’s take a look at some of the new features in JDK17.

New features in JDK17

In total, JDK17 provides 14 optimization points or changes. We’ll go through them all.

New features in the language

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

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

public sealed class SealExample permits Seal1, Seal2{
}

public non-sealed class Seal1 extends SealExample {
}

public final class Seal2 extends SealExample {
}
Copy the code

Final means Seal2 can no longer be inherited. Non-sealed: allows inheritance of any class.

Core library optimization

There are four optimizations for the JAVA core library in JDK17.

  • JEP 306: Restore alights-strict floating-point Semantics

What is this? To put it simply, the previous hardware architecture consumed a lot of resources when it came to strictly performing floating-point semantic calculations. This would have been intolerable long ago, when hardware was not at a high level.

So after JDK1.2, the floating-point semantics were tweaked to modify the default strict floating-point semantics.

But now that it’s 2021, the hardware level has moved at a rapid pace, so the changes introduced earlier are no longer necessary and will be scrapped in JDK17.

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

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

JDK17 enhances this class by providing a RandomGenerator interface that provides a uniform 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.

RandomGenerator interface includes 4 subinterfaces, respectively:

SplittableRandomGenerator: provides the method of the split and splits, allowing users to generate from the existing RandomGenerator a new RandomGenerator.

JumpableRandomGenerator: Extends RandomGenerator’s jump and jump methods to allow the user to skip a certain number of random numbers.

LeapableRandomGenerator: a method that extends Leap and LEAPS of RandomGenerator, allowing the user to skip over large numbers of random numbers.

ArbitrouslyJumpableRandomGenerator: expanded the LeapableRandomGenerator, allowing the user to specify skip random number.

Random, ThreadLocalRandom, SplittableRandom and other classes are also reconstructed.

  • The third is JEP 382: New macOS Rendering Pipeline

This is optimized for Mac and uses the latest Apple Metal API for JAVA 2D rendering.

  • Fourth, JEP 415: Context-Specific Deserialization Filters

One of the most dangerous uses of the JDK is deserialization, because you don’t know if a deserialized object is a dangerous object or not. To address this issue, deserialization filters were introduced in Java 9 to validate the data stream before deserialization.

However, this stream-based filter has several limitations; it is not scalable and it is difficult to update the filter after the code is published. It also does not filter deserialization operations performed by third-party libraries in the application.

To address these issues, JEP 290 also introduces a JVM-wide deserialization filter that can be set through apis, system properties, or security properties. However, such static filters are often not suitable for complex applications with multiple execution contexts, because different contexts may require different filtering conditions.

JDK17 improves the filtering approach of JDK9 to allow jVM-wide configuration of context-specific deserialization filters.

Support for new platforms

  • JEP 391: macOS AArch 64 Port

Mac M1 chips have been around for a long time, and there’s no reason why the JDK can’t support them. This JEP is designed to make JDK17 work with Apple’s new Arm 64 architecture.

The preview feature

  • JEP 406: Pattern Matching for switch (Preview)

This new feature allows pattern matching in Switch.

We know that pattern matching already exists in the preview function, but pattern matching is used in instance of statements like this:

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

But too much instanceof can cause problems:

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;
}
Copy the code

The best way to do this is to convert the above code to 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();
    };
}
Copy the code

This is pattern matching in switch.

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

In JDK14 and 15, the JDK can already call code that is not part of the JVM and access memory that is not part of the JVM. This new feature is enhanced in JDK17.

Wouldn’t it be amazing if the JDK could natively support apis that call non-Java languages?

  • JEP 414: Vector API (Second Incubator)

Vector was introduced in JDK16. I can make vector computations faster. The computation of loop traversal can be simplified by using Vector.

Other changes

Other changes, such as encapsulating the API used internally in the JDK, deprecating the Security Manager,Applet API, and RMI, will not be covered here.

conclusion

JDK17 is an LTS version with a lot of great new features.

This article is available at www.flydean.com/27-jdk17-ne…

The most popular interpretation, the most profound dry goods, the most concise tutorial, many tips you didn’t know waiting for you to discover!

Welcome to pay attention to my public number: “procedures those things”, understand technology, more understand you!