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

[forax at univ-mlv.fr]

> De: "Vicente Romero" <vicente.romero at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Brian Goetz" <brian.goetz at oracle.com>, "Gavin Bierman"
> <gavin.bierman at oracle.com>, "amber-spec-experts"
> <amber-spec-experts at openjdk.java.net>, "joe darcy" <joe.darcy at oracle.com>
> Envoyé: Lundi 26 Octobre 2020 15:15:46
> Objet: Re: getPermittedSubclasses() on j.l.rClass returning an array of
> ClassDesc

> Hi Remi,

> I will update the name, adding the `get` back,

> Thanks,
> Vicente
Many thanks, 
Rémi 

> On 10/24/20 6:32 PM, [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ] wrote:

>> 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" [ mailto:vicente.romero at oracle.com |
>>> <vicente.romero at oracle.com> ]
>>> À: "Remi Forax" [ mailto:forax at univ-mlv.fr | <forax at univ-mlv.fr> ] , "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> ]
>>> 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é: 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/20201026/f1261fd3/attachment-0001.htm>