Draft JVMS changes for Nestmates

[Dan Smith]

> On Apr 19, 2017, at 1:38 AM, John Rose <john.r.rose at oracle.com> wrote:
> 
> "Nest" also connotes a home-like place and therefore privacy.
> (Could also have said "home" or "family"—those are also private spaces.  Or "crib"?)

Sigh. Now I will forever wish we had called this feature "cribs".
https://www.youtube.com/watch?v=cAb54qbMF_k

> Here's a corner case we need to cover:  I have to load my supers before I can load myself.
> If one (or more) of my supers are in the same nest as me, the checking of MoN must succeed
> no matter who is the host class of the nest.
> 
> This could get embarrassing if the host class is the subtype, if the super then needs to
> recursively load the subtype (which is waiting on the supertype to load) before it can
> validate its MoN attribute.  If verification (linking) is started after all of the classes are
> loaded, things are OK, since the MoN checks happen only after everything is loaded.

Yes, I think the earliest we want to be loading MemberOfNest is after superclasses and superinterfaces are loaded (5.3.5 step 4). That avoids the cycle.

> I was surprised to see invokespecial occasionally mentioned cases where it only works on
> private members.  Is that a current constraint, or a new one?
> 
> I thought a class could invokespecial any of its methods, willy-nilly, and this permission
> would seem to extend naturally to nestmates.  (I think I'm forgetting something here.)

The old constraint is that (non-<init>) invokespecial can only reference the current class, a superclass, or a direct superinterface.

The new constraint is that (non-<init>) invokespecial must either reference a private method, or must reference the current class, a superclass, or a direct superinterface.

The purpose of this check is to force outsiders to use virtual dispatch, rather than jumping into the middle of an override chain. But private methods can't be overridden, so an "outsider" from the same nest won't be defeating any restrictions.

(We could grant all members of a nest the right to call invokespecial on all nest members' non-private members and supers, but that's a new feature. Would be similar to granting access to inherited protected members.)

>> When invokespecial involves interface types, the verifier can't guarantee that receiver objects actually implement that interface (JDK-8134358). It's an open question whether this is really a problem, but I included a tentative fix in the invokespecial runtime rules.
> 
> I am leaning towards putting this check in.  If we put it in, it should go in everywhere,
> including invokespecial of default methods, both in and out of the caller's nest.
> I think your language might have allowed an untyped loophole for nestmates.
> 
> My goal in this is simplicity of effect:  There are no loopholes, no exceptions
> to typing of the incoming receiver (L0) of a default method.  If we are going to
> check any of these invokespecial receivers, we must check them all.

The verifier attempts to ensure that:
- For non-<init> invokespecial, the type of the objectref is a subtype of the referenced class/interface
- For non-<init>, non-private invokespecial, the type of the objectref is a subtype of the current class/interface

The proposed rules repeat these two assertions, but with a dynamic check. Private methods are treated differently because they aren't subject to the same constraints. (It could simplify our lives considerably if we had a dedicated `invokeprivate` method, but alas. That's how you should think about it, anyway.)

—Dan