jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting ...@yukatan.fi>
Subject Re: Checkstyle improvements
Date Thu, 28 Apr 2005 09:19:51 GMT
Hi,

Very good points, both Stefan and Tobias.

Tobias:
> well, when the equality depends on mutable data, the object cannot be
> used in sets at all. so no need to return '1' as hashcode. if the
> object cannot be used in set, i would rather throw a
> UnsuportedOperationException:

Sounds good. OK if I add the following snippet to accompany the
overridden equals methods?

    /**
     * Unsupported operation. Instances of this class are mutable and
     * should therefore not be managed in a hash table. See the linked
     * message and the related discussion thread for details.
     *
     * @return nothing, throws an exception instead
     * @throws UnsupportedOperationException always thrown
     * @see
http://article.gmane.org/gmane.comp.apache.jackrabbit.devel/1899
     * @see Object#hashCode()
     */
    public int hashCode() throws UnsupportedOperationException {
       thrown new UnsupportedOperationException(
               "unable to compute hashcode");
    }

PS. Longer term issue: Would it be better to migrate to some other
method like the JCR isSame() instead of equals() in these cases? The
equals and hashCode operations are pretty fundamental to Java objects
and messing with their semantics is an obvious gotcha. The standard
reference equality and hash code implementation of Object.hashCode()
works well also for mutable objects.

BR,

Jukka Zitting



Mime
View raw message