Hi, Doug Lea's concurrent library is a good piece of software. We used it at my old workplace for a couple of years in heavy apps, never a problem. And now it's part of JSE 5 so future migration will be easy. One could also imagine a simple class that detects if running on JSE5 and later and then uses java.util.concurrent, or else uses Doug Lea's library.
Requiring JSE5 for log4j is probably not a good idea: one of log4j's main advantages over JDK 1.4 logging is its ability to run on older JVMs. That said, JSE5 is not only being rapidly adopted (for example, on the Tomcat mailing lists, we've seen far more JSE5 than JDK 1.4 queries not just recently, but for almost two years now), but it will be required for JEE5 containers. So, for example, Tomcat 6, Jetty 7, Geronimo 1.1, Weblogic 10, etc will all require JEE5 or higher as their JVM -- the JDK 1.1, 1.2, 1.3, 1.4 compatibility will be meaningless on the server side at that point. I wonder what percentage of log4j users are client side versus server side. One has to assume 50-50, but who knows ;) Yoav On 12/2/05, Endre Stølsvik <[EMAIL PROTECTED]> wrote: > On Thu, 1 Dec 2005, Jess Holle wrote: > > | Has anyone tried replacing the synchronization in log4j with Java 5 locks to > | and done any benchmarks? > | > | I'm curious as I think it would be interesting to have a lock factory which > | produces something like the existing locks for pre-Java-5 JVMs and Java 5 > | locks in Java 5. > | > | We purely use and require Java 5 and higher for all new development at this > | point, which may make us unusual, but that's where we're at. I understand > the > | need to support earlier JVMs, but am interested in squeezing the best > possible > | performance and scalability out under Java 5. > > My opinion: Server-side programs and in particular libraries don't always > have the opportunity to _decide_ the infrastructure, one important pice of > which is the JRE version. > > What about Doug Lea's "concurrency.jar", which basically _is_ the JSR 166? > This works with 1.2+, and most also "should" work with 1.1 (1.2 is > "collections") > > http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html > > Other elements of concurrency.jar worth examining for the ones of you that > are heavily into the innards of log4j, are possibly: > ConcurrentHashMap > ConcurrentReaderHashMap > ReadWriteLock > and obviously > Sync and Mutex possibly along with CondVar > > Regards, > Endre. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Yoav Shapira System Design and Management Fellow MIT Sloan School of Management Cambridge, MA, USA [EMAIL PROTECTED] / www.yoavshapira.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
