The new features of Java 17 are about to take off? shocked!

Hello everyone, I’m Xiaobian.

It is said that Java 8 is YYDS, so did you notice that Java 17 is also a long-term support version? JDK 19 is currently scheduled to be released in September this year

SpringBoot officially supports Java 17, and Kafka 3.0 deprecates Java 8

Spring Boot 2.5.5 is the first version of Spring Boot to support Java 17. Now you can initialize Spring Boot to support java17 version from Spring Initializr.

The 14 new features of Java 17 are:

• 306: Restore always strict floating point semantics

• 356: Enhanced Pseudo-Random Number Generator

• 382: New macOS rendering pipeline

• 391: macOS/AArch64 port

• 398: Deprecating the Applet API that will be removed soon

• 403: Strongly encapsulate the internal API of JDK

• 406: Switch Pattern Matching (Preview)

• 407: Delete RMI activation

• 409: Sealed class

• 410: Remove experimental AOT and JIT compilers

• 411: Deprecation is about to remove security manager

• 412: External Functions and Memory API (Incubator)

• 414: Vector API (second feature incubation)

• 415: Context-specific deserialization filters

Of these 14 functions, which one is most useful to you.

First LTS release after 3 years

According to the Oracle Java SE Support Roadmap, Java 17 is the first long-term support release since Java 11. Oracle also proposes to change the cadence of JDK LTS releases from every three years to every two years, with each LTS release being serviced for at least 8+ years. The Java version is usually updated every 6 months, in March and September respectively, and the support time of these versions is basically about half a year.

The life cycle of various versions of Java

According to the official blog of Oralce, although the number of users of the 6-month version is increasing, most organizations and enterprises prefer to use the LTS version in the production environment to obtain more stable and reliable services. This is also corroborated by the 2021 Java Community Report released by Snyk, although 61.5% use Java 11 in production, half of Java 11 users (currently the most used version) are in their production stack Use Java 8.

In addition to the 14 major updates and faster LTS service cadence mentioned above, what are the highlights of Java 17?

Oracle Introduces Free Java License

Since Java was acquired by Oracle, paid JDK has been criticized, and now, Oracle announced the launch of JDK free service. What does that mean? Let’s take a look at the official explanation:

• Oracle is providing the industry with a free, leading Oralce JDK that includes all quarterly security updates and includes commercial and production use .

• The new license is the Oracle Free Terms and Conditions (NFTC) license. This Oracle JDK license is free for all users, even for commercial and production use. Redistribution is permitted as long as there is no charge .

• Developers and organizations can now easily download, use, share and redistribute the Oracle JDK without a click.

• Oracle will provide these free releases and updates starting with Oracle JDK 17 and continuing for a full year after the next LTS release. Previous versions are not affected by this change.

• Oracle will continue to provide Oracle OpenJDK releases under the GPL on the same release and schedule as they have been since Java 9.

To sum it up in one sentence, “free” doesn’t mean developers can do whatever they want, because Oracle’s NFTC prohibits paying for redistribution of its Java software.

Before the official release of Java 17, the Java development framework Spring took the lead in announcing on the official blog that Spring Framework 6 and Spring Boot 3 plan to achieve a high-end baseline for overall availability in the fourth quarter of 2022:

• Java 17+ (from Java 8-17 in the Spring Framework 5.3.x line)

• Jakarta EE 9+ (Java EE 7-8 from the Spring framework 5.3.x line)

Support Java 17 by taking action, indirectly calling on developers, it’s time to use Java 17.

Should you upgrade? How fast is Java 17?

Seeing such a sincere update, should developers upgrade? Although you can experience Java 17 just by switching JDK. In response, the OptaPlanner website did a benchmark: How fast is Java? Let me tell you the answer by comparing JDK 17, JDK 16 and JDK 11.

Benchmark method

