Semantics of an empty PermittedSubtypes attribute for the VM

[forax at univ-mlv.fr]

And more generally, 
should the VM offer a way to update the permitted subtypes list dynamically ? 

Most of the mocking API don't work with PermittedSubtypes, either because they try to do sneak a new subtypes using a classloader or for those that are using an agent because they try to change the bytecode at runtime and changing the attribute PermittedSubtypes at runtime is not allowed by JVMTI. 

Rémi 

> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "John Rose" <john.r.rose at oracle.com>
> Cc: "Remi Forax" <forax at univ-mlv.fr>, "amber-spec-experts"
> <amber-spec-experts at openjdk.java.net>
> Envoyé: Vendredi 3 Avril 2020 22:36:32
> Objet: Re: Semantics of an empty PermittedSubtypes attribute for the VM

> I'm mostly thinking of interfaces that will only be implemented by hidden
> classes.

> On 4/3/2020 4:17 PM, John Rose wrote:

>> On Apr 3, 2020, at 6:39 AM, Brian Goetz < [ mailto:brian.goetz at oracle.com |
>> brian.goetz at oracle.com ] > wrote:

>>>> You might think I’m arguing here for allowing S to be
>>>> an empty set, and I might in similar cases, but there are two
>>>> other reasons to outlaw the edge case, rather than ask
>>>> the spec. to account for it (either by extending the general
>>>> rule, or adding a special rule). First, if C wants to permit
>>>> exactly zero subclasses, there’s already a notation for that.

>>> … unless C is an interface.

>> Yes, sure. If there’s a use case for a never-implemented interface
>> (I can think of a few) then we could either (a) allow interfaces to
>> be marked final, or (b) allow empty permit lists, at the cost of
>> the earlier objections (hey, it’s kinda confusing + two ways to
>> say the same thing for non-interfaces).

>> The most straightforward way to get the effect of a never-implemented
>> interface is to give it a permits list which references no implemented types.

>> The most straightforward way to do *that* is make the permits list
>> empty. But there are other ways to get that effect. Make the permits
>> list be a singleton reference to a private class that is either non-existent
>> (never loaded because no classfile) or that is abstract and (somehow)
>> permits no subtypes. In either case the JVM can be asked to observe
>> that no instances are possible.

>> Which tactic is best here? I suppose that depends on the use cases.
>> If we are supposing users will want to use non-implemented
>> interfaces as some sort of design pattern, then “final” interfaces, or
>> empty permits lists, are in the cards. But if it’s some kind of one-off
>> thing (like an interface version of jl.Void) then the notation can be
>> ugly, since it can be done once with adequate explanatory comments.

>> — John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20200403/406afa62/attachment-0001.htm>