Work on features in the Java SE 25 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 25 Reference Implementation on apreview basis, to gain exposure before achieving permanent status in a later release of the Java SE Platform.
Summary
Language
Compact Source Files and Instance Main Methods
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.
Flexible Constructor Bodies
In the body of a constructor, allow statements to appear before an explicitconstructor invocation, i.e.,super(...) orthis(...). Such statementscannot reference the object under construction, but they can initialize itsfields and perform other safe computations. This change allows many constructorsto be expressed more naturally. It also allows fields to be initialized beforethey become visible to other code in the class, such as methods called from asuperclass constructor, thereby improving safety.
Module Import Declarations
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.
Primitive Types in Patterns, instanceof, and switch (Third 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.
Security
Key Derivation Function API
Introduce an API for Key Derivation Functions (KDFs), which are cryptographic algorithms for deriving additional keys from a secret key and other data.
PEM Encodings of Cryptographic Objects (Preview)
Introduce an API for encoding objects that represent cryptographic keys, certificates, and certificate revocation lists into the widely-usedPrivacy-Enhanced Mail (PEM) transport format, and for decoding from that format back into objects. This is apreview API.
Libraries
Scoped Values
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 505).
Stable Values (Preview)
Introduce an API forstable values, which are objects that hold immutable data. Stable values are treated as constants by the JVM, enabling the same performance optimizations that are enabled by declaring a fieldfinal. Compared tofinal fields, however, stable values offer greater flexibility as to the timing of their initialization. This is apreview API.
Structured Concurrency (Fifth Preview)
Simplify concurrent programming by introducing an API forstructured concurrency. Structured concurrency treats groups of related tasks running in different threads as single units of work, thereby streamlining error handling and cancellation, improving reliability, and enhancing observability. This is apreview API.
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 24, this Specification does not add or remove any restricted methods.
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.
