Semantics of an empty PermittedSubtypes attribute for the VM

[Brian Goetz]

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.

On 4/3/2020 4:48 PM, John Rose wrote:
> On Apr 3, 2020, at 1:36 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
>> I'm mostly thinking of interfaces that will only be implemented by hidden classes.
> In order to do that we need a way to hook the HCs
> into the permits list.  That can be done with a private
> abstract class that nobody extends except the desired HCs.
> The HCs themselves cannot be placed on the permits list
> because they cannot be named, and the permits list contains
> names.  (N.B. the experimental constant pool patching
> mechanism would also, in principle, allow HCs to be
> “named” on permit lists, by direct patching of a relevant
> CP entry.  This is one sort of use case I was thinking of
> when I joined the CP patching feature to the HC prototype.
> Basically, imagine a whole ecosystem of HC hierarchies,
> which would require patching the CPs of their various
> classfiles.  It would be a powerful mess.  But there are
> less powerful ways to get the same effects as CP patching,
> for all the use cases we’ve looked at.)
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20200403/1a65463f/attachment.htm>