2 ms·
The issue is that java did not initially ship with logging capabilities, and by the time it was part of the java.util package, a handful of logging systems had
by scrame 5y ago
The issue is that java did not initially ship with logging capabilities, and by the time it was part of the java.util package, a handful of logging systems had already been introduced by library vendors. JBoss, Jakarta Commons, Log4j and ultimately slf4j all were introduced to address these shortcomings.
The larger issue is in javas dependency system are built with dependencies on these libraries, so if there is no commons logging (or bridge, ala slf4j), then the program won't run.
There are a few other techinical traps with the jvm, like using system.out logging can cause issues with threaded code, or having one giant static logger being imported all over the place conveniently (this is before inversion-of-control became the dominant paradigm) had a few shortcomings, especially as programs grew. Ultimately, though, if you were going to use some third party libraries or app servers, you were almost certainly going to get pulled into the commons-logging vortex, which means you're now configuring that AND your homespun logger.
There is also the case for things like SOLR, where it might be just being used out of the box, but the distribution includes the affected JARs, even if you're just posting and retrieving documents with a python script doing print-logging.
Honestly, I didn't even know log4j2 was a thing, I've moved as much over to slf4j/logback as I could ages ago because of the madness of the JDK logging ecosystem.
- tomohawk 5y agoIt's worse than that. When Java finally added a logging library, they added one that no-one had ever heard of before, and which had fundamental flaws. That's why no-one uses it. At the time, log4j existed and was in wide use, but was not represented on the committee. The author of log4j eventually decided to go a different way and created slf4j / logback. This offering is compatible with log4j and considerably simpler in many ways. Having not been in the Java world for many years, I was surprised log4j was still in widespread use. But maybe I shouldn't be surprised - whenever we have to interact with Java teams, we always have to tamp down on the tendency towards complexity.
- yjftsjthsd-h 5y ago> Having not been in the Java world for many years, I was surprised log4j was still in widespread use. It's Java; the ecosystem is, politely, rather conservative and slow moving.
- ashtonkem 5y agoIt's a bit of conservative culture, and a bit the result of success. There is a lot of Java code out there, and a lot of it is quite old. Finding and replacing every single instance of log4j out there would be a lot of work, and before this incident of relatively low benefit to everyone involved.
- hirako2000 5y agoVery well explained. About log4j2, I think it came to exist because log4j fell far behind logback, and many veteran dev didn't like the inherent push for slf4j over logback. While logback can be used standalone, snobs would yell at you. And since figuring out how to config slf4j over it can easily be less than half a day of work, many simply drooped in log4j2 and told snobs to go away. Note: In case someone is tempted to say that it is trivial to plug slf4j over logback, it is for greenfield work. Replacing an existing logging library, or the use of multiple logging libraries in favor of slf4j over one lib is a confusing matter, mostly because the error thrown at runtime are misleading.
- dakra 5y agoI found this a good overview of the history/current status of Java logger libraries https://lambdaisland.com/blog/2020-06-12-logging-in-clojure-making-sense-of-the-mess https://lambdaisland.com/blog/2020-06-12-logging-in-clojure-...