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

forax at univ-mlv.fr forax at univ-mlv.fr
Tue Oct 27 11:51:42 UTC 2020


----- Mail original -----
> De: "Chris Hegarty" <chris.hegarty at oracle.com>
> À: "Vicente Romero" <vicente.romero at oracle.com>
> Cc: "Remi Forax" <forax at univ-mlv.fr>, "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Envoyé: Mardi 27 Octobre 2020 12:45:13
> Objet: Re: getPermittedSubclasses() on j.l.rClass returning an array of ClassDesc

> 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() { .. }


Hi Chris,
in theory yes,
in practice, an array of parametrized types is usually unsafe, in this peculiar case, it's always unsafe because you can write

Class<? extends Itf>[] array = Itf.class.getPermittedSubclasses();
Object[] array2 = array;
array2[0] = Object.class;

Itf itf = array[0].newInstance();  // CCE, the compiler insert a cast to Itf and Object doesn't implement Itf

> 
> 
> -Chris.

Rémi

> 
> 
>> 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