jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tobias Strasser <tobias.stras...@gmail.com>
Subject Re: Checkstyle improvements
Date Thu, 28 Apr 2005 09:59:31 GMT
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....

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

the problem of putting mutable objects into collections is something
completely different.
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.

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
> >>objects.
> >>
> >>
> 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
> >UnsuportedOperationException:
> >
> >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 !
> 
> Regards
> Felix
> 
> 


-- 
------------------------------------------< tobias.strasser@day.com >---
Tobias Strasser, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97 
-----------------------------------------------< http://www.day.com >---

Mime
View raw message