はてなブックマーク

Bridging legacy APIs Often, some of the components you depend on rely on a logging API other than SLF4J. You may also assume that these components will not switch to SLF4J in the immediate future. To deal with such circumstances, SLF4J ships with several bridging modules which redirect calls made to log4j 1.x, JCL and java.util.logging APIs to behave as if they were made to the SLF4J API instead.

The motivation for the SLF4J Android project was to ease using existing libraries which use SLF4J as their logging framework on the Google Android platform. This project is basically a (i) repackaging of the SLF4J API part, together with (ii) a very lightweight binding implementation that simply forwards all SLF4J log requests to the logger provided on the Google Android platform. The API part is

Frequently Asked Questions about SLF4J Generalities What is SLF4J? When should SLF4J be used? Is SLF4J yet another logging facade? If SLF4J fixes Jakarta Commons Logging (JCL), then why wasn't the fix made in JCL instead of creating a new project? When using SLF4J, do I have to recompile my application to switch to a different logging system? What are SLF4J's requirements? What has changed in SLF4