Defender methods and compatibility

[Ali Ebrahimi]

Hi All,

On Tue, Nov 30, 2010 at 7:47 AM, Robert Field <robert.field at oracle.com>wrote:

>  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;
>     }
>

with current Spec, source compatibility breaks if  we have two methods:

class Implementations{
      public static int one(A a){ /* */}
      public static int one(B b){ /* */}
}

otherwise, don' t breaks if:
 class Implementations{
      public static int one(Object a){ /* */}
}

>
> 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
>
>
> Ali Ebrahimi