Hi Remi,
I will update the name, adding the `get` back,
Thanks,
Vicente
On 10/24/20 6:32 PM, [email protected] 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" <[email protected]>
*À: *"Remi Forax" <[email protected]>, "Brian Goetz"
<[email protected]>, "Gavin Bierman" <[email protected]>
*Cc: *"amber-spec-experts" <[email protected]>,
"joe darcy" <[email protected]>
*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, [email protected] wrote:
Ok nice,
I suppose permittedSubclasses has been renamed to
getPermittedSubclasses at the same time.
Rémi
------------------------------------------------------------------------
*De: *"Brian Goetz" <[email protected]>
*À: *"Gavin Bierman" <[email protected]>, "Remi
Forax" <[email protected]>
*Cc: *"amber-spec-experts"
<[email protected]>, "joe darcy"
<[email protected]>
*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<[email protected]>
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
