Lots of static methods in an interface

[Daniel Latrémolière]

> Right.  More generally, there are things to love about this approach (no
> garbage side-classes, fewer "magic" place(s) to look for relevant static
> methods), and things to worry about (messing up the interface with lots
> of methods of varying relevance.)  I think we should embrace both the
> love and the worry.
>
> In reality, I think the two poles -- the "old way" (put everything in a
> side class) and "put everything in the interface" are both probably
> excessive extremes.  The poster child for this tension is Collections;
> do we really want *all* of these methods in Collection?  Some are pretty
> esoteric.
Some methods can also be merged by becoming default methods and using 
override of return type. By example, all unmodifiable*, synchronized*,  
checked* methods can become only three default methods:

|public interface Collection<E> {||
||
||    public default Collection<E> asUnmodifiable() {||
||        return Collections.unmodifiableCollection(this);||
||    }||
||||
||    public default Collection<E> asSynchronized() {||
||        return Collections.synchronizedCollection(this);||
||    }||
||||
||    public default Collection<E> asChecked(Class<E> type) {||
||        return Collections.checkedCollection(this, type);||
||    }||
||||
||}||
||
||public interface List<E> {||
||||
     @Override
||    public default List<E> asUnmodifiable() {||
||        return Collections.unmodifiableList(this);||
||    }||
||||
|||||    @Override
|||    public default List<E> asSynchronized() {||
||        return Collections.synchronizedList(this);||
||    }||
||||
|||||    @Override
|||    public default List<E> asChecked(Class<E> type) {||
||        return Collections.checkedList(this, type);||
||    }||
||||
||}|

etc. for each collection specializing its return type as itself.

Daniel.