> On Thu, 2005-06-16 at 23:09 -0700, Brian Stansberry wrote: > > donkin wrote: > > > > But I don't think the weakref stuff does any harm > > either (as long as > > there are no bugs in it!). So I'd be -0 to including > > it, not -1. > > If the WeakHashtable stuff is going to stay, I'm > wondering if it should be in the main jar. If it's in > the optional jar we have to explain how to use it, > which could easily be interpreted as implying it will > solve memory leaks, which in many cases it won't. If > we at the same time encourage using > commons-logging-adapters.jar (which will defeat the > WeakHashtable), well, let's just say I'll be looking > forward to the Bile Blog entry :) > > The downside to having it in the main jar is it will > be there by default, adding runtime overhead. > > I'm personally indifferent on this (even as to whether > it stays at all), but thought the above was worth > pointing out.
It would definitely be simpler to include WeakHashtable in the standard jar. And I see your point about the confusion inherent in explaining when someone should use the optional jar. I don't think performance is a big deal. This class will be slower than a normal Hashtable. However stuff that applies when log.debug() is called matters; stuff that applies when LogFactory.getLog is called isn't nearly as significant. The WeakHashtable falls into the second category, so no problems there as far as I am concerned. And I don't think having the class in the jar is a big deal in terms of space. It's only one class. On the other hand, it's only a "maybe" fix, while using a ServletContextListener is a guaranteed fix. And it's more code, increasing the potential places for a bug - though I don't believe there is one in that code. In the end, I think I'm also totally neutral on this. Regards, Simon --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
