PaperlayerView exact revision on arXiv

Source-linked AI summary

A Comprehensive Study of Bloated Dependencies in the Maven Ecosystem

César Soto-Valero, Nicolas Harrand, Martin Monperrus, Benoit Baudry

arXiv:2001.07808v1cs.SE

TL;DR

Bloated dependencies are declared packages unnecessary to build or run an application, enlarging binaries and complicating maintenance. DepClean analyzes Maven artifacts' dependency bytecode; across 9,639 artifacts, 75.1% of 723,444 dependency relationships were bloated.

  • Problem

    Systematic evidence on bloated dependencies and their importance to developers is lacking, despite unnecessary binary code and potentially vulnerable unused code.

    Source: §1 · p. 2

  • Method

    DepClean statically analyzes artifact and dependency bytecode for referenced API members and removes dependencies with no direct or indirect API use.

    Source: §3.3 · p. 9, §8 · p. 40

  • Results

    75.1% of 723,444 dependency relationships across 9,639 Maven Central artifacts were bloated; 18 merged pull requests removed 131 dependencies.

    Source: §1 · p. 3

  • Takeaways & Limitations

    Developer feedback indicates removing bloated dependencies is worth the added analysis and effort, though acceptance differed by dependency type.

    Source: §8 · p. 41

    Findings are restricted to Java and Maven; studies of other dependency-management systems are needed to assess generalizability.

    Source: §6.2 · p. 38

Abstract

from arXiv · show

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 the build tool packages with the application's compiled code but that are actually not necessary to build and run the application. This phenomenon artificially grows the size of the built binary and increases maintenance effort. We propose a tool, called DepClean, to analyze 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 that 75.1% of the analyzed dependency relationships are bloated. In other words, it is feasible to reduce the number of dependencies of Maven artifacts up to 1/4 of its current count. We also perform a qualitative study with 30 notable open-source projects. Our results indicate that developers pay attention to their dependencies and are willing to remove bloated dependencies: 18/21 answered pull requests were accepted and merged by developers, removing 131 dependencies in total.

1 Introduction

Maven’s reuse model creates dependency-management challenges, including bloated dependencies: declared packages unnecessary to build or run an application. This study introduces DepClean and measures the scale of bloat and developers’ responses to proposed removals.

1 Introduction

  • Bloated dependencies are declared packages unnecessary to build or run an application, increasing binary size and maintenance effort and potentially embedding exploitable vulnerable code.The larger binary can matter for network delivery and deployment on small devices.Source: §1 · p. 2
  • The study addresses a gap in systematic evidence: prior work touched on dependency-declaration duplication, but the authors report no systematic analysis of bloat or its importance to developers.The authors position this as a large-scale analysis.Source: §1 · p. 2
  • DepClean analyzes Maven’s dependency tree and artifact bytecode to identify bloated dependencies, then generates a POM variant with those dependencies removed.The analysis covers dependencies declared directly and those resolved transitively.Source: §1 · pp. 2–3
  • 75.1% of 723,444 dependency relationships across 9,639 Maven artifacts were bloated, mostly because of unwanted transitive dependencies and multi-module dependency-management complexity.The study also found 18 merged pull requests removing bloated dependencies.Source: §1 · p. 3
  • 18 of 21 answered pull requests were accepted and merged, removing 131 dependencies in the qualitative study.The study involved 30 notable open-source projects.Source: §1 · p. 3

2 Background

The section introduces Maven dependency-management concepts and illustrates their operation using the multi-module Jxls project. It explains how dependency declarations and resolution create the classpath whose contents the study examines.

2.1 Maven Dependency Management Terminology

  • Maven projects use POM files to configure the build; projects may contain multiple modules sharing a parent POM, and deployed artifacts are compiled projects typically packaged as JARs.Artifacts are identified by groupId, artifactId, and version.Source: §2.1 · p. 4
  • Dependency resolution determines and fetches build dependencies, forming a tree of direct, inherited, and transitive relationships; Maven uses a nearest-wins strategy to resolve version conflicts.Direct dependencies are declared in a project or module POM, inherited dependencies in a parent POM, and transitive dependencies arise from their transitive closure.Source: §2.1 · pp. 4–5

