This Specification defines version 19 of the Java Platform, Standard Edition (“Java SE 19”). The Reference Implementation of this Specification is the Java Development Kit, version 19 (“JDK 19”).

This release continues the evolution of the Platform to ensure the broadest possible success of the core Java technology. It previews two language features: record patterns and pattern matching for switch statements and switch expressions. It previews virtual threads which are lightweight threads that dramatically reduce the effort of writing, maintaining, and observing high-throughput concurrent applications. Finally, it previews foreign function and memory APIs which enable Java programs to safely call native libraries and process native data as an alternative to JNI.

This document directly specifies API features, enhancements, clarifications, and bug fixes. It also specifies features by reference to other Specifications which are revised in Maintenance Releases of existing JSRs. The specifications of these changes are contained in two accompanying documents: Annex 1 is the complete Java SE 19 API Specification and Annex 2 is an annotated API specification showing the exact differences relative to Java SE 18. Informative background for these changes may be found in the list of approved Change Specification Requests for this release.

This Specification includes the Java SE 19 Editions of The Java Language Specification and The Java Virtual Machine Specification in Annex 3. The Java SE 19 Editions contain all corrections and clarifications made since the Java SE 18 Editions, as well as additions for new features. Annex 3 also presents changes to The Java Language Specification and The Java Virtual Machine Specification in connection with preview language features in Java SE 19.

This Specification includes the Java SE 19 versions of additional narrative specifications in Annexes 4 — 11. The Java SE 19 versions contain all corrections and clarifications made since the Java SE 18 versions, as well as additions for new features. The JDWP, JNI, and JVM TI Specifications in Annex 6, Annex 7, and Annex 11 respectively contain the most significant changes which were made in connection with JEP 425 Virtual Threads (Preview).

The Final Release of this Specification is expected to include all of the currently described features and updates; however, further changes may be forthcoming. For example, the Expert Group could determine that a feature is not yet be ready for standardization.

Changes to the Java SE Platform Specification are categorized as either features or enhancements. A feature is, roughly speaking, a change of which at least one of the following statements is true:

• It requires two or more weeks of development effort to design and implement,
• It is a significant change worthy of wide review, or
• It is in high demand by the Java community.

Any addition that is not a feature is considered an enhancement.

There is, obviously, room for judgment when interpreting this definition. In order to maximize the visibility of Platform revisions we generally tend to consider borderline items to be features rather than enhancements.

Some Component JSR Specifications previously incorporated into the Platform are still available separately or have significant Specifications themselves. Changes to their Specifications are therefore made in separate Maintenance Releases. The following existing component JSRs may have Maintenance Releases. These will be incorporated by reference before the Final Release of this Specification as necessary:

JSR 269:

Pluggable Annotation-Processing API [MR 13]

Each Component JSR Specification, or revision thereto, may be related to one or more features in the detailed list below.

Work on features in the Java SE 19 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 19 Reference Implementation on a preview basis, to gain exposure before achieving permanent status in a later release of the Java SE Platform.

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 as JNI and JVM TI, and language-independent protocols, such as JDWP and Java 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 in JEP 12 Preview Features.

This section may be compared to the 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:

• An Implementation must issue a warning on the standard error stream every time a restricted method is invoked, except 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 an IllegalCallerException to be thrown, rather than a warning to be issued.)

The restricted methods in Java SE 19 are:

• java.lang.foreign.Linker.nativeLinker
• java.lang.foreign.MemoryAddress.getUtf8String
• java.lang.foreign.MemoryAddress.setUtf8String
• java.lang.foreign.MemoryAddress.get
• java.lang.foreign.MemoryAddress.set
• java.lang.foreign.MemoryAddress.getAtIndex
• java.lang.foreign.MemoryAddress.setAtIndex
• java.lang.foreign.MemorySegment.ofAddress
• java.lang.foreign.SymbolLookup.libraryLookup
• java.lang.foreign.VaList.ofAddress

Preparing for removal of finalization An Implementation must support the finalization of objects, as described in The Java Language Specification, section 12.6. However, this Platform Specification deprecates 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.

The list of Java APIs which are preview features may be found in the Preview API section of the API Specification. They are disabled by default at compile time and run time.

(The Reference Implementation provides the ability to enable the entire set of preview features via the command-line option
--enable-preview to javac and the java launcher.)

The following non-Java APIs and language-independent protocols were added to the Java SE Platform by this Platform Specification. They are enabled by default and cannot be disabled.

JNI Specification

• Function: IsVirtualThread

JVM TI Specification

• Capability: can_support_virtual_threads
• Function: SuspendAllVirtualThreads
• Function: ResumeAllVirtualThreads
• Event type: VirtualThreadStart
• Event type: VirtualThreadEnd

