There is no change to the values returned by the system properties java.specification.version and java.vm.specification.version. They continue to report "1.8". The value returned by the newly defined system property java.specification.maintenance.version is "4".

Add a new system property, java.specification.maintenance.version, which returns the maintenance release number of the Java SE specification being implemented by the JDK.

Add the system property to the table in the specification of System.getProperties():

java.specification.maintenance.version

Java Runtime Environment specification maintenance version, may be interpreted as a positive integer (optional, see below)

Add the following details to the specification of System.getProperties():

The java.specification.maintenance.version property is defined if the specification implemented by this runtime at the time of its construction had undergone a maintenance release. When defined, its value identifies that maintenance release. To indicate the first maintenance release this property will have the value "1", to indicate the second maintenance release, this property will have the value "2", and so on.

The Change Specification Request (CSR) associated with this change is 8286766. This specification of java.specification.maintenance.version aligns with the corresponding specification anticipated in the Final Release of
Java SE 19.

Update the specification of Reference.clone() to always throw CloneNotSupportedException.

clone

protected Object clone()
      throws CloneNotSupportedException

Throws CloneNotSupportedException. A Reference cannot be meaningfully cloned. Construct a new Reference instead.

Overrides:
      clone in class Object

Returns:
      never returns normally

Throws:
      CloneNotSupportedException - always

Since:
      8

The CSR associated with this change is 8285099. This specification of Reference.clone() aligns with the corresponding specification in the Final Release of Java SE 11. Unfortunately, the "Returns:" clause in the Java SE 11 specification is misworded; it should have said "never returns normally", as shown above and as shown in the Java SE 12 specification.

Update the specification of PhantomReference to automatically clear reference objects when they are enqueued. This update better aligns PhantomReference with SoftReference and WeakReference.

Update the PhantomReference class specification:

Phantom reference objects, which are enqueued after the collector determines that their referents may otherwise be reclaimed. Phantom references are most often used for scheduling to schedule pre-mortem cleanup actions. in a more flexible way than is possible with the Java finalization mechanism

If Suppose the garbage collector determines at a certain point in time that the referent of a phantom reference an object is phantom reachable , then at . At that time it will atomically clear all phantom references to that object and all phantom references to any other phantom-reachable objects from which that object is reachable. At that the same time or at some later time it will enqueue the reference. those newly-cleared phantom references that are registered with reference queues.

In order to ensure that a reclaimable object remains so, the referent of a phantom reference may not be retrieved: The get method of a phantom reference always returns null.

Unlike soft and weak references, phantom references are not automatically cleared by the garbage collector as they are enqueued. An object that is reachable via phantom references will remain so until all such references are cleared or themselves become unreachable.

Update the java.lang.ref package specification in the following three regions:

Soft references are for implementing memory-sensitive caches, weak references are for implementing canonicalizing mappings that do not prevent their keys (or values) from being reclaimed, and phantom references are for scheduling pre-mortem post-mortem cleanup actions. in a more flexible way than is possible with the Java finalization mechanism
[ ... ]
Some time after the garbage collector determines that the reachability of the referent has changed to the value corresponding to the type of the reference, it will add clear the reference and add it to the associated queue.
[ ... ]
Automatically-cleared references

Soft and weak references are automatically cleared by the collector before being added to the queues with which they are registered, if any. Therefore soft and weak references need not be registered with a queue in order to be useful, while phantom references do. An object that is reachable via phantom references will remain so until all such references are cleared or themselves become unreachable.

The CSR associated with this change is 8285096. These specifications of PhantomReference and java.lang.ref align with the corresponding specifications in the Final Release of Java SE 13.

Update the JNI Specification to align JNI weak global reference with Java phantom references, driven by the change to automatically clear phantom references.

Update the section describing Weak Global References in terms of phantom reachability:

Weak global references are a special kind of global reference. Unlike normal global references, a weak global reference allows the underlying Java object to be garbage collected. Weak global references may be used in any situation where global or local references are used. When the garbage collector runs, it frees the underlying object if the object is only referred to by weak references. A weak global reference pointing to a freed object is functionally equivalent to NULL. Programmers can detect whether a weak global reference points to a freed object by using IsSameObject to compare the weak reference against NULL.

Weak global references in JNI are a simplified version of the Java Weak References, available as part of the Java SE Platform API (java.lang.ref package and its classes).

Clarification (added June 2001)

Weak global references are related to Java phantom references (java.lang.ref.PhantomReference). A weak global reference to a specific object is treated as a phantom reference referring to that object when determining whether the object is phantom reachable (see java.lang.ref). Such a weak global reference will become functionally equivalent to NULL at the same time as a PhantomReference referring to that same object would be cleared by the garbage collector.

Since garbage collection may occur while native methods are running, objects referred to by weak global references can be freed at any time. While weak global references can be used where global references are used, it is generally inappropriate to do so, as they may become functionally equivalent to NULL without notice.

While IsSameObject can be used to determine whether a weak global reference refers to a freed object, it does not prevent the object from being freed immediately thereafter. Consequently, programmers may not rely on this check to determine whether a weak global reference may used (as a non-NULL reference) in any future JNI function call.

IsSameObject can be used to compare a weak global reference to a non-NULL local or global reference. If the objects are the same, the weak global reference won't become functionally equivalent to NULL so long as the other reference has not been deleted.

