SLF4J 2 dependency, despite being fulfilled by older version

[marcoSpoethAtYatta]

Hi there! We've been working with your library for quite some time now and appreciate the work you've done! We notice you've got a dependency to SLF4J 2 since this commit, despite using the (backwards compatible) API the same way it has been since 1.7.36 and below.

Is there a specific reason to require explicitly the newest version of SLF4J? Doing so makes the resulting Manifest.MF enforce a requirement of org.slf4j;version="[2.0,3), which is not available to all code bases. Be it for safety regulations or inability to use the ServiceLoader now required by SLF4J 2, the dependency cannot be fulfilled by a local SLF4J 1.7.36, even though, by code, it's perfectly compatible.

I played around with a local clone of your repo, created a jar of 1.5.1, but with the version set to 1.7.3, which allows any version of 1.7.3 and up (including 2.0.13) and it seems to work flawlessly.

Any user of your library would be free to decide which version of SLF4J they want to provide.

If there's nothing forcing you to the newest SLF4J, I can create a branch and PR for those POM.xml changes for you to review!

[justin-tay]

1.7.36 was released in Feb 08 2022 and my impression is that it is EOL which may cause issues with people that can't use EOL libraries.

[marcoSpoethAtYatta]

Thank you for the swift response! You're right in that it is EOL, but setting the SLF4J version in the POM to 1.7.36 will (unless specified otherwise) allow any newer version too. People who cannot use EOL libraries can fulfill the dependency with any newer version, such as the currently set 2.0.13. It simply provides developers more flexibility

[justin-tay]

I actually don't quite understand what you mean about the manifest and enforcing a requirement. Could you explain a bit more? Typically for maven you could just exclude the dependency or set the version you want under dependency management.

[marcoSpoethAtYatta]

Sure thing, I'll try my best!

In your pom.xml you define, among other attributes, the dependencies of your library. When you build a jar to export, that data is used to also fill out the MANIFEST.MF file. in the jar. Build tools like Gradle or Maven use info from the pom to define dependency, while framworks like for example OSGi use the MANIFEST. The version you define is used as a guidance or limit on what version you can use to fulfill dependencies.

To refer to the original post: Let's say some domain "A" requires SLF4J version 1.7.36 and domain "B" requires 2.1.5, while this library requires 2.0.13. Code-wise, due to how backwards compatible SLF4J is, 1.7.36 could fulfill the dependency for all 3. Gradle however may resolve this by loading just 2.1.5 (as simple version definitions without any brackets always include newer versions too).

If you now have a limitation of let's say no ServiceLoader usage, which would disallow SLF4J 2.0.0 and upwards, you could not fulfill "B" or this library, even if they are capable of using SLF4J 1.7.X.

Some systems (OSGi / BND is a big offender here) don't allow finer control for defining which version to use, so it just blindly tries to find a appropriate, local version. This fails at it both doesn't support SLF4J 2.X (out of the box) or multiple versions, so you're forced to update all SLF4J dependencies to a version that is (by code) not necessary.

As per the official documentation for the pom, setting it to allow "as many versions as supported, but as little as needed" is the way we define dependencies in our built jars.

Check out for example how Kafka shows up on MavenCentral:. They define SLF4J 1.7.36 and upwards, by their pom.

You could do the same, at least as per your code, as you only use the Logger & LoggerFactory from what I could gather. There'd be no downside (or any real change) for you or your current userbase, but you'd be able to support more limited software.

Sorry if this ended up a bit rambly, it's just something I noticed when I was updating dependencies in our project

[marcoSpoethAtYatta]

Guess the short summary of everything I wrote here would be: rather than explicitly depend on the newest SLF4J version, you could implicitly allow the newest, without preventing those, having to use the older ones

[justin-tay]

Thanks for the explanation. I think it's unlikely that the version of SLF4J in the pom will be downgraded to 1.7.36 though. The light-4j project also has it as 2.x. I do see the point that as this is slf4j-api the actual version that will actually be used depends on the actual logging implementation dependencies eg logback which will set the appropriate slf4j-api version. Would likely need @stevehu to comment on this.

I'm not familiar with OSGi. Would just modifying the MANIFEST.MF work for you? For instance modifying the Import-Package instructions for the maven-bundle-plugin?

