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 apreview basis, to gain exposure before achieving permanent status in a later release of the Java SE Platform.
Summary
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 theJava Native Interface (JNI) and adjust theForeign Function & Memory (FFM) API to issue warnings in a consistent manner. All such warnings aim to prepare developers for a future release that ensuresintegrity 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)
Introducescoped 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 apreview API.
Stream Gatherers
Enhance theStream 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 forstructured 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 apreview API.
Language
Flexible Constructor Bodies (Third Preview)
In constructors in the Java programming language, allow statements to appearbefore an explicit constructor invocation, i.e.,super(..) orthis(..). Thestatements cannot reference the instance under construction, but they caninitialize its fields. Initializing fields before invoking another constructormakes a class more reliable when methods are overridden. This is apreviewlanguage feature.
Module Import Declarations (Second Preview)
Enhance the Java programming language with the ability to succinctly import allof the packages exported by a module. This simplifies the reuse of modularlibraries, but does not require the importing code to be in a module itself.This is apreview language feature.
Primitive Types in Patterns, instanceof, and switch (Second Preview)
Enhance pattern matching by allowing primitive types in all pattern contexts,and extendinstanceof andswitch 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 firstprograms without needing to understand language features designed for largeprograms. Far from using a separate dialect of the language, beginners can writestreamlined declarations for single-class programs and then seamlessly expandtheir programs to use more advanced features as their skills grow. Experienceddevelopers can likewise enjoy writing small programs succinctly, without theneed for constructs intended for programming in the large. This is apreviewlanguage 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 apreview 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 viaJEP 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 thequantum-resistant Module-Lattice-Based Digital Signature Algorithm (ML-DSA).Digital signatures are used to detect unauthorized modifications to data and toauthenticate the identity of signatories. ML-DSA is designed to be secureagainst future quantum computing attacks. It has been standardized by the UnitedStates 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 thequantum-resistant Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM). Keyencapsulation mechanisms (KEMs) are used to secure symmetric keys over insecurecommunication channels using public key cryptography. ML-KEM is designed to besecure against future quantum computing attacks. It has been standardized by theUnited 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:
- High quality. A preview feature must display the same level of technical excellence and finesse as a final and permanent feature of the Java SE Platform.
- Not experimental. A preview feature must not be experimental, risky, incomplete, or unstable. An experimental feature must not be previewed in a release of the Java SE Platform.
- Universally available. All preview features included in a Java SE Platform Specification must be supported in full by every implementation of that Specification.
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 asJNI andJVM 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:
- support all, and only, the preview features included by this Specification.
- disable all preview features in the Java language, Java Virtual Machine, and Java SE API at compile time and run time by default.
- allow the user to indicate to the Java compiler and the Java runtime that the entire set of preview features are to be enabled.
- not allow the user to enable preview features on an individual basis, because they have equal status in the Platform and must be enabled or disabled as a set.
- always enable the non-Java APIs and language-independent protocols that are part of any preview feature, regardless of whether preview features are enabled or disabled.
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 12Preview 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 asrestricted methods.
All methods in the Java SE API that are not restricted areunrestricted. 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:
- An Implementation must issue a warning on the standard error
stream every time a restricted method is invoked, unless (1) the
invocation occurs in a class in thejava.base module, or (2) the
invocation occurs in a class in a module specified previously to
ModuleLayer.Controller.enableNativeAccess, or (3) as provided for
below.
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 ofnative methods, the following rule applies:
- An Implementation must issue a warning on the standard error stream every time a native method is bound, unless (1) the method is declared in a class in the java.base module, or (2) the method is declared in a class in a module specified previously toModuleLayer.Controller.enableNativeAccess, or (3) as provided for below.
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 anative 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, whereM 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 ofnative 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 whennative methods are bound. These actions are calledrestricted operations. The identification of restricted operations is enabled via the command-line option--illegal-native-access=X, whereX isallow,warn, ordeny. 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; anddeny 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 andwarn.)
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.
