On Dec 9th 2008 16:57 GMT Curt Arnold wrote: > The supposed performance benefit of the SLF4J formatter over the > java.text.MessageFormat only occurs when you compare the performance > against naive use of java.text.MessageFormat. LogMF handles the > simplest pattern specifications (those just involving {0}, {1}, etc) > internally and only delegates to java.text.MessageFormat for more > complex pattern specifications, resulting in equivalent performance to > the SLF4J formatter on functionally equivalent format specifiers while > still supporting the full java.text.MessageFormat capabilities. On Dec 11th 2008 08:21 GMT Curt Arnold wrote:
As I remember, my benchmarks were very, very low overhead logging calls (NullAppender or the like) or less than threshold logging calls and the performance between the formatters was totally lost in the NullAppender overhead. It was several years ago, so I'll have to dig in the archives.
There is no point in digging into into the archives. Unless you can point to a mistake in the test case I provided yesterday, it irrefutably demonstrates that LogMF does not offer equivalent performance. Recognizing performance advantage of the SLF4J formatter would have been a welcome change. At the very least you should stop referring to the "supposed" or "alleged" performance benefits of the SLF4J formatter. Moreover, in the future, you should refrain from making incorrect statements with such self-confidence and certainty and later weasel yourself out of them by minimizing their importance. As for Jorg who does like message formatting, he is obviously entitled to his opinion. However, as log4j committers, out job is to respond to user demand. While several years ago one could reasonably argue that SLF4J was not a mature and stable API, that argument is no longer valid. Not only is the SLF4J API stable and mature, it is also very popular. By adopting the SLF4J API natively, the log4j community would do the larger java developer community an immense service by disambiguating java logging. I don't think that half-hearted attempts such as the "extras companion" help, on the contrary. Java logging does not need more choice. On the contrary, it needs consolidation. The Apache Software Foundation does not control the SLF4J project, but since when the ASF is about control? There are many Apache projects which implement specifications drafted outside Apache. So, what is in it for log4j? First, it would give new life to the project. Second, it would make log4j an easier sell. Some developers, albeit not all, will say: "let use log4j for logging instead of jul because it natively implements SLF4J. We can later switch if we want to". So, what is in it for SLF4J? SLF4J would be endorsed by log4j which is certainly good for SLF4J. However, it is also good for log4j. Some developers, albeit not all, will say: "should we use jul, log4j or logback as the underlying SLF4J implementation? Let us use log4j because it implements SLF4J natively." Sound far-fetched? Think 3 years ahead and pretend 50% of all OSS projects already use SLF4J for logging. I believe that is going to happen whether log4j implements SLF4J or not. If you think that is a possibility, then implementing the SLF4J API today makes sense. Enough said. -- Ceki Gülcü --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]