extension method implementations for methods of java.lang.Object

Thomas Jung thomas.andreas.jung at googlemail.com
Thu Aug 19 06:12:13 PDT 2010


That's clear. To support this use cases the method resolution rules
would have to be changed (i.e. complicated).

Thomas

On 19 August 2010 15:05, Brian Goetz <brian.goetz at oracle.com> wrote:
> But, even given that, in this case the resolution for a call to equals()
> would go straight to Object.equals(), since we only consult defaults if the
> object does not already have an implementation from its inheritance
> hierarchy.  All objects already have an equals().
>
> On 8/19/2010 4:50 AM, Maurizio Cimadamore wrote:
>>
>> On 19/08/10 08:59, Thomas Jung wrote:
>>>
>>> Hi,
>>>
>>> with the current prototype it's not possible to define a default
>>> implementation for Object#equals.
>>>
>>> interface A{
>>>        extension boolean xequals(Object obj) default As.eq;
>>>        extension boolean equals(Object obj) default As.eq;
>>> }
>>>
>>> static class As{
>>>        public static boolean eq(A me, Object object){
>>>                throw new RuntimeException();
>>>        }
>>> }
>>>
>>> a.equals(new Object());    //passes
>>> a.xequals(new Object());  //throws exception
>>>
>>> This feature is useful if the equals implementation for some subtypes
>>> of A can be expressed based on the methods defined in A.
>>>
>> The VM extension required to handle extension methods at runtime is not
>> available yet - as a result it is not possible to get to execute the
>> above code (or any code containing extension methods) with the right
>> semantics... in fact, since the runtime infrastructure is missing, the
>> VM gets method dispatching completely wrong - the invokevirtual
>> targeting A.equals() is dispatched to Object.equals() while for
>> A.xequals() the VM complains because it cannot find a suitable
>> implementation of xequals() inside the instance 'a'.
>>
>> Maurizio
>>>
>>>   -
>>> Thomas
>>>
>>>
>>
>>
>


More information about the lambda-dev mailing list