Semantics of an empty PermittedSubtypes attribute for the VM
John Rose
john.r.rose at oracle.com
Fri Apr 3 20:58:08 UTC 2020
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>
More information about the amber-spec-experts
mailing list