Semantics of an empty PermittedSubtypes attribute for the VM

[John Rose]

That’s what I think I said?

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.
> 
> 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> <mailto: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/ce484933/attachment.htm>