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