• Hardware: A stable machine not running any other computationally demanding processes, configuration: Intel® Xeon® Silver 4116 @ 2.1 GHz (12 cores total / 24 threads) and 128 GiBRAM memory, running RHEL 8 x86_64.

• JDK version:

• JDK 11

 openjdk 11.0.12 2021-07-20OpenJDK Runtime Environment Temurin-11.0.12+7 (build 11.0.12+7)OpenJDK 64-Bit Server VM Temurin-11.0.12+7 (build 11.0.12+7, mixed mode)

 openjdk 16.0.2 2021-07-20OpenJDK Runtime Environment (build 16.0.2+7-67)OpenJDK 64-Bit Server VM (build 16.0.2+7-67, mixed mode, sharing)

 openjdk 17 2021-09-14OpenJDK Runtime Environment (build 17+35-2724)OpenJDK 64-Bit Server VM (build 17+35-2724, mixed mode, sharing)

• JVM options: -Xmx3840M and specify the garbage collector explicitly:

• -XX:+UseG1GC For G1GC, the low-latency garbage collector (default in all three JDKs).

• -XX:+UseParallelGC For ParallelGC, high throughput garbage collector.

• Main class: org.optaplanner.examples.app.GeneralOptaPlannerBenchmarkApp from module 8.10.0.Final in optaplanner-examplesOptaPlanner .

• Each run used OptaPlanner to solve 11 planning problems, such as employee scheduling, school timetables, and cloud optimization. Each planning problem runs for 5 minutes. Logging is set to INFO . Benchmarks begin with a 30-second JVM warm up, followed by discards.

• Solving the planning problem doesn’t involve IO (other than the few milliseconds of loading the input during startup). A single CPU is completely saturated. It keeps creating many short lived objects which are then collected by the GC .

• The benchmark measures the number of scores calculated per second, the higher the better. Calculating a score for a solution planned by a test plan is not an easy task: it involves many calculations, including checking for conflicts between each entity and every other entity.

• Number of runs: 3 runs in sequence for each JDK and each garbage collector combination. The results below are the average of these 3 runs.

Test Results

Java 11 (LTS) and Java 16 and Java 17 (LTS)

Table 1. Computation per second score using G1GC on different JDKs

Table 2. Computation per second score using ParallelGC on different JDKs

Remark:

Looking at the raw data for 3 separate runs (not shown here), the number of machine reallocations (B1 and B10) fluctuates wildly between runs on the same JDK and GC, typically more than 10%, other numbers are not affected by this The effect of unreliability.

It’s arguably better to ignore Machine Reassignment numbers. But to avoid problems with picking data, these results and averages do include them.

G1GC vs ParallelGC on Java 17

Table 3. Computation scores per second for different GCs under JDK 17

Benchmark Summary

On average, benchmark results using OptaPlanner as an example show:

• For G1GC (default), Java 17 is 8.66% faster than Java 11 and 2.41% faster than Java 16.

• For ParallelGC, Java 17 is 6.54% faster than Java 11 and 0.37% faster than Java 16.

• Parallel GC is 16.39% faster than G1 GC.

The results are not too surprising: the latest JDK is faster, and the high-throughput garbage collector is faster than the low-latency garbage collector.

say more

In JDK 15 based benchmarks, Java 15 is 11.24% faster than Java 11. Now, Java 17 has less gain over Java 11. Does this mean that Java 17 is slower than Java 15?

The answer is no, Java 17 is still faster than Java 15 because those previous benchmarks were run on a different codebase (OptaPlanner 7.44 instead of 8.10). Don’t compare oranges to apples, they are not comparable.

in conclusion

All in all, the performance of JDK17 is still very worth upgrading, at least in terms of OptaPlanner Demo.

Also, the fastest garbage collector for these use cases is still ParallelGC, not G1GC (default).

What surprises does Java 17 bring to you as the first LTS release after 3 years? In the face of the strong development of JVMs such as Go and Kotlion, do you think Java can still maintain its dominance?

The text and pictures in this article are from the architect’s column