On May 9, 2020, at 12:59 PM, Dan Smith <[email protected]> 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
