Defender methods and compatibility

Alex Buckley alex.buckley at oracle.com
Mon Nov 29 16:12:51 PST 2010


Hi Nathan,

On 11/29/2010 3:17 PM, Nathan Bryant wrote:
> Neal,
> 
> Maybe I just don't get it. In Brian and Oracle's version, changing the
> default may be source incompatible, only if the change is to which
> static method provides the default. Changing the body of that static
> method should usually be source compatible.
> 
> In your preferred solution, there is no source compatibility at all, in
> the case where two superinterfaces wish to provide defenders for the
> same method. Requiring the implementing class to resolve the ambiguity
> is not source compatible.

In Neal's scheme, mod-extn is always SC because any ambiguity that could 
occur in an implementation class was _already_ disambiguated when the 
second extension method was _added_. (Jim Mayer is quite right in his 
observation that inline defaults "push some of the risk of breaking 
source compatibility back on to the act of adding an extension (add-extn).")

It's a clever trick, but throwing away the ability to compare default 
methods is a huge disadvantage given that a single class may obtain 
defaults from a _graph_ of superinterfaces not just a tree.

Alex


More information about the lambda-dev mailing list