Consider to use java.util.logging instead of slf4j

[zdenek-jonas]

We might want to consider using java.util.logging instead of slf4j.

java.util.logging is part of the JDK, so using it means having one less external dependency.

[zambrovski]

You are right about dependencies, but in almost all backend enterprise projects over last ten years (J2EE, JEE, Spring) the key of successful logging was to use a proper logging abstraction (as slf4j API is). It was a pain to configure all the java.util, commons-loggin, jboss-logging, log4j1 and jog4j2 friendly frameworks and bridge them all to slf4j and then configure a proper logging backend (like logstash or something or logback) to produce adequate log with central configuration usable in a distributed environment, well maintained in elk stack...

So please if you definitely want to fall back to JUL for logging, at least introduce an own facade so someone can easily replace it by proper enterprise logging.

There are long discussions on that on StackOverflow, and I really believe t is not just "some small design decision" but rather has a huge impact on configuration and flexibility of the framework:

• https://stackoverflow.com/questions/11359187/why-not-use-java-util-logging

[zdenek-jonas]

The purpose of this issue is to discuss it. There is no decision now. The last version has been updated to SFL4J 2.

[michael-schnell]

As SLF4J is just an API (only one small JAR), there shouldn't be a real problem with external dependencies. If your favourite logger is "java.util.logging", you can easily use it with SLF4J by adding "slf4j-jdk14" to your classpath. As Simon pointed out, for other users the possibility to have a different SLF4J implementation is quite important.

[hrstoyanov]

@zdenek-jonas very good call to get rid of slf4j!
You can also consider using Java 9+ System.Logging which is just like SLF4J, but is standard, and can forward to any other logging implementation (by default it is forwarding to standard JUL):
microstream-one/microstream#627