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 it for bug fixes, patches and performance enhancements for the next few years.
Spring 6 and Spring boot 3 will have first-class support for Java 17. So it is a good idea to plan for upgrading to Java 17.
We can download Java 17 from this link.
1. List of JEPs in Java 17The below listed 14 JEPs are part of Java 17.
Let us talk about which JEPs directly impact the work that developers do every day.
2.1. Restore Always-Strict Floating-Point SemanticsThis JEP is targeted toward scientific calculations that involve floating-point numbers. To guarantee the same calculation result on all platforms, we have been using the keyword strictfp.
The strictfp modifier accomplishes this by representing all intermediate values as IEEE single-precision and double-precision values. However, due to hardware heating issues, it became optional in JDK 1.2.
Today, as the hardwares has evolved and those heating issues are fixed, default floating-point semantics have been changed to consistently strict.
2.2. Pattern Matching for Switch (Preview)With this change, we do not need to use
strictfpkeyword, anymore.
This change adds pattern matching for switch statements and expressions. Since this is a preview feature, we need to use ‘–enable-preview‘ option to enable it.
2.2.1. No explicitnull checks are needed
Traditional switch statements throw NullPointerException if the selector expression evaluates to null. With this change, we can check for such null expressions as the separate case itself.
if (s == null) {
System.out.println("oops!");
return;
}
switch (s) {
case "Foo", "Bar" -> System.out.println("Great");
default -> System.out.println("Ok");
}switch (s) {
case null -> System.out.println("Oops");
case "Foo", "Bar" -> System.out.println("Great");
default -> System.out.println("Ok");
}instanceof checking
Before Java 16, if we had to write a code that checks the instance type and performed some logic, it was the way:
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)
}In Java 16, we can write the above expression in a much 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)
}Java 17 takes it to the next level with switch expression. 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();
}2.3. Sealed ClassesWhile the above changes have been made, it has been ensured that all of the old switch expressions must continue to work. You can see all the changes to
switchexpressions in the JEP webpage.
In Java, by default, there has been no restriction on a class which public interfaces it can implement. From Java 15, we can declare a class or interface sealed class or sealed interface using the modifier ‘sealed‘.
Sealed classes and interfaces restrict which other classes or interfaces may extend or implement them.
public sealed class Account
permits CurrentAccount, SavingAccount, LoanAccount {
}It was a preview feature in Java 15 and Java 16. In Java 17, it has become a standard feature with no changes to what was available in Java 16.
2.4. Enhanced Pseudo-Random Number Generators 2.4.1. RandomGeneratorRead More : Sealed Classes and Interfaces
This JEP introduced a new interface called RandomGenerator which aims to make future pseudorandom number generator (PRNG) algorithms easier to implement or use.
With the legacy PRNG classes Random, ThreadLocalRandom, and SplittableRandom, it is difficult to replace any of them in an application with some other algorithm because they do not have any supertype to support runtime changes.
With the introduction of RandomGenerator interface, we can inject any implementing generator class where the client uses RandomGenerator type in the application code. The new classes are:
Also, legacy random classes, such as Java.util.Random, SplittableRandom, ThreadLocalRandom and SecureRandom now extend the new RandomGenerator interface.
2.4.2. RandomGeneratorFactoryThe RandomGeneratorFactory provides methods for selecting random number generator algorithms. We can choose a particular algorithm by its name and use it for generating random numbers.
The default algorithm is L32X64MixRandom. Following is the list of all supported algorithms:
The Legecy group represents the old PRNGs. Please note that none of the new implementations are thread-safe while both Java.util.Random and Java.security.SecureRandom are.
RandomGeneratorFactory factory = RandomGeneratorFactory.of("SecureRandom")
RandomGenerator random = factory.create(200L);
//get random numbers
randomGenerator.nextDouble();Most of the web browsers have already removed the support for Applets due to security concerns. In Java 9, Applet API was marked deprecated.
Since it has become irrelevant today, Java 17 has marked it for removal.
2.6. Strongly Encapsulate JDK InternalsThis JEP strongly encapsulates all internal elements of the JDK, except for critical internal APIs such as sun.misc.Unsafe.
From Java 9 to Java 16, developers were able to access the JDK internal APIs using the flag –illegal-access. Java 17 will ignore the flag, and if the flag is present.
The console will display a message informing the discontinuation of the flag.
2.7. Remove RMI ActivationRemove the Remote Method Invocation (RMI) Activation mechanism while preserving the rest of RMI. It is obsolete and has been deprecated in Java 15.
2.8. Remove the Experimental AOT and JIT CompilerThis JEP removes the experimental Java-based ahead-of-time (AOT) and just-in-time (JIT) compiler introduced in Java 9 and Java 10.
The Graal compiler was made available as an experimental JIT compiler in JDK 10 via JEP 317. Since they were introduced, there was little use of these experimental features, and the effort required to maintain and enhance them was significant.
The developers can still leverage these features using GraalVM.
3. ConclusionJava 17 has lots of exciting features and a long road of support and commitment. It removes many of the already deprecated APIs from Java.
There is significantly less chance to find any applications which are still using those deprecated features, still, developers must be careful to thoroughly check the application code and dependencies before migrating to Java 17.
As Java 17 is an LTS release, and major popular frameworks (e.g., Spring 6 and Spring Boot 3) will be supporting the new features, it is better to plan for Java 17 migration.
Happy Learning !!
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4