IsSameObject can also be used to compare a weak global reference to NULL to determine whether the underlying object has been freed. However, programmers should not rely on this check to determine whether a weak global reference may be used (as a non-NULL reference) in any future JNI function call, since an intervening garbage collection could change the weak global reference.

To overcome this inherent limitation Instead, it is recommended that a standard (strong) local or global reference to the same underlying object be acquired using one of the JNI functions NewLocalRef or NewGlobalRef. , and that this strong reference be used to access the intended object These functions will return NULL if the object has been freed. , and otherwise will return a strong reference (which will prevent the object from being freed). The new reference should be explicitly deleted when immediate access to the object is no longer required, allowing the object to be freed Otherwise, the new reference will prevent the underlying object from being freed. The new reference, if non-NULL, can then be used to access the underlying object, and deleted when such access is no longer needed.

The weak global reference is weaker than other types of weak references (Java objects of the SoftReference or WeakReference classes). A weak global reference to a specific object will not become functionally equivalent to NULL until after SoftReference or WeakReference objects referring to that same specific object have had their references cleared.

The weak global reference is weaker than Java's internal references to objects requiring finalization. A weak global reference will not become functionally equivalent to NULL until after the completion of the finalizer for the referenced object, if present.

Interactions between weak global references and PhantomReferences are undefined. In particular, implementations of a Java VM may (or may not) process weak global references after PhantomReferences, and it may (or may not) be possible to use weak global references to hold on to objects which are also referred to by PhantomReference objects. This undefined use of weak global references should be avoided.

Update the "Returns" of JNI NewGlobalRef:

Returns a global reference , or NULL if the given obj value was NULL, or system runs out of memory. to the given obj.

May return NULL if:

• obj refers to null
• the system has run out of memory
• obj was a weak global reference and has already been garbage collected

The CSR associated with this change is 8287056. These specifications of JNI Weak Global References and JNI NewGlobalRef align with the corresponding specifications in the Final Release of Java SE 13.

Modify the specification of Reference.enqueue() to automatically clear reference objects when they are enqueued. This aligns the treatment of reference objects enqueued by application code with the treatment of reference objects by garbage collectors.

Adds Clears this reference object and adds it to the queue with which it is registered, if any.

The CSR associated with this change is 8285101. This specification of Reference.enqueue() aligns with the corresponding specification in the Final Release of Java SE 9.

Retire Runtime.runFinalizersOnExit() (and the associated System.runFinalizersOnExit()) so that it always throws UnsupportedOperationException.

Update the specification of Runtime.runFinalizersOnExit() to read:

runFinalizersOnExit

@Deprecated public static void runFinalizersOnExit(boolean value)

Deprecated. This method was originally designed to enable or disable running finalizers on exit. Running finalizers on exit was disabled by default. If enabled, then the finalizers of all objects whose finalizers had not yet been automatically invoked were to be run before the Java runtime exits. That behavior is inherently unsafe. It may result in finalizers being called on live objects while other threads are concurrently manipulating those objects, resulting in erratic behavior or deadlock.

Throws UnsupportedOperationException.

Parameters:
      value - ignored

Since:
      JDK1.1

Update the specification of System.runFinalizersOnExit() to read:

runFinalizersOnExit

@Deprecated public static void runFinalizersOnExit(boolean value)

Deprecated. This method was originally designed to enable or disable running finalizers on exit. Running finalizers on exit was disabled by default. If enabled, then the finalizers of all objects whose finalizers had not yet been automatically invoked were to be run before the Java runtime exits. That behavior is inherently unsafe. It may result in finalizers being called on live objects while other threads are concurrently manipulating those objects, resulting in erratic behavior or deadlock.

Throws UnsupportedOperationException.

The call System.runFinalizersOnExit() is effectively equivalent to the call:

      Runtime.runFinalizersOnExit()

Parameters:
      value - ignored

Since:
      JDK1.1

See Also:
      Runtime.runFinalizersOnExit(boolean)

The references to "running finalizers on exit" in Runtime.exit(), Runtime.addShutdownHook(), and Runtime.halt() are all removed.

Update the Runtime.exit() specification:

The virtual machine's shutdown sequence consists of two phases. In the first phase all All registered shutdown hooks, if any, are started in some unspecified order and allowed to run concurrently until they finish. In the second phase all uninvoked finalizers are run if finalization-on-exit has been enabled. Once this is done the virtual machine halts.

If this method is invoked after the virtual machine has begun its all shutdown sequence then if shutdown hooks are being run this method will block indefinitely. If shutdown hooks have already been run and on-exit finalization has been enabled the status is nonzero then this method halts the virtual machine with the given status code. if the status is nonzero; otherwise, it Otherwise, this method blocks indefinitely.

Update the Runtime.addShutdownHook() specification:

When all the hooks have finished it will then run all uninvoked finalizers if finalization-on-exit has been enabled. Finally, the virtual machine will halt.

Update the Runtime.halt() specification:

Unlike the exit method, this method does not cause shutdown hooks to be started. and does not run uninvoked finalizers if finalization-on-exit has been enabled If the shutdown sequence has already been initiated then this method does not wait for any running shutdown hooks or finalizers to finish their work.

The CSR associated with this change is 8287133. These specifications of Runtime.exit(), Runtime.addShutdownHooks(), and Runtime.halt() align with the corresponding specifications in the Final Release of Java SE 11.