> On May 11, 2020, at 11:10 AM, Brian Goetz <brian.go...@oracle.com> wrote:
>
>
>> 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.
Language vs. VM is one axis, but it's not the one I'm talking about. The
relevant axis here could be called reified vs. raw, or maybe linked vs.
unlinked. Core reflection has a strong preference for producing fully-formed
objects, rather than names and similar structures that can be "resolved" to
fully-formed objects.
