Interactive, Effort-Aware Library Version Harmonization

💡 Research Summary

The paper addresses the pervasive problem of library version inconsistencies in multi‑module Java projects that use Maven. Because each module can declare its own dependencies and Maven allows both explicit version numbers and property‑based version inheritance, it is common for different modules to depend on different versions of the same third‑party library. Such inconsistencies increase maintenance effort and can cause runtime conflicts, especially when modules depend on each other. Existing tools such as Maven’s Enforcer plugin only detect convergence problems in the transitive dependency graph and provide no assistance for harmonizing directly declared versions across modules.

To understand developers’ needs, the authors conducted an online survey of 131 Java developers who had contributed to popular Maven projects (more than 200 stars on GitHub). The survey revealed that 90.8 % had encountered version inconsistencies and 69.4 % considered them a maintenance problem. The main root causes were lack of awareness of the same library being used in other modules (≈67 %) and backward‑incompatibility between library versions (≈66 %). Detection was mostly manual (POM inspection) or triggered by bugs caused by conflicting versions. Fixing was often avoided because of heavy effort required to resolve API incompatibilities and the intensity of library API usage. When developers did fix inconsistencies, they tended to select the newest version that required the fewest API changes, and they spent hours to days on the task, with locating inconsistencies, choosing a harmonized version, and refactoring source code being the most time‑consuming steps.

Guided by these insights, the authors propose LibHarmo, the first interactive, effort‑aware technique for library version harmonization in Maven projects. LibHarmo operates in three phases:

1. Inconsistency Detection – It builds a POM inheritance graph (a directed acyclic graph of parent‑child relationships), resolves both direct dependencies and those managed via dependencyManagement, and identifies “true” inconsistencies (different versions declared) as well as “false” consistencies (same version declared via different properties).
2. Harmonized Version Suggestion – For each inconsistency, LibHarmo performs static analysis of the project’s source code to collect all calls to the library’s APIs. It then queries a library database (containing JAR files and documentation) to compare candidate versions. The version that minimizes the number of deleted or changed API calls is proposed as the harmonized version. Developers interact with the tool to confirm the target modules and the selected version.
3. Refactoring and API Recommendation – Once a version is accepted, LibHarmo automatically updates the relevant POM files. It also suggests replacements for any deleted APIs based on the library’s documentation, helping developers to adjust source code with minimal manual effort.

The prototype was evaluated on 443 highly‑starred Java Maven projects from GitHub. LibHarmo detected 621 version inconsistencies, affecting 152 projects (34.3 %). On average, the harmonized version required the deletion of 1 API and modification of 2 APIs, impacting 1 % of deleted‑API calls and 12 % of changed‑API calls across the projects. The authors manually verified five inconsistencies with the original developers; one had already been harmonized, confirming the practical relevance of the findings.

Key contributions of the paper include:

• The first large‑scale survey of Java developers on library version inconsistency practices and tool expectations.
• The design of an interactive, effort‑aware harmonization technique that combines dependency graph analysis, API‑level impact estimation, and developer interaction.
• An empirical evaluation demonstrating that a substantial fraction of popular Maven projects suffer from version inconsistencies and that LibHarmo can pinpoint them with concrete effort metrics.

The study highlights the limitation of current Maven tooling, which does not address direct, cross‑module version mismatches, and shows that providing developers with quantitative effort estimates and API‑level guidance can make harmonization feasible. Future work includes integrating LibHarmo into continuous‑integration pipelines, extending the API impact analysis to cover behavioral changes, and adapting the approach to other build systems (e.g., Gradle) and programming languages.