On 11/05/2020 18:10, Brian Goetz 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. I would rather pull core reflection _down_
to its true spirit (classfile contents), and then separately build
more conveniences _on top_.
I'm all for saying that reflection is a mixed bag in its attempt to be
many different APIs at once, and that at some point it would be nice to
sort that API out. That said, I'd like to point out that, for better or
for worse, reflection already has two ways to deal with missing information:
* throw exception (nestmate attributes do that)
* silently ignore contents (annotations behave like that)
Without making this a consistency argument, one could already argue that
having two different way of failing for what it's essentially the same
underlying condition is already a red herring. But here we're adding a
third way - which instead of failing, returns the view that was
available at compile-time. While I don't necessarily disagree with the
spirit and I agree that in principle that's a sound footing (if we could
also do the same for all the other API points), just introducing it for
a single API point seems to make the situation worse, not better.
Maurizio