2.2 A Brief Journey in the Dependencies of the Jxls Library

  • Jxls is a three-module Maven project; its jxls-poi module combines direct, inherited, and transitive dependencies in the dependency tree shown in Figure 1.The figure omits testing dependencies for simplicity.Source: §2.2 · p. 5, Figure 1 · p. 6
  • Maven’s nearest-wins strategy selects version 1.7.12 over Jxls’s nearer-to-root version 1.7.26, and the resulting classpath motivates checking whether every included artifact is needed.The selected version is nearer to the root in the dependency tree.Source: §2.2 · p. 5

3 Bloated Dependencies

The section defines bloated dependencies through whether Maven-resolved dependencies are used, then presents DepClean to identify and remove bloated relationships.

3.1 Novel Concepts

  • A dependency is bloated when none of its API elements are used, directly or indirectly, by the artifact that depends on it.The definition applies to a dependency relationship along a path in the Maven Dependency Tree.Source: §3.1 · p. 7
  • The Dependency Usage Tree extends the Maven Dependency Tree by labeling dependencies as used or bloated and direct, inherited, or transitive.These two criteria yield six labels: used-direct, used-inherited, used-transitive, bloated-direct, bloated-inherited, and bloated-transitive.Source: §3.1 · p. 7

3.2 Example

  • In the jxls-poi example, commons-jexl and sl4j are unused direct and inherited dependencies, while commons-codec and commons-collections are unused transitive dependencies.The paper reports that the direct dependency can be removed from the POM and the inherited one from its parent; the transitive dependencies are not necessary to build jxls-poi.Source: §3.2 · p. 8

3.3 DepClean: A Tool for Detecting and Removing Bloated Dependencies

  • DepClean analyzes bytecode references to API members, reports dependency usage, and produces a POM variant with bloated dependencies removed.It detects direct and indirect use; directly declared bloated dependencies are removed, while inherited or transitive ones are excluded in the POM.Source: §3.3 · pp. 9, 11

4 Experimental Methodology

The methodology combines a quantitative analysis of Maven artifacts with a qualitative study of open-source projects to examine dependency bloat and developer responses.

4.1 Research Questions

  • The study asks how often bloated dependencies occur, how Maven reuse practices relate to them, and whether developers will remove direct or exclude transitive cases.The quantitative questions cover dependency-tree complexity and multi-module architecture; the qualitative questions examine developer reactions to proposed changes.Source: §4.1 · pp. 12–13

4.2.1 Protocol of the Quantitative Study (RQ1 & RQ2)

  • Researchers randomly sampled 14,699 Maven artifacts and selected 9,639 study subjects meeting additional criteria, including public APIs, reuse, compile-scope dependencies, and being the latest released version at the time.They downloaded binaries and POMs from Maven Central, resolved direct and transitive dependencies locally, and excluded artifacts depending on external repositories or encountering dependency-download errors.Source: §4.2.1 · p. 13
  • For each artifact, DepClean labels dependency relationships through bytecode analysis, then the study measures usage distributions, dependency-tree complexity, and single- versus multi-module differences.The dataset contains 723,444 relationships: 44,488 direct, 180,693 inherited, and 498,263 transitive.Source: §4.2.1 · pp. 13, 15

4.2.2 Protocol of the Qualitative Study (RQ3 & RQ4)

  • The qualitative study selected 30 notable GitHub projects meeting stated activity, buildability, dependency, contribution, and popularity criteria, and submitted at least one pull request per project.For direct-dependency proposals, researchers removed the POM entry only when the project still built and its tests passed; transitive cases were proposed as exclusions.Source: §4.2.2 · pp. 16–17
  • Researchers reviewed POM-file histories to contextualize proposed changes and, when differences were significant, compared packaged-artifact size and dependency-tree complexity.Each pull request included an explanatory message about the proposed change and the impact of retaining the dependency.Source: §4.2.2 · p. 17

5 Experimental Results

The experimental results examine bloated dependency relationships across the studied Maven artifacts and developers’ responses to proposals to remove or exclude them. They cover patterns in transitive bloat and acceptance of proposals targeting direct and transitive dependencies.

5.1 RQ1: How frequently do bloated dependencies occur?

  • 543, 610 (75.1%) of 723, 444 dependency relationships were bloated: 412, 288 (57%) transitive, 111, 649 (15.4%) inherited, and 19, 673 (2.7%) direct.The study counts dependency relationships, not unique artifacts; a dependency can be bloated in one artifact and used in another.Source: Figure 9 · p. 19, §5.1 · p. 19
  • Direct dependencies are only 3.4% of all dependencies, while 85, 975 used dependencies are transitive, so most necessary dependencies are not explicitly declared.Used transitive dependencies may be called by the artifact's code or serve as necessary providers for other dependencies.Source: §5.1 · p. 20

