DefaultMethods

From APIDesign

(Difference between revisions)
Jump to: navigation, search
(The Sorting Problem)
(The Sorting Problem)
Line 53: Line 53:
</source>
</source>
-
as such the ''JSONList'' can be ''sorted'' without notifying about changes. This is a similar problem as discussed in [[Chapter 8]] of [[TheAPIBook]].
+
as such the ''JSONList'' can be ''sorted'' without notifying about changes. This is a similar problem as with delegation as discussed in [[Chapter 8]] of [[TheAPIBook]]. Adding methods into existing types causes this kind of problems.
 +
 
 +
=== Beware of [[DefaultMethods]] ===
The solution is to [http://hg.netbeans.org/html4j/rev/0b81a0bcf46f overwrite the sort method], but this is the kind of problems we can expect with [[DefaultMethods]] - '''interface''' no longer represents a snapshot of protocol at a time, but can [[evolution|evolve]].
The solution is to [http://hg.netbeans.org/html4j/rev/0b81a0bcf46f overwrite the sort method], but this is the kind of problems we can expect with [[DefaultMethods]] - '''interface''' no longer represents a snapshot of protocol at a time, but can [[evolution|evolve]].

Revision as of 08:59, 24 September 2016

DefaultMethods is a new feature in 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 interface in a backward compatible way for ages. Of course, as usual inJava, only when the JDK team felt the need itself (because of adding a lot of new 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 will have consequences. Here is one.

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 can be the problem?

@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 of course, the problem appeared with DefaultMethods.

The Sorting Problem

If you write this code:

People p = new People();
List<String> names = p.getNicknames();
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 callled. In spite of that, 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);
}

and of course 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. This is a similar problem as with delegation as discussed in Chapter 8 of TheAPIBook. Adding methods into existing types causes this kind of problems.

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 protocol at a time, but can evolve.

Personal tools
buy