The arrival of Java 17!

Oracle is proud to announce the general availabilty of JDK 17. This release is the eighth Feature Release delivered on time through the six-month release cadence. This level of predictability allows developers to easily manage their adoption of innovation thanks to s steady stream of expected changes.

Java’s ability to boost performance, stability, and security continues to make it the world’s most popular programming language. According to an IDC report over ten million developers, representing 75% of full-time developers worldwide, use Java, more than any other language.

JDK 17 is now available!

Oracle now offers JDK 17 for developers, end-users, and enterprises. As an LTS release, Oracle JDK 17 will receive performance, stability and security updates for at least 8 years following the Oracle Critical Patch Update (CPU) schedule as outlined in the Oracle Java SE Support Roadmap.

Oracle JDK 18, the next six month cadence release is now scheduled for in March 2022.

Java 17 is the second long-term support (LTS) under the release cadence announced in 2018. Oracle has announced plans to shorten the time between future LTS releases, from 3 years to 2 years so you should expect the next LTS to be Java 21 in September of 2023.

Another important change with Oracle JDK 17 is new simple license terms which will allow companies to use Oracle JDK 17, including the quarterly performance, stability, and security patches, at no cost for at least the next three years, allowing one full year of overlap with the next LTS release. Java SE Subscribers get access to Oracle’s Java SE Support and commercial features such as GraalVM Enterprise, Java Management Service and the Advanced Management Console.

Java 17, Together

As with previous release, with Java 17, we continue to celebrate the contributions from many individuals and organizations in the OpenJDK Community — we all build Java, together!

JDK 17 Fix Ratio

The rate of change over time in the JDK releases has remained largely constant for years, but under the six-month cadence the pace at which production-ready features and improvements are delivered has vastly improved.

Instead of making tens of thousands of fixes and delivering close to one hundred JEPs (JDK Enhancement Proposals) every few years as we did with yesteryear Major Releases, enhancements are delivered in leaner Feature Releases on a more manageable, predictable six-month schedule. The changes range from significant new features to small enhancements to routine maintenance, bug fixes, and documentation improvements. Each change is represented in a single commit for a single issue in the JDK Bug System.

Of the 12,733 JIRA issues marked as fixed in Java 12 through Java 17 at the time of their GA, 9,218 were completed by people working for Oracle while 3,515 were contributed by individual developers and developers working for other organizations.

In Java 17, of the 2,645 JIRA issues marked as fixed, 1,774 were completed by Oracle, while 871 were contributed by other members of the Java community. Going through the issues and collating the organization data from assignees results in the following chart of organizations sponsoring the development of contributions in Java 17:

Oracle would like to thank the developers working for organizations like Amazon, NTT Data, Red Hat, SAP and Tencent for their notable contributions.  We are also thankful to see contributions from smaller organizations such as Bellsoft, DataDog, Loongson, Skymatic and independent developers who collectively contributed 6% of the fixes in Java 17.

We are equally grateful to the many experienced developers who reviewed proposed changes, the early adopters who tried out early access builds and reported issues, and the dedicated professionals who provided feedback on the OpenJDK mailing lists. 

The following individuals provided invaluable feedback on build quality, logged good quality bugs, or offered frequent updates:

◉ Jaikiran Pai (Apache Ant)

◉ Rick Hillegas (Apache Derby)

◉ Uwe Schindler (Apache Lucene)

◉ Mark Thomas (Apache Tomcat)

◉ Martin Grigorov (Apache Tomcat, Apache Wicket)

◉ Rafael Winterhalter (Byte Buddy)

◉ Yoann Rodière (Hibernate ORM, Validator, Search, Reactive)

◉ Marc Hoffman (JaCoCo)

◉ Lukas Eder (jOOQ)

◉ Christian Stein (JUnit 5)

◉ David Karnok (RxJava)

Additionally, through the Quality Outreach program we would like to thank the following FOSS projects and individuals who provided excellent feedback on testing Java 17 early access builds to help improve the quality of the release.

◉ Apache Aries Spi Fly

◉ Apache CXF

◉ Apache Zookeeper (Enrico Olivelli)

◉ Aries JAX-RS

◉ BurningWave

◉ DataSketches

◉ Eclipse Collections

◉ Eo-yaml

◉ FXGL

◉ JabRef

◉ JaCoCo (Evgeny Mandikov)

◉ Java Katas (Chandra Guntur)

◉ Jenkins

◉ Jobrunr

◉ JOOQ

◉ JUnit

◉ Karate

◉ MyBatis (Iwao Ave)

◉ Netty

◉ PDFsam

◉ Sedja

◉ Selenide

◉ Syncope

◉ Vaadin

New in Java 17

Along with thousands of performance, stability and security updates, Java 17 delivers fourteen enhancements/changes (known as JDK Enhancement Proposals - JEPs), including three delivered in incubator modules and one preview language feature.

Incubator modules allow putting non-final APIs and non-final tools in the hands of developers and users to gather feedback that will ultimately improve the quality of the Java platform.

Similarly, Preview Features are fully specified and fully implemented Language or VM Features of the Java SE Platform; and yet impermanent. They are made available in JDK Feature Releases to allow for developer feedback based on real-world uses, before them becoming permanent in a future release.  This also affords tool vendors the opportunity to work towards supporting features before they are finalized into the Java SE Standard.

