Semantics of an empty PermittedSubtypes attribute for the VM

John Rose john.r.rose at oracle.com
Fri Apr 3 21:03:45 UTC 2020


On Apr 3, 2020, at 1:52 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
> 
> An easier way to get there might be:
> 
>     public sealed interface I 
>         permits C { }
> 
>     private non-sealed abstract class C implements I { }
> 
> and have the HCs extend C.

Also, as a special case, if no such HCs ever show up,
then the JVM can infer that (at least for now) the
interface I has no implementors at all.

This can be enforced more permanently by this formula:

    public sealed interface I 
        permits C { }
    private final class C { private C() {} }

Here, the JVM would be encouraged (somehow) to believe
that C is never instantiated; a belief that is easy to verify
by observing that C::new is never executed.

To enforce it even more statically I think we would need
a class which is both abstract and final.

    public sealed interface I 
        permits C { }
    private abstract final class C { }

Offhand I can’t think of an equally “airtight” way to define a class
this is (a) never directly instantiated and (b) never subclassed.

— John


More information about the amber-spec-experts mailing list