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

[Remi Forax]

> De: "John Rose" <john.r.rose at oracle.com>
> À: "daniel smith" <daniel.smith at oracle.com>
> Cc: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>, "joe darcy"
> <joe.darcy at oracle.com>
> Envoyé: Samedi 9 Mai 2020 22:15:07
> Objet: Re: getPermittedSubclasses() on j.l.rClass returning an array of
> ClassDesc

> On May 9, 2020, at 12:59 PM, Dan Smith < [ mailto:daniel.smith at oracle.com |
> daniel.smith at oracle.com ] > wrote:

>> 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.

> Yes, that was my thought also. Probably because such an API
> is also needed in the design of template classes, at least as currently
> envisioned: A bootstrap method for expanding a template species
> will inevitably need deep access into the “pieces and parts” of the
> template class it is expanding, and those bits will be in symbolic
> form (or lower-level things), not resolved.

> This BTW is one of many reasons we want a symbolic linkage mode
> for indy and condy, in which the BSM is set to run on pre-resolved
> ConstantDesc data.

I think it's worst, you want some type arguments to be already resolved and some not yet to be resolved. 

> Class::getNestMembers does something odd, by providing a way
> to visit related classes without a separate access check. If a nest
> has public and non-public members, you can use a public class
> to visit non-public related classes. The permitted-subs accessor
> is similar, but permitted-subs have more variability; they can
> be in different packages, etc. This means it is more likely that
> a permitted-sub will have lesser access than the top class.

> Here’s something very ugly we could do, FTR. (I’m not
> fully comfortable with any of these choices.) Make the
> new accessor @CallerSensitive (like Class::forName) and
> have it check accessibility. If it throws, it throws away
> any partial information that might have been available.
> That’s how Core Reflection rolls.

Yesterday, i was thinking exactly the same thing, I decide that it doesn't worth it because usually implementation classes leaks because getClass() is not caller sensitive. 

> Or leave it as it is, and allow leakage of inaccessible types,
> throwing only if types are truly non-existent. Trying to
> filter results (to return partial info) is IMO a chase after
> diminishing returns.

> — John

Rémi