Semantics of an empty PermittedSubtypes attribute for the VM
Brian Goetz
brian.goetz at oracle.com
Fri Apr 3 20:52:16 UTC 2020
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>
More information about the amber-spec-experts
mailing list