Semantics of an empty PermittedSubtypes attribute for the VM

forax at forax at
Fri Apr 3 21:42:28 UTC 2020

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. 


> De: "Brian Goetz" <brian.goetz at>
> À: "John Rose" <john.r.rose at>
> Cc: "Remi Forax" <forax at>, "amber-spec-experts"
> <amber-spec-experts at>
> 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 |
>> brian.goetz at ] > 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: <>

More information about the amber-spec-experts mailing list