Use SLF4J for logging

[Marcono1234]

Is your feature request related to a problem? Please describe.

Currently this project uses java.util.logging, this has the following disadvantages:

• It is difficult to bridge to any other logging frameworks due to how java.util.logging is designed (implementation can only be set using System property, no ServiceLoader support)
• Since Java 9 java.util.logging is in the separate module java.logging and applications might not want to include that

Describe the solution you'd like

It would be good to use SLF4J for logging which has the following advantages:

• It is the de facto standard logging facade
  • Most applications likely already have it on their classpath
  • Many bridging projects from/to SLF4J are available
• It is relatively small: 40 KB for version 1.7.30

Describe alternatives you've considered

It would also be possible to use Log4j 2 API (without Log4j 2 Core), though SLF4J might be more common, and Log4j 2 API is larger (294 KB for version 2.14.0).

[sjoerdtalsma]

Although small and most applications having it on their classpath already, I still find the need to limit the number of dependencies for this library of greater importance.

All you need to log with SLF4J is the jul-to-slf4j jar. Most applications that use SLF4J for logging also already have that on their classpath as well. See SLF4JBridgeHandler for usage information.

[Marcono1234]

I still find the need to limit the number of dependencies for this library of greater importance

This might shift in the future when more projects are using the Java Platform Module System and start to exclude modules they are not interested in; for comparison the java.logging JMOD file for JDK 16 is 118 KB large. Then the choice might be between the 40 KB SLF4J dependency and the 118 KB java.logging module.

All you need to log with SLF4J is the jul-to-slf4j jar.

Except, that sadly due to how java.util.logging is designed, it is not that easy. Either you have to set a System property on startup to replace the LogManager implementation (Log4j 2 approach), which is not feasible if the project is itself used by other projects. Or you have to manually install a Handler, such as SLF4JBridgeHandler you have pointed out, which is error-prone because it has to be done at every entry point of the application (also not feasible for projects which themselves are used as dependencies), and accidential reconfiguration of java.util.logging might remove the handler or create a race condition where for a short moment no handler is installed. (I have not mentioned the logging.properties config file approach here because it is even less portable)

Would you mind at least leaving this issue open? I suspect that libraries using this project will be eventually facing these issues.

An alternative to SLF4J with Java 9 would be to use java.lang.System.Logger.

[sjoerdtalsma]

Would you mind at least leaving this issue open? I suspect that libraries using this project will be eventually facing these issues.

I don't mind at all, will leave it open. Maybe others will come with more pro's or cons.