----- Mail original ----- > De: "Brian Goetz" <[email protected]> > À: "daniel smith" <[email protected]> > Cc: "Remi Forax" <[email protected]>, "amber-spec-experts" > <[email protected]>, "joe darcy" > <[email protected]> > 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
