Virtual extension methods -- second draft

[Brian Goetz]

> In section (3), method dispatch, it isn't clear if this is discussing
> compile-time behavior or runtime behavior, nor is it clear is this is
> describing the behavior when the qualifying type is a class or the
> qualifying type is an interface.

The first draft badly conflated compile-time and run-time behavior.  This 
draft attempts to do better by first describing the runtime semantics, and 
only then discussing possible implementation techniques, both compile-time and 
run-time.  After an initial bout of optimism where I thought most of this 
could be done at compile time and the runtime behavior would be a "safety 
net", I have come around to the conclusion that it is better to push as much 
of the behavior to runtime as implementation considerations allow (which is a 
good fit for invokedynamic.)  Anything the static compiler would do would be 
more of a "helping the runtime get there faster."

The method dispatch section attempts to describe the semantics of a method 
invocation of a defender method.  There are a lot of things to work out, 
including which invoke instructions are generated by the compiler (virtual, 
interface, dynamic) at the call site, and whether the others actually have 
semantics.  Despite the improvements from V1 to V2, its still a draft, with 
the aim of discovering whether this is a practical means of achieving the real 
goal -- library evolution.

> The full matrix must be described.

Agreed, just not down at the JVMS level yet.

> Taking the section more literally, it appears to be discussing runtime
> dispatch of an invokeinterface invocation where the receiver type in
> the constant pool is D.

Or an invokedynamic.

> But the section discusses walking up the
> superclass hierarchy from D.  Since D is an interface, its direct
> supertype is Object, and there are no intermediate supertypes.

The intention of this section (though I did not make this clear) is that D is 
a class, and the invoke in question is an invokevirtual or invokedynamic.

> Perhaps some of the mentions of "D" in this section should instead be
> referring to the actual runtime class of the receiver.

That's what I meant.

> In section (3.1), resolving ambiguity, this describes one kind of
> failure at runtime.  Is there a corresponding compile-time error to
> avoid these?

Yes, of course, but this is not enough to keep such bytecodes from arriving at 
the VM, so the VM has to be prepared for this too.

> Section (13) seems to assume that the
> previous API suite had no defender methods, but the binary
> compatibility implications of adding defender methods when some may
> already be present should be explained.

Yes, we'll start with a clean slate, but over time the slate will get dirtied 
and slate maintenance must be planned for.

> Nice work, by the way.

Thanks!