-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Boris,
> Your arguments against some bad design in some JDK libraries may be OK > or not, I maybe was a little harsh ;) > 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). I care a lot about I18N. But I personally think that i18n has nothing lost in loggers. Do you want to get bug-reports with japanese log-files? The log-file is NOT for the end user. It might be ignorant: but which developer can not understand english? How do we communicate on mailing lists? The application itself should be able to support i18n for user feedback: in exceptions, GUI, etc. > - Good (not excellent) possibilities to extend/override/exchange the > backend. May be your oppinion but not mine. > - No further dependencies than JDK1.4 or above That is the major point > - Interface of the logger-class has some good helper methods I see no Interface. There is an overloaded Java-Class. Helpers should not be part of the usage Interface but be add-on classes. > - Supported by the major wrappers JCL causing no dependency problems if > an API requires JCL I am not sure if I get you wrong here. But we are talking about the API you are using. You can of course use JCL together with JUL and everything is fine if you get all the features you need. But if someone is using JUL directly it does not help anyone if it can be adapted by JCL or whatever. BTW have you tried to hot-configure the JUL system at runtime? Works fine with log4j, though. > - Supported by the currently niche player SLF4J causing no dependency > problems if an API requires SLF4J same as above. > - Major issues solved in third party APIs (i.E., but not the only one, > x4juli) Okay we need to make sure what we are talking about. Maybe I got it wrong when I catched up the discussion. But there are two things to distinguis: 1) The API you are programming agains when you are writing code that wants to log. 2) The logging toolkit implementation For me the important thing is 1). And JUL is NOT an acceptable API to me. But JCL is. For 2) you can use log4j or JUL or whatever you like. I often have to integrate components from different open-source projects and different vendors. This could be so easy if there was just one logging API (e.g. JCL). Then I can choose for my complete application what logging toolkit I want to use. Another one might choose a different one for the same application. But the truth is different. One component uses JCL via LogFactory, one JUL, one log4j, one logkit, one avalon, one DNA, one plexus, one metro, etc. You end up with tons of logging jars and a situation that makes it impossible to have a homogenous logging system for the application. - From this point of view I can not see the point for slf4j!!! Why can't log4j directly implement the JCL Log interface. I guess that the JCL team would allow log4j team to include their Log interface in the log4j JAR file. But Java classpaths somehow tend to be a political issue. Regards Jörg -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFE7Mm+mPuec2Dcv/8RAuCdAJ9ivXKYCOjxiXQM7GfPDFicC1dQrgCgl1de 44YN4Zeqd7h6rtKdcn9x6e8= =xStS -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
