Defender methods and compatibility

[Jim Mayer]

Neal and Brian,

Am I right that there are two partially separable issues that Neal is
bringing up?

(1) that Neal would like to remove the rule that allows extension methods to
be defined in two super-interfaces of a class without explicit
disambiguation if the two interfaces specify the same default.  For example:

    interface I { extension void m() default X.a; }
    interface J { extension void m() default X.a; }
    class C implements I, J {}

and

(2) that Neal would like to be able to specify the "default" in-line (with
(1) being a prerequisite for this).

If that's correct, then I'm going to ignore the issue of in-line
specification and just focus on (1) (if incorrect, then I'm going to type
gobbledygook ).

My reading of Neal's argument is that he would like the act of selecting a
different default method for an extension (mod-extn) to be source
compatible.  To get this property, he's willing to push some of the risk of
breaking source compatibility back on to the act of adding an extension
(add-extn).  The justification for this is that "add-extn" cannot be source
compatible anyway, and that removing the rule gives an absolute guarantee of
source compatibility for "mod-extn".

Making this change to the draft specification would make adding identical
extension methods with identical defaults to a set of interfaces that are
likely to be implemented by a single class harder because they would be more
likely to trigger a compile error.  I have no clue as to how often this
would happen in practice.

My questions for Brian, then, are:


   1. What are the specific use cases where being able to specify the same
   default implementation in multiple definitions would make a significant
   difference to the ability to extend an API.
   2. In those cases, are there any workarounds available (e.g., putting the
   common definition of the method into its own interface).

Thanks!

-- Jim

On Sun, Nov 28, 2010 at 10:50 PM, Neal Gafter <neal at gafter.com> wrote:

> On Sun, Nov 28, 2010 at 4:23 PM, Brian Goetz <brian.goetz at oracle.com>
> wrote:
>
> > >>> Anyway, the good news is that mod-extn _is_ SC. That's true whether a
> > >>> default is specified in the interface via a method body or a method
> > name.
> > >>>
> > >>
> > >> Should have said: mod-extn _may be_ SC. When an implementation class
> > >> doesn't override the extension, it's possible for previously-identical
> > >> extension methods to diverge (i.e. one changes its default) and break
> > SC.
> > >>
> > >
> > > Understood.  That is the particular part of the specification that I
> take
> > > issue with.  mod-extn (changing the code of a default method) should
> (in
> > my
> > > opinion) always be source compatible, as the code of a method is a
> prime
> > > example of an implementation detail.
> >
> > Sorry for the delay in responding on this: have been on holiday.
> >
> > The code of the default method *is* an implementation detail.  However,
> the
> > identity of the default method is not.  You can consider it to be a new
> > dimension of the signature, if you like; it is part of the inheritance
> > metadata.  I can see why you would want to consider it an implementation
> > detail -- I wanted to initially as well -- but that's not really how this
> > feature works.
> >
>
> It is clear that's not how it works, and that's the problem with the
> current
> specification.  The default shouldn't have any concept of "identity"
> separate than that of the method itself, nor should the specification add a
> new way for compatibility to be broken.  Otherwise we're introducing a new
> mechanism for making interfaces more flexible, but introducing a new way to
> break source compatibility that makes it far less flexible than it could
> be.  We don't want API designers to have to worry about changing a defender
> method's default in a new version of an API.  Such a change should be
> clearly, obviously, and always source and binary compatible, and API
> designers should have the freedom to make such changes from version to
> version without such breakage.
>
> As a side benefit, such an improved specification enables the default
> implementation to be written inline, instead of indirectly, reducing the
> syntactic footprint of the language change.
>
> But the limitations on SC are not new.  We're used to having certain
> > "subject to" caveats in the definition of SC.  For example, add-meth is
> SC,
> > but in reality only to a point: if the newly added method would cause an
> > illegal override in a subclass, then it is not SC, but this a minor
> enough
> > consideration to be swept under the rug via an asterisk and we consider
> > add-meth to be source compatible.  (Note that the conflict may be with an
> > implementation not known to the class being modified.)
> >
>
> Right.  Adding methods to APIs has always been subject to that kind of
> breakage, even before this proposed language change.  It would be hard to
> imagine this language change making that any better.
>
>
> > The exact same sort of caveat is in operation for mod-extn.  mod-extn is
> > source-comptable, except when it causes a conflict with a subclass that
> > inherits the method *and* the same method with a different default from
> > another (unknown to the modified interface) interface.  While this sort
> of
> > conflict may well be more likely than the sort in the previous example
> (or
> > may not, we're not sure yet), it is definitely of the same flavor.
> >
>
> It isn't the exact same sort of caveat: here the proposal adds a new kind
> of
> incompatibility previously absent from the language.  Changing a method's
> implementation (e.g. its default implementation) has never previously been
> a
> source incompatible change, and for very good reasons.  The software
> engineering principles that led to and are supported by the current
> language
> design appear to have been ignored.
>
> If you consider this new kind of source compatibility issue to be in the
> noise, then you probably also consider the questionable benefits of
> treating
> the defaults as having some sort of identity also to be in the noise.  In
> that case, you should prefer a solution that preserves source
> compatibility.
>
>