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.rom...@oracle.com> > À: "Remi Forax" <fo...@univ-mlv.fr>, "Brian Goetz" <brian.go...@oracle.com>, > "Gavin Bierman" <gavin.bier...@oracle.com> > Cc: "amber-spec-experts" <amber-spec-experts@openjdk.java.net>, "joe darcy" > <joe.da...@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:fo...@univ-mlv.fr | fo...@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.go...@oracle.com | >>> <brian.go...@oracle.com> ] >>> À: "Gavin Bierman" [ mailto:gavin.bier...@oracle.com | >>> <gavin.bier...@oracle.com> ] , "Remi Forax" [ mailto:fo...@univ-mlv.fr | >>> <fo...@univ-mlv.fr> ] >>> Cc: "amber-spec-experts" [ mailto:amber-spec-experts@openjdk.java.net | >>> <amber-spec-experts@openjdk.java.net> ] , "joe darcy" [ >>> mailto:joe.da...@oracle.com | <joe.da...@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:fo...@univ-mlv.fr | >>>>> <fo...@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 ]
