Replies: 4 comments 3 replies
-
well for 1, stop using log4j. You didn't indicate which but presume 1. Also not being static is rather meaningless to modern loggers. They are instances grabbed from a factory. There is very little over head or cost. And there are already pletty of tools that tell users to stop writing them wrong (ie sonar for example will tell you its missing static final). I would not be surprised that spotbugs likely already does the same. There are also add-ins (plugins) for spotbugs that already do this, slf4j one in fact. Main thing is make sure modern logger usage. |
Beta Was this translation helpful? Give feedback.
-
@rulrok you probably saw that but there's a plugin for SpotBugs checking the correct usage of SLF4J: https://github.com/KengoTODA/findbugs-slf4j I have found that ArchUnit is a good solution if you don't want to write your own detector, it should be quite easy to write a rule checking that loggers must be static. |
Beta Was this translation helpful? Give feedback.
-
@rulrok Coming back to this. Can you clarify you are log4j1? Rest is mostly my opinions and mostly reality. The state of java loggers in 2023 and really since 2021 is this.
Products like spring boot use slf4j/logback as the default logger, they are a big market share there. While they allow switching to log4j2, its extra work and IMHO no reason to do so. Same reason I would not make spring boot use jetty or undertow, no real reason to do so over tomcat other than preference. Personally I feel log4j2 even came to exist due to the owner of slf4j/logback. It works incredibly well but author is a blocker for most part but it still outperforms others. As noted with findbugs-slf4j utility, or openrewrite, or sonar, or many others, they all look at usage of slf4j more strongly because its the most used. As to your performance issues, I don't think spotbugs is right place to even tell a user what libraries to be using to start with nor should we be writing 'how to do log4j1' properly. The loggers have greatly changed over the years. Its important to use supported loggers at all times as with any other code. While our library is about static code, @KengoTODA wrote that findbugs-slf4j and given he did it separately, it was clearly separate for a reason. That is to say someone could write one for every single logger out there but they don't all necessarily work the same and many would be wasted effort. Even that one is incredibly noisy and not super accurate especially if you 'inject' loggers or use the newer style slf4j 2 has that no longer requires to define the class name. |
Beta Was this translation helpful? Give feedback.
-
Hi again. As I am returning to real Java development recently, I am not really aware of the bets logging practices/solutions, but log4j2 has very optimistic sayings throughout their docs about performance and so on. Changing the log frameworks is not feasible for the moment where I am working, but I will certainly look into them whenever possible. I appreciate all the comments upon this. I will see how I can use them to improve on what I have right now. Thanks. |
Beta Was this translation helpful? Give feedback.
-
Hello,
on my code I have detected a performance issue on which a class on a critial path. It declared the log4j logger like this:
As this class is heavily instantiated, it causes a performance overhead.
It should have been declared as
static
:As it is such a easy to slip through error, a detector could save some headache for folks.
Beta Was this translation helpful? Give feedback.
All reactions