commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Boris Unckel <>
Subject Re: [logging] SLF4J?
Date Fri, 18 Aug 2006 11:48:21 GMT
Hello Jörg,

Joerg Hohwiller wrote:
>> But in the end, JCL will continue to improve as will SLF4J I expect, and
>> people can choose as they wish - until j.u.logging knocks both libs into
>> the dustbin of history.
I do not think that JUL will knock out JCL or SLF4J[1]. JCL is much too 
spreaded. JUL itself (without
homegrown additions or Tomcat-JULI[2] or x4juli[3]) has too less 
features (especially the handlers and the configuration[4])
too compete successfully against log4j or its derivates nlog4j[5] or 
> just to let you know my oppinion:
> this will never ever happen.
> j.u.l is crap because it does NOT have something that one can call an API!
Could you specify that with specific design errors? I know the 
argumentation of Ceki, who has written something
before JDK 1.4 JSRs were finalized and tried to put log4j in place. 
Please do not repeat them - what did _you_ mean?
> I do not know what they drink at sun's but the jdk is full of rotten design
> mistakes.
> Some highlights:
> * See Calendar.get(int). And a Month starts with 0, but day with 1.
This has nothing to do with JUL.
> * Why does Iterator not extend Enumeration
This has nothing to do with JUL.
> * See the complete collections and
>   OperationNotSupportedException - is that an API?
This has nothing to do with JUL.
> I know its not always easy to design a great API and of course JDK is the most
> central part so there will always be someone complaining. At least the newer
> things get designed better.
> Serious applications will continue NOT to use j.u.l !!!
Your arguments against some bad design in some JDK libraries may be OK 
or not, but I do not see the point
against JUL. I think there are still good arguments to use JUL:
- I18N support with default JDK mechanisms (there may be better, OK, but 
the JCP decided to use this ones).
- Good (not excellent) possibilities to extend/override/exchange the 
- No further dependencies than JDK1.4 or above
- Interface of the logger-class has some good helper methods
- Supported by the major wrappers JCL causing no dependency problems if 
an API requires JCL
- Supported by the currently niche player SLF4J causing no dependency 
problems if an API requires SLF4J
- Major issues solved in third party APIs (i.E., but not the only one, 
> Please keep going with JCL - hey, ho :)
Yes, JCL is cool and the new 1.1 release makes life much easier, 
especially its new diagnostic functions and its improved
exception/error messages. Great job. Hopefully containers who 
use/distribute it, will turn to this version.
JCL, especially its logger interface and neutral LogFactory is still the 
number one choice for API developers.
Classloader problems are based on missing knowledge, odd/strange 
behaviour of containers and the need
for the absolute maximum flexibility demanded by the users and/or 
design/implementation goals of the developers.

The static binding approach of SLF4J could be achieved with one build 
script and one or two binding classes -
may be a good optional turn for "self-compilers".



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message