Changing the topic since this discussion isn't really related to the release vote.
On Jul 15, 2012, at 7:36 AM, Gary Gregory wrote: > On Sun, Jul 15, 2012 at 10:13 AM, Ralph Goers <[email protected]> > wrote: > On Jul 15, 2012, at 6:36 AM, Gary Gregory wrote: > >> Hi All: >> >> I've only now been able to take a peek at v2 in SVN so... sorry for the late >> email but I feel better late than never. >> >> With log4j 1.2, my usage pattern is: >> >> logger.debug(String.format("This %s and that %d on this day %1$tm >> %1$te,%1$tY", this, this.getThat(), this.getCalendar())); >> >> In 2.0, we have this example: >> >> logger.debug("Logging in user {} with id {}", user.getName(), user.getId()); >> >> Why invent a new syntax when String.format is baked into the JRE? > > Because you are doing the string formatting whether the log event will be > logged or not, which means your logger.debug should always be wrapped in an > if isDebugEnabled. Also, the current syntax is compatible with SLF4J. See > http://www.slf4j.org/faq.html#logging_performance. > > Good discussion :) > > Yes, of course, I left the if/is* code out for brevity, it is not the point > of my discussion. I plan on leaving my if/is code in place even if/when I > move to log4j 2.0, it's just faster to call one API with no args than the > alternative. ;) > > I'm baffled by the SLF4J comment. Because SLF4J is now widely adopted as a standard Logging API. Efficiently supporting what it does out of the box is a good thing IMO. > > I am a log4j 1.2 user, and I want to move to 2.0, so I have to learn the > SLF4J syntax instead of what is baked in the JRE to use this great new > feature? Bleh. That seems backwards to me. If we are trying to get people to > migrate from SLF4J to Log4J, then we could make that possible with another > option instead of baking it in the product. No - you don't have to. As your example shows Log4j 1.x doesn't even support parameterized messages. Just keep doing what you are doing. > > I could see that the String format should be pluggable (if that's a word). > IMO the default should be the JRE with a plugin for formats from other > products. Not if it is 10 times slower than the SLF4J syntax. > > I am not a JUL user but some of our customers are, how does the JUL syntax > compare with SLF4J? If it is not the same, it's going to be confusing! They > both use { and }. Blech. I haven't even provided the JUL adapter for Log4j 2 yet. AFAIK there are only two ways to do it and they both suck. > > > If you want to write your debug message the way you have shown there is > nothing that says you can't. It will still work. However, as I recall Ceki > ran tests that showed the Java text formatting is pretty slow. See > http://bugzilla.slf4j.org/show_bug.cgi?id=116 for a nice discussion on this, > and related topics. > > Is that still true in the latest Java 6 and 7? All of our customers are on > Java 6 FWIW. Does SLF4J and String.format have the same features? Is that > even comparing apples to apples? I'm about to leave for the airport so I can't check right now, but my expectation is that when I look at String.format I am going to find a MessageFormat in it. But no, comparing SLF4J's formatting syntax to Java's String formatting syntax is not comparing apples to apples, which is precisely why SLF4J's performs so much better. It is simpler. > > > One other point. The String with placeholders is handled by > ParamaterizedMessage. This class could either be extended or enhanced to > support another syntax. If it is extended then that class would have to be > used in the logging call such as > > logger.debug(new FormattedMessage("This %s and that %d on this day > %1$tm %1$te,%1$tY", this, this.getThat(), this.getCalendar())); > > That is pretty heavy and provides no advantage over String.format IMO (I use > the if/is/log pattern). Why is "new FormattedMessage" any heavier than "String.format". It does have an advantage in that it is less expensive when you don't use encapsulating ifs, which a lot of people would like to do without. > > I want my config to say: use class foo to format the strings with args then. > What the default string format is then debatable. ;) You would need to figure out a way to do that where it doesn't create a real mess. Think about a commons project using that format while a different piece of code uses the SLF4J format. How is the user supposed to know how to deal with that?
