defender methods and method of Object

Jack Moxley jack at
Tue Mar 13 00:59:59 PDT 2012

I think he has a point, perhaps object is special as it is conceptually both interface and implementation. We have merely hit a design flaw.

Object as the root of all inheritance is a special case all over the shop I am not quite sure why people are so hesitant at allowing it to be different yet again.

Sent from my iPhone

On 13 Mar 2012, at 02:57, Neal Gafter <neal at> wrote:

> This would introduce a cycle into the inheritance graph Object ->
> ObjectDefaults
> -> Object.  Not such a good idea.
> On Mon, Mar 12, 2012 at 5:40 PM, Henri Gerrits <henrigerrits at>wrote:
>> Maybe Object's implementations of equals(), hashCode() and toString() can
>> be moved to a new interface java.lang.ObjectDefaults (ugh!) as (native?)
>> default methods.
>> Object can then implement that interface without providing
>> implementations.  And then no special case is needed for Object methods
>> when applying the conflict resolution rules of section 12, and everyone's
>> happy.
>> Not sure if this is possible, though.
>> Henri
>>  ------------------------------
>> *From:* Dan Smith <daniel.smith at>
>> *To:* Neal Gafter <neal at>
>> *Cc:* David Holmes <david.holmes at>; "lambda-dev at"
>> <lambda-dev at>
>> *Sent:* Monday, March 12, 2012 3:31 PM
>> *Subject:* Re: defender methods and method of Object
>> On Mar 10, 2012, at 1:01 PM, Neal Gafter wrote:
>>> On Sat, Mar 10, 2012 at 5:06 AM, David Holmes <david.holmes at>
>> wrote:
>>> On 10/03/2012 3:56 AM, 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.
>>> If you go down this path then you are throwing away the "superclass
>>> implementation always wins" rule - in which case what rule are you going
>>> to replace that with?
>>> I suspect the rule that Dan is imagining is something like "superclass
>> implementation always wins (except for Object implementation); if none then
>> interface implementation wins; if none then Object implementation wins."
>> Even simpler, actually.  See "State of the Lambda" [1], section 12, the
>> rules described after "Two basic principles drive these rules..."  What is
>> interesting and unique about the Object methods is that _both_ rules apply,
>> and give different answers.  So one of the two, either "class beats
>> interface" or "overrider beats overridden", has to take priority.
>> I'm not wholeheartedly endorsing the idea of the "overrider beats
>> overridden" rule having a higher priority, though.  It's plausible, and I
>> like how it fits pretty cleanly into the model, but the model that prefers
>> the "class beats interface" rule is also pretty clean.  The implications of
>> either approach deserve a lot more thought.
>> —Dan
>> [1]

More information about the lambda-dev mailing list