Evolving interfaces: source/binary compatibility issues

[Brian Goetz]

Yes, this is a known risk.  Note that this is not a new problem 
introduced by default methods; this risk has been around since day 1, in 
that adding a method to a superclass (such as AbstractList) carries this 
exact same risk.  What is new is that we are turning down the 
conservatism knob on adding methods to commonly used supertypes.  This 
is a tradeoff between making the platform more usable for everyone, and 
causing some source incompatibilities.

Unless we're willing to freeze the platform in concrete (we're not), 
what we can do is try and reduce the surface area of potential 
conflicts.  One way we've already done this is by not adding 
filter/map/etc to Collection, but instead adding a stream() method to 
Collection which is less likely to conflict.

Conflicts are also more likely to occur on nilary methods; List.sort() 
is more likely to conflict than List.reduce(Supplier<T>, 
BinaryOperator<T>).  Similarly, conflicts are more likely to occur on 
the "obvious" short names like "sort".

The comment about Comparator.reverse() is well-taken and I'll bring that 
up in our next round of bikeshedding.


On 11/23/2012 10:23 AM, Gernot Neppert wrote:
> Hi all,
>
> when I browsed the Java 8 docs and found that java.util.List finally has
> a method "void sort(Comparator<? super E> comparator)",
> I was quite happy at first.
> Unfortunately, that bliss lasted only until I found that one of my own
> implementations of java.util.List already has such a method - albeit
> "protected".
> This has at least two consequences:
>
> 1. I can't compile my old code against the JDK 8, since it tries to
> implement an interface method with weaker access privileges.
>
> 2. Even worse: if I link my old compiled code against a JDK 8, it may
> raise an "java.lang.IllegalAccessError" at Runtime, since code from the
> new codebase may innociously call back my "sort" method via the interface.
>
> Here are some other methods that are likely to cause trouble, because
> they are obvious extensions likely to be already present in user-code:
>
> java.util.Comparator.reverse()
>
> java.util.Collection.addAll(Iterable)
>
> Do you consider this a real danger or does it seem esoteric?
>
>
>
>
>
>
>
>