Do Developers Depend on Deprecated Library Versions? A Mining Study of Log4j
Fuente:
arXiv
Saved in:
| Main Authors: | , , , , , , , |
|---|---|
| Format: | Preprint |
| Published: |
2025
|
| Subjects: | |
| Online Access: | |
| Tags: |
Add Tag
No Tags, Be the first to tag this record!
|
| _version_ | 1866915227870691328 |
|---|---|
| author | Yoshioka, Haruhiko Lertbanjongngam, Sila Inaba, Masayuki Fan, Youmei Nakano, Takashi Shimari, Kazumasa Kula, Raula Gaikovina Matsumoto, Kenichi |
| author_facet | Yoshioka, Haruhiko Lertbanjongngam, Sila Inaba, Masayuki Fan, Youmei Nakano, Takashi Shimari, Kazumasa Kula, Raula Gaikovina Matsumoto, Kenichi |
| contents | 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. |
| format | Preprint |
| id |
arxiv_https___arxiv_org_abs_2504_03167 |
| institution | arXiv |
| publishDate | 2025 |
| record_format | arxiv |
| spellingShingle | Do Developers Depend on Deprecated Library Versions? A Mining Study of Log4j Yoshioka, Haruhiko Lertbanjongngam, Sila Inaba, Masayuki Fan, Youmei Nakano, Takashi Shimari, Kazumasa Kula, Raula Gaikovina Matsumoto, Kenichi Software Engineering 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. |
| title | Do Developers Depend on Deprecated Library Versions? A Mining Study of Log4j |
| topic | Software Engineering |
| url | https://arxiv.org/abs/2504.03167 |