Java SE 24 ( JSR 399) (original) (raw)

Work on features in the Java SE 24 Reference Implementation is organized in terms of JDK Enhancement Proposals (JEPs). Each feature description gives a link to the corresponding JEP document as a convenience, but that document is not a normative part of this Specification. Some features are included in the Java SE 24 Reference Implementation on a preview basis, to gain exposure before achieving permanent status in a later release of the Java SE Platform.

Summary

Libraries Class-File API
Prepare to Restrict the Use of JNI
Scoped Values (Fourth Preview)
Stream Gatherers
Structured Concurrency (Fourth Preview)
Language Flexible Constructor Bodies (Third Preview)
Module Import Declarations (Second Preview)
Primitive Types in Patterns, instanceof, and switch (Second Preview)
Simple Source Files and Instance Main Methods (Fourth Preview)
Security Key Derivation Function API (Preview)
Permanently Disable the Security Manager
Quantum-Resistant Module-Lattice-Based Digital Signature Algorithm
Quantum-Resistant Module-Lattice-Based Key Encapsulation Mechanism

Libraries

Class-File API

Provide a standard API for parsing, generating, and transforming Java class files.

Prepare to Restrict the Use of JNI

Issue warnings about uses of the Java Native Interface (JNI) and adjust the Foreign Function & Memory (FFM) API to issue warnings in a consistent manner. All such warnings aim to prepare developers for a future release that ensures integrity by default by uniformly restricting JNI and the FFM API. Application developers can avoid both current warnings and future restrictions by selectively enabling these interfaces where essential.

Scoped Values (Fourth Preview)

Introduce scoped values, which enable a method to share immutable data both with its callees within a thread, and with child threads. Scoped values are easier to reason about than thread-local variables. They also have lower space and time costs, especially when used together with virtual threads (JEP 444) and structured concurrency (JEP 480). This is a preview API.

Stream Gatherers

Enhance the Stream API to support custom intermediate operations. This will allow stream pipelines to transform data in ways that are not easily achievable with the existing built-in intermediate operations.

Structured Concurrency (Fourth Preview)

Simplify concurrent programming by introducing an API for structured concurrency. Structured concurrency treats groups of related tasks running in different threads as a single unit of work, thereby streamlining error handling and cancellation, improving reliability, and enhancing observability. This is a preview API.

Language

Flexible Constructor Bodies (Third Preview)

In constructors in the Java programming language, allow statements to appear before an explicit constructor invocation, i.e., super(..) or this(..). The statements cannot reference the instance under construction, but they can initialize its fields. Initializing fields before invoking another constructor makes a class more reliable when methods are overridden. This is a preview language feature.

Module Import Declarations (Second Preview)

Enhance the Java programming language with the ability to succinctly import all of the packages exported by a module. This simplifies the reuse of modular libraries, but does not require the importing code to be in a module itself. This is a preview language feature.

Primitive Types in Patterns, instanceof, and switch (Second Preview)

Enhance pattern matching by allowing primitive types in all pattern contexts, and extend instanceof and switch to work with all primitive types. This is apreview language feature.

Simple Source Files and Instance Main Methods (Fourth Preview)

Evolve the Java programming language so that beginners can write their first programs without needing to understand language features designed for large programs. Far from using a separate dialect of the language, beginners can write streamlined declarations for single-class programs and then seamlessly expand their programs to use more advanced features as their skills grow. Experienced developers can likewise enjoy writing small programs succinctly, without the need for constructs intended for programming in the large. This is a preview language feature.

Security

Key Derivation Function API (Preview)

Introduce an API for Key Derivation Functions (KDFs), which are cryptographic algorithms for deriving additional keys from a secret key and other data. This is a preview API.

Permanently Disable the Security Manager

The Security Manager has not been the primary means of securing client-side Java code for many years, it has rarely been used to secure server-side code, and it is costly to maintain. We therefore deprecated it for removal in Java 17 via JEP 411 (2021). As the next step toward removing the Security Manager, we will revise the Java Platform specification so that developers cannot enable it and other Platform classes do not refer to it. This change will have no impact on the vast majority of applications, libraries, and tools. We will remove the Security Manager API in a future release.

Quantum-Resistant Module-Lattice-Based Digital Signature Algorithm

Enhance the security of Java applications by providing an implementation of the quantum-resistant Module-Lattice-Based Digital Signature Algorithm (ML-DSA). Digital signatures are used to detect unauthorized modifications to data and to authenticate the identity of signatories. ML-DSA is designed to be secure against future quantum computing attacks. It has been standardized by the United States National Institute of Standards and Technology (NIST) inFIPS 204.

