Default interface methods are especially appropriate when the new method can be
defined in terms of other existing methods in the interface. For examples,
when Collections added isEmpty(), it is basically just a shorthand for
length()==0 [but certain subclasses might still be able to provide a more
efficient implementation, for example a linked list might require traversing
the entire list to get the length, while isEmpty could simply check the head].
For public APIs, adding a new default interface method is safe (will not break
source or binary compatibility), but for internal APIs, we don’t promise
backward compatibility anyway.
The pattern of adding a new default interface method with an empty
implementation does concern me. Perhaps a new interface that extends the
original would be a more compile-time-verifiable way to express that new
optional methods have been added that only some but not all implementations
might implement?
> On May 8, 2020, at 11:31 AM, John Blum <jb...@pivotal.io> wrote:
>
> Another way to think about this is:
>
> 1. First, default methods are not inherently bad. They are useful in many
> situations and can be "overridden" on implementing classes, if necessary.
> 2. A default method should be provided when the operation is not strictly
> required or if the implementation (procedure/algorithm) is rather simple
> (e.g. following the template pattern), for example...
>
> @FunctionalInterace {
> interface Sorter {
>
> default Object[] sort(Object... array) {
> return convert(Arrays.asList(array)).toArray();
> }
>
> <T extends Iterable<?>> T convert(T collection);
>
> }
>
> 3. If the interface footprint is small (as it should be) then it is
> possible to use in *Lambda* expressions (and *Method References*), as
> proper @FunctionalInterface as shown above, which is very useful when
> composing *Streams*, etc.
>
> Food for thought.
>
> -j
>
>
> On Fri, May 8, 2020 at 10:17 AM Jacob Barrett <jbarr...@pivotal.io> wrote:
>
>> As a general rule default implementations on an interface should only used
>> when absolutely necessary because all the implementations are out of your
>> control. For example, the collection interfaces in the JDK all gained new
>> APIs but Java doesn’t implement every instance of them so a default is
>> necessary for forward progress. However, if you own all instances you
>> should not need to use default. So in this particular PR the use of default
>> in the InternalCache in my opinion is wrong. We should control all internal
>> interfaces and therefor can update them all with the correct
>> implementation.
>>
>> -Jake
>>
>>> On May 8, 2020, at 9:49 AM, Kirk Lund <kl...@apache.org> wrote:
>>>
>>> I believe some of the Geode community has already decided that we
>> shouldn't
>>> overuse default methods in interfaces. Dan and others were the ones who
>>> decided this and thus I can't really explain to folks in PRs why it's bad
>>> to overuse default methods. Could some of the folks with strong
>>> understanding of why we should avoid making every method default empty
>>> please speak up here and/or in https://github.com/apache/geode/pull/5014
>> ?
>>>
>>> My understanding is that default implementations should only be provided
>> in
>>> interfaces when it's important to do so for facilitating some sort of
>>> deprecation and replacing a deprecated method.
>>>
>>> Thanks,
>>> Kirk
>>
>>
>
> --
> -John
> Spring Data Team
