Two good reasons to stick with this: 1) It's a decent API. Simple, easy to use. 2) you don't control what your library dependencies use. This can be a mix of

Two good reasons to stick with this: 1) It's a decent API. Simple, easy to use. 2) you don't control what your library dependencies use. This can be a mix of log4j, log4j2, java util logging, and commons-logging. These are all commonly used in libraries. If you don't use slf4j, you end up with a console full of messages that are formatted slightly different from each other. So even if you use JUL logging, you should use slf4j to ensure some uniformity. And if you do that, you might as well take the next step and format your logs properly using log4j2 or logback. It's not that hard with slf4j, you can use any of the common logging APIs and it will all end up in the same place. If you use most common server frameworks (e.g. Spring), you have no choice. Slf4j is going to be on the classpath and it will likely come in via any number of other dependencies as well.