5.2 RQ2: How do the reuse practices affect bloated dependencies?

  • 5, 561 (57.7%) artifacts have more than 50% transitive dependencies, while 879 (9.1%) have none.Across the 9, 639 artifacts, transitive-dependency proportions vary substantially; the figure orders artifacts by their direct-dependency ratio.Source: §5.2 · p. 23, Figure 11 · p. 24

5.2.1 Transitive dependencies

  • ρ = 0.65 (p-value < 0.01) links transitive-dependency share with bloat, and ρ = 0.67 (p-value < 0.01) links tree size with bloated-transitive counts.Artifacts with tree height greater than 9 have at least 28% bloated-transitive dependencies, and the median share exceeds 50% for trees taller than 5; Maven omits dependencies repeated deeper in a tree, so trees tend to be wider than deep.Source: §5.2.1 · pp. 24–26, Figure 12 · p. 24

5.2.2 Single-module vs. multi-module

  • Multi-module artifacts have 76.2% bloat versus 73.1% for single-module artifacts, with inherited dependencies accounting for 24.2% of multi-module relationships.Parent POMs shift dependencies from direct and transitive categories into inherited ones; they can make inherited bloat harder to remove and understand, motivating better tooling.Source: §5.2.2 · pp. 26–28, Figure 14 · p. 26

5.3 RQ3: To what extent are developers willing to remove bloated-direct dependencies?

  • 14/15 pull requests with developer responses were accepted and merged, removing 68 dependencies from project dependency trees.All developers agreed that refining project POMs mattered, and 8/15 responded within 24 hours. Jenkins developers cautioned that removing unused dependencies can break downstream consumers that rely on their inclusion.Source: §5.3 · pp. 28–29, §5.3.1 · p. 30
  • DepClean’s bloated-direct finding for checkstyle’s junit-jupiter-engine was a false positive because reflective use is not captured at the bytecode level.The dependency was added for migrating integration tests to JUnit 5 after deprecation of the Surefire provider.Source: §5.3.2 · p. 30
  • 14 of 15 responded-to pull requests to remove bloated-direct dependencies were accepted, removing 68 dependencies from 14 projects.The undertow-benchmarks change removed six suggested dependencies and reduced the packaged JAR by more than 1MB.Source: §5.3.4 · p. 31

5.4 RQ4: To what extent are developers willing to exclude bloated-transitive dependencies?

  • For transitive exclusions, developers weighed substantial gains against client impact and maintenance concerns, and considered test-scope bloat less harmful.Jenkins maintainers rejected exclusions despite confirming the dependencies were unused in its core, citing potential effects on clients; other developers raised concerns about maintaining exclusion lists, while test-only dependencies were sometimes kept for end users to exclude.Source: §5.4 · p. 32, §5.4.1 · p. 33, §5.4.2 · pp. 33–34
  • Excluding bloated-transitive dependencies reduced spoon’s bundled JAR from 16.2MB to 12.7MB (27.6%), and developers merged the change.The exclusion also reduced the number of classes in the JAR.Source: §5.4.4 · p. 34, Table 6 · p. 35
  • 4 of 8 responded-to pull requests to exclude bloated-transitive dependencies were accepted, removing 63 dependencies from 4 projects; developers had no clear consensus.Some accepted exclusions when they offered substantial gains, while others were concerned about client impact and maintaining exclusion lists.Source: §5.4 · p. 32, §5.4.6 · p. 35

6 Discussion

The discussion links dependency bloat to security and maintenance concerns while noting that developers find transitive dependencies especially difficult to reason about. Its findings are bounded by the Java/Maven setting and by limits of static bytecode analysis and dependency retrieval.

6.1 Implications of Results

  • Bloated dependencies can add potentially exploitable code, and DepClean could complement vulnerability scanners by identifying dependencies for removal rather than upgrade.The discussion frames unnecessary dependencies as an additional source of potential vulnerabilities.Source: §6.1 · p. 36
  • Most bloat stems from transitive dependencies and Maven dependency inheritance; Java 9 modules may reduce transitive growth and make debloating safer by constraining reflection.The proposed benefits are finer-grained reuse declarations and reflection limited to white-listed modules.Source: §6.1 · p. 36
  • Transitive bloat is the largest portion of reported bloat, yet developers find it harder to handle than direct bloat and may view exclusions as a maintainability burden.The study also reports that notable projects with strict development rules are affected, and developers confirmed and removed most reported bloated-direct dependencies.Source: §6.1 · p. 37

