4 ms·

Log4j2 does have some legitimate improvements over logback. These days you don't need anything fancy, just spew logs into stdout and something will capture it t

Log4j2 does have some legitimate improvements over logback. These days you don't need anything fancy, just spew logs into stdout and something will capture it to your ELK, so those loggers seem obsolete indeed. Java need standard logging with slightly improved ergonomics and that's about it.

marginalia_nu 4y ago
Yes, Java logging is ridiculously complicated for largely historical concerns that just don't make much sense in 2022. Like what you most likely need is a wrapper for System.out that maybe does some clever buffering and backpressure management, but the rest is sensibly managed outside of the application; whether by logrotate, ELK, or whatever. Long story short, no modern Java logging framework has any sensible reason to be much longer than a few hundred lines of code.
- kelnos 4y ago
  I don't 100% agree with this, because even when you're doing containers and just dumping your log output to stdout, you still might be shipping that to a log aggregation system that will work a lot better with structured logging. So you might want to output JSON or some other structured format, and you might want your logger to support tagging, markers, stuff like that. Even then, of course, this kind of logging should be able to be done in far fewer lines than most Java logging frameworks.
smarx007 4y ago
> Java need standard logging with slightly improved ergonomics That's exactly what JDK9+ java.lang.System.Logger is. See https://stackoverflow.com/questions/59976828/difference-between-java-util-logging-logger-and-java-lang-system-logger https://stackoverflow.com/questions/59976828/difference-betw...
- ptx 4y ago
  It seems to be mainly intended for use internally in the JDK, though. From the JEP[1]: "It is not a goal to define a general-purpose interface for logging. The service interface contains only the minimal set of methods that the JDK needs for its own usage." And from the motivation section: "The proposed service enables applications to configure the JDK to use the same logging framework as the application: It would only need to provide an implementation of the service that returns platform loggers that wrap the loggers of the preferred logging framework." [1] https://openjdk.org/jeps/264 https://openjdk.org/jeps/264
  - smarx007 4y ago
    Oh, thank you! Learned something today. Plus a lesson to rely less on tech blogs and RTFM more!

marginalia_nu 4y ago

Yes, Java logging is ridiculously complicated for largely historical concerns that just don't make much sense in 2022. Like what you most likely need is a wrapper for System.out that maybe does some clever buffering and backpressure management, but the rest is sensibly managed outside of the application; whether by logrotate, ELK, or whatever. Long story short, no modern Java logging framework has any sensible reason to be much longer than a few hundred lines of code.

kelnos 4y ago
I don't 100% agree with this, because even when you're doing containers and just dumping your log output to stdout, you still might be shipping that to a log aggregation system that will work a lot better with structured logging. So you might want to output JSON or some other structured format, and you might want your logger to support tagging, markers, stuff like that. Even then, of course, this kind of logging should be able to be done in far fewer lines than most Java logging frameworks.

smarx007 4y ago

> Java need standard logging with slightly improved ergonomics That's exactly what JDK9+ java.lang.System.Logger is. See https://stackoverflow.com/questions/59976828/difference-between-java-util-logging-logger-and-java-lang-system-logger https://stackoverflow.com/questions/59976828/difference-betw...

ptx 4y ago
It seems to be mainly intended for use internally in the JDK, though. From the JEP[1]: "It is not a goal to define a general-purpose interface for logging. The service interface contains only the minimal set of methods that the JDK needs for its own usage." And from the motivation section: "The proposed service enables applications to configure the JDK to use the same logging framework as the application: It would only need to provide an implementation of the service that returns platform loggers that wrap the loggers of the preferred logging framework." [1] https://openjdk.org/jeps/264 https://openjdk.org/jeps/264
- smarx007 4y ago
  Oh, thank you! Learned something today. Plus a lesson to rely less on tech blogs and RTFM more!