A comprehensive study of bloated dependencies in the Maven ecosystem

Abstract

Build automation tools and package managers have a profound influence on software development. They facilitate the reuse of third-party libraries, support a clear separation between the application’s code and its external dependencies, and automate several software development tasks. However, the wide adoption of these tools introduces new challenges related to dependency management. In this paper, we propose an original study of one such challenge: the emergence of bloated dependencies. Bloated dependencies are libraries that are packaged with the application’s compiled code but that are actually not necessary to build and run the application. They artificially grow the size of the built binary and increase maintenance effort. We propose DepClean, a tool to determine the presence of bloated dependencies in Maven artifacts. We analyze 9,639 Java artifacts hosted on Maven Central, which include a total of 723,444 dependency relationships. Our key result is as follows: 2.7% of the dependencies directly declared are bloated, 15.4% of the inherited dependencies are bloated, and 57% of the transitive dependencies of the studied artifacts are bloated. In other words, it is feasible to reduce the number of dependencies of Maven artifacts to 1/4 of its current count. Our qualitative assessment with 30 notable open-source projects indicates that developers pay attention to their dependencies when they are notified of the problem. They are willing to remove bloated dependencies: 21/26 answered pull requests were accepted and merged by developers, removing 140 dependencies in total: 75 direct and 65 transitive.

Communicating Natural Programs to Humans and Machines

“…While this DSL-first workflow has yielded impressive results, the DSL itself is also a single point of failure. A key challenge for designing any DSL is determining its scope: a good DSL should make it easy to construct programs for the domain, without bloating the language with redundant concepts [27][28][29]. For systems that seek to understand human natural language, extensive effort is often necessary to ensure that the DSL aligns reasonably to human instructions [30,31].…”

The Used, the Bloated, and the Vulnerable: Reducing the Attack Surface of an Industrial Application

“…Many other configuration options enable and fine-tune additional ProGuard features, (such as, field or method removal, obfuscation, method inlining, class merging). DepClean [1] identifies and removes bloated dependencies that are part of the dependency tree of the project under analysis, but whose code is not used (neither directly nor indirectly) by the application. Differently from Maven Shade and ProGuard, the focus of DepClean is not to produce a compact Java archive for use at runtime, but rather to simplify the dependency tree at development time.…”

“…The effect of software reuse on security is investigated by Gkortzis et al in [2], who show empirical evidence of the relation between the size of a code base and its likelihood to contain some vulnerabilities. Recently, Soto-Valero et al conducted a large-scale study to assess the prevalence of bloated dependencies in the Maven ecosystem [1]. In the same paper, they presented DepClean, one of the tools we used in our case study.…”

“…Automated package management tools allow developers to find and integrate third-party components in their projects with minimal effort. While automated dependency management simplifies software reuse, it may contribute to the phenomenon of software bloat [1]. As Gkortzis et al put it "code reuse cuts both ways", since "a system can become more secure by relying on mature dependencies, or more insecure by exposing a larger attack surface via exploitable dependencies" [2].…”

“…In practice, only a fraction of the functionality (and code) of a dependency may actually be needed, and entire components could be redundant. Even if some dependency code is not reachable when included in a given application (and thus it can be considered dead code in that context), it can still contribute to extending the attack surface of that application, e.g., because it includes gadget classes leading to deserialization vulnerabilities 1 .…”