For instance if I change it to

      <plugin>
        <groupId>org.apache.felix</groupId>
        <artifactId>maven-bundle-plugin</artifactId>
        <version>${version.maven-bundle-plugin}</version>
        <extensions>true</extensions>
        <configuration>
          <instructions>
            <Import-Package>
              org.jcodings;resolution:=optional,
              org.jcodings.specific;resolution:=optional,
              org.joni;resolution:=optional,
              org.joni.exception;resolution:=optional,
              org.slf4j;version="[1.7,36)",
              *
            </Import-Package>
          </instructions>
        </configuration>
      </plugin>

The MANIFEST.MF will then be

Import-Package: org.jcodings;resolution:=optional,org.jcodings.specific;
 resolution:=optional,org.joni;resolution:=optional,org.joni.exception;r
 esolution:=optional,org.slf4j;version="[1.7,36)",com.ethlo.time;version
 ="[1.10,2)",com.fasterxml.jackson.annotation;version="[2.17,3)",com.fas
 terxml.jackson.core;version="[2.17,3)",com.fasterxml.jackson.databind;v
 ersion="[2.17,3)",com.fasterxml.jackson.databind.annotation;version="[2
 .17,3)",com.fasterxml.jackson.databind.json;version="[2.17,3)",com.fast
 erxml.jackson.databind.node;version="[2.17,3)",com.fasterxml.jackson.da
 tabind.ser.std;version="[2.17,3)",com.fasterxml.jackson.databind.util;v
 ersion="[2.17,3)",com.fasterxml.jackson.dataformat.yaml;version="[2.17,
 3)",com.networknt.org.apache.commons.validator.routines,com.networknt.s
 chema,com.networknt.schema.annotation,com.networknt.schema.format,com.n
 etworknt.schema.i18n,com.networknt.schema.output,com.networknt.schema.r
 egex,com.networknt.schema.resource,com.networknt.schema.result,com.netw
 orknt.schema.serialization,com.networknt.schema.serialization.node,com.
 networknt.schema.utils,com.networknt.schema.walk,org.graalvm.polyglot;r
 esolution:=optional

I'm not sure what are the implications of doing this or if this is going to be a breaking change.

[marcoSpoethAtYatta]

I think in theory editing the manifest would work, though not sure to what exact extend. At least during compile and run time OSGi and BND would accept those.

But won't it be strange for the library to require 2.0.13 per the pom, which is shown in mavencentral too? Maven / Gradle would also only be able to recognize a dependency for the newest version. Only frameworks that use the manifest would be able to take advantage, but then only if they know about this specific detail, which is not easy to find out about in practical way.

It's a very generous offer, which I truly appreciate, but I think such a change would introduce unexpected behaviour for other users of your library

[justin-tay]

I do agree it is strange. The main reason for my suggestion is because it sounds like it is difficult to customize the behavior of OSGi and BND. While for Maven / Gradle it should be relatively easy to exclude the dependency or set a specific version for dependency management.

I do find it strange that out of all the libraries out there, it is this library that has this specific issue as I would think the majority of libraries have upgraded to 2.x or are planning to do so. I would think it's a matter of time that you will encounter other libraries at 2.x, surely you can't be going around convincing everyone to downgrade, particularly if they are using any 2.x features like the fluent api.

I'm also not clear about your no ServiceLoader usage requirement that leads you to not use 2.x. I see that there is a slf4j.provider system property that bypasses the service loader mechanism. Would that work for you?

• https://github.com/qos-ch/slf4j/blob/1d82519b07d7d755096d916dfbfaddd2d0e07c4f/slf4j-api/src/main/java/org/slf4j/LoggerFactory.java#L91

[marcoSpoethAtYatta]

Oh our project, despite using OSGi, is able to upgrade to SLF4J 2, I just mentioned ServiceLoader limits, as I thought that was a more real world near example than some arbitrary "management just doesn't want SLF4J to update" or something along those lines.

When updating SLF4J and any libraries that could now be upgraded I also took a look at how and what they logged (the logged content has become a security concern recently) and I just noticed the typical 1.X logging used.

It's not specifically a problem with this library (or even a problem at all), I was just thinking about older codebases. But yeah, I guess you're right, it's probably time to say goodbye to SLF4J 1.X.

If you think changing the version's not needed feel free to close this issue. Thank you for your incredible support!