Purpose of SLF4JServiceProvider.getRequestedApiVersion()?

[garretwilson]

Can someone explain the purpose of SLF4JServiceProvider.getRequestedApiVersion(), or point me to some more extensive documentation about it?

On the face of it (just looking at the interface, which has a hard-coded value), it smells of a kludge. I looked in the code and initialization seems to do a "sanity check", comparing against known versions; suddenly this seems like even a worse idea than it did before. I'll bet at one time it seemed like a good thing to do, perhaps to help migrate from 1.x? There are so many downsides to this approach, though, that unless there is a huge need now, I really think this should be abandoned.

This is the sort of thing that everybody forgets about until 2055, when the logging provider everybody is using around the world suddenly breaks with an error such as:

The requested version 2.4.6 by your slf4j provider is not compatible with [3.0, 4.0].

We saw all sorts of problems like this upgrading past versions of Java when there were libraries (e.g. in Maven plugins) that would check to make sure versions were in some range that didn't recognize the new Java version syntax. This is worse because it's checking actual versions.

Furthermore the code doesn't even do a true version comparison. That is, my provider might send back that it requests 2.0.5, and that would still work because the current code only checks to see if it starts with 2.0 (even though the current version is 2.0.9).

Take the NOP_FallbackServiceProvider provider, for example. There is no reason why it should request version 2.0.99. What happens when SLF4J goes to version 3.0? If someone forgets to update the REQUESTED_API_VERSION string, if the new version of SLF4J doesn't allow things in the 2.0 range, this will suddenly fail.

If we really need to check to make sure old providers are compatible with future versions of SLF4J, you can just change the interface. If the old provider isn't compatible, its interface won't be compatible. And if you need to do some fine-grained checks about capabilities, a getCapabilities() method can be added to this SLF4JServiceProvider so that SLF4J can determine if the correct capabilities are supported. (This can even be done in a backwards-compatible way with Java interface default implementations.) See comment in SLF4J-450 for example.

Overall I don't see the use of this hard-coded supported/requested version , but I see a whole lot of risks.

[NathanSweet]

Crickets?

[ceki]

Linked with https://jira.qos.ch/browse/SLF4J-603 for tracking

[rgoers]

I have to disagree. I don't think this does what you think. Although SLF4J might put out many releases not all of them affect the binding with an implementation. But when the binding is impacted you do not want your application to suddenly encounter weird errors. Yes, you might be able to prevent this by specifying version ranges in the logging implementation's pom file, but in practice it is likely that the application specified the versions to use causing that check to be ignored. So having an error that says "Logging implementation xxx does not support at least SLF4J version 1.x.x and will be ignored" can be extremely helpful.