commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Zoller <g...@codaware.com>
Subject Re: [collections] Question about CollectionUtils semantics
Date Tue, 28 Jan 2003 16:06:12 GMT
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:   <mailto:commons-user-unsubscribe@jakarta.apache.org>
>For additional commands, e-mail: <mailto:commons-user-help@jakarta.apache.org>
>
>  
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message