JDWP Specification

• Command: ThreadReference/IsVirtual
• Modifier kind: Event Request/Set.PlatformThreadsOnly

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

A module is a named set of packages designed for reuse. A specification governed by the JCP defines standard packages, and may group them into one or more standard modules.

This Specification groups the standard packages of the Java SE Platform into 21 standard modules, which we refer to as the Java SE modules. The name of a Java SE module always starts with the string "java.". The complete list of such modules is:

java.base java.compiler java.datatransfer java.desktop java.instrument java.logging java.management

java.management.rmi java.naming java.net.http java.prefs java.rmi java.scripting java.se (aggregator)

java.security.jgss java.security.sasl java.sql java.sql.rowset java.transaction.xa java.xml java.xml.crypto

Compared to Java SE 18, this Specification does not add or remove any modules.

The module graph The Java SE modules depend upon each other as stated in their specifications, which are part of the overall API Specification. The corresponding complete Java SE module graph has too many edges to be displayed easily in visual form; here is the transitive reduction of the directed acyclic graph, in which redundant edges are omitted (click to enlarge):

Here is how to read this visualization of the module graph:

• If one module depends upon another, and it grants implied readability to that module via a requires transitive directive, then there is an edge from the first module to the second.

• At the very bottom is the java.base module, which contains essential classes such as java.lang.Object and java.lang.String. The base module depends upon no module, and every other module depends upon the base module.

• At the top is the java.se module, which gathers together all of the modules that comprise the Java SE Platform. This is an example of an aggregator module, which logically gathers the content of other modules by granting implied readability to them, but adds no content of its own. A run-time system configured to contain the java.se module will contain all of the packages of the Java SE Platform.

A module is a Java SE module — that is, considered part of the Java SE Platform Specification — if and only if it is a standard module reachable from the java.se module.

Relaxing strong encapsulation As an aid to migration, previous versions of this Specification permitted an Implementation to provide a means to invoke its run-time system with one or more packages of one or more of its modules open to code in all unnamed modules, i.e., to code on the class path. This is no longer permitted.

(The Reference Implementation provided this capability via the command-line option --illegal-access=permit.)

An Implementation must not relax the strong encapsulation of any of its modules, either by default or upon request. That is, its run-time system must not behave as if some packages in the Implementation’s modules are open when they are not open according to their module declarations. A package, or an entire module, is open to code in all unnamed modules if and only if:

• It is explicitly declared to be open, without qualification, in a module declaration, or
• The run-time system is explicitly invoked to open it to code in all unnamed modules, as provided for below.

This section may be compared to the corresponding section that appeared in Java SE 16.

Incorporated subsections This Specification incorporates the following subsections by reference from Java SE 9 Platform Specification (JSR 379), “Modules”:

• Constraints on Java SE modules
• Constraints on all modules in an Implementation
• Overriding module declarations
• Upgradeable modules The only upgradeable module in this Platform Specification is java.compiler.

No APIs were removed from the Java SE Platform by this Platform Specification.

The following APIs were proposed for removal from the Java SE Platform by the Platform Specifications for Java SE 9, Java SE 10, Java SE 13, Java SE 14, Java SE 16, Java SE 17, and Java SE 18. They are not removed in this release of the Java SE Platform. They continue to be eligible for removal in a future release.

Packages 

• java.applet (17)

Classes 

• java.applet.Applet (17)
• java.applet.AppletContext (17)
• java.applet.AppletStub (17)
• java.applet.AudioClip (17)
• java.beans.AppletInitializer (17)
• java.lang.Compiler (9)
• java.lang.SecurityManager (17)
• java.rmi.RMISecurityManager (17)
• java.security.AccessControlContext (17)
• java.security.AccessController (17)
• java.security.Certificate (10)
• java.security.DomainCombiner (17)
• java.security.Identity (10)
• java.security.IdentityScope (10)
• java.security.Policy (17)
• java.security.Policy.Parameters (17)
• java.security.PolicySpi (17)
• java.security.Signer (10)
• javax.security.auth.SubjectDomainCombiner (17)
• javax.security.cert.Certificate (13)
• javax.security.cert.X509Certificate (13)
• javax.swing.JApplet (17)

Exceptions 

• java.security.AccessControlException (17)
• javax.security.cert.CertificateEncodingException (13)
• javax.security.cert.CertificateException (13)
• javax.security.cert.CertificateExpiredException (13)
• javax.security.cert.CertificateNotYetValidException (13)
• javax.security.cert.CertificateParsingException (13)

Methods 

