# Addressing the complexity of the Java logging ecosystem with capabilities

DevFeed: [Addressing the complexity of the Java logging ecosystem with capabilities](<https://devfeed.tech/articles/addressing-the-complexity-of-the-java-logging-ecosystem-with-capabilities-24592.md>)

Original publisher: [Read original article](<https://blog.gradle.org/addressing-logging-complexity-capabilities>)

Author: Louis Jacomet

Published: 2019-12-17T05:00:00Z

Content type: article

Language: en

Sources: [The Gradle Blog](<https://devfeed.tech/sources/the-gradle-blog.md>)

Topics: [Gradle](<https://devfeed.tech/topics/gradle.md>), [Dependency management](<https://devfeed.tech/topics/dependency-management.md>), [Logging](<https://devfeed.tech/topics/logging.md>), [Java](<https://devfeed.tech/topics/java.md>)

Tags: [dependencies](<https://devfeed.tech/tags/dependencies.md>), [dependency-management](<https://devfeed.tech/tags/dependency-management.md>), [google](<https://devfeed.tech/tags/google.md>), [gradle](<https://devfeed.tech/tags/gradle.md>), [log4j](<https://devfeed.tech/tags/log4j.md>), [logging](<https://devfeed.tech/tags/logging.md>), [netflix](<https://devfeed.tech/tags/netflix.md>)

## AI overview

This article explains how Gradle capabilities can address complexity in the Java logging ecosystem by detecting incompatible dependencies on an application's classpath. It uses common logging libraries and real-world failure scenarios to show why build tools need metadata about valid logging configurations.

## Source excerpt

Gradle 6.0 comes with a number of improvements around dependency management that we present in a series of blog posts. In this post we explore the detection of incompatible dependencies on the classpath, through the concept of capabilities. In order to illustrate this concept, we will look at the state of logging for Java applications and libraries. Aside from the Java core libraries providing java.util.logging (JUL), there are a number of logging libraries available to developers, for example: Apache Log4J Slf4J, potentially combined with LOGBack Apache Commons Logging Apache Log4J 2 Google's Flogger The logging problem With such a vast offering, it is no surprise that different libraries use different logging APIs. Combined with the sometimes poor-quality metadata, it is quite common to end up with multiple logging implementations on the runtime classpath of an application. This leads, amongst other things, to this well-known Slf4J warning: SLF4J: Class path contains multiple SLF4J bindings. SLF4J: Found binding in [jar:file:.../slf4j-log4j12-1.7.29.jar!/org/slf4j/impl/StaticLoggerBinder.class] SLF4J: Found binding in [jar:file:.../logback-classic-1.2.3.jar!/org/slf4j/impl/StaticLoggerBinder.class] SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation. SLF4J: Actual binding is of type [org.slf4j.impl.Log4jLoggerFactory] While one could say "This is only a warning", it shows us a place where problems can and do happen. One of our users, the engineering team at Netflix, told us the following story: By selecting the wrong Slf4J logging binding, the log files in one of their systems ended up in the wrong location - causing a disk to fill up that eventually crashed the system. They are surely not the only ones having experienced something like this. Another example: the Slf4J documentation clearly states that if you mix the bridging and delegating JARs for a given integration, you will encounter a StackOverflowError. Log4J 2 adds its own compl