It's not just that it is _inconvenient_ to return the Class, "because of
class loading." It may not be _possible_, as the class may not be
there, but we would still like to be able to reflect what the class says.
So the choices are:
- Don't make this information accessible at all
- Return descriptor strings
- Return ClassDesc
Of the latter two, clearly ClassDesc is better than descriptor strings.
(You could argue that we should go from array to List; this is an OK
option but then the "for consistency" patrol will criticize it.)
I think a better question is: what do we expect people to DO with this
information? That class C permits D doesn't confer anything about what
any given user can do with D; D might be nonexistent, or inaccessible to
some clients. Or it might not have any members that are accessible to
some client. So what would a client plan to do with the Class?
On 5/8/2020 6:53 PM, Remi Forax 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