Oracle Releases Java 17

Next Java long-term support release delivers thousands of updates, further improving the language and platform to help developers be more productive

Oracle JDK 17 gives customers security, performance, and bug-fix updates through September 2029

Oracle today announced the availability of Java 17, the latest version of the world’s number one programming language and development platform. Java 17 delivers thousands of performance, stability, and security updates, as well as 14 JEPs (JDK Enhancement Proposals) that further improve the Java language and platform to help developers be more productive.

Java 17 is the latest long-term support (LTS) release under Java’s six-month release cadence and is the result of extensive collaboration between Oracle engineers and other members of the worldwide Java developer community via the OpenJDK Community and the Java Community Process (JCP). Since the previous JDK 11 LTS released three years ago, over 70 JEPs have been implemented.

Read More:  Creatio Partners With A Leading Solutions & Consultancy Services Provider In Turkey, PeraNet

Offering a Simpler License

Oracle JDK 17 and future JDK releases are provided under a free-to-use license until a full year after the next LTS release. Oracle will also continue providing Oracle OpenJDK releases under the open-source General Public License (GPL), as it has since 2017.

Enhancing Long-Term Support for Customers

Oracle is collaborating with the Java developer community and the JCP on enhancing LTS scheduling to give organizations more flexibility on when, or if, they want to migrate to a newer Java LTS version. Oracle is proposing that the next LTS release should be Java 21 and made available in September 2023, which will change the ongoing LTS release cadence from three years to two years.

Backed by the Oracle LTS and Java SE Subscription, customers can migrate to Java 17 at the pace that best meets their needs. Oracle will provide customers with security, performance, and bug-fix updates for Java 17 through at least September 2029.

“Over the last three years we’ve heard how much developers love the latest features, and we’ve seen the ecosystem truly embrace the six-month release cadence,” said Georges Saab, vice president of development, Java Platform Group, Oracle. “One of the biggest challenges Java developers face today is that their organization only allows them to use the latest LTS release. By moving LTS releases to every two years, developers that are with conservative organizations now have more choice and access to the features that they love and want to use.”

“Oracle is making changes that will significantly benefit the Java community by shifting the long-term support releases to a two-year cadence and introducing a new, more relaxed license that provides free production use of Oracle JDK for an extended time,” said Dr. Arnal Dayaratna, research vice president, Software Development at IDC. “These changes will give organizations greater flexibility in managing the complexity of modern application development and deployments in the cloud, on-premises, and in hybrid environments.”

Accelerating Java’s Adoption in the Cloud

Java is one of the most successful development platforms ever and is built on continuous innovation that address the evolving needs of developers. To accelerate Java adoption in the cloud, Oracle recently introduced the Oracle Java Management Service, a new Oracle Cloud Infrastructure (OCI)-native service to help organizations manage Java runtimes and applications on-premises or on any cloud.

Java Management Service gives customers visibility into their Java deployments across the enterprise. This spans all of the Java versions installed in their environment, including versions of Java running in development and in production. It also highlights any unplanned Java applications running and checks if all installed Java versions are up to date with the latest security patches.

JDK 17 includes new language enhancements, updates to the libraries, support for new Apple computers, removals and deprecations of legacy features, and work to ensure Java code written today will continue working without change in future JDK versions. It also offers a language feature preview and incubating APIs to gather feedback from the Java community. Updates include:

Read More:  SalesTechStar Interview Kash Shaikh, CEO And President At Virtana

Java Language Enhancement

• JEP 409: Sealed Classes – Sealed classes and interfaces restrict which other classes or interfaces may extend or implement them. This enhancement is yet another improvement from Project Amber, which aims to increase developer productivity by evolving the Java language.

Updates and Improvements to 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 Java 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, so they have been removed by JEP 306.
• JEP 356: Enhanced Pseudo-Random Number Generator – Provides new interface types and implementations for pseudorandom number generators (PRNGs). This change improves the interoperability of different PRNGs and makes it easy to request an algorithm based on requirements rather than hard coding a specific implementation.
• JEP 382: New macOS Rendering Pipeline – Implements a Java 2D pipeline for macOS using the Apple Metal API. The new pipeline will reduce the JDK’s dependency on the deprecated Apple OpenGL API.

New Platform Support

• JEP 391: macOS AArch64 Port – Ports the JDK to the macOS/AArch64 platform. This port will allow Java applications to run natively on the new Arm 64-based Apple Silicon computers.

Removals and Deprecations

• JEP 398: Deprecate the Applet API for Removal – All web-browser vendors have either removed support for Java browser plug-ins or announced plans to do so. The Applet API was deprecated, but not for removal, in Java 9 in September 2017.
• JEP 407: Remove RMI Activation – Removes the Remote Method Invocation (RMI) Activation mechanism, while preserving the rest of RMI.
• JEP 410: Remove the Experimental AOT and JIT Compiler – The experimental Java-based ahead-of-time (AOT) and just-in-time (JIT) compiler were experimental features that did not see much adoption. Being optional, they were already removed from JDK 16. This JEP removes these components from the JDK source code.
• JEP 411: Deprecate the Security Manager for Removal – The Security Manager dates back to 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. Removing it in a future release will eliminate a significant maintenance burden and enable the Java platform to move forward.

Future Proofing Java Programs

• JEP 403: Strongly Encapsulate JDK Internals – It will no longer be possible to relax the strong encapsulation of internal elements via a single command-line option, as was possible in JDK 9 through JDK 16. It will still be possible to access existing internal APIs, but it will now require enumerating, as command-line parameters or JAR-file manifest attributes, each package for which encapsulation should be relaxed. This change will lead to more secure applications and fewer dependencies on non-standard, internal JDK implementation details.

Previews and Incubators for Later JDK Releases

• JEP 406: Pattern Matching for switch (Preview) – Allows an expression to be tested against several patterns, each with a specific action, so that complex data-oriented queries can be expressed concisely and safely.
• JEP 412: Foreign Function and Memory API (Incubator) – Improves incubating APIs introduced in JDK 14 and JDK 15 that enable Java programs to 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, these APIs enable Java programs to call native libraries and process native data without the brittleness and complexity of Java Native Interface (JNI). These APIs are being developed in Project Panama, which aims to improve the interaction between Java and non-Java code.
• JEP 414: Vector API (Second Incubator) – Allows expressing vector computations that reliably compile at runtime to optimized vector instructions on supported CPU architectures, thereby achieving performance superior to equivalent scalar computations.