Work on features in the Java SE 23 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 23 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 (Second Preview)
Provide a standard API for parsing, generating, and transforming Java classfiles. This is apreview API.
Scoped Values (Third 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 (Second Preview)
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. This is apreview API.
Structured Concurrency (Third 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 (Second 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.
Implicitly Declared Classes and Instance Main Methods (Third 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 apreview language feature.
Module Import Declarations (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 moduleitself. This is apreview language feature.
Primitive Types in Patterns, instanceof, and switch (Preview)
Enhance pattern matching by allowing primitive type patterns in allpattern contexts, and extendinstanceof andswitch to work withall primitive types. This is apreview language feature.
Tools
Markdown Documentation Comments
Enable JavaDoc documentation comments to be written in Markdown ratherthan solely in a mixture of HTML and JavaDoc@-tags.
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 identified previously to
ModuleLayer.Controller.enableNativeAccess, or (3) as provided for
below.
An Implementation may provide a means to invoke its run-time system with all restricted methods treated as unrestricted when invoked from code identified 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 identified code to invoke, so no warnings are issued during the execution of such code.
If code other than that identified to the run-time system invokes a restricted method, the Implementation may give a signal other than a warning issued on the standard error stream.
(The Reference Implementation provides the ability to treat restricted methods as unrestricted for code in certain modules via the command-line option--enable-native-access=M.M is a comma-separated list of modules whose code is permitted to invoke restricted methods as if they were unrestricted, i.e., without warnings. The special operand
ALL-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 code outside the listed modules will cause anIllegalCallerException to be thrown, rather than a warning to be issued.)
The list of restricted methods may be found in theRestricted Methods section of theAPI Specification.
Compared to Java SE 22, this Specification does not add or remove any restricted methods.
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.
