User model stacking: current status

[Brian Goetz]

>> With Valhalla, Point is a class, with types Point.ref and Point.val; Point.class is a full-power mirror for Point.ref, and Point.val.class is a limited mirror that is analogous to the int mirror.  If you ask a Point for its getClass(), it always returns Point.class.  It would not bother me if the Point.val.class mirror is fully limited, and the only way to do lookups (e.g., getMethods) is to switch over to the class mirror (for which we'd probably have a `Class::getPrimaryClass` method.)
> That approach seems reasonable for Reflection. For MethodHandles, I
> think we'll need to support MethodHandles.Lookup with both the L & Q
> version to correctly type the receiver argument, at least for virtual
> calls.

Agreed.  Which is a straightforward extension of how we already handle 
the int/Integer story, except that now a receiver is involved too.  Will 
we need new API surface to allow this to be expressed?

>> It's not just nestmate access control; it would be reasonable to declare the val as package-access, and trust your package mates too.
> At the VM-level, classes are either public or package.  While the
> source code also allows specifying private or protected for
> innerclasses, the VM doesn't use those bits for access control (though
> Reflection sometimes does).  That's part of why I'm reaching for
> something else to hang the private bit on (and thus trigger the nest
> check).
>
> I don't think we want to teach the VM to use the inner class flags for
> *some* access checks as it will be easy to confuse when each set of
> flags is used (long bug tail) and will lead to inconsistencies with
> existing programs.
>
> Without some extra "thing" to hang the accessibility bits on, I don't
> think we can express public / package / private (nest) in the existing
> public/package bits used for classes at the VM level.

OK, thanks for connecting those dots for me.