Yes, it has a few design flaws that were never addressed that make it a bit slow and inefficient. Also it is a bit lacking in features. Separating how logs are

Yes, it has a few design flaws that were never addressed that make it a bit slow and inefficient. Also it is a bit lacking in features. Separating how logs are formatted and published from how you log from your code is a good idea. This is essentially what slf4j does. It will happily intercept java util logging, log4j, and other common logging APIs using API compatible stubs for each of these and redirect them to your preferred logging framework. What things like log4j2 and logback offer is a lot of control over how the logs are processed, formatted, and published. Logback has plugins, appenders for different logging backends, etc. I actually have my own plugin for logback that writes logs straight to a remote elasticsearch cluster. It does things like add MDC (mapped diagnostic context) fields and selected environment variables to the json blob that it sends to elasticsearch and a few more useful things. That makes it easy to make logging dashboards. Log4j2 has similar features. Java util logging is a bit barebones. It's what you use when you really don't care about your logs.