After six months of development, Oracle has released the Java SE 26 platform (Java Platform, Standard Edition 26), with the OpenJDK open project serving as its reference implementation. Except for the removal of some deprecated features, Java SE 26 maintains backward compatibility with previous versions of the Java platform — most previously written Java projects will run without modifications on the new version. Installation-ready builds of Java SE 26 (JDK, JRE, and Server JRE) are available for Linux (x86_64, AArch64), Windows (x86_64), and macOS (x86_64, AArch64). The reference implementation of Java SE 26 developed under the OpenJDK project is fully open under the GPLv2 license with exceptions for GNU ClassPath, which allow dynamic linking with commercial products.
Java SE 26 is categorized as a regular support release, with updates being provided until the next release. For long-term support (LTS) branches, Java SE 25, Java SE 21, or Java SE 17 should be used, with updates released until 2033, 2031, and 2029 respectively (public updates until September 2030, 2028, and 2026). Extended support for the LTS branch Java SE 8 will last until 2030, while Java SE 11 will be supported until 2032.
Among the changes in Java SE 26 (1, 2, 3, 4):
- A warning has been implemented for using deep reflection to modify fields marked with the keyword "final." In the future, it is planned to disable unsafe language features by default and to make fields marked as final completely immutable, removing the workaround for modifying them through deep reflection (API Reflection).
- The Applet API (java.applet.Applet*, javax.swing.JApplet), used for launching Java applications in browsers, has been removed. This API became obsolete following the discontinuation of support for the Java plugin in browsers and was declared deprecated in 2021.
- The capability to utilize ahead-of-time (AOT) pre-formed cache with any garbage collectors, including ZGC (Z Garbage Collector), has been implemented. This change entails support for sequential loading of cached Java objects into memory, using a universal, garbage-collector-independent format instead of a direct mapping to memory for cache-specific representations. Utilizing AOT cache reduces startup time and accelerates the warmup of the HotSpot virtual machine.
- The HTTP Client API has added support for the HTTP/3 protocol, allowing applications and libraries to interact with servers using HTTP/3 after minimal code changes.
- The performance of the G1 garbage collector has been improved by reducing blocking for synchronizing application threads with garbage collector threads.
- A second preliminary API for encoding and decoding objects with cryptographic keys, certificates, and certificate revocation lists has been proposed, using the PEM (Privacy-Enhanced Mail) format.
- A sixth preliminary API for Structured Concurrency has been proposed for testing, simplifying the development of multithreaded applications by treating multiple tasks running in different threads as a single block.
- The second preliminary edition of the Lazy Constants API has been added for working with objects containing immutable data, treated in the JVM as constants. Performance optimizations similar to those for fields marked with the 'final' keyword apply to such objects. Unlike 'final', the new API separates the creation of constant values from their initialization, ensuring that a value can be initialized only once, reducing program startup times, and allowing constant folding optimizations in user code, previously used only in the internal code of the JDK. class Application { // Was: // static final UserService USERS = new UserService(); // Now you can: static final StableValue USERS = StableValue.of(); public static UserService users() { return USERS.orElseSet(UserService::new); } }
- The pattern matching mechanism introduces a fourth preliminary option for using primitive types (int, byte, char, and other basic types that are not objects) across all template types, in the 'instanceof' operator, and in 'switch' blocks. switch (x.getStatus()) { case 0 -> 'okay'; case 1 -> 'warning'; case 2 -> 'error'; case int i -> 'unknown status: ' + i; } if (i instanceof byte b) { … b … }
- An eleventh test implementation of the Vector API has been proposed, providing functions for vector computations executed using x86_64 and AArch64 processor vector instructions, allowing operations to be simultaneously applied to multiple values (SIMD). Unlike the auto-vectorization capabilities for scalar operations provided in the HotSpot JIT compiler, the new API offers explicit control over vectorization for parallel data processing.
Additionally, Oracle announced Project Detroit, which will develop within OpenJDK, aimed at enhancing portability between Java, JavaScript, and Python. The project intends to provide an embedding capability within the JVM runtime process with the JavaScript engine V8 and the CPython interpreter. Previously, Oracle had developed the Nashorn JavaScript engine running on top of the JVM, but the project was discontinued due to the challenges of developing a separate JavaScript implementation when the main ecosystem is tied to the V8 engine.
Also noteworthy is the release of the update for the JavaFX application development platform 26. In the coming hours, the release of the GraalVM 26 universal virtual machine is also expected, supporting the execution of applications in JavaScript (Node.js), Python, Ruby, R, any JVM languages (Java, Scala, Clojure, Kotlin), and languages that can generate LLVM bitcode (C, C++, Rust).
Source: opennet.ru
