4 ms·
Its so incredibly refreshing when technologies are positioned by saying what they don't do. When we describe our cool stuff to the world, its natural to go on
by abraae 10y ago
Its so incredibly refreshing when technologies are positioned by saying what they don't do.
When we describe our cool stuff to the world, its natural to go on and on about all the cool stuff it can do. But I'm more inclined to trust technologies that state clearly what they can't or don't do, or are not intended for.
I don't know if there is a name for this effect, but having only nodded at SL4J from a distance, I feel much happier about using it (or choosing not to) after reading this:
> In short, libraries and other embedded components should consider SLF4J for their logging needs because libraries cannot afford to impose their choice of logging framework on the end-user. On the other hand, it does not necessarily make sense for stand-alone applications to use SLF4J. Stand-alone applications can invoke the logging framework of their choice directly.
- niftich 10y agoSLF4J is quality software, but it's quite ironic that it needs to exist at all, considering how much of both the Java mentality and the commercially significant Java EE platform is about coding against a well-defined interface that defines basic contract and semantics and allows the developer/customer/etc to supply their favorite and most-appropriate implementation of choice. In the case of SLF4J, it was the community (or rather, Ceki Gülcü, the author of now-several logging frameworks, in response to his dissatisfaction with the community-led Apache Commons Logging) who stepped in to provide the 'generic' API, while Sun went and developed an actual 'hardcoded' implementation deliberately different from the popular third-party logging frameworks of the time instead and shipped it with Java 1.4.