1、第三方库依赖冲突问题研究综述*李硕1,2,刘杰1,2,3,王帅1,田浩翔1,2,叶丹1,2,31(中国科学院软件研究所,北京100190)2(中国科学院大学,北京100049)3(计算机科学国家重点实验室(中国科学院软件研究所),北京100190)通信作者:刘杰,E-mail:;叶丹,E-mail:摘要:软件开发过程中,开发人员通过大量使用第三方库来实现代码复用.不同第三方库之间存在依赖关系,第三方库间的不兼容会导致第三方库的安装、加载、调用时出现错误,进而导致系统异常,这类问题称之为第三方库依赖冲突问题.依赖冲突的根本原因是加载的第三方库无法覆盖软件引用的必需特性(例如:方法).依赖冲突问题
2、会在第三方库的下载安装,项目编译和运行时中出现,且定位困难.依赖冲突问题的修复要求开发人员对使用的第三方库版本间差别具有准确的理解,并且第三方库之间复杂的依赖关系增加了修复难度.为了能够在软件运行前,发现软件中存在的依赖冲突,并且能够响应和处理运行过程中由依赖冲突引发的系统异常,国内外学者展开了各种针对依赖冲突问题的研究.从依赖冲突问题的 4 个方面,对当前已有研究工作进行了梳理,包括:第三方库的使用实证分析、依赖冲突原因分析、依赖冲突检测方法以及依赖冲突常用修复方式.最后对该领域未来值得关注的研究问题进行了展望.关键词:依赖冲突;第三方库;软件生态系统;依赖管理;函数接口兼容性中图法分类号:
3、TP311中文引用格式:李硕,刘杰,王帅,田浩翔,叶丹.第三方库依赖冲突问题研究综述.软件学报,2023,34(10):46364660.http:/ on Dependency Conflict Problem of Third-party LibrariesLIShuo1,2,LIUJie1,2,3,WANGShuai1,TIANHao-Xiang1,2,YEDan1,2,31(InstituteofSoftware,ChineseAcademyofSciences,Beijing100190,China)2(UniversityofChineseAcademyofSciences,Bei
4、jing100049,China)3(StateKeyLaboratoryofComputerScience(InstituteofSoftware,ChineseAcademyofSciences),Beijing100190,China)Abstract:During software development,developers use third-party libraries extensively to achieve code reuse.Due to the dependenciesamong different third-party libraries,the incomp
5、atibilities among them lead to errors during the installing,loading,or calling of thoselibraries and ultimately result in system anomalies.Such a problem is called a dependency conflict(DC,also referred to as conflictdependency or CD)issue of third-party libraries.The root cause of such issues is th
6、at the third-party libraries loaded fail to cover therequired features(e.g.,methods)cited by the software.DC issues often occur during the download and install,project compiling,andrunningofthird-partylibrariesandaredifficulttolocate.FixingDCissuesrequiresdeveloperstoknowthedifferencesamongtheversio
7、nsofthethird-partylibrariestheyuseaccurately,andthecomplexdependenciesamongthethird-partylibrariesincreasethedifficultyinthiswork.ToidentifytheDCissuesinthesoftwarebeforeitsrunningandtodealwiththesystemanomaliescausedbythoseissuesduring*基金项目:国家重点研发计划(2017YFA0700603);国家自然科学基金(61972386)收稿时间:2021-10-09
8、;修改时间:2021-12-28,2022-01-06,2022-01-16;采用时间:2022-02-18;jos 在线出版时间:2022-05-24CNKI 网络首发时间:2023-04-06软件学报ISSN1000-9825,CODENRUXUEWE-mail:Journal of Software,2023,34(10):46364660doi:10.13328/ki.jos.006666http:/中国科学院软件研究所版权所有.Tel:+86-10-62562563running,researchers around the world have conducted various
9、studies on such issues.This study presents a systematic review of thisresearch topic from four aspects,including the empirical analysis of third-party library usage,the cause analysis of DC issues,and thedetectionmethodsandcommonfixingwaysforsuchissues.Finally,thepotentialresearchopportunitiesinthis
10、fieldarediscussed.Key words:dependencyconflicts;third-partylibraries;softwareecosystem;dependencymanagement;APIcompatibility 1 引言 1.1 研究背景第三方库(又称第三方依赖或软件包)是一种重要的可复用软件资源,在一定条件下,可以独立于其他第三方库进行安装和删除1.软件开发过程中调用第三方库是一种提高开发效率的普遍做法,特别是随着现代信息技术的迅速发展,软件规模不断增加,软件开发对第三方库的依赖也在不断增加.已有研究工作表明一个项目直接依赖于多个不同的库2.此外,由于第
11、三方库之间存在依赖关系,一个项目往往会被隐式的加入更多的依赖关系,导致依赖更多的库25.第三方库的使用大大提升了软件开发效率,但也给软件开发带来了潜在的风险.当加载的第三方库无法覆盖所在项目的必需特性(例如,方法)时,就会发生依赖冲突问题.结合软件工程的开发实践,开发人员可能会采用buildtools 自动完成第三方库的下载安装和项目编译,也可能根据配置文件,手动下载安装第三方库,再执行项目编译.因此,依赖冲突问题会在第三方库下载安装、项目编译和运行过程中出现,比如:克隆了 GitHub 上的某个项目,需要下载第三方库时,由于没有满足引用的第三方库之间的约束条件,导致第三方库下载安装失败;在项
12、目编译时,由于本地环境中,存在与引用的第三方库重名的代码文件,导致无法加载正确的第三方库或使用了第三方库中不存在的相关方法,项目编译报错;在运行阶段,由于加载的第三方库版本与所需版本不一致,提示找不到某些类或方法,抛出异常,程序运行失败.目前对依赖冲突的解决方式多为开发人员借助经验知识去处理,会消耗大量的时间和人工成本.运行过程中的报错信息在多数情况下不足以支撑开发人员找到问题根源,并且由于第三方库之间存在复杂的调用关系,更改某一第三方库同时可能引起其他第三方库的不适用,这些问题增加了定位和解决依赖冲突问题的难度.同时依赖冲突问题会伴随如下特点:难以重现问题出现的场景、编译器提示的问题报告中描
13、述信息不够清晰、第三方库代码缺失、第三方库代码复杂难以调试等.这些问题在开发过程中给开发人员带来了巨大挑战.依赖冲突问题的检测和修复成为当前软件开发中的重要技能.为了避免依赖冲突问题的出现,第三方库的开发人员提出了一种声明机制,即在 metadata 中对库本身依赖的其他第三方库信息进行声明.但是由于 metadata信息需要开发人员手动维护,难以保证其时效性和准确性.Maven68、Pip9等成熟的软件管理工具也提供了依赖关系管理功能,帮助开发人员在开发过程中选择依赖的第三方库版本.但由于多种复杂因素,这些工具不能保证加载的是最契合开发人员需求的版本,并且由于开发人员可能缺乏对依赖的第三方库
14、的了解,导致错误的几率增加.1.2 文献检索方式针对以上分析,研究人员对第三方库的使用情况和依赖冲突问题的产生原因、检测方法、修复方式都开展了大量研究.为了对该问题的已有研究工作和成果进行系统的梳理,我们首先选择了文献搜索的关键词:dependencyconflict、conflictdependency、third-partylibrary、第三方库、依赖冲突、包管理.随后在谷歌学术搜索引擎(GoogleScholar)、ACMDigitalLibrary、IEEEExplore、Springer、Elsevier 以及 CNKI 等搜索引擎和数据库上,通过上述关键词来检索与本文主题相关的论
15、文.对上述检索的文献进行筛选,筛选条件包括:与本文主题的相关性、文献质量.通过文献标题、关键词、摘要等信息,识别并移除与主题无关的文献;在与主题相关的文献中,选择发表会议/期刊属于 CCF 推荐的国际学术会议/期刊的文章.通过 GoogleScholar、ACMDigitalLibrary、IEEEExplore 等学术搜索引擎来查阅论文的被引用情况和相关研究人员已发表论文的清单,进一步补充与本文研究主题相关的文献集.最终确定了与本文主题相关的高质量论文.李硕等:第三方库依赖冲突问题研究综述4637经过筛选后,我们发现尚未有对依赖冲突问题进行全面综述的文献.早在 2006 年 Mancinel
16、li 等人10、2012年 Artho 等人1,介绍的依赖冲突有关问题,是针对 Linux 中的依赖冲突问题.而后学术界和工业界逐渐对依赖冲突问题进行关注.为了使得本文内容更加完整,且更好地反映相关研究的发展脉络,本文中所介绍论文与已有论文可能会存在少部分重叠.最终,本论文选取了 90 篇相关论文进行详细介绍,图 1 展示了搜集论文统计结果.参照CCF 推荐领域划分标准,图 1(a)展示了所选论文主要集中在软件工程/系统软件/程序设计语言领域.图 1(b)展示了所选文章发表会议/期刊的分布情况,其中包括会议论文 71 篇,期刊论文 16 篇;大多数论文是所涉及领域的高质量会议和期刊,例如 IC
17、SE 会议(14 篇)、ESEC/FSE 会议(11 篇)、ASE 会议(5 篇)、CCS 会议(2 篇)、OOPSLA(1 篇)、ECOOP 会议(1 篇)、NDSS 会议(2 篇)、ESE 期刊(4 篇)、TSE 会议(4 篇)、IST 期刊(2 篇)、软件学报(3 篇).(a)选文发表领域分布2520151050200520062007201020112012201320142015201720162019202020182021(b)不同会议或期刊论文发表分布篇数软件工程/系统软件/程序设计语言网络与信息安全人工智能77616其他图1选文统计结果 1.3 研究问题本文在对当前已有研究成
18、果梳理基础上,对依赖冲突问题进行了全面的综述,包括 4 个方面:第三方库的使用情况,依赖冲突原因分析,有关检测方法以及当前开发人员采用的修复方式,并对该领域未来潜在的值得关注的研究方向进行展望.本文主要选择了 GitHub 使用语言排行榜11中的前 3 种使用最为广泛的语言(JavaScript、Java 和 Python)以及多个生态系统中依赖冲突问题作为研究对象进行分析,并尝试回答以下 4 个问题.问题 1:有关第三方库使用情况以及开发情况是怎样的?与依赖冲突问题的关系是怎样的?问题 2:依赖冲突问题发生的原因是什么,可以被划分为哪些模式?问题 3:依赖冲突问题检测方法有哪些,特点是什么?
19、问题 4:目前开发人员修复依赖冲突的方式是什么?本文第 2 节给出整体研究框架.第 3 节对依赖冲突问题的相关实证分析,进行总结分类.第 4 节系统分析依赖冲突问题发生的根本原因.第 5 节对依赖冲突问题的检测方法进行分类阐述,并对工具进行对比.第 6 节总结依赖冲突问题的修复方式.最后对该领域未来潜在值得关注的研究方向进行展望.2 第三方库依赖冲突问题与研究框架 2.1 第三方库依赖冲突问题简介大量引用第三方库极易引发依赖冲突问题.此类问题的出现是由于当同一个库的多个版本存在于相同路径下时,Java、Python、JavaScript 等第三方库的加载机制规定了第三方库在运行时的加载位置12
20、,多数情况下当两个第三方库无法共存时,那么将只有一个第三方库被加载,而与之存在冲突的其他第三方库无法安装或无法加载5,当项目在运行时引用不兼容的、被隐藏掉的第三方时,将引发运行时异常(例如,ClassNotFoundException和 NoSuchMethodError2).此类问题称之为依赖冲突问题(conflictdependency,或是 dependencyconflict).除两个第三方库包含内容直接导致冲突外,也可能因为其依赖的底层第三方库互相冲突.因此,两个看似毫无关联的第三方4638软件学报2023 年第 34 卷第 10 期库也可能因为依赖冲突而无法安装13.第三方库依赖冲
21、突的表现形式是依赖的第三方库和实际使用的第三方库不一致.图 2 为 Keras 框架中出现的依赖冲突问题实例14,当开发人员加载的 TensorFlow 版本为 1.X 时,程序无法正常运行,提示 AttributeError,其原因为加载的类不包含项目需要引用的方法,此实例为典型的依赖冲突问题,此种类型常出现在运行阶段异常2,1518,其他类型的依赖冲突问题也可能出现在第三方库的安装阶段和项目编译过程17,19.伴随着大型系统的普及,第三方库之间的冲突问题更加广泛频繁出现.原因在于大型系统广泛依赖于第三方库,并且大型系统的开发多采用微服务、多模块的开发方式;一个大型系统,分为多个服务,由不同
22、的团队进行开发,开发过程中,协调依赖的第三方库、保证库以及对应的版本的一致性非常困难.Jibesh 等人16进行的实证研究分析发现,1/4 的第三方库存在潜在的冲突,可能导致软件崩溃或其他意外的行为.已有研究工作主要集中在对依赖冲突问题的实证研究、对依赖冲突表现形式的分析、对依赖冲突问题的检测方法的研究以及对依赖冲突问题的解决方法的研究.图2依赖冲突实例常见的依赖冲突问题表现形式多样:安装过程中的表现形式为安装第三方库失败,提示异常信息;运行过程中的表现形式为编译器提示无法找到需要的类或方法;或通过了编译过程,但无法得到正确的运行结果18.依赖冲突问题的原因复杂多样,本文将其概括为 3 种类别
23、,包括:版本冲突、版本误用、名称冲突.版本冲突包含两种类型:同一个第三方库之间的冲突和不同第三方库之间的冲突.同一个第三方库之间的冲突可以划分为直接依赖与传递依赖之间的冲突、传递依赖之间的冲突、所需第三方库与本地安装的第三方库之间的冲突.不同第三方库之间的冲突,可以划分为直接依赖间的冲突、直接依赖与传递依赖之间的冲突、传递依赖之间的冲突.版本误用表现形式为对第三方库版本的误用导致的依赖冲突.名称冲突指项目代码和第三方库之间的命名冲突,此种类型较为少见.目前对依赖冲突问题的检测工具相对较少,主要集中在对第三方库的冲突问题进行预判,提示开发人员可能存在的风险15,19,20,也有部分工作针对存在依
24、赖冲突问题的项目生成测试用例,报告出现问题的原因2,1618.对于依赖冲突问题的修复,目前主要依靠人工修复方式完成.2.2 研究框架本文的整体研究框架如图 3 所示.按照 GitHub 使用语言排行榜11,主要关注排行榜中前 3 名的语言JavaScript、Python、Java.JavaScript 社区、Java 社区和 Python 社区包含了对应语言以及对语言有关问题的讨论.本文提及的 npm、PyPI 代指 npm 生态系统、PyPI 生态系统.npm 生态系统、Maven 生态系统和 Eclipse 社区、PyPI 生态系统为对应语言提供了第三方库的下载以及管理通道.其他较大规模
25、社区,例如 R/CRAN社区,Android社区以及 Linux 社区等,是在本文的研究过程中,发现的相关社区,作为补充内容.JavaScript 和 Python 是动态类型的脚本语言,Java 是静态类型的程序设计语言.3 种语言具有各自的特性,包管理模式间也存在差异,但三者在依赖冲突问题上可以抽取共性.依赖冲突问题发生在第三方库的使用过程中,因此本文首先对第三方库使用的相关研究工作进行了分类汇总;其次对导致依赖冲突的原因进行了分类分析;接着参照依赖冲突的原因对依赖冲突问题的检测方法进行分类,并对比总结检测工具,然后参照开发人员采取的 7 种修复方式进行分类,最后进行总结并指出未来的潜在研
26、究问题.李硕等:第三方库依赖冲突问题研究综述4639语言-社区社区和生态系统视角第三方库使用者视觉分析第三方库开发者视觉分析分析内容第三方库的选择分析第三方库版本的选择分析第三方库使用情况第三方库变更对使用者的影响第三方库升级原因分析第三方库更新风格分析1.版本冲突2.版本误用3.用户端代码和第三方库之间的名称冲突第三方库使用实证分析依赖冲突原因及分析依赖冲突检测方法修复方式打印警告信息针对第三方库版本冲突的检测方法针对第三方库版本误用的检测方法针对第三方库名称冲突的检测方法环境隔离针对版本冲突的修复策略针对版本误用&名称冲突的修复策略对项目代码进行修改对本地代码进行修改以适应库版本修改后的特
27、性修复依赖第三方库版本修改第三方库的加载路径调整依赖项的路径加载顺序调整本地项目直接依赖的版本约束与上游或下游项目协调,调整冲突的版本约束去除冲突的直接依赖,保留传递依赖本地安装第三方库与需要安装的第三方库版本不一致,可以创建隔离环境图3研究框架 3 第三方库使用实证分析针对问题 1,本文对第三方库使用的相关研究工作进行整合,分别从第三方库的使用者视角和第三方库的开发者视角,对依赖冲突问题进行总结分析,主要分为 6 个分析对象,对应的分析内容如表 1 所示.对于第三方库使用者视角分析,本文从第三方库的选择(选择哪个第三方库)、第三方库版本的选择(具体版本的选择)、第三方库使用情况,以及第三方库
28、变更对使用者的影响 4 个方面进行阐述.本文发现,对于第三方库的选择,更倾向于选择被广泛使用的第三方库,并且开发人员对第三方库的依赖性逐渐增强,但对于使用第三方库带来的潜在影响以及风险关注度较低;对于第三方库版本的选择,开发人员对版本的选择具有不同的倾向,集中在对项目性能的影响方面的关注;对于第三方库使用情况分析发现,第三方库 API 使用不均衡;第三方库版本变更带来的影响,由于内容的变更程度不同,其对本地项目的影响范围亦有所不同.第三方库开发者视角下的分析内容主要集中在第三方库升级原因和第三方库更新风格两个部分.第三方库升级原因主要包括实现新需求、提升可维护性、偿还技术债 3 个方面;不同语
29、言、不同生态系统的库开发者对第三方库的更新风格不一致,Java 语言的 Eclipse 生态系统更倾向于保持向后兼容的升级,R/CRAN 社区更倾向于协作交流,而 Node.js/npm 生态系统更倾向于对内容大幅度变更,对兼容性保持较低.4640软件学报2023 年第 34 卷第 10 期表1第三方库使用分析视角分析对象结论有关文献第三方库使用者视角第三方库的选择开发人员对第三方库的依赖性增强,并且倾向于使用成熟度较高、使用更加广泛的第三方库.但开发人员对当前第三方库管理工具提供的语义版本控制使用较少根据不同使用情况选择不同的衡量指标,同一种语言的库的衡量指标也有多个,例如使用GitHub排
30、名、开发社区下载数量排名等开发人员在选择第三方库时,关注点在于库是否提供的特定功能,但对性能、使用库带来的其他潜在风险的关注度较低2132第三方库版本的选择对于不同语言、不同生态系统、不同阶段的开发人员而言,其采用的版本具有不同的倾向.总体而言,开发人员更倾向于选择较为稳定的版本,并且对有关语义版本控制工具的采用较少在使用第三方库时,时常会面临版本更新的权衡问题:是为了保持项目稳定,将第三方库版本进行限定;还是不断迭代更新第三方库的版本,以使用新特性.使用人员更新或者不更新第三方库版本的原因是不尽相同的但由于语言特性、使用场景以及社区规约不同等因素,开发人员对是否更新第三方库的偏好也有所不同.
31、版本升级的周期也有所不同24,26,28,3347第三方库使用情况开发者对第三方库中API的利用率不均衡,即使加载完整的第三方库相较于开发人员手动编写代码实现有关功能,会消耗更多资源,但第三方库的运行效率通常会远高于开发人员手动编写代码由于开发人对API的使用规约了解甚少,开发人员常会使用一些已经被声明为将被弃用的类或方法,并且常会误用API16,33,4852第三方库变更对使用者的影响库版本的变更会对库使用者带来巨大的影响,因为其版本变更常存在不兼容的更改,容易造成依赖冲突问题,需要本地代码进行重构来适配库版本的变更研究表明,第三方库的更改大多数情况下是不兼容的更改,研究人员有意避免版本变更
32、带来的影响,但由于测试不充分等原因,仍可能造成依赖冲突问题.开发人员会检查库的变更对代码的影响,必要时候进行代码的重构来适配库的变更研究人员从不同角度分别提出了识别第三方库中API发生变化的有关方法、对被声明为弃用的API寻找替代方案、检测API的修改是否影响了开发人员的调用26,46,48,5365第三方库开发者视角升级原因对于不同语言、不同生态系统,第三方库的升级是常见的,库的升级原因基本一致,主要包括:实现新需求,提升可维护性,偿还技术债28,6668更新风格不同语言、不同生态系统的第三方库开发者对库的修改风格是不同的,但大多数都会考虑到代码兼容性问题,防止依赖冲突问题的出现46,48,
33、6975对第三方库使用的相关研究工作分析整理后发现,API 兼容性问题是导致依赖冲突的重要原因之一;第三方库的升级往往是对其中的 API 进行了修改,这种修改是导致版本不兼容的重要原因.因此,对第三方库升级和API 兼容性进行分析,是依赖冲突问题分析中,不可或缺的一部分.例如,Artho 等人1指出第三方库的升级会导致库之间的依赖冲突问题,Wang 等人18揭示了在第三方库依赖冲突问题中,存在用户期望使用的第三方库与实际加载的不一致,这种不一致是由于加载的版本不符合用户的需求.第三方库版本的升级需要向前兼容,升级版本没有做好兼容性处理,可能会导致依赖冲突问题的出现.由此可见,依赖冲突问题与 A
34、PI 兼容性问题、第三方库升级存在不可忽视的相关性,因此本文对第三方库升级、API 兼容性问题等与依赖冲突有关的内容进行了分析.3.1 第三方库使用者视角分析本节从第三方库的使用者角度对第三方库的使用情况,包括第三方库的选择、第三方库版本的选择、第三方库内容的使用情况、第三方库变更带来的影响这 4 个方面进行阐述.3.1.1第三方库的选择分析对于第三方库使用者而言,第三方库的使用已经成为开发过程中不可或缺的一部分,开发人员更倾向于使用第三方库,并且对第三方库的依赖性不断增强.不论是何种语言、何种生态系统,每个项目都会使用大量的第三方库22,项目之间的依赖性在演进过程中不断增加23,24,项目依
35、赖的包数量一般遵循指数级增长趋势2527.并且对于经验较少的开发人员倾向使用“trival”的包22,这类包的特点是实现较为简单的任务;经验丰富的开发人员相反,更倾向于使用成熟度高、使用较为广泛的第三方库.但总体而言,不论是经验丰富还是经验较少的开发人员,很大李硕等:第三方库依赖冲突问题研究综述4641程度上依赖于一组使用较为广泛的库.在使用过程中如何选择具体的第三方库,对于不同语言的社区,衡量指标具有差异.开发人员往往根据不同使用情况选择不同的衡量指标,同一种语言的库的衡量指标也有多个.例如,Wittern 等人28发现 npm 生态系统中,对第三方库的使用情况有 3 种不同的衡量指标:第三
36、方库排名(类比 PageRank 排名)、下载数量排名、GitHub 排名.不同的衡量标准不能相互替代,它们可以用来描述特定类型包的流行程度.排名机制的不同,直接影响对第三方库推荐工具的设计.并且,对每一种排名来说,新的第三方库并不能直接进入排名前列,但有一些第三方库随着时间推移仍保留在排名靠前的位置.开发人员在第三方库的选择过程中,主要关注于是否实现了需要的功能,但对性能、使用库带来的潜在风险关注度较低.Wang 等人21发现超过一半的项目使用了包含安全缺陷的第三方库,并且 2/3 的第三方库包含安全漏洞.这些安全漏洞的普遍存在表明,如果开发人员不知道已使用库中的安全问题,则项目可能面临潜在
37、风险.Zimmermann 等人27通过分析第三方库之间的依赖关系和已被发现的安全问题来研究 npm 生态系统中的安全风险,研究发现第三方库的可用性使开发人员依赖于越来越多的第三方库,多个第三方库间的关联性增加,使得单个库能够影响其他库的安全性,从而增加了第三方库存在漏洞的可能性,使项目受到攻击的风险大大增加.BlackDuck76软件中的 Codecenter 部分,提示开源代码中是否存在安全漏洞问题.现实世界中已经发生了多起由第三方库漏洞引发的严重事故,如:OpenSSL 中出现的心脏滴血漏洞(heartbleed)、GNUBash 出现的破壳漏洞(shellshock)和 Java 中的
38、反序列化漏洞(deserialization).Veracode77、SAP65以及 OWASP78,79通知开发人员使用的库版本中的安全错误.Pfretzschner等人80将分析工具集成到 OpenWhisk(一个开源的无服务器云平台),为开发人员提示使用了用于恶意行为的依赖库.VAS81建立在 OWASP78之上,从开发人员的依赖配置文件中抽取直接依赖的第三方库,与有漏洞的第三方库的名称进行匹配.当名称匹配成功时,认为项目是有漏洞的.现有对 Java30和 Android应用31,32的漏洞分析主要关注的就是第三方库带来的安全风险,并且发现了第三方库代码中存在潜在的安全威胁.Linare
39、s-Vsquez 等人29研究发现,与不成熟的应用程序使用的 API 相比,较为成熟的应用程序所使用的 API明显更不容易出错.3.1.2第三方库版本的选择分析开发人员对于第三方库的选择具有不同的倾向,在开发过程中,开发人员会根据实际需求,对第三方库的版本选择进行考量;此外,使用不同语言的开发人员,对第三方库版本更新的偏好亦有所不同.本节对开发人员选择和更新第三方库版本的偏好进行分析.不同语言、不同生态系统、不同阶段的开发人员,选择的第三方库版本具有不同的倾向.总体上看,开发人员更倾向于选择较为稳定的版本,但对有关语义版本控制工具的采用较少.Blincoe 等人24对数百万种依赖关系进行了深入
40、研究.他们发现有经验的开发人员倾向于放弃灵活的版本控制,实际上大多数库管理工具都鼓励第三方库遵循语义版本控制,但开发人员很少使用现有库管理工具中的语义版本控制21,因为他们经历过与兼容性相关的错误,更喜欢使用稳定的版本,而且他们重视稳定的(可重现的)项目构建,因此大多数项目声明了它们所引用的第三方库的固定版本.不同语言的开发人员对版本的管理有所不同,通常 JavaScript 语言的开发人员不会对版本进行强制约束,并且多达一半的开发人员偏向自动依赖于最新版本28;而 Java 语言的开发人员考虑到稳定性、健壮性和安全性,更倾向于选择以前的稳定版本,而不是最新的版本33;此外,Python 语言
41、开发者也倾向于使用较为稳定的版本.实际上,多达一半的开发人员在开发过程中会自动依赖于最新版本,并且随着时间的增长,开发人员倾向于使用更新的第三方库.Zhang 等人34发现库的版本变更中,API 的修改升级可能是深度学习程序中各种bug 的根源.Wu 等人35提出了一种识别框架演化规则的方法.即使第三方库的维护人员采用了各种编号约定库版本,但版本号本身并不能代表库成熟度.然而在实际使用中,开发人员会倾向于认为版本号较高的库性能更加稳定.开发人员在使用第三方库时,时常会面临版本更新的权衡问题:是为了保持项目稳定,将第三方库版本进行限定;还是不断迭代更新第三方库的版本,以使用新特性.使用人员更新或
42、者不更新第三方库版本的原因是不尽相同的.开发人员选择不更新第三方库版本的原因,包括:更新第三方库可能会引入兼容性问题,开发人员需要对项目进行大量修改;可能带来未知的 bug 或安全问题36,37;可能造成上下游项目的依赖冲突问题37,40;更新第三方库所4642软件学报2023 年第 34 卷第 10 期需要的传递依赖的版本,可能不符合项目约束,导致无法更新41,或者更新后的版本与当前版本差距较小,对项目没有任何影响,徒增更新成本和风险38,39,4244.开发人员选择更新第三方库版本的原因,包括:更新库的版本可以使用库的新特性36,43;修复旧版本第三方库存在的 bug 或安全漏洞41;进行
43、预防性维修任务39;由于开源社区(生态系统)的政策规约,开发人员需要定期对使用的第三方库进行更新37;由于使用版本控制工具,自动升级相库45.除了一些常见的共性原因外,不同社区(生态系统)的开发人员由于语言特性、使用场景以及社区规约不同,对是否更新第三方库的偏好也有所不同.npm 社区(生态系统)中,Decan 等人37研究发现,社区政策会影响开发人员对第三方库的更新.npm,Python,CRAN 和 RubyGems 这 4 个生态系统中,当采用了版本控制工具时,第三方库版本的更新频率会增加35,42,45.对于 3 个主流语言社区进行调研发现53,开发人员执行升级是因为考虑到机会成本,例
44、如维护过时代码的成本、围绕已知 bug 进行修改的成本、推迟新特性的成本;并且项目中某一依赖版本的升级,可能会影响其他依赖版本的升级,否则会引发一系列的连锁反应.Maven 社区中,Kula 等人41以及 Cox 等人39研究发现对于安全性相关问题关注度较低,因此没有更新第三方库.Android 社区中,Salza 等人43研究发现,库的更新与库的用途息息相关,例如开发人员对于 APP 的 GUI 等外观相关的特性较为关注,为了迎合大众审美需求,对第三方库相关版本更新较快;同时 Derr 等人82研究发现由于开发人员的粗心大意,或进行版本升级的代价相对较高,或无法衡量升级后的版本是否存在兼容性
45、问题,开发人员决定不更新第三方库版本.Bavota 等人26进行的定量和定性分析发现,当项目升级依赖的第三方库版本发生更新时,他们不会对所有库执行升级,平均会升级 60%的新可用版本.项目的大小与项目升级频率之间没有显著的相关性.Hora 等人40研究了 Pharo 生态系统(拥有大约 3600 个不同的系统)的库修改升级问题,发现开发人员通常不能快速对这些升级做出反应(平均反应时间为 34 天),往往需要较多的时间应对版本的更新.对于不同的生态系统而言,其更新周期也有所不同.McDonnell等人47研究了 Android 框架中 API 的稳定性和演变引发的问题,发现平均每月有 115 个
46、 API 更新,应用中有 28%的 API 使用应该被更新,但由于多种原因没有进行更新,滞后中值为 16 个月.3.1.3第三方库使用情况开发者对第三方库中 API 的利用率不均衡.研究表明复用第三方库的主要目的是使用第三方库中的 API,因此第三方库 API 的使用是软件开发中不可分割的一部分.开发项目中存在大量 API 的使用,平均 3 行代码就会引用一些 API49.相对于开发框架这种特殊类型的第三方库,Wu 等人48发现对于一些常用的框架,其 API 的平均使用率在 35%.即使第三方库中功能使用率较低,在多数情况下,使用第三方库的 API,运行效率会远高于开发人员手动编写代码50.Q
47、iu 等人33对 Java 中的 API 使用情况进行调查研究,发现在使用第三方库的过程中,一些核心库的 API 利用率不高,而对核心库的使用需要加载其全部 API,增加了程序运行过程的资源浪费.由于开发人对 API 的使用规约51了解甚少,开发人员通常会使用一些已经被声明为将被弃用的类或方法,并且常会误用API.API 误用导致的依赖冲突问题存在多种情况:例如多余的 API 调用、遗漏的 API 调用、错误的API 调用参数、缺少前置条件判断、忽略异常处理等83.Patra 等人16发现 1/4 的第三方库存在潜在的冲突,超过17%的第三方库出现过至少一次依赖冲突问题,这些冲突会导致系统崩溃
48、和其他意外事件.Cai 等人52研究了 62894个 Android 应用程序的依赖冲突问题,分析了这些问题的表现形式和原因,研究表明在 Android 应用程序中,依赖冲突问题在安装时和运行时均可能发生:安装时冲突问题主要由于 SDK 版本问题,运行时的冲突问题主要与底层 API 相关.3.1.4第三方库变更对使用者的影响第三方库版本的变更会给库的使用者带来巨大影响,很容易造成依赖冲突问题,开发人员需要对项目代码进行重构来适配库版本的变更.Kula 等人53实现了一个可视化工具,利用从 Maven 存储库中提取的依赖项统计数据来调查库更新的历史.即使库中内容的变更不是破坏性更改,开发项目也会
49、受到影响;依据变更程度,其影响范围亦有所不同.其中最突出的影响表现为,当项目代码引用第三方库中的某一类的类型或方法发生变化时23,26,本地代码需要进行重构.版本变更的情况之一是版本升级,第三方库的版本升级中,类和方法的变更比其他变更发生得更为频繁,因此对项目代码的影响更大.Wu 等人48分析了 Apache 和 Eclipse 生态系统第三方库升级中 API 的变更情况,同样发现与其他更改类型相比,第三方库缺少类和方法的情况更加常见,对项目代码的影响也更大.李硕等:第三方库依赖冲突问题研究综述4643为了探究第三方库版本是否发生变更,研究人员从不同角度分别提出了:识别第三方库中 API 发生
50、变化的有关方法、对被声明为弃用的 API 寻找替代方案、检测 API 的修改是否影响了开发人员的调用.Meng 等人54提出一种基于历史的匹配方法,来识别和理解 Java 框架的 API 演变.Xing 等人55认识到框架中 API 的变化,并提出了弃用 API 的合理替代方案.Jezek 等人56对 109 个 Java 开源程序和 564 个程序版本研究发现,API 是不稳定的,因为不兼容的库更改是常见的.Raemaekers 等人84对 MavenCentral 中的第三方库进行研究发现,接近 1/3 的库都发生了不兼容的更改.Wu 等人48以及 Bogart 等人46在研究中发现当使用
