That's a good point. Even though this would weaken my argument (slightly), I now wonder if modern JITs can completely optimize debug.log(someExpensiveFunction()) into a NOOP if they realize that the argument won't end up being used inside the log function.
The javadoc for slf4j's Logger.debug implies that the JIT cannot be relied on for this:
"This form avoids superfluous string concatenation when the logger is disabled for the DEBUG level"
I think that means if you call Logger.debug("a"+"b"), the string concatenation happens even if DEBUG logging is disabled. But maybe JITs have improved since that javadoc was written, or the author was not aware of how smart JITs are.
I would be curious to know if there is a JIT expert who could weigh in on this question.
In the case of non-toy runtimes in general to be honest.
It's one of the simplest and most commonly implemented peephole optimisations - perl has handled it for as long as I can remember, I'm pretty sure cpython does, etc. etc.
The javadoc for slf4j's Logger.debug implies that the JIT cannot be relied on for this:
http://slf4j.org/apidocs/org/slf4j/Logger.html#debug(java.la......)
"This form avoids superfluous string concatenation when the logger is disabled for the DEBUG level"
I think that means if you call Logger.debug("a"+"b"), the string concatenation happens even if DEBUG logging is disabled. But maybe JITs have improved since that javadoc was written, or the author was not aware of how smart JITs are.
I would be curious to know if there is a JIT expert who could weigh in on this question.