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

Chris Hegarty chris.hegarty at oracle.com
Tue Oct 27 11:45:13 UTC 2020


While I agree with all comments in this thread so far, I have one additional comment relating to the type parameter.

Since the set of permitted classes must be subclasses of T, should the declaration be:

public Class<? extends T>[] getPermittedSubclasses() { .. }


-Chris.


> On 26 Oct 2020, at 14:15, Vicente Romero <vicente.romero at oracle.com> wrote:
> 
> Hi Remi,
> 
> I will update the name, adding the `get` back,
> 
> Thanks,
> Vicente 
> 
> On 10/24/20 6:32 PM, 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" <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, 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" <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 <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
>> 
>> 
>> 
>> 
> 



More information about the amber-spec-experts mailing list