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]
