AbstractList etc. functionality as interfaces with default methods?

[Peter Levart]

On 05/14/2015 03:16 AM, Brian Goetz wrote:
> Not only is there a problem with modCount, but also with equals/hashCode/toString.  You can’t define these Object methods in an interface.

They could be defined as static methods to delegate to. From API 
consistency perspective, we have for example the following static 
methods on primitive wrapper classes:

Boolean.hashCode(boolean)
Byte.hashCode(byte)
Character.hashCode(char)
Short.hashCode(short)
...

They are defined to return the same as instance methods of corresponding 
wrapper classes. What I am missing sometimes is the equivalent of equals 
methods:

Boolean.equals(boolean, boolean)
Byte.equals(byte, byte)

That's perhaps because one can use '==' operator instead, but the 
definition of '==' operator is different for float and double values 
from corresponding .equals() methods for their wrapper classes. If for 
nothing else, static equals methods could be useful to avoid boxing the 
primitive to access the semantics of wrapper .equals().

Bringing this to List interface, there could be three static methods 
implementing the basic List contract:

static int hashCode(List<?> list) { ... }
static boolean equals(List<?> list, Object obj);
static String toString(List<?> list);

Fortunately, static interface methods are not "inherited" so they don't 
pollute the namespace of implementing classes and can't be invoked via 
instance either so they don't pollute the IDE auto-completion pop-ups.

Regards, Peter

>
> On May 8, 2015, at 5:41 AM, Attila Szegedi <attila.szegedi at oracle.com> wrote:
>
>> So I’m in a position where I’d need to have a class implement List, but it already extends something else, so I can’t have it extend AbstractList, which leaves me with a lot of boilerplate methods to implement.
>>
>> Would it seem like a good idea to reimagine AbstractList and friends as interfaces with default methods?
>>
>> Of course, I know that technically for backwards compatibility we can’t really do this, but what we could do is:
>>
>> public interface DefaultList<T> extends List<T> {
>>     … add all methods from AbstractList here as default methods …
>> }
>>
>> public abstract class AbstractList<T> implements DefaultList<T> {
>> }
>>
>> (I’ll hand-wave the issue of “protected int modCount” issue for now.)
>>
>> Actually, this seems like such an obvious idea that I’m 100% sure it must’ve been considered before, but I can’t find any related discussion.
>>
>> Attila.