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

Vicente Romero vicente.romero at
Sat Oct 24 21:40:58 UTC 2020


The name of the method is still: permittedSubclasses


On 10/24/20 7:35 AM, forax at wrote:
> Ok nice,
> I suppose permittedSubclasses has been renamed to 
> getPermittedSubclasses at the same time.
> Rémi
> ------------------------------------------------------------------------
>     *De: *"Brian Goetz" <brian.goetz at>
>     *À: *"Gavin Bierman" <gavin.bierman at>, "Remi Forax"
>     <forax at>
>     *Cc: *"amber-spec-experts" <amber-spec-experts at>,
>     "joe darcy" <joe.darcy at>
>     *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>  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]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the amber-spec-experts mailing list