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

[Maurizio Cimadamore]

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