Switch to SLF4J 2.x for implicit Log4J implementation dependency.

[garretwilson]

It would appear from the dependencies that you're using the older series of SLF4J 1.x, because you're using the Log4j SLF4J 1.x implementation:

        <dependency>
            <groupId>org.apache.logging.log4j</groupId>
            <artifactId>log4j-slf4j-impl</artifactId>
        </dependency>

The big problem with SLF4J 1.x is that is it uses a static class that is included cross-package in the implementation JAR, breaking Java modularization and other things. Everyone should be switching to SLF4J 2.x as soon as possible.

The good news is that SLF4J 2.x is backwards-compatible, so that when you simply switch your library to SLF4J 2.x, all your code works the same. (You can use new features if you want.) But by including the SLF4J 1.x implementation of Log4J, you are forcing an application to use the old version which prevents the use of modern Java features and prevents an application from moving forward to SLF4J 2.x

Instead you should be using:

        <dependency>
            <groupId>org.apache.logging.log4j</groupId>
            <artifactId>log4j-slf4j2-impl</artifactId>
        </dependency>

See Log4j 2 SLF4J Binding and What has changed in SLF4J version 2.0.0?.

A developer may be able to work around this by adding a Maven exclude for org.apache.logging.log4j:log4j-slf4j-impl and manually adding a dependency to org.apache.logging.log4j:log4j-slf4j2-impl. (I haven't tried this.)

[garretwilson]

I'm actually a little confused about whether your library is written to the Log4j API or the SLF4J library. The ticket #965 seems to say that you're writing to the Log4j API (which is disappointing that you're not writing to the SLF4J API). But if this is true, then why do you even include the SLF4J Log4J implementation? If the user wants to access your library using SLF4J, they can add the appropriate SLF4J bridge dependency.

But better yet you would be writing to the SLF4J 2.x API.

[scottgerring]

Hey @jeromevdl and @garretwilson , i'm going to close this one as discussion seems to have moved to #965.

[garretwilson]

But @scottgerring , the discussions in the two tickets are distinct and orthogonal.

You are already using SLF4J. This ticket is to upgrade it to SLF4J 1.x so you won't be forcing users to use old SLF4J implementations and holding back projects from using Java modules and the like.

Whether you switch exclusively to the SLF4J API and/or Logback in #965 is distinct. It is orthogonal—whatever decision is made in that ticket, either yay or nay, will not change this request and the need to update SLF4J to the 2.x line.

This ticket should be reopened.

[scottgerring]

Hey Garrett no worries I skimmed past the nuance. I'll put a test branch together with the dependency flipped as you suggest and see if it really does seem to be low impact.

[garretwilson]

Thanks. Any questions let me know. I worked pretty deep in the stuff related to SLF4J 2.x changes and even released an SLF4J shim for libraries such as Spark 3.3.0 which inappropriately relied on StaticLoggerBinder from the SLF4J 1.x line (but has since been updated). See SLF4J-561 for example. Let me know how I can help.

[scottgerring]

Released in 1.16.0