An Empirical Study of Usages, Updates and Risks of Third-Party Libraries in Java Projects
Not on the map. Why?
Abstract (arXiv)
Third-party libraries are a central building block to develop software systems. However, outdated third-party libraries are commonly used, and developers are usually less aware of the potential risks. Therefore, a quantitative and holistic study on usages, updates and risks of third-party libraries can provide practical insights to improve the ecosystem sustainably. In this paper, we conduct such a study in the Java ecosystem. Specifically, we conduct a library usage analysis (e.g., usage intensity and outdatedness) and a library update analysis (e.g., update intensity and delay) using 806 open-source projects. The two analyses aim to quantify usage and update practices holistically from the perspective of both open-source projects and third-party libraries. Then, we conduct a library risk analysis (e.g., potential risk and developer response) in terms of bugs with 15 popularly-used third-party libraries. This analysis aims to quantify the potential risk of using outdated libraries and the developer response to the risk. Our findings from the three analyses provide practical insights to developers and researchers on problems and potential solutions in maintaining third-party libraries (e.g., smart alerting and automated updating of outdated libraries). To demonstrate the usefulness of our findings, we propose a bug-driven alerting system for assisting developers to make confident decisions in updating third-party library versions. We have released our dataset to foster valuable applications and improve the ecosystem.
Key facts. Cited by 11 papers in the map (data through 7 Oct 2026). First posted on arXiv 25 Feb 2020.
Builds on
No reference list yet.
Built on by
Citing papers per year: 2023: 1; 2024: 0; 2025: 5; 2026: 5.
11 papers.
- 2023An Empirical Study of Pre-Trained Model Reuse in the Hugging Face Deep Learning Model Registrycited by 45
- 2025Migrating Code At Scale With LLMs At Googlecited by 14
- 2026Environment-Aware Code Generation: How far are We?cited by 4
- 2025MatchFixAgent: Language-Agnostic Autonomous Repository-Level Code Translation Validation and Repaircited by 3
- 2025How Robust are LLM-Generated Library Imports? An Empirical Study using Stack Overflowcited by 2
- 2026MR-Coupler: Automated Metamorphic Test Generation via Functional Coupling Analysiscited by 1
- 2026From Registry to Repository: How AI Agent Skills Are Written, Adapted, and Maintainedcited by 1
- 2025LibRec: Benchmarking Retrieval-Augmented LLMs for Library Migration Recommendationscited by 0
- 2025Which Is Better For Reducing Outdated and Vulnerable Dependencies: Pinning or Floating?cited by 0
- 2026From Adoption to Deployment: A Qualitative Study on AI Integration in Software Development Practicecited by 0
- 2026Code That Works, Environments That Don't: Measuring Environment Reproducibility in AI-Generated Softwarecited by 0
- 2026Code That Works, Environments That Don't: Measuring Environment Reproducibility in AI-Generated Software30 Sep 2026
- 2026From Adoption to Deployment: A Qualitative Study on AI Integration in Software Development Practice18 Jul 2026
- 2026From Registry to Repository: How AI Agent Skills Are Written, Adapted, and Maintained1 Jul 2026
- 2026MR-Coupler: Automated Metamorphic Test Generation via Functional Coupling Analysis11 Apr 2026
- 2026Environment-Aware Code Generation: How far are We?18 Jan 2026
- 2025Which Is Better For Reducing Outdated and Vulnerable Dependencies: Pinning or Floating?7 Oct 2025
- 2025MatchFixAgent: Language-Agnostic Autonomous Repository-Level Code Translation Validation and Repair19 Sep 2025
- 2025LibRec: Benchmarking Retrieval-Augmented LLMs for Library Migration Recommendations13 Aug 2025
- 2025How Robust are LLM-Generated Library Imports? An Empirical Study using Stack Overflow14 Jul 2025
- 2025Migrating Code At Scale With LLMs At Google13 Apr 2025
- 2023An Empirical Study of Pre-Trained Model Reuse in the Hugging Face Deep Learning Model Registry5 Mar 2023