Return-Path: Delivered-To: apmail-incubator-jackrabbit-dev-archive@www.apache.org Received: (qmail 27989 invoked from network); 28 Apr 2005 10:00:03 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 28 Apr 2005 10:00:03 -0000 Received: (qmail 13714 invoked by uid 500); 28 Apr 2005 10:00:40 -0000 Mailing-List: contact jackrabbit-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: jackrabbit-dev@incubator.apache.org Delivered-To: mailing list jackrabbit-dev@incubator.apache.org Received: (qmail 13650 invoked by uid 99); 28 Apr 2005 10:00:39 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=RCVD_BY_IP X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: domain of tobias.strasser@gmail.com designates 64.233.184.200 as permitted sender) Received: from wproxy.gmail.com (HELO wproxy.gmail.com) (64.233.184.200) by apache.org (qpsmtpd/0.28) with ESMTP; Thu, 28 Apr 2005 03:00:38 -0700 Received: by wproxy.gmail.com with SMTP id 69so533351wri for ; Thu, 28 Apr 2005 02:59:31 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=nvs6kuFSe9uUsSZ9jAE6D4o1mM3GkTvclNCSMbYz1QXp2Ua/pOz+agMjNA7eYNvs7wMzQ51AZ8KBRp0rZPAF+pj47veQZ6eb9OpFvh+VmYx2KcuTmg2FEynAqpepYpINoyaaTCWCyIiOK2rPtovjtdOBN/Mr8elBRg5En35mvw4= Received: by 10.54.21.23 with SMTP id 23mr658986wru; Thu, 28 Apr 2005 02:59:31 -0700 (PDT) Received: by 10.54.63.15 with HTTP; Thu, 28 Apr 2005 02:59:31 -0700 (PDT) Message-ID: <8be7318805042802597fd9873a@mail.gmail.com> Date: Thu, 28 Apr 2005 11:59:31 +0200 From: Tobias Strasser Reply-To: tobias.strasser@day.com To: jackrabbit-dev@incubator.apache.org Subject: Re: Checkstyle improvements In-Reply-To: <4270ABC2.4050405@day.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <4253BA9B.50905@yukatan.fi> <1114594211.2995.20.camel@hukka.local> <90a8d1c005042708469566ce3@mail.gmail.com> <1114630701.8493.37.camel@hukka.local> <90a8d1c0050428014347ce001b@mail.gmail.com> <8be73188050428020068ce3786@mail.gmail.com> <4270ABC2.4050405@day.com> X-Virus-Checked: Checked X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N you are right. just reading the javadoc for hashCode() again. *

Whenever it is invoked on the same object more than once during= =20 * an execution of a Java application, the hashCode method= =20 * must consistently return the same integer, provided no informati= on=20 * used in equals 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.=20 the important part here is: ...provided no information used in equals 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 wrote: >=20 >=20 > >>+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. >=20 > Now, it makes perfect sense to not use variable KEYS. This is not > specific to java, this is also true for any database application. >=20 > >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: >=20 > 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. >=20 > > 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 hashc= ode"); > >} > > > > > There is no need for that ! Simply document the class to be mutable > regarding equality and the rest is in the responsibility of the programme= r ! >=20 > In fact the proposed behavi is very dangerous and may lead to > unexplainable situations. >=20 > Yes, I am picky on that. But this is not an issue of style but an issue > of correctness ! >=20 > Regards > Felix >=20 >=20 --=20 ------------------------------------------< 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=20 -----------------------------------------------< http://www.day.com >---