You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by Peter Koßek <Pe...@t-online.de> on 2003/01/28 01:36:51 UTC
[collections] Question about CollectionUtils semantics
----- Original Message -----
From: "Greg Zoller"
Subject: Re: Question about CollectionUtils semantics
> I think the reason your example works is that you're using String-typed
> variables...
No. That's not really the reason why.
> I have another example that uses another object:
>
> public class Hey {
> private String id;
> public Hey( String id ) { this.id = id; }
> public boolean equals( Object obj ) {
> Hey otherHey = (Hey) obj;
> if( otherHey.id.equals( this.id ) )
> return true;
> return false;
> }
> public String toString() { return id; }
> }
Hey - where is your #hashCode implementation? You forgot to fulfill the contract
mentioned in
http://java.sun.com/j2se/1.4/docs/api/java/lang/Object.html#hashCode() . Years
before the first Java programmer forgot to fulfill the contract, programmers of
other languages did the same:
http://wiki.cs.uiuc.edu/VisualWorks/Not+implementing+%23hash+while+overriding+%3
D - and still there's no end in sight. If you didn't know this problem at all,
you should have a look into the book "Effective Java" by Joshua Bloch.
Incomplete object implementations which override #equals but don't override
#hashCode cannot be used within HashSets and HashMaps. The hashing algorithm
will fail then.
The CollectionUtils#intersection implementation relies on the use of HashMaps.
The Collection#retainAll doesn't use hashing, so it can't fail. But if you try
to use incomplete object implementations, your code will run into large problems
sooner or later, because hashing is used so often.
> Regards,
> Greg
-peter
Re: [collections] Question about CollectionUtils semantics
Posted by Todd Jonker <tv...@pobox.com>.
Agreed. Documentation is absolutely needed. In fact, this exact issue cost
me several hours of debugging time when I first started using the library.
The fact is that, for example, ArrayList operations work fine without hash,
but CollectionUtils augmentations don't.
Like Greg, I very rarely implement hash, since I tend not to need it, and
its a major pain to code properly.
.T.
On 1/28/03 11:06 AM, greg@codaware.com wrote:
> Peter...
>
> Ok, fair enough. Point well taken. If I expect hash-related data
> structures to
> work I need to complete the implementation of my objects. But... are you
> advocating that a programmer have intimate knowledge of an API's
> implementation
> in order to get the "expected" semantics? The fact remains that there
> is a behavior
> difference between the commons and java APIs, for whatever reason.
> Neither documentation set stresses the importance of implementing #hashCode
> (and at least in my experience this is not something I would commonly do
> for every object I create). At the very least this should be documented
> heavily
> to reset users' expectations or the semantics changed.
>
> Regards,
> Greg
--
WAR is NOT a NECESSITY
http://www.UnitedForPeace.org/
http://www.NotInOurName.net/
http://www.MoveOn.org/
Re: [collections] Question about CollectionUtils semantics
Posted by Greg Zoller <gr...@codaware.com>.
Peter...
Ok, fair enough. Point well taken. If I expect hash-related data
structures to
work I need to complete the implementation of my objects. But... are you
advocating that a programmer have intimate knowledge of an API's
implementation
in order to get the "expected" semantics? The fact remains that there
is a behavior
difference between the commons and java APIs, for whatever reason.
Neither documentation set stresses the importance of implementing #hashCode
(and at least in my experience this is not something I would commonly do
for every object I create). At the very least this should be documented
heavily
to reset users' expectations or the semantics changed.
Regards,
Greg
Peter Koßek wrote:
>----- Original Message -----
>From: "Greg Zoller"
>Subject: Re: Question about CollectionUtils semantics
>
>
>
>
>>I think the reason your example works is that you're using String-typed
>>variables...
>>
>>
>
>No. That's not really the reason why.
>
>
>
>>I have another example that uses another object:
>>
>>public class Hey {
>> private String id;
>> public Hey( String id ) { this.id = id; }
>> public boolean equals( Object obj ) {
>> Hey otherHey = (Hey) obj;
>> if( otherHey.id.equals( this.id ) )
>> return true;
>> return false;
>> }
>> public String toString() { return id; }
>>}
>>
>>
>
>Hey - where is your #hashCode implementation? You forgot to fulfill the contract
>mentioned in
>http://java.sun.com/j2se/1.4/docs/api/java/lang/Object.html#hashCode() . Years
>before the first Java programmer forgot to fulfill the contract, programmers of
>other languages did the same:
>http://wiki.cs.uiuc.edu/VisualWorks/Not+implementing+%23hash+while+overriding+%3
>D - and still there's no end in sight. If you didn't know this problem at all,
>you should have a look into the book "Effective Java" by Joshua Bloch.
>
>Incomplete object implementations which override #equals but don't override
>#hashCode cannot be used within HashSets and HashMaps. The hashing algorithm
>will fail then.
>
>The CollectionUtils#intersection implementation relies on the use of HashMaps.
>The Collection#retainAll doesn't use hashing, so it can't fail. But if you try
>to use incomplete object implementations, your code will run into large problems
>sooner or later, because hashing is used so often.
>
>
>
>>Regards,
>>Greg
>>
>>
>
>-peter
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>