You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Michael Dürig <md...@apache.org> on 2012/02/09 23:45:20 UTC

[jr3 Microkernel] equals() not symmetric

Hi,

I stumbled upon this by chance: The equals method for the classes 
ChildNodeEntriesMap and ChildNodeEntry is not symmetric. This will most 
certainly lead to subtle bugs later on.

Michael

Re: [jr3 Microkernel] equals() not symmetric

Posted by Michael Dürig <md...@apache.org>.
On 10.2.12 11:00, Ard Schrijvers wrote:
> On Fri, Feb 10, 2012 at 11:41 AM, Stefan Guggisberg
> <st...@gmail.com>  wrote:
>> On Thu, Feb 9, 2012 at 11:45 PM, Michael Dürig<md...@apache.org>  wrote:
>>>
>>> Hi,
>>>
>>> I stumbled upon this by chance: The equals method for the classes
>>> ChildNodeEntriesMap and ChildNodeEntry is not symmetric.
>>
>> hmm, i am pretty sure they're symmetric, i.e.: a.equals(b) == b.equals(a)
>
> They look symmetric to me as well. Unless you refer to the Bucket innerclass
>
> ChildNodeEntriesMap#Bucket : This one has an invalid equals method
> breaking symmetry : Using super.equals in an equals implementation
> almost always breaks symmetry

BTW, AFIK the only way to get equals() right wrt. sub-typing is to use a 
double dispatch through a second helper method. Quite similar to the 
visitor pattern.

Michael

>
> Regards Ard
>
>>
>> or are you referring to the missing hashCode() override?
>> i admit that i've been lazy since those internal objects are not
>> intended to be used as keys for hash tables and sorts.
>>
>> but you're probably right, it doesn't hurt to implement them :)
>>
>> cheers
>> stefan
>>
>>> This will most
>>> certainly lead to subtle bugs later on.
>>>
>>> Michael
>
>
>

Re: [jr3 Microkernel] equals() not symmetric

Posted by Michael Dürig <md...@apache.org>.

On 10.2.12 11:00, Ard Schrijvers wrote:
> On Fri, Feb 10, 2012 at 11:41 AM, Stefan Guggisberg
> <st...@gmail.com>  wrote:
>> On Thu, Feb 9, 2012 at 11:45 PM, Michael Dürig<md...@apache.org>  wrote:
>>>
>>> Hi,
>>>
>>> I stumbled upon this by chance: The equals method for the classes
>>> ChildNodeEntriesMap and ChildNodeEntry is not symmetric.
>>
>> hmm, i am pretty sure they're symmetric, i.e.: a.equals(b) == b.equals(a)
>
> They look symmetric to me as well. Unless you refer to the Bucket innerclass
>
> ChildNodeEntriesMap#Bucket : This one has an invalid equals method
> breaking symmetry : Using super.equals in an equals implementation
> almost always breaks symmetry

Yes, that's what I was referring to actually.
Michael

>
> Regards Ard
>
>>
>> or are you referring to the missing hashCode() override?
>> i admit that i've been lazy since those internal objects are not
>> intended to be used as keys for hash tables and sorts.
>>
>> but you're probably right, it doesn't hurt to implement them :)
>>
>> cheers
>> stefan
>>
>>> This will most
>>> certainly lead to subtle bugs later on.
>>>
>>> Michael
>
>
>

Re: [jr3 Microkernel] equals() not symmetric

Posted by Stefan Guggisberg <st...@gmail.com>.
On Fri, Feb 10, 2012 at 12:00 PM, Ard Schrijvers
<a....@onehippo.com> wrote:
> On Fri, Feb 10, 2012 at 11:41 AM, Stefan Guggisberg
> <st...@gmail.com> wrote:
>> On Thu, Feb 9, 2012 at 11:45 PM, Michael Dürig <md...@apache.org> wrote:
>>>
>>> Hi,
>>>
>>> I stumbled upon this by chance: The equals method for the classes
>>> ChildNodeEntriesMap and ChildNodeEntry is not symmetric.
>>
>> hmm, i am pretty sure they're symmetric, i.e.: a.equals(b) == b.equals(a)
>
> They look symmetric to me as well. Unless you refer to the Bucket innerclass
>
> ChildNodeEntriesMap#Bucket : This one has an invalid equals method

-> ChildNodeEntriesTree#Bucket

> breaking symmetry : Using super.equals in an equals implementation
> almost always breaks symmetry

good catch!

thanks
stefan

>
> Regards Ard
>
>>
>> or are you referring to the missing hashCode() override?
>> i admit that i've been lazy since those internal objects are not
>> intended to be used as keys for hash tables and sorts.
>>
>> but you're probably right, it doesn't hurt to implement them :)
>>
>> cheers
>> stefan
>>
>>> This will most
>>> certainly lead to subtle bugs later on.
>>>
>>> Michael
>
>
>
> --
> Amsterdam - Oosteinde 11, 1017 WT Amsterdam
> Boston - 1 Broadway, Cambridge, MA 02142
>
> US +1 877 414 4776 (toll free)
> Europe +31(0)20 522 4466
> www.onehippo.com

Re: [jr3 Microkernel] equals() not symmetric

Posted by Ard Schrijvers <a....@onehippo.com>.
On Fri, Feb 10, 2012 at 11:41 AM, Stefan Guggisberg
<st...@gmail.com> wrote:
> On Thu, Feb 9, 2012 at 11:45 PM, Michael Dürig <md...@apache.org> wrote:
>>
>> Hi,
>>
>> I stumbled upon this by chance: The equals method for the classes
>> ChildNodeEntriesMap and ChildNodeEntry is not symmetric.
>
> hmm, i am pretty sure they're symmetric, i.e.: a.equals(b) == b.equals(a)

They look symmetric to me as well. Unless you refer to the Bucket innerclass

ChildNodeEntriesMap#Bucket : This one has an invalid equals method
breaking symmetry : Using super.equals in an equals implementation
almost always breaks symmetry

Regards Ard

>
> or are you referring to the missing hashCode() override?
> i admit that i've been lazy since those internal objects are not
> intended to be used as keys for hash tables and sorts.
>
> but you're probably right, it doesn't hurt to implement them :)
>
> cheers
> stefan
>
>> This will most
>> certainly lead to subtle bugs later on.
>>
>> Michael



-- 
Amsterdam - Oosteinde 11, 1017 WT Amsterdam
Boston - 1 Broadway, Cambridge, MA 02142

US +1 877 414 4776 (toll free)
Europe +31(0)20 522 4466
www.onehippo.com

Re: [jr3 Microkernel] equals() not symmetric

Posted by Stefan Guggisberg <st...@gmail.com>.
On Thu, Feb 9, 2012 at 11:45 PM, Michael Dürig <md...@apache.org> wrote:
>
> Hi,
>
> I stumbled upon this by chance: The equals method for the classes
> ChildNodeEntriesMap and ChildNodeEntry is not symmetric.

hmm, i am pretty sure they're symmetric, i.e.: a.equals(b) == b.equals(a)

or are you referring to the missing hashCode() override?
i admit that i've been lazy since those internal objects are not
intended to be used as keys for hash tables and sorts.

but you're probably right, it doesn't hurt to implement them :)

cheers
stefan

> This will most
> certainly lead to subtle bugs later on.
>
> Michael