Hi,
The name of the method is still: permittedSubclasses
Vicente
On 10/24/20 7:35 AM, fo...@univ-mlv.fr wrote:
Ok nice,
I suppose permittedSubclasses has been renamed to
getPermittedSubclasses at the same time.
Rémi
------------------------------------------------------------------------
*De: *"Brian Goetz" <brian.go...@oracle.com>
*À: *"Gavin Bierman" <gavin.bier...@oracle.com>, "Remi Forax"
<fo...@univ-mlv.fr>
*Cc: *"amber-spec-experts" <amber-spec-experts@openjdk.java.net>,
"joe darcy" <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<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
