Still, the iPhone 13 isn’t exactly 13, and Cook is squeezing out toothpaste updates as usual.

In contrast, I think JDK 17 is more interesting. In addition to the new features, Oracle has officially announced that JDK 17 is now available for free.

Oracle JDK 17 and future JDK releases are available under a free use license for a full year until the next LTS release.

What does LTS mean? Long-term Support is a version of long-term Support, which is different from interim versions 16, 15, 14, 13, and 12.

JDK 6, JDK 8, and JDK 11 are the three most commonly used releases in production. Will JDK 17 be next?

This chart shows the timeline of Oracle JDK support. As you can see, JDK 17 will be supported for up to 8 years until September 2029!

According to the speed of technology update and iteration, 8 years is really a long time!

Given the nature of Oracle’s urine, the 8-year free release was a good one to encourage users to feel free to upgrade to JDK 17.

However, it looks like JDK 8 will support a longer time frame, with an extension to December 2030. It seems that I have discovered some truth: he is strong, he is strong, I use Java 8!

Recommend GitHub’s open source Java Programmer’s Path to progress column! Humorous, easy to understand, extremely friendly and comfortable for Java beginners 😘, including but not limited to Java syntax, Java collection framework, Java IO, Java concurrent programming, Java virtual machine and other core knowledge points.

GitHub address: github.com/itwanger/to…

Prior to JDK 17, LTS releases were released every three years: 11 in 2018, 8 in 2014, and 7 in 2011.

After that, Oracle plans to release future LTS releases every two years, meaning that the next LTS release, JDK 21, will be released in September 2023.

The speed of technology update iteration is fast again!

It’s important to note that non-long-lived versions should never be used in production, but they can be used as learning objects.

JDK 17 offers 14 JEP Enhancement Proposals, which we’ll look at here!

features instructions
306:Restore Always-Strict Floating-Point Semantics Restore floating-point definitions that always enforce strict patterns
356:Enhanced Pseudo-Random Number Generators Enhanced pseudo-random number generator
382:New macOS Rendering Pipeline New macOS rendering pipeline
391:macOS/AArch64 Port MacOS AArch64 port
398:Deprecate the Applet API for Removal Deprecated Applet API
403:Strongly Encapsulate JDK Internals JDK internal strong encapsulation
406:Pattern Matching for switch (Preview) Supports pattern matching for the Switch
407:Remove RMI Activation Remove RMI activation
409:Sealed Classes Seal type
410:Remove the Experimental AOT and JIT Compiler Removed experimental AOT and JIT compilers
411:Deprecate the Security Manager for Removal Deprecate the security manager
412:Foreign Function & Memory API (Incubator) External functions and memory apis (incubating)
414:Vector API (Second Incubator) Vector API (secondary incubation)
415:Context-Specific Deserialization Filters Context-specific deserialization filters

Java Language Enhancements

JEP 409: Sealed classes, sealed classes and interfaces that can restrict other classes or interfaces from extending or implementing them.

public abstract sealed class Shape permits Circle{}Copy the code

The Shape class is decorated with the keyword sealed, indicating that it is a sealed class. The enclosing class must specify which class it is inherited from, such as Circle:

public final class Circle extends Shape {}Copy the code

The Circle class must be decorated with the final keyword to indicate that it can no longer be inherited by other classes.

This sealed class is interesting, I only allow who who who inheritance, a little bit of designated inheritance inside flavor.

Library updates and improvements

JEP 306: Restore floating point definitions that always enforce strict mode. Java originally only had strict floating-point semantics, but since JDK 1.2, subtle variations in these strict semantics were allowed by default to accommodate the limitations of the hardware architecture at the time, which are now unnecessary.

JEP 356: Enhanced pseudo-random number generator. Provides new interface types and implementations for pseudo-random number generators (PRNG).

JEP 382: New macOS rendering pipeline. Java 2D rendering pipes are implemented for macOS using Apple Metal apis. The new pipeline reduces the JDK’s reliance on the deprecated Apple OpenGL API.

New Platform support

JEP 391: macOS AArch64 port. This port allows Java applications to run on the new Arm 64-based Apple Silicon computers.

Delete and discard

JEP 398: Deprecating the Applet API. An Applet is a Java program that runs in a Web browser and has long since become obsolete, making it necessary to remove it.

JEP 407: Removed the remote method call (RMI) activation mechanism.

JEP 410: Removed experimental AOT and JIT compilers. These two experimental features are not widely used and are removed to save maintenance.

JEP 411: Deprecating security manager. The security manager dates back to Java 1.0, but has not protected well over the years, removing the worry.

Java programs for the future

JEP 403: Strong internal JDK encapsulation that restricts external access to JDK internal classes. This change makes applications more secure and reduces reliance on non-standard, internal JDK implementation details.

Preview and incubator for subsequent JDK releases

JEP 406: Mode matching is supported for the Switch.

We wanted to compare one variable O to multiple alternatives, but the previous switch didn’t support pattern matching using Instanceof, so we had to use if-else.

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

JDK 17 provides support for switch statements based on pattern matching:

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

Write like this is not instant tall on many, comfortable.

JEP 412: External functions and memory API (incubator). By effectively calling external functions (code outside the JVM) and securely accessing external memory, this enables Java programs to call the local library and process native data without the vulnerability and complexity of the Java Native Interface (JNI).

JEP 414: Vector API (second incubator). The Vector API was introduced by JEP 338 and integrated into Java 16 as an incubation API.

The Vector API aims to improve the predictability and robustness of vectorized computations by providing a way to write complex Vector algorithms in Java. Many areas can benefit from this explicit vector API, including machine learning, linear algebra, cryptography, finance, and code for the JDK itself.

The official link: www.oracle.com/news/announ…

To be honest, JDK updates are happening faster than they used to, but developers are still stuck with JDK 8 or even JDK 6.

Not many people are actively upgrading to JDK 11, especially after Oracle started charging for it commercially.

Whether due to open source or free pressure, JDK 17 has been declared free for commercial use and intends to remain so in future releases.

This is a jar of honey for users, up to 8 years of support, maybe you will want to upgrade to JDK 17!

What do you think?

I am the second brother, and there is nothing to hold me but purpose, and though there are roses and shade and still harbor by the shore, I am not tied.