纵向分析臃肿的Java依赖

纵向分析臃肿的Java依赖

原文标题:A longitudinal analysis of bloated java dependencies
原文作者:César Soto-Valero, Thomas Durieux, Benoit Baudry
原文链接:https://arxiv.org/pdf/2105.14226.pdf
发表期刊:ESEC/FSE'21
笔记作者:NING@SecQuan
笔记小编:ourren@SecQuan

1 研究介绍

软件开发不可避免的会引入或写入一些不必要、未使用的代码,这就是软件臃肿(bloated software)。这个现象已经出现许久,关于如何解决这个问题的研究也提出了很多,代表性的包括 JRed、 Slimium、RAZOR、Cimplifier、Trimmer等。而这些工作大多都是在不同细粒度上完成了去臃肿工作,而并没有从纵向(这里我理解的就是时间维度)的角度对软件膨胀问题进行分析。该方向的研究能够帮助我们看到整个 JAVA/Maven 生态中臃肿的依赖关系,同时能够看到整个生态的发展情况,并提示开发人员意识到去臃肿的重要性。

2 背景知识

纵向分析臃肿的Java依赖
图 1 背景知识

Maven dependency:Maven 依赖,简单来说就是定义项目 A 和项目 B 的一种关系,例如 A 引入 B,就会在 A 中的 pom.xml 文件写入一个定位符 <groupId, artifactId, version>,如图 1 中 Figure 1所示。

Direct dependency:直接依赖,就是项目主 pom 文件中引入的依赖。

Transitive dependency:间接依赖,指的是直接依赖项目中引入的依赖。

Dependency tree:依赖树,项目依赖构建的一种树状结构,如图 1 中 Figure 2 所示。

Bloated dependency:臃肿依赖,存在与依赖树中,但是未被代码所使用的依赖,如图 1 中 Figure 3 所示。

Dependency usage status:依赖使用状态,在项目生命周期中依赖是否被使用的状态。

3 研究问题及结果

纵向分析臃肿的Java依赖
图 3-1 研究框架

实验流程如图 3-1 所示,主要通过 collect、filter、analyze 三阶段完成纵向调研的流程。作者提出了 4 个问题来帮助引导调研方向。数据集主要包含筛选后的 435 个开源项目。

  • RQ1:随着项目 Release 版本的迭代,其中臃肿依赖数目如何变化?
纵向分析臃肿的Java依赖
图 3-2 Result-1

作者从 2011 年 1 月到 2020 年 11 月,每个项目中的臃肿依赖变化如图,发现直接依赖的臃肿比较平稳,而间接依赖中的臃肿不断增加。

  • RQ2:项目中每个依赖随时间变化,依赖使用状态会发生哪些变化?
纵向分析臃肿的Java依赖
图 3-3 Result-2.1
纵向分析臃肿的Java依赖
图 3-4 Result-2.2

如图 3-3 所示,针对一个依赖的可能情况作者发现了 5 种可能情况。于是对其依赖的总体变化情况做了调查,结果如图 3-4 所示。

  • RQ3:开发者会维护那些臃肿的依赖吗?
纵向分析臃肿的Java依赖
图 3-5 Result-3

作者对比了开发人员和 Dependabot 在处理依赖更新上的情况。表明软件膨胀人为地增加了维护工作,并且依赖机器人需要改进以检测膨胀的依赖关系。

  • RQ4:那些开发行为会改变依赖的使用状态呢?
纵向分析臃肿的Java依赖
图 3-6 Result-4

作者发现大部分的臃肿还是源于新依赖的引入和代码的修改。

4 个人思考

  • 当下既然存在 DepClean 这种工具,为什么还是存在许多冗余的依赖项呢?并且这方面的研究还是蛮多的,代码仓库应该推动冗余依赖的管理问题。

  • 针对项目安全问题,可以使用该类工具帮助缩减项目大小,从而减小资源的使用。

  • DecClean 工作原理主要基于静态检测,肯定有不足,检测不到的依赖问题。这可能会误报臃肿依赖的数目,作者也提到了这一点,但是作者认为这个对该项工作影响不大,但是感觉还是需要考虑一下。

  • 未来臃肿处理工作可以使用动态分析,从而减少误报。

安全学术圈招募队友-ing 
有兴趣加入学术圈的请联系 secdr#qq.com

原文始发于微信公众号(安全学术圈):纵向分析臃肿的Java依赖

版权声明:admin 发表于 2022年11月12日 上午8:00。
转载请注明:纵向分析臃肿的Java依赖 | CTF导航

相关文章

暂无评论

暂无评论...