According to a survey from Zero Turnaround Apache log4j is the leading Java logging framework.
This was actually a very interesting survey. It shows SLF4J is most often used as a logging facade with 61%. But it seems it is most often used with Apache Log4j, which is used by 52% of all survey participants. Just 29% use logback and only 7% JDK Logging. The same number of people write their own framework.
While the report says “Logback” is the successor of “Log4j” I need to say this is wrong. The successor of Log4j 1 is Log4j2. Our users will love to know that Apache Log4j 2 is under heavy development. After all these years we are moving away from the ancient code of Log4j 1 to Log4j 2. We have learned from the lessons of the past and build Log4j 2 to be insanely fast and stable.
In fact we wanted to make Log4j 2 so reliable that you can use it as an audit logging framework. With all the other frameworks this can’t be done so far. For example, log4j 1 and logback will loose event while reconfiguring which is not acceptable when you need to audit. Read more about that in the official docs.
There are actually many more improvements which should make use Log4j 2 in favor to any other logging framework.
Not only because Log4j 2 is just fantastic (in my opinion). It’s developed with the umbrella of the Apache Software Foundation. The Foundation does take care that all developed code at Apache stays free. Nobody can suddenly close down the source repositories and force you to pay for the code. You are not tied to any commercial entity. With the ASF you prevent vendor-lock in.
At Apache Logging we invite people to join us as committers on a regular basis. We are an open community. If we see you have an long term interest in our project chances are very good that you’ll be invited to join us. In other terms: you can definitely influence Apache Logging and you can be sure that Apache Log4j is developed in a way the community wants it, not any commercial entities.
With that being said I would like to point you to another site. While the Apache Software Foundation protects your favorite Logging-Framework, many people have asked me about a standard for Logging within the JDK. Looking how widely spread slf4j is I agree there is a need. I have recently joined the “New Logging” approach. I believe it is time for the JDK to provide a standard logging facade. With such a facade the “Logging wars” can finally be put to an end. My hope is the Apache Logging team will be able to provide you a first reference implementation of that facade. Unfortunately this is a long road to go. If you are interested, join the Java.net project and voice your opinion.
Bulletproof Java Code: A Practical Strategy for Developing Functional, Reliable, and Secure Java Code
Use Java? If you do, you know that Java software can be used to drive application logic of Web services or Web applications. Perhaps you use it for desktop applications? Or, embedded devices? Whatever your use of Java code, functional errors are the enemy!
To combat this enemy, your team might already perform functional testing. Even so, you're taking significant risks if you have not yet implemented a comprehensive team-wide quality management strategy. Such a strategy alleviates reliability, security, and performance problems to ensure that your code is free of functionality errors.Read this article to learn about this simple four-step strategy that is proven to make Java code more reliable, more secure, and easier to maintain.