-Original Message-
From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]]
On 3/14/02 9:25 AM, GOMEZ Henri [EMAIL PROTECTED] wrote:
I was just thinking about log4j case, which is an excellent
piece of code but wasn't use in latest jdk.
Right and even though I know that logging will be in the next
JDK, I am
still going to design using it.
But you know what ? People use log4j because it came from
Apache and is synonim of quality.
Nah - I use log4j because it *is* quality. Maybe people give
it a look
because of the apache relationship, but I clearly use it for
what it is.
Geir
The log4j issue highlights a couple other flaws in Sun's Put everything in
the world in the JDK approach. How many people, doing product development
in the real world can actually make use of the new logging API (or other JDK
1.4 specific features)? It only exists in JDK 1.4 and for licensing reasons
will never exist outside an official JDK. What about code that has to run
on platforms that don't have a 1.4 JRE yet? What about shops developing
with tools that don't support JDK 1.4 yet? What about code that has to run
inside containers that don't support 1.4 JREs yet?
Then there is the risk factor. Suppose the logging facility works great,
but there is a serious bug, or performance problem or whatever that makes
the JDK not feasible for production? By using JDK1.4 specific features
you've locked yourself in and you can't go back without serious effort. How
many companies are willing to risk blowing their development schedules on a
new JDK release? I think a lot of shops will wait for JDK 1.4.1 before they
really switch over.
Contrast that with Log4J. It works on any platform with a Java runtime.
Its been around long enough that the kinks have been worked out. Lots of
APIs and components already use it. The cost/benefit, risk/reward analysis
swings pretty far away from the JDK stuff.
Marc Saegesser
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
