DefaultMethods

From APIDesign

Revision as of 10:35, 5 March 2018

DefaultMethods are a new feature of JDK8 which breaks the clear separation between Java interface (only specifies a contract) and class (provides some implementation). Many members of the Java community were crying for having a way to add methods into already published interface in a backward compatible way for ages. Of course, as usual in Java, only when the JDK team felt the need itself (because of adding a lot of new Lambda methods into Collection & co. classes), it listen to the general request.

On the other hand, there were people claiming that DefaultMethods are bad - that an interface should be a code-less specification and the change would have consequences. Here is one.

Useful?

From one point of view, it is a useful concept. Especially if one paints himself into a corner by not following advices of TheAPIBook when designing the first version of the API. If one mixes client and provider API into one type - like List, then one gets into trouble. On one side people call into the type (e.g. use it as ClientAPI). On the other hand, they also implement it - like ArrayList - but also numerous custom implementations written by developers around the globe - e.g. use it as ProviderAPI.

Later one needs to add new methods into the ClientAPI side of the contract. In such situation one is going to welcome default methods as a nice way to help one get out of the corner. By adding default methods one can enhance the ClientAPI part of the interface, while keeping (most of) the compatibility for those who implement the interface.

However the concept of default methods also comes with drawbacks.

By-Passing Your Interface

When I was implementing netbeans:Html4Java API, I had to create an observable list - so I did it and created JSONList. I've carefully overwritten each public method that modified the list state and called a change notification handler. What could go wrong?

@Override
public boolean add(T e) {
  boolean ret = super.add(e);
  notifyChange();
  return ret;
}

I thought I did everything correctly, as all the methods of the List interface were properly overwritten. But (as you can probably guess) a problem appeared with DefaultMethods.

The Sorting Problem

If you write this code:

People p = new People();
List<String> names = p.getNicknames(); // returns the JSONList implementation
Collections.sort(names);

it works properly on JDK7, but it gets broken on JDK8. The code needs to compile on JDK7, so no DefaultMethods (introduced in JDK8) are called. In spite of that the code behaves differently on JDK8 and the notification change isn't delivered!

The problem is that the static sort method in Collections does the sorting by itself in JDK7, but in JDK8 it delegates to List.sort:

public static <T extends Comparable<? super T>> void sort(List<T> list) {
    list.sort(null);
}

In addition to that there is an optimized implementation of sort in ArrayList that bypasses all existing (at time of JDK7) methods and sorts directly the internal array:

@Override
@SuppressWarnings("unchecked")
public void sort(Comparator<? super E> c) {
    final int expectedModCount = modCount;
    Arrays.sort((E[]) elementData, 0, size, c);
    if (modCount != expectedModCount) {
        throw new ConcurrentModificationException();
    }
    modCount++;
}

as such the JSONList can be sorted without notifying about changes. None of the methods known in JDK7 is called and yet the content of the array is altered.

This is a similar problem as the one with delegation and adding new methods into existing types as discussed in Chapter 8 of TheAPIBook.

Beware of DefaultMethods

The solution is to overwrite the sort method, but this is the kind of problems we can expect with DefaultMethods - interface no longer represents a snapshot of a protocol at a time, it evolves (which is what we wanted), but also with all the (sometimes unwanted) consequences.