Re: defender methods and method of Object

Remi Forax forax at
Fri Mar 9 12:49:01 PST 2012

As you said, Object provides good default implementations but I see no reason why an interface could not provide useful defaults too by example based on some abstract methods defined in the interface too.


Sent from my Phone

----- Reply message -----
From: "Brian Goetz" <brian.goetz at>
To: "Dan Smith" <daniel.smith at>
Cc: "lambda-dev at" <lambda-dev at>, "David Holmes" <david.holmes at>
Subject: defender methods and method of Object
Date: Fri, Mar 9, 2012 20:23

I'm not convinced.  The implementations of equals, hashCode, and 
toString provided by an interface are almost certainly going to be wrong 
for most subclasses that inherit them, whereas the versions provided by 
Object are generally sound, if basic.  (To say nothing of the pain that 
will ensue when someone adds a hashCode/equals method pair to an 
interface implemented by a class that doesn't provide such a pair (which 
is a reasonable choice), and all of a sudden, behavior of that class 
when put into hash-based containers changes wildly.)

On 3/9/2012 12:56 PM, Dan Smith wrote:
> Yes, I've been thinking the same thing.  Since the Object methods are morally members of every interface, it would make sense that a default method could effectively override them, and the "throw out all super methods that have already been overridden" rule could then apply.  It all depends on what order the inheritance conflict-resolution rules are applied in.
> (There's something to the argument in the other direction, though, that it's really nice that if a method is implemented in the class hierarchy, we ignore the interfaces.  It seems like the implementation relies on this pretty heavily, and it could get hairy if every single class had the potential of inherited default methods replacing the behavior of Object methods.)
> —Dan
> On Mar 3, 2012, at 12:45 PM, Sam Pullara wrote:
>> I am all for special casing these. It is far too useful to be able to
>> provide equals()/hashCode()/toString() at the interface level for
>> things like List to not to include this capability. Especially since
>> there is precedent for their special treatment.
>> Sam
>> On Sat, Mar 3, 2012 at 11:19 AM, Yuval Shavit<yshavit at>  wrote:
>>> Well, Object is special-cased in the very definition of an interface (in
>>> 4.10.2), so I could see the case for special-casing it for default
>>> implementations.
>>> On Sat, Mar 3, 2012 at 6:23 AM, David Holmes<david.holmes at>wrote:
>>>> I don't see any reason to special case Object methods. Superclass wins
>>>> over interface with a default - pure and simple.
>>>> David
>>>> On 3/03/2012 2:19 AM, Rémi Forax wrote:
>>>>> On 03/02/2012 05:08 PM, bitter_fox wrote:
>>>>>> Hi,
>>>>>> You have to override toString in A to use the default implementation,
>>>>>> in this case, using the syntax "Interface.super.method()":
>>>>>> (because the definition of super-class is preferred if the extended
>>>>>> definitions from super-class and super-interface are clashing)
>>>>>> public class A implements Foo
>>>>>> {
>>>>>>       public String toString()
>>>>>>       {
>>>>>>           return Foo.super.toString();
>>>>>>       }
>>>>>> }
>>>>>> new A().toString(); // returns "Foo"
>>>>>> However, this calling would be StackOverflowError because the syntax
>>>>>> may be only on "Syntax" and be not implemented for byte code.
>>>>>> I can't judge that semantics is right or wrong, so I only refer to the
>>>>>> way to override.(Although I think it is right...)
>>>>>> Excuse me if you already know the way.
>>>>> No problem.
>>>>> I just think that the semantics should be changed a little bit by adding
>>>>> a special case for method from Object because
>>>>> otherwise the default method will be never called directly
>>>>> (as you said, you can use
>>>>>> Regards,
>>>>>> bitter_fox
>>>>> cheers,
>>>>> Rémi

More information about the lambda-dev mailing list