Purpose of SLF4JServiceProvider.getRequestedApiVersion()
?
#363
Unanswered
garretwilson
asked this question in
Q&A
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
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:
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 with2.0
(even though the current version is2.0.9
).Take the
NOP_FallbackServiceProvider
provider, for example. There is no reason why it should request version2.0.99
. What happens when SLF4J goes to version 3.0? If someone forgets to update theREQUESTED_API_VERSION
string, if the new version of SLF4J doesn't allow things in the2.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 thisSLF4JServiceProvider
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.
Beta Was this translation helpful? Give feedback.
All reactions