Logo
ScienceStack
Table of Contents
Fetching ...
Sign In

Do Developers Depend on Deprecated Library Versions? A Mining Study of Log4j

Haruhiko Yoshioka, Sila Lertbanjongngam, Masayuki Inaba, Youmei Fan, Takashi Nakano, Kazumasa Shimari, Raula Gaikovina Kula, Kenichi Matsumoto

TL;DR

This study investigates whether deprecated Log4j v1.x continues to be used in open-source projects after its end-of-life, using the Mining Software Repositories 2025 dataset and the Goblin framework. It analyzes 10,000 logs per version, identifying 693 v1 and 401 v2 projects from 2005–2023, and computes migration and adoption patterns through RQ1–RQ3. Key findings show substantial post-EOL persistence of v1 (33.81%), limited migration to v2 (7.21% overall; 88% of migrations after 2015), and a sizable share of newcomers adopting the deprecated version. The results highlight ongoing dependency-management challenges and security risks, suggesting qualitative follow-up to understand decision factors and to improve migration guidance for practitioners.

Abstract

Log4j has become a widely adopted logging library for Java programs due to its long history and high reliability. Its widespread use is notable not only because of its maturity but also due to the complexity and depth of its features, which have made it an essential tool for many developers. However, Log4j 1.x, which reached its end of support (deprecated), poses significant security risks and has numerous deprecated features that can be exploited by attackers. Despite this, some clients may still rely on this library. We aim to understand whether clients are still using Log4j 1.x despite its official support ending. We utilized the Mining Software Repositories 2025 challenge dataset, which provides a large and representative sample of open-source software projects. We analyzed over 10,000 log entries from the Mining Software Repositories 2025 challenge dataset using the Goblin framework to identify trends in usage rates for both Log4j 1.x and Log4j-core 2.x. Specifically, our study addressed two key issues: (1) We examined the usage rates and trends for these two libraries, highlighting any notable differences or patterns in their adoption. (2) We demonstrate that projects initiated after a deprecated library has reached the end of its support lifecycle can still maintain significant popularity. These findings highlight how deprecated are still popular, with the next step being to understand the reasoning behind these adoptions.

Do Developers Depend on Deprecated Library Versions? A Mining Study of Log4j

TL;DR

This study investigates whether deprecated Log4j v1.x continues to be used in open-source projects after its end-of-life, using the Mining Software Repositories 2025 dataset and the Goblin framework. It analyzes 10,000 logs per version, identifying 693 v1 and 401 v2 projects from 2005–2023, and computes migration and adoption patterns through RQ1–RQ3. Key findings show substantial post-EOL persistence of v1 (33.81%), limited migration to v2 (7.21% overall; 88% of migrations after 2015), and a sizable share of newcomers adopting the deprecated version. The results highlight ongoing dependency-management challenges and security risks, suggesting qualitative follow-up to understand decision factors and to improve migration guidance for practitioners.

Abstract

Log4j has become a widely adopted logging library for Java programs due to its long history and high reliability. Its widespread use is notable not only because of its maturity but also due to the complexity and depth of its features, which have made it an essential tool for many developers. However, Log4j 1.x, which reached its end of support (deprecated), poses significant security risks and has numerous deprecated features that can be exploited by attackers. Despite this, some clients may still rely on this library. We aim to understand whether clients are still using Log4j 1.x despite its official support ending. We utilized the Mining Software Repositories 2025 challenge dataset, which provides a large and representative sample of open-source software projects. We analyzed over 10,000 log entries from the Mining Software Repositories 2025 challenge dataset using the Goblin framework to identify trends in usage rates for both Log4j 1.x and Log4j-core 2.x. Specifically, our study addressed two key issues: (1) We examined the usage rates and trends for these two libraries, highlighting any notable differences or patterns in their adoption. (2) We demonstrate that projects initiated after a deprecated library has reached the end of its support lifecycle can still maintain significant popularity. These findings highlight how deprecated are still popular, with the next step being to understand the reasoning behind these adoptions.

Paper Structure

This paper contains 11 sections, 6 figures.

Table of Contents

  1. Introduction
  2. Study Design
  3. Data Preparation
  4. RQ1: To what extent is a deprecated Log4j version still being used in software projects?
  5. RQ2: Do newcomer projects tend to adopt the newer version or the deprecated version?
  6. RQ3: Are software projects with more releases more likely to adopt the new version over the deprecated version?
  7. Results
  8. RQ1: To what extent is a deprecated Log4j version still being used in software projects?
  9. RQ2: Do newcomer projects tend to adopt the newer version or the deprecated version?
  10. RQ3: Are software projects with more releases more likely to adopt the new version over the deprecated version?
  11. Discussion and Future Work

Figures (6)

  • Figure 1: Overview of the data collection and preparation for the study.
  • Figure 2: Usage trend of Log4j artifacts over the years, including unreleased projects.
  • Figure 3: Usage trend of Log4j artifacts over the years, filtered to include only released projects.
  • Figure 4: Proportion of newcomers and continuing users of Log4j v1 in latest released projects by year
  • Figure 5: Scatter plot of project releases frequencies with a heatmap.
  • ...and 1 more figures