Remove slf4j to achieve zero-dependency policy

[hakky54]

Remove slf4j to achieve zero-dependency policy

[charphi]

I agree with you.
The solution provided by persim is more a hack than an ellegant solution.
slf4j is ok as a single dependency since it is really stable.

[Hakky54]

Yes, that stackoverflow topic is quite old. And I am not quite sure how it will be with version 2.x of slf4j

But great to hear that you can use the library with your current setup, let's keep this issue open so others maybe can share their thoughts about this topic.

[Athou]

I feel like having slf4j-api as a dependency is perfectly acceptable nowadays since it's now the de facto logging facade.

I encountered this the other day though and it looks like an interesting alternative if you really want to go the zero-dependency way
https://github.com/sproket/Persism/blob/master/src/net/sf/persism/Log.java

[charphi]

This "persim" solution is interesting but I'm concerned that it might not work with GraalVM native image (to be tested).

There is also a "new" logging facade in Java9+ (http://openjdk.java.net/jeps/264) but it is not yet integrated in slf4j and is not compatible with Java8 of course.

[Athou]

As far as I'm concerned, slf4j is a perfectly acceptable dependency. Your library will work fine for everyone, and those who want to route its logging to their logging framework of choice only need to bundle the right slf4j-to-logging-framework implementation, and chances are they already do because almost everybody uses slf4j nowadays.

I'm not sure dependency hell as mentioned by OP is worth the hassle regarding slf4j. The authors of slf4j made sure their api was binary compatible since the first stable release (http://www.slf4j.org/faq.html#compatibility).

[Hakky54]

This is a good remark, thank you for pointing out. Up till now I already tried making it less dependent on other libraries to prevent a dependency hell. The only remaining library is indeed slf4j. I have seen that you added slf4j-jdk14 to your project to make this library working, this wasn't not my intention actually when choosing for a logging solution.

Currently I am not quite sure what a good solution would be. If I use the logging solution which is available within the jdk, the developers using this library won't be able to configure the log appenders. Most of the projects are already using slf4j and have their own slf4j bindings. If I don't ship this library with a slf4j binding it won't clash with other projects who already have a binding.

If I do ship it with a binding, for example apache. And someone is using this library and within his project he is using logback. He needs to exclude manually in the pom apache from this library. In your case, you are not using a binding at all. so shipping this library with a default binding will also work and in that way you can remove the additional dependency from your pom. But it can hurt other developers who already have a binding.

So I need to think a bit longer about this before changing, but I will drop a message here if I make any progress on it.

[charphi]

I have the same problem with my own libs.
It is possible to redirect jdk logging to slf4j but it has a performance cost.
Another solution would be to use a log facade (1 interface with few methods) to let users choose their own logger.

[Hakky54]

I came across this nice topic: Stackoverflow - Why not use java.util.logging?. After reading this I think it is better to stay with the slf4j api, as it performs better.

I won't be providing a default slf4j binding, in this way the developers who have already their own slf4j binding in their project won't be burdened by an error of having multiple slf4j implementation on their classpath.

The downside of this approach is that projects who don't rely on slf4j api at all for logging are forced to add a binding when using this library. Although I understand your suggestion of having zero dependency policy, I think it is better to keep the slf4j api compared to using java util logging. At least the performance would be better as java util logging is 10x slower.

What do you think?

[charphi]

It is difficult to choose. The stackoverflow topic is interesting but is from 2012. The situation might not be exactly the same today.
slf4j is a great library; I really like it. Still, will its next iteration (v2.x) be compatible with the current one?

Note that I'm able to use your library as it is today. So you might postpone your decision.

[Hakky54]

That is an interesting project, really cool that someone thought about a solution for this kind of topic. I think in our case if someone is not including an slf4j binding the library still works. The only ugly part is that it will print some warnings and it won't log anything when the SSLFactory wants to log something. The library would be still usable without adding a custom implementation.

I just tried it with your project: https://github.com/Athou/ssl-test
When I remove:

<dependency>
	<groupId>org.slf4j</groupId>
	<artifactId>slf4j-simple</artifactId>
	<version>1.7.30</version>
	<scope>test</scope>
</dependency>

it will print:

[INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ ssl-test ---
[INFO] Surefire report directory: /Users/hakan/projects/private/ssl-test/target/surefire-reports

-------------------------------------------------------
 T E S T S
-------------------------------------------------------
Running test.SslTest
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
Loading JavaScript to validate ECMA262 regular expression in JsonSchema because java.util.regex package in Java does not match ECMA262
Warning: Nashorn engine is planned to be removed from a future JDK release
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.952 sec

Results :

Tests run: 1, Failures: 0, Errors: 0, Skipped: 0

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  5.751 s
[INFO] Finished at: 2021-02-01T18:15:55+01:00
[INFO] ------------------------------------------------------------------------

And as you can see it is still working.

I am still curious regarding the library you mentioned, so I will try that out. Thank you!

[Hakky54]

Although we are 6 months further I am still not sure what the proper solution will be. I think the suggestion of charphi is still valid. The ideal situation would be zero dependencies. However I am fine with the statement as less dependencies as possible to prevent dependency hell.

I feel like having slf4j-api as a dependency is perfectly acceptable nowadays since it's now the de facto logging facade.

Exactly for this reason I think it is still reasonable to include slf4j API as a logging facade

[Hakky54]

Hey guys @charphi @Athou

I have an update regarding this issue. I still like the idea to prevent additional transitive dependencies to the end-user. And I also like the way how persim is solving the issue by dynamically trying different logging api's at runtime and fallbacks to jul.

I didn't prefer to copy the log class of persim into the code base of this library, so I created a new project see here:
GitHub - YASLF4J (yet another simple logging facade for java)
In this way it is also usable to others if they also want to make use of it without copying it into their code base. It works with slf4j or log4j2 too when it is available on the classpath or else it will fall back to java util logging.

I also tested it with graalvm as @charphi has doubts if it would work. It will work if the following build argument will be provided when building a native image with graalvm: --allow-incomplete-classpath

See here for the merged PR: #90

What do your think, would this be something which will work for you guys? Or prefer a different solution?

[Hakky54]

As far as I'm concerned, slf4j is a perfectly acceptable dependency. Your library will work fine for everyone, and those who want to route its logging to their logging framework of choice only need to bundle the right slf4j-to-logging-framework implementation, and chances are they already do because almost everybody uses slf4j nowadays.

Yes I agree on this point. I am actually also fine with keeping slf4j. As I don't think it will lead to a dependency hell. What do you think @charphi regarding the comment of Jérémie?

[Hakky54]

I came into a conclusion that having slf4j-api as a transitive dependency will not result into a dependency hell. I think the zero-dependency policy is a good practise as every library should have minimum required transitive dependencies. Slf4j is also widely used, so relying on it should be ok. I have considered to replace slf4j with yaslf4j. It has pros, as it will not have a transitive dependency of slf4j and it will still work with it when it is present on the classpath of the end-user. The downside is that the end-user needs a additional flag for graalvm --allow-incomplete-classpath which in my opinion is not a very good practise. I was also curious what Philippe would respond, but he didn't replied. So overall I decided to close this issue as I came to a conclusion that it is fine to have slf4j as a transitive dependency.