getPermittedSubclasses() on j.l.rClass returning an array of ClassDesc

[forax at univ-mlv.fr]

 ----- Mail original -----
> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "daniel smith" <daniel.smith at oracle.com>
> Cc: "Remi Forax" <forax at univ-mlv.fr>, "amber-spec-experts" <amber-spec-experts at openjdk.java.net>, "joe darcy"
> <joe.darcy at oracle.com>
> Envoyé: Lundi 11 Mai 2020 19:10:10
> Objet: Re: getPermittedSubclasses() on j.l.rClass returning an array of ClassDesc

>> The core reflection API has historically been happy to ignore those corner
>> cases. Instead, it's designed for the typical situation where everything is
>> consistent and available. You're somewhat uncomfortable with this design
>> choice, which is fair, but maybe a better long-term path to getting to a less
>> brittle API is to design a new, lower-level API, rather than trying to slowly
>> introduce a new way of doing things into java.lang.Class.
> 
> Maybe.  Right now, reflection is _mostly_ classfile reflection, but with
> a few weird conveniences sprinkled atop (i.e., getMethods() returns all
> public methods, inherited or not), which are just enough to make people
> think that reflection is just a bad implementation of language-level
> reflection.  I would rather pull core reflection _down_ to its true
> spirit (classfile contents), and then separately build more conveniences
> _on top_.

Most of the methods are convenient methods, not only getMethods(), getField(String) or getMethod(String, Class...) are also convenient methods because for the JVMS a method is declaringClass + name + descriptor while the reflection API uses declaringClass + name + parameterTypes, the return type is missing so the reflection API tries to fill that gap.

The reflection API is neither the class file content nor a proper Java mirror, it's in a stasis in between the two, a class file API will be more low level, while a Java mirroring API will be more heigh level.

Rémi