Virtual extension methods -- a strawman design

[Brian Goetz]

>> The attached document reflects our current thinking in the area of
>> extension methods, which was introduced in section 8 of the Strawman
>> proposal.  This document (arguably) improves on the static extension
>> method scheme presented there.
>
> The document is written in a way that gives the impression that
> extension methods are to be used by the JDK 7 platform authors only.
> Is this really your intent?

No, but I could see how it could come across that way.  The intention is that 
this is a mechanism for *library owners* to evolve their already-published 
libraries.  Oracle is certainly an important member of the category of library 
owners, but not the only one.

> The reason I'm wondering is the final sentence in the first paragraph
> of section 4 ("The class file emitted by the compiler implements all
> methods in the interface...") and the first sentence in section 5
> ("Classes compiled by the JDK 7 compiler will not need any special
> treatment").  This is just not true if the feature (that is,
> binary-compatible evolution of interfaces) is available to the general
> public.

Yes, that statement in the document was optimistically incorrect.

> Are there any constraints on the visibility of the default method?
> The obviously loophole-free approach would be to require that they are
> public methods in the same package as the interface itself.  If you
> permit non-public methods here (or public methods in other packages),
> you need to make sure that class authors are aware of the ability to
> reference overridden methods way above in the class hierarchy, which
> might be used to bypass security checks.

That's definitely on the "niggly details that need some thought" list.  As you 
say, public would make everything easy.