Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (athena.apache.org: domain of sebbaz@gmail.com designates
 209.85.217.12 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version
         :content-type:content-transfer-encoding:content-disposition
         :references;
        b=GVm+kPzImhboLC9L15ohHuge4xFMs8IT5oKyks9cM3MwD2hsj8SnprfGe4q9SPCnsQ
         t6akUJBCYAw3cbRfDmJ2jEzYCHAM+MUr/U4tbYpS7/lVQ3vzrrC6fssSwcUQF/2fxMT2
         HtVjNGtp9SW2cPPJmMLwV0j6tb9LirpiMXVCM=
Message-ID: <25aac9fc0809160757kd9a2547u5a006962d726d68@mail.gmail.com>
Date: Tue, 16 Sep 2008 15:57:49 +0100
From: sebb <sebbaz@gmail.com>
To: "Commons Developers List" <dev@commons.apache.org>
Subject: Re: [LANG] - suggestions for new Identity Hash code classes
In-Reply-To: <48CFC5D4.40800@apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <25aac9fc0809160449k2d1a8c08i82528309955b6a1e@mail.gmail.com>
	 <48CFAA1E.30501@apache.org>
	 <25aac9fc0809160556v1209d933h2d0daaa617056b2b@mail.gmail.com>
	 <48CFB33B.8090601@apache.org>
	 <25aac9fc0809160638m324a8811g6a9c3e01be73041c@mail.gmail.com>
	 <F0D7281DAB048B438E8F5EC4ECEFBDDC0310CD35@esmail.elsag.de>
	 <25aac9fc0809160728x4e3d7b5djd8fa0d4768d848e7@mail.gmail.com>
	 <48CFC5D4.40800@apache.org>

On 16/09/2008, Simon Kitching <skitching@apache.org> wrote:
> sebb schrieb:
>
> > On 16/09/2008, J=F6rg Schaible <Joerg.Schaible@scalaris.com> wrote:
> >
> >
> > > sebb wrote:
> > >  > On 16/09/2008, Simon Kitching <skitching@apache.org> wrote:
> > >
> > > [snip]
> > >
> > >
> > >
> > > >
> > > > >  It's not quite clear to me why a threadlocal is being used here.
> I'm
> > > > >
> > > > >
> > > >
> > >  >> guessing it is for performance to avoid recreating the HashSet
> > >  >> object.
> > >  >
> > >  > I don't know for sure, but that is probably the case.
> > >  >
> > >  >> Or is
> > >  >> it to "tunnel" the registry set between cooperating classes?
> > >  >
> > >  > Not at present, although the registy access methods are
> > >  > package protected.
> > >  >
> > >  > That may be a mistake...
> > >
> > >
> > > My guess: It's used in case of a circular object graph ...
> > >
> > >
> > >
> >
> > Yes, they are used in the enclosing class for just that purpose.
> >
> > But as far as I can see there is no need for the methods to be
> > anything other than private - and the contents of the HashMap only
> > contain anything during the calculation of the hashcode, so it's not
> > obvious how the methods could be called anyway.
> >
> > I meant it was probably a mistake for the methods to be package protect=
ed.
> >
> >
>  In that case, I wonder why it bothers to use a thread-local at all, rath=
er
> than just passing the registry object around as a parameter...
>
>  Is the performance benefit of avoiding creation of a HashSet object real=
ly
> measurable given that this class is doing significant amounts of reflecti=
on?
>
>  Because this class never calls ThreadLocal.remove(), the created HashSet
> object will remain attached to every thread that ever was active when a
> HashCodeBuilder call was made. That's not *too* bad, ie it seems to me th=
at
> it would be acceptable as long as there was a corresponding benefit
> somewhere. But I can't see the benefit ATM..

Ditto.

I think it would make also sense to privatise the add/remove etc methods.

However, this would change the API.
But as that part of the API seems to be useless, I would not object to
it being removed.

>
> ---------------------------------------------------------------------
>  To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>  For additional commands, e-mail: dev-help@commons.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org