commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sandy McArthur" <sandy...@gmail.com>
Subject Re: [logging] discovery and memory leaks
Date Tue, 21 Feb 2006 22:27:48 GMT
On 2/21/06, robert burrell donkin <robertburrelldonkin@blueyonder.co.uk> wrote:
> the reason for indexing on classloaders is to allow configurations to be
> saved on a per classloader basis. it strikes me that identity should be
> as good as equality for this indexing. if so, then we could use
> System.identityHashCode as the index rather than the actual classloader.
>
> please feel free to spot the flaws with this plan :)

Just gotta stress the *should*. System.identityHashCode returns an
int, technically that won't cut it for 64 bit Java.

That said if you find a real solution to this problem I'd like to know
because the reference and debug features of composite pool
implementation I submitted currently depend on hoping the
System.identityHashCode doesn't return the same value for two
different instances.

I don't like that code but I don't expect many people to use it in
production. If you expect people to often use that technique in
production I think we should keep looking.

--
Sandy McArthur

"He who dares not offend cannot be honest."
- Thomas Paine

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


Mime
View raw message