jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Elliot Metsger <emets...@jhu.edu>
Subject Re: Checkstyle improvements
Date Thu, 28 Apr 2005 12:17:49 GMT
I'm not a Jackrabbit developer so take my .02 for what they are worth! :)

Tobias Strasser wrote:
> you are right. just reading the javadoc for hashCode() again.
>      * <li>Whenever it is invoked on the same object more than once during 
>      *     an execution of a Java application, the <tt>hashCode</tt> method

>      *     must consistently return the same integer, provided no information 
>      *     used in <tt>equals</tt> comparisons on the object is modified.
>      *     This integer need not remain consistent from one execution of an
>      *     application to another execution of the same application. 
> the important part here is:
>  ...provided no information  used in <tt>equals</tt> comparisons on
> the object is modified....

I generally prefer to compute hash code on the same fields that equals 
relies on.

> so, either we are lazy, and return '1' or we compute the hashcode
> depending on the same fields, that equals relies on.

Recognizing that in HashSets this will provide an uneven distribution of 
objects in hashbuckets (the objects in the set will all have hashcode of 
1) which may impact performance depending on how large the collection 
is.  If you return '1', perhaps a warning in the javadoc about placing 
these objects in Sets.

> the problem of putting mutable objects into collections is something
> completely different.

I agree.

> cheers, tobi
> btw: for example, take a look at the source code of
> 'java.util.Calendar'. there the hashcode and equals also depend on
> mutable fields.

Will do, sounds like an interesting excercise!


> On 4/28/05, Felix Meschberger <Felix.Meschberger@day.com> wrote:
>>>>+1 for overriding hashCode() returning a constant integer
>>>>for mutable classes. i don't fully agree with the javadoc though.
>>>>if you implement hashCode() 'correctly', i.e. calculate the hashcode
>>>>based on the objects fields, you risk losing track of data in a
>>>>hash table.
>>>>mutable objects should imo never be managed in hash tables.
>>>>returning a constant integer is therefore fine with me for mutable
>>What do you mean by "not be managed in hash tables" ? Of course, objects
>>whose equality state - fields compared by equals() - changes during
>>their live time should not be used as KEYS in maps. But they may of
>>course be perfectly used as VALUES.
>>Now, it makes perfect sense to not use variable KEYS. This is not
>>specific to java, this is also true for any database application.
>>>well, when the equality depends on mutable data, the object cannot be
>>>used in sets at all.
>>True, or as the JavaDoc of the Set interface states:
>>    Note: Great care must be exercised if mutable objects are used as
>>    set elements.  The behavior of a set is not specified if the value
>>    of an object is changed in a manner that affects equals comparisons
>>    while the object isan element in the set.  A special case of this
>>    prohibition is that it is not permissible for a set to contain
>>    itself as an element.
>>>so no need to return '1' as hashcode. if the
>>>object cannot be used in set, i would rather throw a
>>>public int hashCode() {
>>>      thrown new UnsupportedOperationException("unable to compute hashcode");
>>There is no need for that ! Simply document the class to be mutable
>>regarding equality and the rest is in the responsibility of the programmer !
>>In fact the proposed behavi is very dangerous and may lead to
>>unexplainable situations.
>>Yes, I am picky on that. But this is not an issue of style but an issue
>>of correctness !

View raw message