JDK-8344943 : Mark not subclassable classes final in java.base exported classes
  • Type: Enhancement
  • Component: core-libs
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2024-11-25
  • Updated: 2024-11-26
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdUnresolved
Related Reports
CSR :  
JDK-8345054 - Mark not subclassable classes final in java.base exported classes
Relates :  
JDK-8210031 - implementation for JVM Constants API
Description
The following public classes in packages exported by java.base are not subclassable (have only private constructors), but are not marked final.

Since none of these top-level classes have subclasses in their nested classes, these can trivially be marked final:

java.lang.invoke.MethodHandleProxies
java.lang.invoke.MethodHandles
java.lang.Runtime
java.nio.charset.CodingErrorAction
java.nio.charset.CoderResult
java.lang.constant.DynamicCallSiteDesc
java.lang.reflect.Modifier
java.lang.runtime.ObjectMethods
java.lang.runtime.SwitchBootstraps
java.net.URLDecoder
java.net.URLEncoder
java.security.DrbgParameters
java.util.Base64
java.util.Collections
java.util.FormattableFlags
java.util.concurrent.Executors
java.util.concurrent.locks.LockSupport  

By extending the search to include classes with at-most package-private constructors, we find the following classes:

java.net.InterfaceAddress
java.lang.module.ModuleDescriptor
java.lang.Package
java.io.OptionalDataException
Comments
Thanks Brian and Vicente for providing context. The CSR JDK-8345054 proposes to reword the note in DynamicCallSiteDesc such that it does not mention subtypes: > This class is immutable and its behavior does not rely on object identity
26-11-2024
So, there was a part of this API that was co-developed but pull backed from the initial version, in which it was possible to subclass DCD. There was a way to canonicalize a DCD that had a well known bootstrap, so that analysis code could deal in subtypes of well-known classes rather than well-known bootstraps. This got deferred (and has not been resumed), which is probably behind the inconsistencies. Since it is a binary-compatible change to go from final to nonfinal, marking it as final now is not irreversible if the original strategy is resurrected.
25-11-2024
I don't remember the context, I think that [~briangoetz] was the one that wrote the API and most of the code. I guess that we can always add a public constructor but not sure if that was the original intention.
25-11-2024
The note about subclassing in DynamicCallSiteDesc was there from the introduction of this class in JDK-8210031, so was the private constructor. Perhaps [~vromero] can comment on why the note about subclassing was added for this non-subclassable class? Just a copy/paste, or was it intentional somehow?
25-11-2024
The API wording for DynamicCallSiteDesc is as if it is extensible; but its private constructor prohibits such subclassing. Don't know what the original intention was.
25-11-2024