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

[forax at univ-mlv.fr]

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

Rémi 

> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "Gavin Bierman" <gavin.bierman at oracle.com>, "Remi Forax" <forax at univ-mlv.fr>
> Cc: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>, "joe darcy"
> <joe.darcy at oracle.com>
> 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 univ-mlv.fr |
>>> <forax at univ-mlv.fr> ] 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] [ https://bugs.openjdk.java.net/browse/JDK-8244556 |
>>> https://bugs.openjdk.java.net/browse/JDK-8244556 ]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20201024/29647dec/attachment.htm>