• java.awt.Graphics.finalize (18)
• java.awt.PrintJob.finalize (18)
• java.beans.Beans.instantiate (17)
• java.lang.Enum.finalize (18)
• java.lang.Object.finalize (18)
• java.lang.Runtime.runFinalization (18)
• java.lang.SecurityManager.checkMulticast (17)
• java.lang.System.getSecurityManager (17)
• java.lang.System.runFinalization (18)
• java.lang.System.setSecurityManager (17)
• java.lang.Thread.checkAccess (17)
• java.lang.Thread.countStackFrames (9)
• java.lang.Thread.resume (14)
• java.lang.Thread.stop (18)
• java.lang.Thread.suspend (14)
• java.lang.ThreadGroup.allowThreadSuspension (14)
• java.lang.ThreadGroup.checkAccess (17)
• java.lang.ThreadGroup.destroy (16)
• java.lang.ThreadGroup.isDaemon (16)
• java.lang.ThreadGroup.isDestroyed (16)
• java.lang.ThreadGroup.resume (14)
• java.lang.ThreadGroup.setDaemon (16)
• java.lang.ThreadGroup.stop (16)
• java.lang.ThreadGroup.suspend (14)
• java.util.concurrent.Executors.privilegedCallable (17)
• java.util.concurrent.Executors.privilegedCallableUsingCurrentClassLoader (17)
• java.util.concurrent.Executors.privilegedThreadFactory (17)
• java.util.concurrent.ThreadPoolExecutor.finalize (18)
• java.util.logging.LogManager.checkAccess (17)
• javax.imageio.spi.ServiceRegistry.finalize (18)
• javax.imageio.stream.FileCacheImageInputStream.finalize (18)
• javax.imageio.stream.FileImageInputStream.finalize (18)
• javax.imageio.stream.FileImageOutputStream.finalize (18)
• javax.imageio.stream.ImageInputStreamImpl.finalize (18)
• javax.imageio.stream.MemoryCacheImageInputStream.finalize (18)
• javax.net.ssl.HandshakeCompletedEvent.getPeerCertificateChain (13)
• javax.net.ssl.SSLSession.getPeerCertificateChain (13)
• javax.security.auth.Subject.doAs(Subject,PrivilegedAction) (18)
• javax.security.auth.Subject.doAs(Subject,PrivilegedExceptionAction) (18)
• javax.security.auth.Subject.doAsPrivileged
      (Subject,PrivilegedAction,AccessControlContext) (17)
• javax.security.auth.Subject.doAsPrivileged
      (Subject,PrivilegedExceptionAction,AccessControlContext) (17)
• javax.security.auth.Subject.getSubject (17)
• javax.swing.RepaintManager.addDirtyRegion (17)

Constructors 

• java.lang.Boolean.<init>(boolean) (16)
• java.lang.Boolean.<init>(String) (16)
• java.lang.Byte.<init>(byte) (16)
• java.lang.Byte.<init>(String) (16)
• java.lang.Character.<init>(char) (16)
• java.lang.Double.<init>(double) (16)
• java.lang.Double.<init>(String) (16)
• java.lang.Float.<init>(double) (16)
• java.lang.Float.<init>(float) (16)
• java.lang.Float.<init>(String) (16)
• java.lang.Integer.<init>(int) (16)
• java.lang.Integer.<init>(String) (16)
• java.lang.Long.<init>(long) (16)
• java.lang.Long.<init>(String) (16)
• java.lang.Short.<init>(short) (16)
• java.lang.Short.<init>(String) (16)
• javax.management.relation.RoleStatus.<init>() (16)

Fields 

• javax.naming.Context.APPLET (17)

The following APIs are proposed for removal from the Java SE Platform by this Platform Specification. They are annotated as @Deprecated with forRemoval=true, following the convention established by Enhanced Deprecation. This makes them eligible for removal in a future release.

Classes  

• javax.swing.plaf.basic.BasicMenuItemUI.MouseInputHandler (19)
• javax.swing.plaf.basic.BasicScrollPaneUI.HSBChangeListener (19)
• javax.swing.plaf.basic.BasicScrollPaneUI.PropertyChangeHandler (19)
• javax.swing.plaf.basic.BasicScrollPaneUI.ViewportChangeHandler (19)
• javax.swing.plaf.basic.BasicScrollPaneUI.VSBChangeListener (19)

Methods  

• javax.swing.plaf.basic.BasicDirectoryModel.intervalAdded (19)
• javax.swing.plaf.basic.BasicDirectoryModel.intervalRemoved (19)
• javax.swing.plaf.basic.BasicDirectoryModel.lt (19)
• javax.swing.plaf.basic.BasicToolBarUI.createFloatingFrame (19)

Additional details about deprecations, including potential alternatives, may be found in the Deprecated API section of the API Specification. Migration away from deprecated APIs is strongly encouraged.