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

3062 软件学报 2025 年第 36 卷第 7 期

余依赖项更新导致持续集成时间浪费, 发现 55.88% 的依赖项更新相关构建时间是无效的, 并提出 Dep-sCImitar 工
具, 通过跳过无效构建减少了 68.34% 的时间浪费. 尽管这些研究也关注于 Java 项目的异味, 但主要侧重于项目的
持续集成和持续交付, 而我们则着眼于项目开发过程中的依赖管理. 总的来说, 目前关于 Java 依赖管理的研究主
要集中在 Maven 上, 而本文则致力于综合分析 Java 项目中两种最常用的构建工具 Maven 和 Gradle, 全面总结了
这两类项目可能存在的依赖管理问题. 通过这种综合分析, 本文对现有研究进行了继承与扩展, 从而更深入地探
究 Java 项目中的依赖管理问题.
在 Java 之外, 其他语言如 Python 和 JavaScript 同样拥有广泛的用户群体和庞大的依赖库规模, 所以其依赖管
理问题也得到了广泛的研究 [13,14,18,21,23−25,66−69] . Cao 等人 [13] 和 Jafari 等人 [14] 分别对 JavaScript 项目和 Python 项目中
可能存在的依赖异味进行了调研, 并发现依赖异味在这两类语言中同样普遍存在. 本文的研究目的与前述工作相
契合, 但由于 Java 是静态类型语言, 其依赖管理机制更为严格. 且相较于 Python 和 JavaScript 的构建工具, Maven
和 Gradle 在语法和配置方式上存在着显著的不同. 因此, 本文特别结合了 Maven 和 Gradle 的特性, 对可能在 Java
项目中出现的依赖异味进行了针对性的适配和扩展. Patra 等人 [18] 提出了 ConflictJS 以分析在客户端 Web 应用中
常用的第三方 JavaScript 库之间的冲突. 文献 [23] 对 PyPI 生态系统中 Python 项目的依赖冲突问题进行调研, 并提
出 WATCHMAN 以持续监控并报告潜在的依赖冲突. 文献 [25] 提出了 LooCo, 其通过自动放宽 Python 项目的库
版本约束来减少依赖冲突导致的构建错误问题. Vázquez 等人 [21] 通过从 JavaScript 应用中删除冗余功能来分析捆
绑在 JavaScript 应用中的第三方软件库, 以提高网页加载速度. Drosos 等人 [66] 对 PyPI 生态系统中的冗余依赖现象
进行了大规模细粒度分析, 发现超过 50% 的依赖存在冗余问题, 且 15% 的漏洞集中在这些冗余代码中. Peng 等人 [67]
提出了 PyConf 工具, 针对 PyPI 生态系统中的配置问题进行源码级检测, 发现 68% 的问题无法通过现有版本级检
查发现, 并且现有的依赖推断工具在处理依赖冲突和依赖库缺失时存在明显不足. Qian 等人 [24] 提出了 Slimium 框
架, 通过静态、动态和启发式分析的混合方法, 对 Chromium 浏览器进行代码去膨胀, 以减少安全攻击面, 实验证
明该框架能够在 40 个流行网站上平均去除 94 个 (61.4%) CVE, 削减 23.85 MB 的代码. 前述工作主要关注于
Python 和 JavaScript 项目中的依赖冲突和冗余依赖问题, 这类问题同样会在 Java 项目中出现, 说明了这些问题的
普遍性因此, 本文也对 Java 项目中可能出现的这类问题进行了讨论.

5.2 开源软件生态
随着开源软件生态的不断发展, 流行的软件库往往关系着一系列下游项目, 任何问题都很容易传播造成广泛
影响 [70] . 因此, 研究软件库在生态系统中的影响至关重要 [71,72] . Ochoa 等人 [73,74] 发现大多数破坏性变更 (breaking
change) 影响的代码并未被任何下游项目使用, 而仅有 7.9% 的下游项目受到破坏性变更的影响. Jayasuriya 等
人 [75,76] 发现传递依赖的更新是引入破坏性变更的主要因素, 并且几乎一半的破坏性变更违反了语义化版本
(semantic versioning), 并发现 2.30% 的变更引发了下游项目的测试失败. Zhang 等人 [77] 则提出了 Sembid 工具以检
测依赖库中不同版本接口语义不一致的问题. Dann 等人 [78] 提出了 UPCY, 其通过对依赖树的图操作帮助开发人员
在更新项目依赖时减少不兼容性问题. Li 等人 [79] 探讨了 Go 语言生态系统第三方库升级中的破坏性变更问题, 并
发现检测工具和数据集的缺乏使得开发者难以识别和应对这些变更的影响. 前述研究聚焦于项目接口的动态更新
过程, 着眼于随着时间推移, 项目如何不断变化以适应新的需求和环境. 相比之下, 本文专注于如何在项目的特定
状态下, 通过消除依赖管理中潜藏问题以确保项目的稳定和安全. Wu 等人 [80] 通过收集大量漏洞实例以分析上游
项目中漏洞对下游项目的潜在威胁. Zhang 等人 [19,81] 针对 Maven 生态系统中上游项目阻塞补丁导致漏洞持久化的
问题进行调研, 并提出工具 RANGER 和 CORAL 以自动将依赖库恢复至安全版本. Mir 等人 [82] 探讨了依赖的传递
性和调用图粒度对 Maven 生态系统中漏洞传播分析精度的影响. Pashchenko 等人 [83] 提出 Vuln4Real 以解决学术
界和工业界在报告开源软件中易受攻击的依赖关系时存在的夸大问题. Zhao 等人 [20] 提出了综合评估模型, 针对
Java 的软件成分分析工具进行了依赖解析能力和漏洞检测效果的全面评估. Fourné等人 [84] 聚焦于软件供应链安
全, 探讨了可重复构建 (reproducible build) 如何为构建工具提供强有力的防御基础. Keshani 等人 [85] 开发了自动化
工具 AROMA, 通过自动查找库的源代码和原始发布环境信息, 以提高 Maven 生态系统的可重复构建性. 类似的,