commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <robertburrelldon...@blueyonder.co.uk>
Subject Re: [logging] 1.0.5: WeakHashtable
Date Thu, 10 Mar 2005 21:55:28 GMT
On Thu, 2005-03-10 at 06:39, Brian Stansberry wrote:
> --- 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.

that's good news :)

IIRC JCL doesn't run too well anyway under 1.1.x (the context
classloader stuff is 1.2 only). one of the reasons why i've wanted to
lift off a simple abstract superclass is that this would allow JCL to
function again under 1.1.x JVMs. 

any care to volunteer to verify empirically that i'm right about JCL not
running on a 1.1.8 JVM anymore?

> > 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 ;-)

+1

> > 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
> }

i believe that this method can sometimes cause issues with
implementations such as kaffe which contain classes from higher versions
of the spec. not that i'm against either method, just a little reluctant
to jump in too fast. if JCL can only now run on 1.2 JVMs then we could
simply move WeakHashtable into the core distribution.

> 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.

darn - that's a bug: should catch throwable.

- robert


---------------------------------------------------------------------
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