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

John Rose john.r.rose at
Sat May 9 20:15:07 UTC 2020

On May 9, 2020, at 12:59 PM, Dan Smith <daniel.smith at> 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.

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.

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the amber-spec-experts mailing list