Q: Why is java.lang.Runtime non-final?

[Eirik Bjørsnøs]

On Fri, Nov 22, 2024 at 4:47 AM Joseph D. Darcy <joe.darcy at oracle.com>
wrote:

> PS it would be a "small matter of programming" to write an annotation
> processor to find the not subclassable public classes in the JDK that were
> not marked final.
>
Joe, your bait was too hard to resist.

These are the non-final, not subclassable, public, non-enum classes, in
packages with unqualified exports in java.base:

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

All of these compiles fine with final added. (Note a subclass can access a
private constructor if enclosed by the same class (is this called a nest?)

What is the compatibility impact of adding final to the above classes. It
will perhaps require a CSR in any case?

Cheers,
Eirik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20241122/23517f20/attachment.htm>