6.2 Threats to Validity

  • The study excludes artifacts without complete dependency-usage information, despite using Maven plugins to collect dependency relationships.Incomplete dependency resolution could make DepClean's constructed dependency-under-test information incomplete.Source: §6.2 · p. 37
  • Repackaged or copied dependency code is not explicitly declared in POM files, so DepClean can miss it and the analysis may underestimate bloat.The authors judge these cases unlikely to affect the main results given the dataset size and feedback from actively maintained projects.Source: §6.2 · p. 37
  • Static bytecode analysis can yield false positives when use occurs through dynamic features, although DepClean handles some common reflective calls and uses an exclusion list.The authors note that source-only information such as constants, annotations, and Javadoc links is not detected.Source: §6.2 · p. 37
  • The findings cover Java and Maven; whether they generalize to other dependency-management systems remains an open question.The qualitative study used diverse, mature, popular open-source Java projects, but the authors still identify representativeness as an external-validity concern.Source: §6.2 · p. 38

7 Related Work

Related work places dependency bloat within broader software debloating and ecosystem dependency-management research. The paper distinguishes its Maven-wide analysis and developer feedback from prior work on build performance, API use, and dependency fragility.

7.1 Analysis and Mitigation of Software Bloat

  • The paper characterizes bloated dependencies as a distinct form of software bloat, alongside prior work on software growth, complexity, and its risks.Those risks include harder maintenance, increased attack surface, and degraded performance.Source: §7.1 · p. 38
  • Molly reduces CI build time by lazily retrieving dependencies, whereas DepClean statically analyzes Maven projects rather than replacing Maven.For the studied projects, Molly's average build-time speed-up reaches 45% compared with Maven.Source: §7.1 · p. 38
  • DepClean analyzes and removes unused dependencies at a coarser granularity than techniques that trim unreachable code or specialize programs [14].The paper describes dependency bloat as a significant cause of program bloat in its empirical results.Source: §7.1 · p. 39
  • Prior API-usage studies examined library members and developer use, but the paper adds practical evidence about developers' reactions to bloated dependencies.The cited work also considers API design [13] and developer productivity.Source: §7.1 · p. 39

7.2 Dependency Management in Software Ecosystems

  • Prior build-system research found Java systems grow in size and complexity; the authors interpret bloated dependencies as one consequence of that trend.The passage describes the evolution patterns as linear or exponential.Source: §7.2 · p. 39
  • Ecosystem studies reported many transitive dependencies and fragile dependency trees, while this work analyzes bloat from both users and providers.The cited studies found popular libraries tend to have larger dependency trees.Source: §7.2 · p. 39
  • Research on dependency errors and transitive-dependency problems supplies related context, while this study extends redundancy analysis to Maven Central.The paper hypothesizes that removing dependency bloat could reduce spurious dependency-related CI errors.Source: §7.2 · p. 40
  • Prior work examined unspecified dependencies and dependency-configuration evolution; the paper positions its qualitative findings as complementary evidence about developer practice.The cited Apache-community study found build specifications tend to grow unless explicitly refactored.Source: §7.2 · pp. 39–40

8 Conclusion

The study examines bloated dependencies in Maven through ecosystem-scale analysis and developer feedback. It concludes that POM files need continued engineering, while practical questions about dependency debloating remain open.

8 Conclusion

  • Bloated dependencies are presented as a two-sided challenge for dependency-management systems and developers who declare unused dependencies.The study frames the phenomenon as arising from software reuse.Source: §8 · p. 40
  • 2.7% of 723,444 dependency relationships across 9,639 Maven Central artifacts were reported as bloated.The authors identify unwanted transitive dependencies and multi-module dependency heritage as possible causes.Source: §8 · p. 40
  • 14 of 15 answered pull requests to remove bloated direct dependencies were accepted, compared with 4 of 8 for bloated transitive dependencies.The authors report that overall developer feedback made dependency removal worth the additional analysis and effort.Source: §8 · p. 41
  • Future work must address when to analyze bloat, who is responsible, and how to manage complex dependency trees without conflicts.The study calls for continued POM-file engineering and reports developer interest in DepClean.Source: §8 · p. 41

Related papers

Loading 2001.07808v1…