getPermittedSubclasses() on j.l.rClass returning an array of ClassDesc

forax at forax at
Sat Oct 24 22:32:22 UTC 2020

Hi Vicente, 

the 'get' was removed because the method was not returning Class objects, now that permittedSubclasses behave like the other methods of java.lang.Class, 
the name should be changed back to "get..." to reflect that. 


> De: "Vicente Romero" <vicente.romero at>
> À: "Remi Forax" <forax at>, "Brian Goetz" <brian.goetz at>,
> "Gavin Bierman" <gavin.bierman at>
> Cc: "amber-spec-experts" <amber-spec-experts at>, "joe darcy"
> <joe.darcy at>
> Envoyé: Samedi 24 Octobre 2020 23:40:58
> Objet: Re: getPermittedSubclasses() on j.l.rClass returning an array of
> ClassDesc

> Hi,

> The name of the method is still: permittedSubclasses

> Vicente

> On 10/24/20 7:35 AM, [ mailto:forax at | forax at ] wrote:

>> Ok nice,
>> I suppose permittedSubclasses has been renamed to getPermittedSubclasses at the
>> same time.

>> Rémi

>>> De: "Brian Goetz" [ mailto:brian.goetz at | <brian.goetz at> ]
>>> À: "Gavin Bierman" [ mailto:gavin.bierman at |
>>> <gavin.bierman at> ] , "Remi Forax" [ mailto:forax at |
>>> <forax at> ]
>>> Cc: "amber-spec-experts" [ mailto:amber-spec-experts at |
>>> <amber-spec-experts at> ] , "joe darcy" [
>>> mailto:joe.darcy at | <joe.darcy at> ]
>>> Envoyé: Vendredi 23 Octobre 2020 17:36:44
>>> Objet: Re: getPermittedSubclasses() on j.l.rClass returning an array of
>>> ClassDesc

>>> FTR: this was largely a "for consistency" decision, because nestmates does it
>>> the same way. (Which is to say, it was a deliberate suboptimal choice aimed at
>>> minimizing the number of API idioms that users of reflection had to deal with.)

>>> On 10/23/2020 11:27 AM, Gavin Bierman wrote:

>>>> Just to follow this up; we have decided to change the signature of
>>>> permittedSubclasses to the following:

>>>> public Class<?>[] permittedSubclasses() {}

>>>> Thanks!
>>>> Gavin

>>>>> On 8 May 2020, at 23:53, Remi Forax [ mailto:forax at |
>>>>> <forax at> ] wrote:

>>>>> The current draft of the reflection API for the sealed keyword adds a method
>>>>> getPermittedSubclasses() [1] to java.lang.Class.

>>>>> I'm not fully sure that returning an array of ClassDesc is the right choice
>>>>> here, mainly for two reasons,

>>>>> 1/ it's weird to return an array of ClassDesc when all others similar methods
>>>>> return an array of Class,
>>>>>   I know why a ClassDesc might be "better" because it avoid the class loading,
>>>>>  but it also means that now to fully understand java.lang.Class, people has to
>>>>>   understand how java.lang.constant works.
>>>>>  The java.lang.constant API was not designed for that, the first line of the
>>>>>  overview of this package talks about descriptors, constant pool and indy, not
>>>>>   something beginners should worry about.

>>>>> 2/ returning a symbolic view (ClassDesc) instead of a Class is *very* error
>>>>> prone from a user POV, to resolve a ClassDesc to a class, the user as to
>>>>> provide a Lookup
>>>>>  and there is a good chance that users will pick the wrong ones. The number of
>>>>>   people that understand classloading and how Lookup works is < 10,
>>>>>  even experts struggle given the number of time the Lookup API as to be patched
>>>>>   in recent years. Returning a ClassDesc in this context is like asking a child
>>>>>   to read the serial number of a loaded gun.
>>>>>  Perhaps a way to mitigate that is to provide the code a user should use to get
>>>>>   the equivalent classes in the javadoc of getPermittedSubclasses().

>>>>> cheers,
>>>>> Rémi

>>>>> [1] [ |
>>>>> ]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the amber-spec-experts mailing list