Defender methods and compatibility

[Nathan Bryant]

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.

Nathan

-----Original Message-----
From: lambda-dev-bounces at openjdk.java.net
[mailto:lambda-dev-bounces at openjdk.java.net] On Behalf Of Neal Gafter
Sent: Monday, November 29, 2010 5:28 PM
To: Reinier Zwitserloot
Cc: lambda-dev at openjdk.java.net
Subject: Re: Defender methods and compatibility

On Mon, Nov 29, 2010 at 9:53 AM, Reinier Zwitserloot <
reinier at zwitserloot.com> wrote:

> When is the currently proposed "default method is part of the
signature"
> aspect going to result in a problem? If this is about ideological
purity,
> then I vote we stop painting this bikeshed.
>

An interesting reference to Parkinson's *law of triviality*.  The basis
of
Parkinson's law is that people seem to care less about issues they don't
understand, no matter how important those issues might be relative to
the
issues for which they express a preference.  "painting this bikeshed" is
an
*ad hominem *suggestion that the participants in this discussion are
really
only commenting on those issues simple enough for them to understand.

In this case, however, you also appear to be saying that you don't fully
appreciate the issue, and therefore don't see any point in continuing
the
discussion.  Which ironically reinforces the reference to Parkinson's
law.

To be (hopefully) more clear, here are the costs of the current
approach:
o New syntax for extension methods (as opposed to using the existing
method
body syntax)
o Changing the default of an extension method is not source compatible
(in
the sense that it can cause some existing clients to no longer compile)
o Under the current draft spec, not binary compatible either, but there
have
been promised (as yet unexplained) complexities to be added to method
resolution (and therefore the JVM) that may be introduced to reduce this
effect.

Here are the benefits:
o Certain compile-time ambiguities might be avoided when extension
methods
in unrelated classes have the same signature and implementation.

The practical impact of the source incompatibility is that an API
designer
cannot change an extension method's default without potentially breaking
some clients (i.e. causing them to no longer compile).  That is so
because
the API designer generally does not possess all of the client code of
the
API to test against to ensure they all still compile.  Changing the
default
implementation is just the sort of change an API designer would want to
make
from one release to another to, for example, improve performance.  But
the
fact that it is an incompatible change inhibits the API designer from
making
such changes in the future.  As a consequence, the language feature as
proposed is more likely to result in future APIs that have more (rather
than
fewer) artifacts of their history.  Historical artifacts are one of the
pain
points of the Java platform that we'd be better off minimizing.

The default of an extension method is not a part of the
programmer-visible
API in any useful, observable sense *except to the extent that it can
introduce this incompatibility.*