Mailing-List: contact jackrabbit-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jackrabbit-dev@incubator.apache.org
Received-SPF: pass (hermes.apache.org: domain of stefan.guggisberg@gmail.com
 designates 64.233.162.194 as permitted sender)
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=sV5vVJ5lttX2obd3K7qzmZGCE3EPgXXv41xYEosh8jGqQ3o7zTEM9JgU/bycuhWovab5vy1rUjpPiUK6XxIJL3KPdRn0XGSbEcvSyA9TrxeJ1CkMyDXkQDeYlJCABsRi5Pk3RiTjQghz71ahxSwG+a5IZ6hIj86lSTCB/FV7dys=
Message-ID: <90a8d1c0050428014347ce001b@mail.gmail.com>
Date: Thu, 28 Apr 2005 10:43:52 +0200
From: Stefan Guggisberg <stefan.guggisberg@gmail.com>
Reply-To: Stefan Guggisberg <stefan.guggisberg@gmail.com>
To: jackrabbit-dev@incubator.apache.org
Subject: Re: Checkstyle improvements
In-Reply-To: <1114630701.8493.37.camel@hukka.local>
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>

On 4/27/05, Jukka Zitting <jz@yukatan.fi> wrote:
> Hi,
>=20
> Stefan wrote on protected member variables:
> > therefore i suggest to disable the related Checkstyle check.
>=20
> Sounds fine to me, especially since the protected member variable
> pattern is so common in Jackrabbit.
>=20
> In fact this pattern reflects the more general design style in
> Jackrabbit and in the JCR API as well. In many places Jackrabbit uses
> classic inheritance for common functionality between classes. Realizing
> this was a major step in getting to understand the Jackrabbit internals.
> Based on this I intend to create and add (sooner or later :-) some class
> inheritance diagrams as a part of the JCR-73 Javadoc improvement task.
>=20
> > regarding missing hashCode(): i intentionally do never override hashCod=
e()
> > for mutable objects. hashCode() should imo only be implemented for
> > immutable objects.
>=20
> As Felix already noted:
>=20
> There's always the catch that you won't be able to use HashSets or
> similar data structures to reliably keep track of such objects (two
> "equal" objects might have different hash codes). Thus, if nothing else,
> I'd suggest using the following placeholder code to implementing the
> hashCode() methods. It certainly isn't fast but satisfies the
> equals/hashCode contract for all equals() implementations.
>=20
>     /**
>      * Always returns <code>1</code>. Implemented as a simple
>      * placeholder to satisfy the equals/hashCode contract. This
>      * method should be properly implemented if instances of
>      * this class need to be managed in a hash table.
>      *
>      * @return always <code>1</code>
>      * @see Object#hashCode()
>      */
>     public int hashCode() {
>         return 1;
>     }

+1 for overriding hashCode() returning a constant integer=20
for mutable classes. i don't fully agree with the javadoc though.
if you implement hashCode() 'correctly', i.e. calculate the hashcode=20
based on the objects fields, you risk losing track of data in a=20
hash table.

mutable objects should imo never be managed in hash tables.
returning a constant integer is therefore fine with me for mutable
objects. =20

cheers
stefan

>=20
> > in general: i think that checkstyle is a good tool that helps to improv=
e the
> > quality and consistency of the code base. but we should use common
> > sense when interpreting the recommendations. blindly following all the
> > recommendations or or trying to achieve 0 reported issues is imo not
> > worthwhile.
>=20
> Agreed. My goal with JCR-97 is not to blindly follow guidelines but to
> get rid of the simple issues so that the Checkstyle report is actually
> useful in enforcing a common coding style and locating potentially
> troublesome constructs (like the hashCode issue). A newcomer like me can
> also use the report as a list of gotchas to watch out for.
>=20
> BR,
>=20
> Jukka Zitting
>=20
>