That isn't entirely correct. Someone seems to love the JUL API so much that they wrapped it in Java 5 (varargs support) and wrote a couple of plugins to translate it to various logging frameworks (JUL, log4j and slf4j are supported even though slf4j isn't mentioned in the docs). It's in 4.0 release the POM as a test dependency, though.
The code looks fast enough but I'm not sure how much value you get from adding another log-layer on top of the existing ones.
Since I can't find any pointers why they did it, my guess is currently that the JBoss logging layer allows to i18n the log messages. Great if you need it but I'm wary of the performance impact.
That said, I'd still vote to replace JCL with slf4j for these reasons:
- slf4j gives consumers options
- JCL's automatic logging framework recognition is flawed/broken/insufficient, depending on your point of view.
- JCL is dead, slf4j is still supported by it's developer
- Re backward compatibility: You're leaking a dependency. Eventually, you will have to fix that anyway. Why not replace something broken with something good? Yes, developers will complain but frameworks like logback have so many useful features and their config is so much more simple and more powerful that I regret every day that I didn't upgrade from log4j.
For example: I've written an appender with logback that logs nothing until an error happens. At that time, it will log the last 20 INFO messages and the last 200 DEBUG messages. The whole code is about 250 lines. I get a log file which only contains interesting information plus a fast logger.
To drive this home: I'm patching my third-party dependencies to use slf4j if they depend on JUL. The last bigger project on my list was BIRT (patched 400+ files). ZK is probably next.
Spring uses JCL, which is not a very big problem because I can use the slf4j bridge which causes only a small performance loss but I always prefer frameworks that don't tie my to a certain logging implementation at runtime. The problem with JUL is that the translation is very, very expensive.