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

[forax at univ-mlv.fr]

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. 

Rémi 

> De: "Vicente Romero" <vicente.romero at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>, "Brian Goetz" <brian.goetz at oracle.com>,
> "Gavin Bierman" <gavin.bierman at oracle.com>
> Cc: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>, "joe darcy"
> <joe.darcy at oracle.com>
> 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 univ-mlv.fr | forax at univ-mlv.fr ] wrote:

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

>> Rémi

>>> De: "Brian Goetz" [ mailto:brian.goetz at oracle.com | <brian.goetz at oracle.com> ]
>>> À: "Gavin Bierman" [ mailto:gavin.bierman at oracle.com |
>>> <gavin.bierman at oracle.com> ] , "Remi Forax" [ mailto:forax at univ-mlv.fr |
>>> <forax at univ-mlv.fr> ]
>>> Cc: "amber-spec-experts" [ mailto:amber-spec-experts at openjdk.java.net |
>>> <amber-spec-experts at openjdk.java.net> ] , "joe darcy" [
>>> mailto:joe.darcy at oracle.com | <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/20201025/d614b136/attachment.htm>