4 ms·

When are they going to release Log5j? Or even Log4k to address these issues?

by bgro 4y ago

hedora 4y ago
The log4j author already did this about a decade ago. No one could understand log4j back then, so the replacement is much, much simpler, and API compatible for 99+% of use cases. Few projects seem to have bothered moving to it, probably becuase log4j is such a collosal pain to set up or modify.
- bxparks 4y ago
  What is that replacement? java.util.logging?
  - jffry 4y ago
    I believe that replacement is Logback [1] + SLF4J, according to the intro section on Wikipedia's log4j article [2] [1] https://logback.qos.ch/reasonsToSwitch.html https://logback.qos.ch/reasonsToSwitch.html [2] https://en.wikipedia.org/wiki/Log4j https://en.wikipedia.org/wiki/Log4j
- qw 4y ago
  I think Spring Boot defaults to Logback these days.
- hinkley 4y ago
  > No one could understand log4j back then If you're scoffing at this, I want you to do an experiment. Imagine yourself at 26, when you just knew enough to be dangerous. Or as the person you're currently mentoring/would like to mentor. Now go into your application code, set a breakpoint on one of the moderately complex `logger.info()` calls, run your application and step into log4j. All the way down, until it writes to disk. If you don't say "what the fuck" out loud at least once, you're a soulless monster and should go live in a cave. If your application has a pretty good architecture, you may well discover that the code leading up to the `logger.info()` call is substantially less complex than the code below it. Just to write some text to the end of a single-writer file. It chaps my ass that log4js, which claims specifically not to be a javascript port of log4j, has the same pattern of layers and weird indirection (some of which are avoided by monkey patching, which is in many respects even worse from a legibility standpoint, and absolutely from a discoverability standpoint). Much of this is chasing after not implementing the same 1 line function 6 times, which is made weirder by the fact that you have to write individual unit tests for each of the log levels, so you've already written 95% of the duplicated code. Logging frameworks are a nearly canonical example of DRY as an antipattern.
- vips7L 4y ago
  > Few projects seem to have bothered moving to it, probably becuase log4j is such a collosal pain to set up or modify. Every new project I see defaults to slf4j/logback.

When are they going to release Log5j? Or even Log4k to address these issues?

by bgro 4y ago

When are they going to release Log5j? Or even Log4k to address these issues?

The log4j author already did this about a decade ago. No one could understand log4j back then, so the replacement is much, much simpler, and API compatible for 99+% of use cases. Few projects seem to have bothered moving to it, probably becuase log4j is such a collosal pain to set up or modify.

bxparks 4y ago
What is that replacement? java.util.logging?
- jffry 4y ago
  I believe that replacement is Logback [1] + SLF4J, according to the intro section on Wikipedia's log4j article [2] [1] https://logback.qos.ch/reasonsToSwitch.html https://logback.qos.ch/reasonsToSwitch.html [2] https://en.wikipedia.org/wiki/Log4j https://en.wikipedia.org/wiki/Log4j
qw 4y ago
I think Spring Boot defaults to Logback these days.
hinkley 4y ago
> No one could understand log4j back then If you're scoffing at this, I want you to do an experiment. Imagine yourself at 26, when you just knew enough to be dangerous. Or as the person you're currently mentoring/would like to mentor. Now go into your application code, set a breakpoint on one of the moderately complex `logger.info()` calls, run your application and step into log4j. All the way down, until it writes to disk. If you don't say "what the fuck" out loud at least once, you're a soulless monster and should go live in a cave. If your application has a pretty good architecture, you may well discover that the code leading up to the `logger.info()` call is substantially less complex than the code below it. Just to write some text to the end of a single-writer file. It chaps my ass that log4js, which claims specifically not to be a javascript port of log4j, has the same pattern of layers and weird indirection (some of which are avoided by monkey patching, which is in many respects even worse from a legibility standpoint, and absolutely from a discoverability standpoint). Much of this is chasing after not implementing the same 1 line function 6 times, which is made weirder by the fact that you have to write individual unit tests for each of the log levels, so you've already written 95% of the duplicated code. Logging frameworks are a nearly canonical example of DRY as an antipattern.
vips7L 4y ago
> Few projects seem to have bothered moving to it, probably becuase log4j is such a collosal pain to set up or modify. Every new project I see defaults to slf4j/logback.