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