4 ms·

I never understood where log4j 2 was supposed to fit in the ecosystem. * We had log4j 1, which was good enough for most use cases and everywhere. * We had slf

I never understood where log4j 2 was supposed to fit in the ecosystem. * We had log4j 1, which was good enough for most use cases and everywhere. * We had slf4j/logback, which was from the same authors, and broke backward compatibility but gave us a fundamentally better design. * We had java.util.logging, which while braindead was builtin to Java and hence available everywhere. *We had commons logging, which was never supposed to escape from tomcat, but got overused everywhere anyway. All of this was more logging frameworks than was healthy for 1 language, and there are some more smaller ones. Then apache decides to put new people on log4j, do a backward incompatible v2 design that nevertheless is worse than slf4j. Why?

shagie 4y ago
> Then apache decides to put new people on log4j, do a backward incompatible v2 design that nevertheless is worse than slf4j. Why? slf4j itself isn't a logging framework. It's a facade to logging frameworks. Simple Logging Facade for Java ( https://www.slf4j.org https://www.slf4j.org ) It needs a logging framework behind it - log4j, log4j2, logback, commons, JUL. The question is "why do log4j2?" Logback went from the log4j1.x path ( https://logback.qos.ch https://logback.qos.ch ) Log4j2 has a lot of features that weren't present when the project started ( https://en.wikipedia.org/wiki/Log4j#Apache_Log4j_2 https://en.wikipedia.org/wiki/Log4j#Apache_Log4j_2 ). There is a licensing difference between Logback (LGPL) and Log4jx (Apache Commons).
- Aperocky 4y ago
  > Log4j2 has a lot of features Apache projects in general have this feature creep seeping into every single one of their products that I have used. It's just hard to trust apache projects now.
- kelnos 4y ago
  > It needs a logging framework behind it - log4j Minor nit: log4j doesn't implement the slf4j interface, though. If you do want log4j to do your logging, but use slf4j in your application, you need to include a "bridge" library that adapts slf4j to log4j. And, conversely, if you have dependencies that use log4j, but want things to end up going through your slf4j-supporting backend (say, logback), you need to exclude the "real" log4j jar and include a different library that implements log4j's interface and forwards calls to slf4j.
vbezhenar 4y ago
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
layer8 4y ago
> Then apache decides to put new people on log4j, do a backward incompatible v2 design that nevertheless is worse than slf4j. Why? Because the original Log4j author wanted to do his own thing for a Log4j successor (slf4j/logback), and the Apache Log4j maintainers also had ideas about a next-gen framework and wanted to do that. That’s Open Source, everyone can do their own thing if they like, and some things will get adopted more than others. Log4j2 got the most adoption because they had the Log4j “brand” and the Apache backing and more company-backed(?) maintainers. I don’t consider java.util.logging to be braindead. It can in principle be used as a logging facade like slf4j, but not too many do that, and Log4j 1 had come first and kept that momentum. The real mistake was for Java to not have a standard logging API earlier. (It took six years after Java 1.0.)
- YetAnotherNick 4y ago
  Hearing logging library and next-gen framework in the same sentence would never not make me laugh.
- twic 4y ago
  I use java.util.logging in a few apps, to cut down on dependencies, and i consider it to be fairly braindead. The fundamentals are okay, to the extent that they are copies of log4j, but there are a bunch of little things that just aren't done right, like: - logging methods taking arrays rather than varargs (this would be a trivial change!) - there being no way to create a SimpleFormatter with a custom format in code other than setting a system property before creating it - there being no Logger:getLogger override which takes a class, only strings At some point, i am going to write a little facade which wraps jul and fixes the papercuts, which feels like a very silly thing to be doing!
  - layer8 4y ago
    Those are cosmetic issues, in my book. The basic architecture is sound. In any serious application you will want to have a central logging wrapper anyway (I always use one), which automatically takes care of the varargs issue. The implementation of SimpleFormatter is 30 lines that you can easily copy and adjust as needed, including with your own custom format. Regarding logger names, I always define an explicit set of logger names for the application, because that makes the logger names independent from implementation-detail subpackages, and any operations-side log filtering based on logger names will remains stable, regardless of how you refactor your implementation into Java packages. Basically, I see the logger names as part of the external interface of the application, and therefore I want to have them decoupled from the internal package structure, so that mere refactorings don't break that interface. You can still easily find all program locations that log to a specific logger, for example by Find Usages on the respective static Logger constant.

shagie 4y ago

> Then apache decides to put new people on log4j, do a backward incompatible v2 design that nevertheless is worse than slf4j. Why? slf4j itself isn't a logging framework. It's a facade to logging frameworks. Simple Logging Facade for Java ( https://www.slf4j.org https://www.slf4j.org ) It needs a logging framework behind it - log4j, log4j2, logback, commons, JUL. The question is "why do log4j2?" Logback went from the log4j1.x path ( https://logback.qos.ch https://logback.qos.ch ) Log4j2 has a lot of features that weren't present when the project started ( https://en.wikipedia.org/wiki/Log4j#Apache_Log4j_2 https://en.wikipedia.org/wiki/Log4j#Apache_Log4j_2 ). There is a licensing difference between Logback (LGPL) and Log4jx (Apache Commons).

Aperocky 4y ago
> Log4j2 has a lot of features Apache projects in general have this feature creep seeping into every single one of their products that I have used. It's just hard to trust apache projects now.
kelnos 4y ago
> It needs a logging framework behind it - log4j Minor nit: log4j doesn't implement the slf4j interface, though. If you do want log4j to do your logging, but use slf4j in your application, you need to include a "bridge" library that adapts slf4j to log4j. And, conversely, if you have dependencies that use log4j, but want things to end up going through your slf4j-supporting backend (say, logback), you need to exclude the "real" log4j jar and include a different library that implements log4j's interface and forwards calls to slf4j.

vbezhenar 4y ago

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

layer8 4y ago

> Then apache decides to put new people on log4j, do a backward incompatible v2 design that nevertheless is worse than slf4j. Why? Because the original Log4j author wanted to do his own thing for a Log4j successor (slf4j/logback), and the Apache Log4j maintainers also had ideas about a next-gen framework and wanted to do that. That’s Open Source, everyone can do their own thing if they like, and some things will get adopted more than others. Log4j2 got the most adoption because they had the Log4j “brand” and the Apache backing and more company-backed(?) maintainers. I don’t consider java.util.logging to be braindead. It can in principle be used as a logging facade like slf4j, but not too many do that, and Log4j 1 had come first and kept that momentum. The real mistake was for Java to not have a standard logging API earlier. (It took six years after Java 1.0.)

YetAnotherNick 4y ago
Hearing logging library and next-gen framework in the same sentence would never not make me laugh.
twic 4y ago
I use java.util.logging in a few apps, to cut down on dependencies, and i consider it to be fairly braindead. The fundamentals are okay, to the extent that they are copies of log4j, but there are a bunch of little things that just aren't done right, like: - logging methods taking arrays rather than varargs (this would be a trivial change!) - there being no way to create a SimpleFormatter with a custom format in code other than setting a system property before creating it - there being no Logger:getLogger override which takes a class, only strings At some point, i am going to write a little facade which wraps jul and fixes the papercuts, which feels like a very silly thing to be doing!
- layer8 4y ago
  Those are cosmetic issues, in my book. The basic architecture is sound. In any serious application you will want to have a central logging wrapper anyway (I always use one), which automatically takes care of the varargs issue. The implementation of SimpleFormatter is 30 lines that you can easily copy and adjust as needed, including with your own custom format. Regarding logger names, I always define an explicit set of logger names for the application, because that makes the logger names independent from implementation-detail subpackages, and any operations-side log filtering based on logger names will remains stable, regardless of how you refactor your implementation into Java packages. Basically, I see the logger names as part of the external interface of the application, and therefore I want to have them decoupled from the internal package structure, so that mere refactorings don't break that interface. You can still easily find all program locations that log to a specific logger, for example by Find Usages on the respective static Logger constant.