Defender methods and compatibility

[Neal Gafter]

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.