Yoav Shapira wrote:
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.
Or detects that neither is available and uses something simple -- for a
client-side app with little threading but a requirement for few/small
jars, for instance.
That's really what I was getting at for Java 5 to begin with.
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.
I never argued to *require* JSE5 -- just to take advantage of it
conditionally where appropriate. Yes, that would add an virtual method
call to the stack at a minimum, but that's not much and I was just
wondering aloud if there were cases where that might not be worthwhile.
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.
Moreover one has to wonder how many pre-Java-5 environments are going to
bother deploying new versions of log4j...
--
Jess Holle
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
