Page 140 - 《软件学报》2025年第7期

孙伟杰 等: Java 依赖异味的实证研究与统一检测技术 3061

者深入思考了这类问题: “It was a good discussion and I never got a chance to think about it in depth. Thanks.” 在 Issue
#2021 (异味 2.1 和异味 2.2) [55] 中, 开发者感谢我们的帮助, 并提到通过使用构建封装器生成新项目为用户提供了
很大的便利: “Thanks for your help. We generate new projects with the Maven wrapper which is very convenient for
users.” 在 Issue #1655 (异味 2.3) [56] 中, 开发者感谢我们指出问题, 并承认这个问题可能表明他们的构建工具封装器
的过时或错误设置: “Thanks for highlighting the checksum mismatch with our ‘gradle-wrapper.jar’. You’re right—This
discrepancy suggests that our wrapper might be outdated or incorrectly set up.” 在 Issue #2546 (异味 2.4 和异味
2.5) [57] 中, 开发者对依赖管理的改进展示出兴趣, 并希望进一步查看其他可能改进: “I like the improvement for the
dependency version management. I do want to take a closer look into other pom files that might be able to take
advantage of this.” 这些总结展示了开发者对我们检测工具的正面反馈, 并强调了我们的工具在发现和解决问题中
的有效性.

表 20 提交的问题报告

问题报告 (项目名, 报告编号)
apache/seatunnel, #6772▲; apache/tinkerpop, #2546♠; line/armeria, #5581♠; GoogleContainerTools/jib, #4234▲;
Discord4J/Discord4J, #1200★; networknt/light-4j, #2189★; alkacon/opencms-core, #787★; tchiotludo/akhq, #1657★;
SerCeMan/jnr-fuse, #181★; MobilityData/gtfs-validator, #1655★; wiremock/wiremock, #2572★; btraceio/btrace, #668★;
javapathfinder/jpf-core, #432★; networknt/light-4j, #2021★; LibrePDF/OpenPDF, #995♠; apache/flink-cdc, #2753♠;
stleary/JSON-java, #829★; networknt/light-4j, #2001♠; apache/tinkerpop, #2349★; TooTallNate/Java-WebSocket, #1370★;
oracle/opengrok, #4471★; apache/httpcomponents-client, #500★; networknt/light-4j, #1948★;
googleapis/google-cloud-java, #10037♠; MobilityData/gtfs-validator, #1725▲;
★: 依赖异味实例已被确认并修复; ♠: 依赖异味实例被确认但尚未被修复; ▲: 问题报告仍在处理中

基于以上发现, 我们回答研究问题 RQ4 如下: JDepAna 在广泛使用的 Java 项目中达到了 96.1% 的精确率, 我
们据此向开发者报告了 48 例检测出的依赖关系实例, 其中 42 例 (87.5%) 得到了确认, 21 例 (43.8%) 已被快速修
复. 开发者的积极反馈反映了 JDepAna 识别问题的准确性, 也进一步证实了该工具在实际应用中的有效性和实
用性.

5 相关研究工作

5.1 软件依赖管理
软件依赖管理是软件开发过程中至关重要的一个方面, 其挑战和问题随着需求变化以及软件库规模和复杂
性的增加而不断增加 [58−60] . 由于 Java 语言拥有成熟的构建工具和丰富的依赖库, 其依赖管理问题备受关
注 [7−11,18,22,28,29,61−64] . Jezek 等人 [62] 提出了 Maven 在解析传递依赖过程中可能导致的冗余、不一致和重复等问题.
Wang 等人 [8] 系统研究 Maven 项目中的依赖冲突问题, 提出工具 DECCA 以对依赖冲突问题的严重程度进行评估,
[9]
[7]
并提出 RIDDLE 和 SENSOR 以自动生成测试用例触发依赖冲突导致的语义冲突和程序崩溃. Soto-Valero 等
人 [10,11,22] 针对 Maven 项目中冗余的依赖关系进行定性和定量分析并提出 DEPCLEAN 和 DEPTRIM 用以检测和消
除冗余的依赖库. Huang 等人 [17] 针对 Maven 项目中模块之间依赖库版本冲突的问题进行调研, 并提出 LIBHARMO
以自动化解决这类问题. 本文继承并深入探讨了现有研究中提及的相关问题, 更进一步将视野延伸至涉及 Gradle
项目, 以全面地理解 Java 项目的依赖管理. Yang 等人 [63] 针对 Maven 项目中依赖范围设置错误的根因进行调研并
给出依赖范围设置的建议. 其工作针对 Maven 中依赖范围误用开展实证研究, 但并未提供对应的检测方法, 而本
文提出了 JDepAna 以实现对这些问题的自动化检测, 并考虑了 Gradle 项目中更为复杂的依赖范围. Vassallo 等
人 [28] 提出 CD-Linter, 一种语义检查工具, 其能够自动识别持续交付 (continuous delivery) 配置文件中的异味, 并通
过大规模长期研究验证了其有效性和可行性. Zhang 等人 [29] 提出 BuildSonic, 其通过分析 Java 项目的持续集成
(continuous integration) 基础设施中的配置文件检测并修复 15 种持续集成中的异味. Weeraddana 等人 [65] 分析了冗