Java 17 features and enhancements

Java 17 was released on September 14, 2021. Java 17 is an LTS (long term support) release, like Java 11 and Java 8. Oracle will support bug fixes, patches and performance improvements over the next few years.

Spring 6 and Spring Boot 3 will have first-class support for Java 17. Therefore, it is a good idea to plan to upgrade to Java 17.

We can download Java 17 from this link *.

2. Java 17 functionality for developers

Let’s talk about which Jeps directly affect the day-to-day work of developers.

2.1. Restore always strict floating point semantics

This JEP is for scientific calculations involving floating point numbers. To ensure the same results on all platforms, we have been using the keyword strictfp.

* StrictFP * The modifier accomplishes this by representing all intermediate values as IEEE single-precision and double-precision values. But it became optional in JDK 1.2 due to hardware heating issues.

Today, as hardware has evolved and these hot issues have been resolved, the default floating-point semantics have been changed to consistently strict.

With this change, we no longer need to use strictFP keywords.

2.2. Switch pattern matching (preview)

This change increases pattern matching for switch statements and expressions. Since this is a preview feature, we need to enable it using the **-enable-preview** option.

2.2.1. It does not need to be explicitnullcheck

The traditional Switch statement throws a NullPointerException if the selector expression evaluates to NULL. With this change, we can examine this empty expression as a separate case by itself.

if (s == null) {
    System.out.println("oops!");
    return;
}
switch (s) {
    case "Foo"."Bar" -> System.out.println("Great");
    default           -> System.out.println("Ok");
}
Copy the code

switch (s) {
    case null         -> System.out.println("Oops");
    case "Foo"."Bar" -> System.out.println("Great");
    default           -> System.out.println("Ok");
}
Copy the code

2.2.2. Improvedinstanceofcheck

Before Java 16, if we had to write a piece of code to check the instance type and perform some logic, this was the method.

Object o;
if (o instanceof String) 
{
    String s = (String) o;
    String.format("String %s", s)
} 
else if (o instanceof Integer) 
{
    Integer i = (Integer) o; 
    String.format("int %d", i)
} 
else if (o instanceof Double) 
{
    Double d = (Double) o;
    String.format("double %f", d)
}
Copy the code

In Java 16, we can write the above expressions in a simpler way.

Object o;
if (o instanceof String s) 
{
    String.format("String %s", s)
} 
else if (o instanceof Integer i) 
{
    String.format("int %d", i)
} 
else if (o instanceof Double d) 
{
    String.format("double %f", d)
}
Copy the code

Java 17 takes it to a new level with switch expressions. Now we can rewrite the above code as.

Object o;
switch (o) 
{
    case Integer i -> String.format("int %d", i);
    case Double d  -> String.format("double %f", d);
    case String s  -> String.format("String %s", s);
    default        -> o.toString();
}
Copy the code

Despite the above changes, you have ensured that all old switch expressions must continue to work. You can see all the changes to the Switch expression on the JEP web page.

2.3. Sealed classes

In Java, by default, there are no restrictions on what public interfaces a class can implement. Starting with Java 15, we can declare a sealed class or interface using the modifier sealed.

Sealed classes and interfaces limit which other classes or interfaces can extend or implement them.

public sealed class Account
    permits CurrentAccount.SavingAccount.LoanAccount {}Copy the code

This is a preview feature in Java 15 and Java 16. It has become a standard feature in Java 17, unchanged from Java 16.

Read more: Sealing classes and interfaces

2.4. Enhanced pseudo-random number generator

2.4.1. Random generator

This JEP introduces a new interface called RandomGenerator, designed to make future pseudo-random number generator (PRNG) algorithms easier to implement or use.

For the traditional PRNG classes Random, ThreadLocalRandom, and SplittableRandom, it is difficult to replace any of them with another algorithm in an application because they do not have any supertypes to support runtime changes.

With the introduction of the RandomGenerator interface, we can inject any implementation generator class in our application code that uses the RandomGenerator type on the client. These new classes are

• SplittableGenerator– Can be split into two objects (original and new), each of which complies with the protocol.
• JumpableGeneratorCan easily jump forward, to a moderate extent.
• Jumpy generatorNot only can he easily jump, but he can also easily jump forward, to a great extent.
• ArbitrarilyJumpableGeneratorIt is easy to jump forward, by an arbitrary amount, to a distant point in the state cycle.
• StreamableGenerator– enhances theRandomGeneratorInterface to provide a returnRandomGeneratorObject flow method.

In addition, traditional Random classes such as java.util. Random, SplittableRandom, ThreadLocalRandom, and SecureRandom now extend the new RandomGenerator interface.

2.4.2. RandomGeneratorFactory

RandomGeneratorFactory provides a way to select random number generator algorithms. We can select a specific algorithm by its name and use it to generate random numbers.

The default algorithm is L32X64MixRandom. Below is a list of all supported algorithms.

• L128X1024MixRandom
• L128X128MixRandom
• L128X256MixRandom
• L32X64MixRandom
• L64X1024MixRandom
• L64X128MixRandom
• L64X128StarStarRandom
• L64X256MixRandom
• Random (legacy)
• Safety random (left behind)
• Separable random (legacy)
• Xoroshiro128PlusPlus
• Xoshiro256Plus

The Legecy group represents the old PRNGs. Please note that these new implementation is not thread-safe, and Java. Util. Random and Java security. SecureRandom are.

RandomGeneratorFactory factory = RandomGeneratorFactory.of("SecureRandom")
RandomGenerator random = factory.create(200L);

//get random numbers
randomGenerator.nextDouble();
Copy the code

2.5. Delete obsolete Applets

Most web browsers have removed support for applets due to security concerns. In Java 9, the Applet API is marked deprecated.

Since it is irrelevant today, Java 17 has marked it for removal.

2.6. Enhance the encapsulation of JDK internal structure

This JEP strongly encapsulates all internal elements of the JDK, with the exception of key internal apis such as Sun.misc.unsafe.

From Java 9 to Java 16, developers can access the JDK’s internal apis using the flag — illegal-Access. Java 17 will ignore this flag if it exists.

The console displays a message informing you of the flag’s deactivation.

2.7. Remove RMI activation

Remove the remote method call (RMI) activation mechanism while preserving the rest of RMI. It is obsolete and deprecated in Java 15.

2.8. Removed experimental AOT and JIT compilers

The JEP removes the experimental Java-based AOT and JUST-in-time (JIT) compilers introduced in Java 9 and Java 10.

The Graal compiler is available as an experimental JIT compiler in JDK 10 through JEP 317. Few people have used these experimental features since they were introduced, and the effort required to maintain and enhance them is important.

Developers can still use GraalVM to take advantage of these features.

3. Summary

Java 17 has a lot of exciting features and a long road of support and promises. It removes many deprecated apis from Java.

The chances of finding any applications that still use these deprecated features are significantly reduced, but developers must be careful to thoroughly examine the application’s code and dependencies before migrating to Java 17.

Since Java 17 is an LTS release, and major popular frameworks such as Spring 6 and Spring Boot 3 will support new capabilities, it is best to plan for Java 17 migration.

Happy study! !