Defender methods and compatibility

[Alex Buckley]

On 11/30/2010 9:56 AM, Neal Gafter wrote:
> Or consider a more elaborate example: First, Google provides the
> third-generation "collections" APIs with static methods for operations that
> Oracle did not include as extension methods.
> 
> Then, someone (say, you) defines extension interfaces that use these as
> defaults.
> 
> Later, Google improves the implementation of these methods by providing
> strictly more specific, behaviorally compatible static overloads.  That is
> normally a source and binary compatible change.  However, because the
> defaults are specified in your sources by name only, when you recompile you
> get the new, improved implementation as your default in only those
> interfaces that are subtypes of the new first argument (receiver) type.
> This can cause your sources to compile just fine if the conflict doesn't
> arise in your source.  But it can break the source code of third parties
> that implement your extension interfaces.

Yes; this echoes Ali's point, where overloading of static methods 
specified as defaults can break SC for the interface specifying the 
defaults. A partial solution is for an interface method with a default 
to denote the full signature of the default. An interface owner who 
moves from an older Google method to a newer, more specific (in the 
first arg) Google method is then clearly doing a mod-extn, and may have 
to answer to annoyed implementers.

> Who do we blame for the problem? ... You might blame Google for adding
> overloads to existing methods, but Google would rightfully point out that
> the new overloads are strictly more specific than the old ones and
> behaviorally compatible (only more efficient).  

Nevertheless, adding a method has never been guaranteed to be source 
compatible.

Alex