Hi Yoni Amir, I agree it's arguable, still many logger implementors tried to fix this, and some get a pretty good job done, but it's simply not possible to completely remove the overhead.

As you say, the practicality of being able to change these are high so we all agree that such a pattern should be avoided in most of the code. But there are code areas which are extremely "hot": invoked millions of times per second on high end systems. These deployments have a say as well, and often wouldn't care less for that specific log statement, to the point people would rather remove the log statement rather than spending millions more in hardware.

So let's say we simply remove the log statements.. that wouldn't help you much to be able to "enable them at runtime", right?

In the Infinispan project, after much arguing we decided to follow the simple convention: "All TRACE level logs are not modifiable at runtime".
I think in Hibernate we should make that clear too. Which isn't to say that all trace messages need to be constant, there certainly are many points in the code which don't need this specific treatment, but it's rather to warn the user that changing TRACE might not work.

I hope that explains the picture better.
That said, I don't think we should ever apply that to DEBUG. I couldn't open my IDE now, but if this debug method is needing this as well, I'd rather change it to "trace" level.

"locking" the DEBUG level is indeed going too far, I'd agree with that