Quantum-Resistant Module-Lattice-Based Key Encapsulation Mechanism

Enhance the security of Java applications by providing an implementation of the quantum-resistant Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM). Key encapsulation mechanisms (KEMs) are used to secure symmetric keys over insecure communication channels using public key cryptography. ML-KEM is designed to be secure against future quantum computing attacks. It has been standardized by the United States National Institute of Standards and Technology (NIST) inFIPS 203.

Preview features A preview feature is a new feature of the Java language, Java Virtual Machine, or Java SE API that is fully specified, fully implemented, and yet impermanent. Preview features must possess the following properties:

Preview features may be removed in a future release, or upgraded to permanent features of the Java SE Platform.

The Java SE API consists solely of Java APIs, but the complete Java SE Platform includes non-Java APIs, such as JNI and JVM TI, and language-independent protocols, such asJDWP andJava Object Serialization. A preview feature may include changes to non-Java APIs and language-independent protocols.

Implementations of this Specification must:

Additional details about preview features, including a description of a preview feature’s life cycle and the relationship of preview features in the Java language to preview features in the Java SE API, are available inJEP 12 Preview Features.

This section may be compared tothe corresponding section that appeared in Java SE 18.

Restricted methods Various methods in the Java SE API allow Java code to interoperate with resources outside the Java runtime in such a way that the runtime cannot prove correct or safe use of the resources. These methods, which are provided because of their high utility, are specified as having the potential to crash the Java runtime or corrupt memory. They are known as_restricted_ methods.

All methods in the Java SE API that are not restricted are_unrestricted_. Given the potential danger of restricted methods, developers should use restricted methods only when no suitable functionality is available in unrestricted methods. To encourage developers to seek unrestricted alternatives to restricted methods, the following rule applies:

In addition, native methods can cause arbitrary undefined behavior, including JVM crashes. Such problems cannot be prevented by the Java runtime, nor do they provoke exceptions for Java code to catch. Given the potential danger of native methods, the following rule applies:

An Implementation may provide a means to invoke its run-time system with (1) all restricted methods treated as unrestricted when invoked from code specified to the run-time system, and (2) native methods treated as if they are already bound if declared in code specified to the run-time system.

If the run-time system is invoked in this way, then by definition there are no restricted methods for the specified code to invoke, and nonative methods in the specified code that are not bound. Therefore, no warnings are issued during the execution of such code.

If code other than that specified to the run-time system either invokes a restricted method or declares a native method that is bound, the Implementation may give a signal other than a warning issued on the standard error stream.

(The Reference Implementation allows the user to specify code in which (1) the invocation of restricted methods will be treated as the invocation of unrestricted methods, and (2) native method declarations will be treated as already bound. This is achieved via the command-line option --enable-native-access=M, where M is a comma-separated list of modules. The special operandALL-UNNAMED indicates every unnamed module, which includes code on the class path. When the
--enable-native-access option is present, any invocation of restricted methods from, or binding of native methods in, code outside the listed modules will cause, at most, one warning to be issued per module.)

(The Reference Implementation can identify when code invokes restricted methods and when native methods are bound. These actions are called restricted operations. The identification of restricted operations is enabled via the command-line option--illegal-native-access=X, where X isallow, warn, or deny. A value ofallow means that all restricted operations will proceed silently; warn will cause a warning to be issued at most once per module if code performs restricted operations; and deny will cause anIllegalCallerException to be thrown for every restricted operation. Future revisions of this Platform Specification are expected to makedeny the default and eventually remove bothallow and warn.)

The list of restricted methods may be found in theRestricted Methods section of theAPI Specification.

Compared to Java SE 23, this Specification designates the following pre-existing methods as restricted:

This section may be compared tothe corresponding section that appeared in Java SE 23.

Preparing for removal of finalization An Implementation must support the finalization of objects, as described inThe Java Language Specification, section 12.6. However, the Java SE 18 Platform Specificationdeprecates finalization, for removal. To aid preparations for the removal of finalization, an Implementation may provide a means to invoke its run-time system with finalization disabled. If finalization is disabled, the effect is that the Java Virtual Machine never invokes an object’s finalizer before the storage for the object is reclaimed by the garbage collector. An Implementation must not, by default, disable finalization.

(The Reference Implementation provides the ability to disable finalization via the command-line option--finalization=disabled.)

Future revisions of this Platform Specification are expected to disable finalization by default and, eventually, to remove finalization from the Java Language Specification.