Defender methods and compatibility

[Robert Field]

  hmmm..., there are a couple of related branch topics (method body 
location, use-site); Sticking with source compatibility...

Assuming a user class X:

     class X implements A, B { }

The interfaces A and B could evolve in the following sequence (where 
some steps could be combined):

0: initial

     interface A {
     }

     interface B {
     }

1: add one default:

     interface A {
         public int get() default Implementations.one;
     }

     interface B {
     }

2: add the same default to B:

     interface A {
         public int get() default Implementations.one;
     }

     interface B {
         public int get() default Implementations.one;
     }

3: change B's default:

     interface A {
         public int get() default Implementations.one;
     }

     interface B {
         public int get() default Implementations.two;
     }

With the current spec, source compatibility breaks (X would have to add 
a "get" method to disambiguate) at step 3.  With Neal's proposal, it 
would break at step 2.  The only "pretty" options would be to have it 
break at step 1 (which, of course would defeat the whole purpose of 
having default methods) or to not have it break at all which would mean 
a (very un-Java-like) ordering on interfaces and the corresponding 
user-perceived "magic" of when things work.

I have to agree with Howard and Rémi/Nathan's arguments that step 2 
would be a rare beast.  Which leaves little difference twixt the two.

-Robert