The evolution of Enterprise Java logging system

Logging is an essential components of large scale enterprise software systems. For large enterprise software system, bugs sometime can take very long time to be discovered, investigated and fixed. This is can be due to  the information in-balance between the development environment and the execution environment. Logging can provide visibilities into the execution of enterprise software system. It had undergone several generations of innovation. 

The first generation of Java logging system are specific logging frameworks, such as Java Logging API, log4j, etc. These frameworks provide some logging features each, however all of them suffer from some sort of the design flaw, thus, the adoption of these logging system has been diverse. 

The second generation of Java logging system comes from the invention of common logging wrapper, such as Apache common logging. These common logging wrappers enable Java developer to write logging framework agnostic code. The wrapper provides a common interface for developers. At the execution time, depending on which logging framework is present in the JCL (Java Class Library), the common logging wrapper will bind with the one that is present at execution time. This seemingly great design have caused a lot of pain due to imperfections in the Java JCL binding process. Softwares using this mechanism suffer from bugs such as memory leaks. 

The third generation of Java logging system is dynamically binded common logging facade, SLF4J. Similar to the 2nd generation common logging wrapper, it decouples logging API from the implementation, thus different organisations running the same software can use different logging system. The difference is the binding happens at the compiling time. As a result, it doesn't suffer from the same bug as the 2nd generation Java logging system do. At the same time, the Java logging framework have been mature enough to support multiple-threaded concurrent logging and log visualization tool.