Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Received-SPF: pass (hermes.apache.org: local policy)
Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  b=C6Rm+De42bmEAuDPS7YHmWEr03Rr+3wL952KjV7uv6YtFOCXiSfqZbtnGZP+MSh8npgCOsK7TZPyYxetVQ+NA2aRyVZBVfiebyCfCSr30+5p6l/P616XM/RL7VGByvO0iICaJqrQ8+efYmKZlIoQqaDlvX1jeaYG/d5xGUCLo9s=
  ;
Message-ID: <20050310063910.42922.qmail@web90002.mail.scd.yahoo.com>
Date: Wed, 9 Mar 2005 22:39:10 -0800 (PST)
From: Brian Stansberry <bes_commons_dev@yahoo.com>
Subject: Re: [logging] 1.0.5: WeakHashtable
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
In-Reply-To: 6667
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii


--- robert burrell donkin
<robertburrelldonkin@blueyonder.co.uk> wrote:
> On Tue, 2005-03-08 at 06:41, Simon Kitching wrote:
> > 
> > Should the WeakHashtable class be rolled into
> commons-logging.jar?
> > It seems easier for users than remembering to
> deploy the extra jar, and
> > should be feasable by having something like this
> in 
> >    Hashtable foo;
> >    String version =
> System.getProperty("java.vm.specification.version");
> >     if (versionLessThan(version, "1.3")) {
> >       foo = new Hashtable();
> >     } else {
> >       // use reflection to create instance
> >       foo = createWeakHashtable();
> >     }
> >   
> > Or is the reason for having it separate because
> there is a performance
> > hit when using it? If that is so, then file
> guide.xml should document
> > that rather than saying "always deploy it when
> using java 1.3 or later".
> 
> there may be some performance hit but this should
> only really happen the
> first time that a Log is obtained for a new
> classloader. i doubt that
> there will be significant real world performance
> degradation by using
> this jar. be nice to have some figures, though.  
> 
> there were two main reasons why it was issued as an
> optional jar:
> 
> 1. JCL has always tried hard to be compatible with
> early JVMs 
> 2. backwards compatibility is very important
>  

I was looking at the javadoc for WeakReference and
Hashtable, and they look like they've actually both
had stable APIs since JDK 1.2.  So, I downloaded a 1.2
SDK and confirmed that I was able to compile
WeakHashtable using it.

This doesn't contradict the point about preserving
compatibility with early JVM, as WeakHashtable won't
run under 1.1.  But, the JCL docs and I believe the
user guide talk about needing 1.3 and it looks like
1.2 is sufficient.

> the memory problem is only likely to manifest when
> frequently hot
> deploying in certain containers. 

In regards to my comment above, I'm sure the large
group of container providers who are supporting JDK
1.2 will be thrilled to know they can use
WeakHashtable to fix their memory leaks ;-)

> i'm a little
> reluctant to use system
> property version numbers (since they haven't always
> been very reliable)
> and prefer to give users the explicit choice as to
> whether they risk
> using the new code or not. 
> 
> however, maybe it would be a reasonable tradeoff in
> this case and i
> would be willing to be convinced. (i tend to be very
> conservation when
> maintaining components with large installation
> bases).
> 
> opinions anyone?
>
 
The way I've seen JDK detection done is by trying to
load a class that first appeared in the target JDK.

ClassLoader loader = getClass().getClassLoader();
boolean jdk12 = false;
try {
  loader.loadClass("java.util.Collection");
  jdk12 = true;
}
catch (Exception e) {
  // ignore
}

BTW, I believe JDK detection is actually mildly safer
than what LogFactory is doing now, which in the
default configuration amounts to calling
Class.forName("o.a.c.l.i.WeakHashtable") and catching
any Exception.  If, contrary to instructions,
commons-logging-optional.jar were on the classpath in
a JDK 1.1 environment, I believe this call would throw
a NoClassDefFoundError which would not be caught.

Brian


__________________________________ 
Do you Yahoo!? 
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/ 

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