We’ve grouped the fourteen JEPs delivered with Java 17 into seven categories:

1. Language Feature

JEP 409: Sealed Classes

Sealed Classes allow API designers to specify which classes or interfaces may extend or implement a given class. Having an exhaustive list of cases to consider when modeling a problem can simplify development. JEP 409 was developed in the OpenJDK Project Amber, which aims to continually improve developer productivity through evolution of the Java programming language.

2. Updates and Improvements on Core Libraries

JEP 306: Restore Always-Strict Floating-Point Semantics

The Java programming language and Java virtual machine originally only had strict floating-point semantics. Starting in JDK 1.2, small variances in those strict semantics were allowed by default to accommodate limitations of then-current hardware architectures. Those variances are no longer helpful or necessary and have been removed by JEP 306.

JEP 356: Enhanced Pseudo-Random Number Generator

Updates to java.util.random improve the interoperability of different PRNGs (Pseudo-Random Number Generators) and make it easy to request an algorithm based on requirements rather than hard coding a specific implementation.  Changes include new interface types and implementations for pseudorandom number generators (PRNGs), including jumpable PRNGs and an additional class of splitable PRNG algorithms (LXM) and a new RandomGeneratorFactory class.

JEP 382: New macOS Rendering Pipeline

This new pipeline reduces the JDK’s dependency on the deprecated Apple OpenGL API by implementing a Java 2D rendering pipeline for macOS using the new Apple Metal API.

JEP 415: Context-Specific Deserialization Filters

Filter Incoming Serialization Data, added with JDK 9 (JEP 290), is improved by allowing applications to configure context-specific and dynamically-selected deserialization filters via a JVM-wide filter factory that is invoked to select a filter for each individual deserialization operation. This makes it possible to take advantage of deserialization filters without requiring every stream’s creator to update their code or making the filter too restrictive or too permissive.

3. New Platform Support

JEP 391: macOS AArch 64 Port

Delivers a version of the JDK for macOS that runs natively on Apple’s newer Arm 64 based systems.

4. Previews and Incubators

JEP 406: Pattern Matching for switch (Preview)

Enhances the Java programming language allowing pattern matching to be tested within a switch statement or switch expression. Using pattern matching in switch complex data-oriented queries can be expressed concisely and safely. JEP 406 was developed in the OpenJDK Project Amber.

JEP 412: Foreign Function and Memory API (Incubator)

Improves APIs introduced with JDK 14 and JDK 15 through which Java programs can interoperate with code and data outside of the Java runtime. By efficiently invoking foreign functions (i.e., code outside the JVM), and by safely accessing foreign memory (i.e., memory not managed by the JVM), the API enables Java programs to call native libraries and process native data without the brittleness and danger of JNI. JEP 412 was developed in the OpenJDK Project Panama which aims to simplify the interaction between Java code and foreign (non-Java) APIs.

JEP 414: Vector API (Second Incubator)

Enhances APIs that allow expressing vector computations in a way that will reliably compile at runtime to optimal vector instructions on supported CPU architectures. Vector operations can deliver performance superior to equivalent scalar computations and are quite common in fields such as Machine Learning, Artificial Intelligence, and Cryptography. JEP 412 was developed in the OpenJDK Project Panama.

5. Future Proofing Java Programs

JEP 403: Strongly Encapsulate JDK Internals

It will no longer be possible to relax the strong encapsulation of internal elements through a single command-line option, as was possible in JDK 9 through JDK 16 This change hides by default all but a few critical internal APIs such as sun.misc.Unsafe. It will still be possible to access existing internal APIs, but this will now require enumerating, as command-line parameters or JAR-file manifest attributes, each package on which encapsulation should be relaxed. The change will lead to more secure applications and less dependencies on non-standard internal implementations.

JEP 403 is the continuation of JEP 396 in JDK 16, which transitioned the JDK from a default of relaxed strong encapsulation to a default of strong encapsulation.

6. Deprecations and Removals

JEP 411: Deprecate the Security Manager for Removal

The Security Manager dates from Java 1.0. It has not been the primary means of securing client-side Java code for many years, and it has rarely been used to secure server-side code.

JEP 398: Deprecate the Applet API for Removal

The Applet API has become essentially irrelevant since all web-browser vendors have either removed support for Java browser plug-ins or announced plans to do so. The Applet API was previously deprecated (though not for removal) in Java 9 (JEP 289) in September 2017.

JEP 407: Remove RMI Activation

Remote Method Invocation (RMI) Activation mechanism has been removed.  This change does not affect the rest of RMI. The RMI Activation mechanism was deprecated for removal in JDK 15 in September 2020.

7. For OpenJDK Contributors

JEP 410: Remove the Experimental AOT and JIT Compiler

The experimental Java-based ahead-of-time (AOT) and just-in-time (JIT) compiler saw little use since its introduction in JDK 9, more widely supported alternatives have emerged, and the effort required to maintain them is significant.  As optional components, they were already removed from JDK 16. This JEP removes the source code from the OpenJDK project.

 

Tooling Support

Timely support for new features by tools and libraries helps drive developer productivity.  With Java 17, we continue to welcome the efforts of leading IDE vendors whose most timely updates offer developers support for current Java versions.  Developers can expect to take advantage of Java 17 support today with the following IDEs:

◉ JetBrains IDEA

◉ Eclipse via a separate marketplace solution

Source: oracle.com