ProHoster > Blog > internet news > Java SE 17 release

Java SE 17 release

After six months of development, Oracle has released Java SE 17 (Java Platform, Standard Edition 17), which uses the OpenJDK open source project as a reference implementation. With the exception of the removal of some deprecated features, Java SE 17 maintains backward compatibility with previous releases of the Java platformβ€”most previously written Java projects will still work without modification when running under the new version. Installable builds of Java SE 17 (JDK, JRE, and Server JRE) are prepared for Linux (x86_64, AArch64), Windows (x86_64), and macOS (x86_64, AArch64). Developed by the OpenJDK project, the Java 17 reference implementation is fully open under the GPLv2 license with GNU ClassPath exceptions to allow dynamic linking to commercial products.

Java SE 17 is categorized as a Long Term Support (LTS) release with updates until 2029. Updates for the past interim release of Java 16 have been discontinued. The previous Java 11 LTS branch will be supported until 2026. The next LTS release is scheduled for September 2024. Recall that starting with the release of Java 10, the project switched to a new development process, which implies a shorter cycle for the formation of new releases. New functionality is now being developed in one constantly updated master branch, which incorporates already completed changes and from which branches are branched every six months to stabilize new releases.

New features in Java 17 include:

  • An experimental implementation of pattern matching in "switch" expressions is proposed, which allows using not exact values ​​in "case" labels, but flexible templates that immediately cover a series of values ​​for which cumbersome chains of "if ... else" expressions had previously been used. In addition, inside the "switch" is provided the ability to handle NULL values. Object o = 123L; String formatted = switch (o) { case Integer i -> String.format("int %d", i); case Long l -> String.format("long %d", l); case Double d -> String.format("double %f", d); case String s -> String.format("String %s", s); default -> o.toString(); };
  • Support for sealed classes and interfaces that cannot be used by other classes and interfaces to inherit, extend, or override implementations has been stabilized. Sealed classes also provide a more declarative way of restricting the use of a superclass than access modifiers, based on an explicit enumeration of the subclasses allowed to be extended. package com.example.geometry; public sealed class Shape permits com.example.polar.Circle, com.example.quad.Rectangle, com.example.quad.simple.Square {…}
  • The second preliminary implementation of the Vector API is proposed, which provides functions for vector calculations that are performed using the vector instructions of the x86_64 and AArch64 processors and allow you to simultaneously apply operations to several values ​​​​at once (SIMD). Unlike the capabilities provided in the HotSpot JIT compiler for autovectorization of scalar operations, the new API makes it possible to explicitly control vectorization for parallel data processing.
  • A preliminary implementation of the Foreign Function & Memory API has been added, with which applications can interact with code and data outside the Java runtime. The new API allows you to efficiently call non-JVM functions and access memory that is not managed by the JVM. For example, you can call functions from external shared libraries and access process data without using JNI.
  • The macOS rendering engine that powers the Java 2D API, which is in turn powered by the Swing API, has been adapted to use the Metal graphics API. The default on macOS is still OpenGL, and enabling Metal support requires setting the "-Dsun.java2d.metal=true" option and having at least a release of macOS 10.14.x.
  • Added port for macOS/AArch64 platform (Apple computers based on new Apple M1 chips). A feature of the port is the support of the W^X (Write XOR Execute) memory protection mechanism, in which memory pages cannot be simultaneously available for writing and execution. (the code can be executed only after the write is disabled, and writing to the memory page is possible only after the execution is disabled).
  • Returned the use of only strict (strictfp) semantics for floating point expressions. Support for "default" semantics, available since the release of Java 1.2, has been dropped, which includes simplifications for running on systems with very old x87 math coprocessors (after the introduction of SSE2 instructions, the need for additional semantics was gone).
  • Implemented new types of interfaces to pseudo-random number generators, as well as implemented additional algorithms for better random number generation. Applications are given the opportunity to choose the algorithm for generating pseudo-random numbers. Improved support for generating streams of random objects.
  • Implemented mandatory strong encapsulation of all JDK internals, except for critical APIs such as sun.misc.Unsafe. Strong encapsulation blocks attempts to access internal classes, methods, and fields from code. Previously, strict encapsulation could be disabled using the "--illegal-access=permit" option, but this has now been deprecated. Applications that need access to internal classes, methods, and fields should explicitly define them using the "--add-opens" option or the Add-Opens attribute in the manifest file.
  • Applications are given the ability to define filters for deserializing data, which can be context dependent and dynamically selected in conjunction with certain deserialization operations. The filters you set are applicable to the entire virtual machine (JVM-wide), i.e. cover not only the application itself, but also third-party libraries used in the application.
  • Swing has added the javax.swing.filechooser.FileSystemView.getSystemIcon method to load large icons to improve UI rendering on high pixel density (HighDPI) screens.
  • The java.net.DatagramSocket API provides support for connecting to Multicast groups without the need for a separate java.net.MulticastSocket API.
  • The IGV (Ideal Graph Visualizer) utility has been improved, which provides interactive visualization of the intermediate code representation in the HotSpot VM C2 JIT compiler.
  • In JavaDoc, by analogy with the javac compiler, when outputting an error, the number of the problematic line in the source file and the location of the error are now indicated.
  • The native.encoding property has been added, reflecting the name of the system character encoding (UTF-8, koi8-r, cp1251, etc.).
  • The java.time.InstantSource interface has been added, which allows you to manipulate time without being tied to a time zone.
  • Added java.util.HexFormat API to convert to hex representation and vice versa.
  • A blackhole mode has been added to the compiler, which disables dead-code elimination operations, which can be used when conducting performance tests.
  • Added "-Xlog:async" option to Runtime to write logs asynchronously.
  • When establishing secure connections, TLS 1.3 is enabled by default (previously TLS 1.2 was used).
  • The previously deprecated Applet API (java.applet.Applet*, javax.swing.JApplet), which was used to run Java applications in the browser, was moved to the category scheduled for deletion (lost relevance after the end of support for the Java plug-in for browsers).
  • Transferred to the category of Security Manager scheduled for removal, which has long lost its relevance and turned out to be unclaimed after the termination of support for the browser plug-in.
  • The RMI Activation mechanism has been removed, which is outdated, moved to the category of an option back in Java 8 and is almost never used in modern practice.
  • An experimental compiler has been removed from the SDK that supports JIT (just-in-time) for dynamic compilation of Java code for the HotSpot JVM, as well as the mode of pre-emptive compilation (AOT, ahead-of-time) of classes to machine code before starting the virtual machine. The compiler was written in Java and based on the work of the Graal project. It is noted that maintaining the compiler requires a lot of labor, which does not justify itself in conditions of lack of demand among developers.

Source: opennet.ru

Add a comment