CN108984416A - 一种评估Maven环境中依赖冲突危险级别的方法 - Google Patents
一种评估Maven环境中依赖冲突危险级别的方法 Download PDFInfo
- Publication number
- CN108984416A CN108984416A CN201810891476.7A CN201810891476A CN108984416A CN 108984416 A CN108984416 A CN 108984416A CN 201810891476 A CN201810891476 A CN 201810891476A CN 108984416 A CN108984416 A CN 108984416A
- Authority
- CN
- China
- Prior art keywords
- conflict
- class
- dependence
- assessment
- danger level
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3604—Software analysis for verifying properties of programs
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Stored Programmes (AREA)
Abstract
本发明提出一种评估Maven环境中依赖冲突危险级别的方法,流程包括:步骤1:获取到当前项目中使用的所有第三方依赖,包括直接依赖和间接依赖;步骤2:对当前项目所有直接依赖和间接依赖进行遍历,识别当前项目中出现的所有依赖冲突;步骤3:针对当前项目中的每个依赖冲突进行NoClass危险级别的评估:步骤4:针对项目中的每个依赖冲突进行NoMethod危险级别的评估:步骤5:对评估结果进行封装,向开发者展现评估结果。本发明不仅可以检测到项目中存在的依赖冲突,而且对依赖冲突的危险等级进行了有效的评估,帮助开发者更清晰地了解项目中存在的依赖冲突的危险性,优先处理高等级的依赖冲突,可以在有限的时间内最大程度的降低软件在运行时的出现xx‑not‑found‑bug的风险。
Description
技术领域
本发明涉及软件可靠性领域,特别涉及一种评估Maven环境中依赖冲突危险级别的方法。
背景技术
在软件开发的过程中,经常会使用第三方开源项目进行软件复用来减少开发成本。Apache组织开发维护的Maven是用java编写的开源项目的管理工具。使用maven进行项目开发可以通过xml形式的pom文件导入及管理项目的依赖。但是在Maven的构建环境中,由于同一个开源项目存在多个版本、maven的依赖管理又存在依赖传递机制,经常会导致项目中出现依赖冲突现象,产生软件缺陷。在软件测试不充分的情况下,这种软件缺陷可能会在软件运行的时候产生开发者意想不到的xx-not-found-bug,主要表现形式包括:java.lang.NoClassDefFoundError、java.lang.ClassNotFoundException、java.lang.NoSuchMetho dError和java.lang.NoSuchMethodException。Maven本身虽然可以检测依赖冲突,但缺乏有效的机制对依赖冲突进行评估。
Java虚拟机中定义的Class格式文件是编译java类文件后产生的字节码,每一个Class文件都对应着唯一一个类或接口的定义信息,java类文件中的属性、方法,以及类中的常量信息,都会被存储在.class文件中。相对于易于程序员读写java文件,class文件的格式被更加严格的定义,更易于被程序分析。目前有asm、Javassist等流行的工具可以在class形式的字节码文件进行操作,进行java类的产生、分析、修改。借助于soot等java优化框架可以分析java程序的内部结构,既能从单个java文件的角度分析每一条java语句,也可以从整个程序的角度分析每个java类,java方法之间的关系。
针对于Maven环境中依赖冲突导致的not-found-bug问题,maven并未提供理想的解决方案。检测项目中的依赖冲突现象只能初步帮助开发者避免此类问题。结合程序内部的类和方法的关系对依赖冲突导致xx-not-found-bug的危险性进行评估比简单的侦测可以更进一步地帮助软件开发者避免程序运行时崩溃。
发明内容
针对于项目中出现的依赖冲突,本发明通过静态分析得到程序运行可能需要加载执行的类和方法,并基于加载执行的可能性对maven环境中的依赖冲突导致的NoClass和NoMethod两种危险分别进行评估分级:使用类之间的引用关系评估NoClass危险级别,使用方法之间的调用关系评估NoMethod危险级别。
一种评估Maven环境中依赖冲突危险级别的方法,包括流程如下,其中步骤3与步骤4不分先后顺序:
步骤1:获取到当前项目中使用的所有第三方依赖,包括直接依赖和间接依赖;
步骤2:对当前项目所有直接依赖和间接依赖进行遍历,识别当前项目中出现的所有依赖冲突;
步骤3:针对当前项目中的每个依赖冲突进行NoClass危险级别的评估,包括步骤3.1~步骤3.6:
步骤3.1:识别出依赖冲突中用于编译当前项目的一个依赖UsedJar,其余没有用于编译当前项目的多个依赖NotUsedJar构成集合NotUsedJarSet,UsedJar中的类构成集合UsedJarClassSet,NotUsedJar内部的类构成集合NotUsedJarClassSet,如果有某个类存在于NotUsedJarClassSet却不存在于UsedJarClassSet,则将该冲突NoClass的危险级别设置为1;
步骤3.2:解析当前项目中所有被使用的jar包,得到当前项目和其第三方依赖中的类集合UsedClassSet;
步骤3.3:遍历当前NoClass危险级别为1的依赖冲突,如果有某个类Class存在于NotUsedJarClassSet却不存在于UsedClassSet,则将该类添加到该依赖冲突的ThrownClassSet中,并将该冲突NoClass的危险级别设置为2;
步骤3.4:根据类之间的ClassRef关系,建立类关系的有向图ClassGraph,有向图中的节点为类,边的起点和终点为引用类和被引用的类,边的权值全部为1;
步骤3.5:解析当前项目,获取当前项目的宿主类集合HostClassSet;
步骤3.6:遍历当前NoClass危险级别为2的依赖冲突:基于ClassGraph,每次以依赖冲突的ThrownClassSet中的一个类为起点,使用Dijkstra算法计算ThrownClass到图中其他节点的最短路径距离,如果依赖冲突的ThrownClassSet中的某个类与HostClassSet中的某个类的最短距离小于无穷大,则将该冲突NoClass的危险级别设置为3;
所述最短路径距离计算方法流程包括步骤3.6.1~步骤3.6.5:
步骤3.6.1:初始时,从ThrownClassSet中选出一个未被计算的类V0,S={V0},T=V-S={项目中的其他类},T中顶点对应的距离值:若存在<V0,Vi>的有向的类引用,d(V0,Vi)为1,若不存在<V0,Vi>的有向的类引用,d(V0,Vi)为∞。
步骤3.6.2:从T中选取一个与S中节点有关联边且权值最小的顶点W,加入到S中。
步骤3.6.3:对其余T中节点的距离值进行修改:若加进W作中间节点,从V0到Vi的距离值缩短,则修改此距离值。
步骤3.6.4:重复上述步骤3.6.2和3.6.3,直到S中包含所有顶点,即W=Vi为止。
步骤3.6.5:重复上述步骤3.6.1~3.6.4,直到ThrownClassSet中的所有类到图中其他节点的最短距离都计算完毕。
步骤4:针对项目中的每个依赖冲突进行NoMethod危险级别的评估,包括步骤4.1~步骤4.3:
步骤4.1:遍历每个依赖冲突,识别出冲突中用于编译当前项目的一个依赖UsedJar,其余没有用于编译当前项目的多个依赖NotUsedJar构成集合NotUsedJarSet,分析UsedJar得到jar包中的类UsedJarClassSet,以及每个类包含的方法Method,再分析每个NotUsedJar得到jar包中的类集合NotUsedJarClassSet,以及每个类包含的方法Method,如果存在某个方法Method的类名既存在于UsedJarClassSet又存在于NotUsedJarClassSet,但是只有NotUsedJar中的类对该方法有实现,则将该方法加入到对应NotUsedJar的ThrownMethodSet中,并将对应的依赖冲突NoMethod的危险级别设置为1。
步骤4.2:遍历每个NoMethod危险级别为1的依赖冲突,对于依赖冲突中的每个NotUsedJar的ThrownMethodSet中的元素ThrownMethod,从ThrownMethod的方法名MethodName中提取类名ClassName,在UsedJar中名为ClassName类为ClassA,如果ClassA的父类依然不存在对ThrownMethod的实现,则将对应的依赖冲突NoMethod的危险级别设置为2。
步骤4.3:遍历每个NoMethod危险级别为2的依赖冲突,构建方法调用关系的有向图MethodGraph。基于MethodGraph,计算以项目为入口被执行的方法集合ReachedMethodSet。如果ReachedMethodSet中有ThrownMethod则将对应的依赖冲突的危险级别设置为3。
步骤5:对评估结果进行封装,向开发者展现评估结果。
有益技术效果:
Maven自身提供依赖冲突的检测机制,可以检测到当前项目中存在的所有依赖冲突。但并不是所有的依赖冲突都会导致bug的出现,如果为开发者报警所有的依赖冲突,则会产生大量的报警信息,而其中大量的假阳性报警则会导致开发者对于真正软件缺陷的忽视。本发明在maven的基础上为开发者提供更多关于依赖冲突的信息:不仅可以检测到项目中存在的依赖冲突,而且根据软件类和方法的内部联系对依赖冲突的危险等级进行了有效的评估。将依赖冲突进行分级可以帮助开发者更清晰地了解项目中存在的依赖冲突的危险性。软件开发者使用本发明优先处理高等级的依赖冲突,可以在有限的时间内最大程度的降低软件在运行时的出现xx-not-found-bug的风险。
附图说明
图1为本发明实施例的流程图;
图2为本发明实施例的评估NoClass危险级别的流程图;
图3为本发明实施例的评估NoClass危险级别的实例图;
图4为本发明实施例的评估NoMethod危险级别的流程图;
图5为本发明实施例的评估NoMethod危险级别的实例图。
具体实施方式
下面结合附图和具体实施实例对发明做进一步说明:
评估Maven环境中依赖冲突危险级别的方法,包括如下流程,如图1所示:
步骤1:获取到当前项目中使用的所有第三方依赖,包括直接依赖和间接依赖:
在maven的构建环境中,写在pom文件中的依赖为直接依赖,写在直接依赖的pom里面的依赖为间接依赖,写在间接依赖pom文件中的依赖也称为间接依赖。以当前项目为根,所有的依赖构成树状结构,称为依赖树。使用maven的api接口,在DependencyNodeVisitor的子类中的visit方法编写相应逻辑,可以遍历依赖树上出现的每个依赖,包括直接依赖和间接依赖,并存储到程序中。
步骤2:对当前项目所有直接依赖和间接依赖进行遍历,识别当前项目中出现的所有依赖冲突:
Maven的每个依赖使用GroupId,Artifact,Version三个字段进行唯一标识,GroupId表示依赖的开发机构,ArtifactId表示依赖的项目名称,Version表示依赖的版本号。GroupId和Artifact相同则视为同一个第三方,如果正在开发的项目的依赖树中出现了同一个第三方的两个Version则产生了依赖的冲突,当前项目在进行编译的时候只会使用其中的一个版本。为了识别出程序中存在的所有依赖冲突,需要统计程序引入的所有第三方,以及每个第三方被应用的版本,如果第三方被引用的版本超过1则构建一个冲突对象记录此冲突的相关数据。
步骤3:针对当前项目中的每个依赖冲突进行NoClass危险级别的评估,包括步骤3.1~步骤3.6:如图2流程所示,图2中level1代表NoClass的危险级别1,level2代表NoClass的危险级别2,level3代表NoClass的危险级别3。下面结合图3实例进行详述。图3中共存在三个冲突{(sample:risk1:1.0,sample:risk1:2.0),(sample:risk2:1.0,sample:risk2:2.0),(sample:risk3:1.0,sample:risk3:2.0)}.
步骤3.1:遍历每个依赖冲突,执行如下两个操作:
(1)在maven的整个依赖树上,树的节点为GroupId:Artifact:Version唯一标识的依赖jar包,树的边表示上层节点依赖于下层节点。最后被maven使用的节点可以通过DependencyNode的State判断,被使用的jar包的state为include。冲突中被使用的依赖为UsedJar,其余没有被使用到的依赖构成集合NotUsedJarSet,图3实例的识别结果如表格1所示:
表格1:图3实例的识别结果表
(2)使用soot工具可以在程序执行的时候将jar包进行解压,然后从解压后的后缀为.class的文件的文件名中提取出jar包中所有的类。对于每个冲突,使用soot解析UsedJar得到UsedJarClassSet,解析NotUsedJarSet中的NotUsedJar得到NotUsedJarClassSet,如果差集NotUsedJarClassSet-UsedJarClassSet中有元素,则将该冲突NoClass的危险级别设置为1,NoClass的危险级别评估结果表I如表格2所示:
表格2:NoClass的危险级别评估结果表I
步骤3.2:使用soot解析依赖树上state为include的依赖,解析当前项目中所有被使用的jar包,得到当前项目和其第三方依赖中的类集合UsedClassSet。
图3实例中state为include的依赖jar包为sample:top:1.0,sample:middle:1.0,sample:risk1:2.0,sample:risk2:2.0,sample:risk3:2.0,所有jar包中的类构成UsedClassSet{class_top,class_middle,class_common1,class_common2,class_common3,class_risk1};
步骤3.3:遍历当前NoClass危险级别为1的依赖冲突,如果NotUsedJarClassSet-UsedClassSet中有元素,则将该类添加到该依赖冲突的ThrownClassSet中,并将该冲突NoClass的危险级别设置为2,NoClass的危险级别评估结果表II如表格3所示:
表格3:NoClass的危险级别评估结果表II
步骤3.4:Javassist可以通过对class文件进行分析,分析类文件中包含的信息得到类之间的引用关系。使用Javassist解析出的类之间的ClassRef关系,建立类关系的带权有向图ClassGraph,图中的节点为类,边的起点和终点为引用类和被引用的类,边的权值全部为1。
步骤3.5:当前项目的代码会被maven编译到对应工程文件夹的target目录下,使用soot解析target目录,获取当前项目的宿主类集合HostClassSet。
步骤3.6:遍历当前NoClass危险级别为2的依赖冲突:基于ClassGraph,每次以依赖冲突的ThrownClassSet中的一个类为起点,使用Dijkstra算法计算ThrownClass到图中其他节点的最短路径距离,如果冲突的ThrownClassSet中的某个类与HostClassSet中的某个类的最短距离小于无穷大,则将该冲突NoClass的危险级别设置为3;
步骤3.6.1:初始时,从ThrownClassSet中选出一个未被计算的类V0,S={V0},T=V-S={项目中的其他类},T中顶点对应的距离值:若存在<V0,Vi>的有向的类引用,d(V0,Vi)为1,若不存在<V0,Vi>的有向的类引用,d(V0,Vi)为∞。
步骤3.6.2:从T中选取一个与S中节点有关联边且权值最小的顶点W,加入到S中。
步骤3.6.3:对其余T中节点的距离值进行修改:若加进W作中间节点,从V0到Vi的距离值缩短,则修改此距离值。
步骤3.6.4:重复上述步骤3.6.2和3.6.3,直到S中包含所有顶点,即W=Vi为止。
步骤3.6.5:重复上述步骤3.6.1~3.6.4,直到ThrownClassSet中的所有类到图中其他节点的最短距离都计算完毕。
NoClass的危险级别评估结果表III如表格4所示:
表格4:NoClass的危险级别评估结果表III
步骤4:如图4所示,针对项目中的每个依赖冲突进行NoMethod危险级别的评估,其中,图4中level1代表NoMethod的危险级别1,level2代表NoMethod的危险级别2,NoMethod代表NoClass的危险级别3。下面结合图5实例进行详述。
步骤4.1:遍历每个依赖冲突:识别出冲突中用于编译当前项目的依赖UsedJar,其他没有用于编译当前项目的依赖NotUsedJar构成集合NotUsedJarSet。使用Java代码优化框架soot分析jar包中的class文件,得到jar包中的类以及类中的方法,图5实例的识别结果如表格5所示:
表格5:图5实例的识别结果
步骤4.1.1:对于每个冲突:使用soot分析UsedJar,得到UsedJar包中的类UsedJarClassSet,以及每个类包含的方法。
步骤4.1.2:对于每个冲突:遍历NotUsedJarSet的每个NotUsedJar,使用soot解析NotUsedJar,得到jar包中的类NotUsedJarClassSet,以及每个类包含的方法。取UsedJarClassSet和NotUsedJarClassSet的交集得到CommonClassSet。如果CommonClass的某个method只有NotUsedJar实现了,则将method加入ThrownMethodSet中,并将对应的依赖冲突NoMethod的危险级别设置为1,NoMethod的危险级别评估结果I如表格6所示:
表格6:NoMethod的危险级别评估结果I
步骤4.2:遍历每个NoMethod危险级别为1的依赖冲突,对于依赖冲突中的每个NotUsedJar的ThrownMethodSet中的元素ThrownMethod:先使用soot得到ThrownMethod的类ThrownMethodClass,再使用soot得到其父类ThrownMethodClassFather,如果父类中依然不存在对ThrownMethod的实现,则将对应的依赖冲突NoMethod的危险级别设置为2,NoMethod的危险级别评估结果II如表格7所示:
表格7:NoMethod的危险级别评估结果II
步骤4.3:基于方法调用关系,计算ThrownMethod在实际运行时是否会被执行:
步骤4.3.1:遍历每个NoMethod危险级别为2的依赖冲突,使用soot的全局模式构建系统的方法调用关系图的MethodGraph。
步骤4.3.3:当前项目的代码会被maven编译到对应工程文件夹的target目录下,使用soot解析target目录,获取当前项目的方法集合HostMethodSet。
步骤4.3.4:基于MethodGraph,使用soot提供的接口计算以HostMethodSet为入口可能会被执行的方法集合ReachedMethodSet。如果ReachedMethodSet中有ThrownMethod则将对应的依赖冲突的NoMethod的危险级别设置为3,NoMethod的危险级别评估结果III如表格8所示:
表格8:NoMethod的危险级别评估结果III:
步骤5:采用数据和展现形式分离的方式,将评估结果封装到数据结构中,对于同一个数据结构,用xml和html两种不同的展现逻辑,向开发者展现评估结果。
Claims (5)
1.一种评估Maven环境中依赖冲突危险级别的方法,其特征在于,包括流程如下,其中步骤3与步骤4不分先后顺序:
步骤1:获取到当前项目中使用的所有第三方依赖,包括直接依赖和间接依赖;
步骤2:对当前项目所有直接依赖和间接依赖进行遍历,识别当前项目中出现的所有依赖冲突;
步骤3:针对当前项目中的每个依赖冲突进行NoClass危险级别的评估;
步骤4:针对项目中的每个依赖冲突进行NoMethod危险级别的评估;
步骤5:对评估结果进行封装,向开发者展现评估结果。
2.根据权利要求1所述一种评估Maven环境中依赖冲突危险级别的方法,其特征在于,所述进行NoClass危险级别的评估,流程包括步骤3.1~步骤3.6:
步骤3.1:识别出依赖冲突中用于编译当前项目的一个依赖UsedJar,其余没有用于编译当前项目的多个依赖NotUsedJar构成集合NotUsedJarSet,UsedJar中的类构成集合UsedJarClassSet,NotUsedJar内部的类构成集合NotUsedJarClassSet,如果有某个类存在于NotUsedJarClassSet却不存在于UsedJarClassSet,则将该冲突NoClass的危险级别设置为1;
步骤3.2:解析当前项目中所有被使用的jar包,得到当前项目和其第三方依赖中的类集合UsedClassSet;
步骤3.3:遍历当前NoClass危险级别为1的依赖冲突,如果有某个类Class存在于NotUsedJarClassSet却不存在于UsedClassSet,则将该类添加到该依赖冲突的ThrownClassSet中,并将该冲突NoClass的危险级别设置为2;
步骤3.4:根据类之间的ClassRef关系,建立类关系的有向图ClassGraph,有向图中的节点为类,边的起点和终点为引用类和被引用的类,边的权值全部为1;
步骤3.5:解析当前项目,获取当前项目的宿主类集合HostClassSet;
步骤3.6:遍历当前NoClass危险级别为2的依赖冲突:基于ClassGraph,每次以依赖冲突的ThrownClassSet中的一个类为起点,使用Dijkstra算法计算ThrownClass到图中其他节点的最短路径距离,如果依赖冲突的ThrownClassSet中的某个类与HostClassSet中的某个类的最短距离小于无穷大,则将该冲突NoClass的危险级别设置为3。
3.根据权利要求1所述一种评估Maven环境中依赖冲突危险级别的方法,其特征在于,所述进行NoMethod危险级别的评估,流程包括步骤4.1~步骤4.3:
步骤4.1:遍历每个依赖冲突,识别出冲突中用于编译当前项目的一个依赖UsedJar,其余没有用于编译当前项目的多个依赖NotUsedJar构成集合NotUsedJarSet,分析UsedJar得到jar包中的类UsedJarClassSet,以及每个类包含的方法Method,再分析每个NotUsedJar得到jar包中的类集合NotUsedJarClassSet,以及每个类包含的方法Method,如果存在某个方法Method的类名既存在于UsedJarClassSet又存在于NotUsedJarClassSet,但是只有NotUsedJar中的类对该方法有实现,则将该方法加入到对应NotUsedJar的ThrownMethodSet中,并将对应的依赖冲突NoMethod的危险级别设置为1;
步骤4.2:遍历每个NoMethod危险级别为1的依赖冲突,对于依赖冲突中的每个NotUsedJar的ThrownMethodSet中的元素ThrownMethod,从ThrownMethod的方法名MethodName中提取类名ClassName,在UsedJar中名为ClassName类为ClassA,如果ClassA的父类依然不存在对ThrownMethod的实现,则将对应的依赖冲突NoMethod的危险级别设置为2;
步骤4.3:遍历每个NoMethod危险级别为2的依赖冲突,构建方法调用关系的有向图MethodGraph,基于MethodGraph,计算以项目为入口被执行的方法集合ReachedMethodSet,如果ReachedMethodSet中有ThrownMethod则将对应的依赖冲突的危险级别设置为3。
4.根据权利要求1所述一种评估Maven环境中依赖冲突危险级别的方法,其特征在于,所述向开发者展现评估结果:采用数据和展现形式分离的方式,将评估结果封装到数据结构中,对于同一个数据结构,用xml和html两种不同的展现逻辑,向开发者展现评估结果。
5.根据权利要求2所述一种评估Maven环境中依赖冲突危险级别的方法,其特征在于,所述最短路径距离计算方法流程包括步骤3.6.1~步骤3.6.5:
步骤3.6.1:初始时,从ThrownClassSet中选出一个未被计算的类V0,S={V0},T=V-S={项目中的其他类},T中顶点对应的距离值:若存在<V0,Vi>的有向的类引用,d(V0,Vi)为1,若不存在<V0,Vi>的有向的类引用,d(V0,Vi)为∞;
步骤3.6.2:从T中选取一个与S中节点有关联边且权值最小的顶点W,加入到S中;
步骤3.6.3:对其余T中节点的距离值进行修改:若加进W作中间节点,从V0到Vi的距离值缩短,则修改此距离值;
步骤3.6.4:重复上述步骤3.6.2和3.6.3,直到S中包含所有顶点,即W=Vi为止;
步骤3.6.5:重复上述步骤3.6.1~3.6.4,直到ThrownClassSet中的所有类到图中其他节点的最短距离都计算完毕。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201810891476.7A CN108984416B (zh) | 2018-08-07 | 2018-08-07 | 一种评估Maven环境中依赖冲突危险级别的方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201810891476.7A CN108984416B (zh) | 2018-08-07 | 2018-08-07 | 一种评估Maven环境中依赖冲突危险级别的方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN108984416A true CN108984416A (zh) | 2018-12-11 |
CN108984416B CN108984416B (zh) | 2022-04-08 |
Family
ID=64556041
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201810891476.7A Active CN108984416B (zh) | 2018-08-07 | 2018-08-07 | 一种评估Maven环境中依赖冲突危险级别的方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN108984416B (zh) |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110618931A (zh) * | 2019-08-14 | 2019-12-27 | 重庆金融资产交易所有限责任公司 | 依赖关系检测方法、装置、计算机设备及可读存储介质 |
CN112181858A (zh) * | 2020-11-09 | 2021-01-05 | 东北大学 | Java软件项目依赖冲突语义一致性的自动化检测方法 |
CN112799937A (zh) * | 2021-01-13 | 2021-05-14 | 东北大学 | 基于GitHub自动化检测Maven项目中依赖冲突问题的方法 |
CN112947896A (zh) * | 2021-03-26 | 2021-06-11 | 中国航空无线电电子研究所 | 一种基于有向图的组件依赖分析方法 |
CN112965913A (zh) * | 2021-03-26 | 2021-06-15 | 东北大学 | 一种Java软件依赖冲突问题自动化修复的方法 |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8099735B2 (en) * | 2007-12-21 | 2012-01-17 | Oracle America, Inc. | Method and system for module initialization |
CN106033336A (zh) * | 2015-03-12 | 2016-10-19 | 阿里巴巴集团控股有限公司 | 解决Maven依赖冲突的方法、装置和系统 |
CN108228229A (zh) * | 2016-12-19 | 2018-06-29 | 深圳业拓讯通信科技有限公司 | 一种Maven依赖的管理方法以及系统 |
-
2018
- 2018-08-07 CN CN201810891476.7A patent/CN108984416B/zh active Active
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8099735B2 (en) * | 2007-12-21 | 2012-01-17 | Oracle America, Inc. | Method and system for module initialization |
CN106033336A (zh) * | 2015-03-12 | 2016-10-19 | 阿里巴巴集团控股有限公司 | 解决Maven依赖冲突的方法、装置和系统 |
CN108228229A (zh) * | 2016-12-19 | 2018-06-29 | 深圳业拓讯通信科技有限公司 | 一种Maven依赖的管理方法以及系统 |
Cited By (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110618931A (zh) * | 2019-08-14 | 2019-12-27 | 重庆金融资产交易所有限责任公司 | 依赖关系检测方法、装置、计算机设备及可读存储介质 |
CN110618931B (zh) * | 2019-08-14 | 2024-06-07 | 重庆金融资产交易所有限责任公司 | 依赖关系检测方法、装置、计算机设备及可读存储介质 |
CN112181858A (zh) * | 2020-11-09 | 2021-01-05 | 东北大学 | Java软件项目依赖冲突语义一致性的自动化检测方法 |
CN112799937A (zh) * | 2021-01-13 | 2021-05-14 | 东北大学 | 基于GitHub自动化检测Maven项目中依赖冲突问题的方法 |
CN112799937B (zh) * | 2021-01-13 | 2023-09-26 | 东北大学 | 基于GitHub自动化检测Maven项目中依赖冲突问题的方法 |
CN112947896A (zh) * | 2021-03-26 | 2021-06-11 | 中国航空无线电电子研究所 | 一种基于有向图的组件依赖分析方法 |
CN112965913A (zh) * | 2021-03-26 | 2021-06-15 | 东北大学 | 一种Java软件依赖冲突问题自动化修复的方法 |
CN112965913B (zh) * | 2021-03-26 | 2023-09-26 | 东北大学 | 一种Java软件依赖冲突问题自动化修复的方法 |
CN112947896B (zh) * | 2021-03-26 | 2023-10-27 | 中国航空无线电电子研究所 | 一种基于有向图的组件依赖分析方法 |
Also Published As
Publication number | Publication date |
---|---|
CN108984416B (zh) | 2022-04-08 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN108984416A (zh) | 一种评估Maven环境中依赖冲突危险级别的方法 | |
US20230123563A1 (en) | System and method for information flow analysis of application code | |
Gosain et al. | Static analysis: A survey of techniques and tools | |
US7478366B2 (en) | Debugger and method for debugging computer programs across multiple programming languages | |
US9747190B2 (en) | Analysis system, analysis method, and computer program product | |
US20170329692A1 (en) | System and methods for model-based analysis of software | |
Bernardi et al. | Design pattern detection using a DSL‐driven graph matching approach | |
US20200125475A1 (en) | Systems and methods for dynamically identifying data arguments and instrumenting source code | |
Choi et al. | NTFuzz: Enabling type-aware kernel fuzzing on windows with static binary analysis | |
JP7218793B2 (ja) | プログラムの機能を向上するための制御フローシステム、非一時的可読媒体、および方法 | |
JP2006185211A (ja) | プログラム解析装置、テスト実行装置、その解析方法及びプログラム | |
Goknil et al. | Generation and validation of traces between requirements and architecture based on formal trace semantics | |
US9304893B1 (en) | Integrated software development and test case management system | |
CN111694746A (zh) | 面向编译型语言AS3的Flash缺陷模糊测评工具 | |
US11379198B1 (en) | Call graph enhancement using stitching algorithm | |
Person et al. | Test analysis: Searching for faults in tests (n) | |
Mover et al. | Mining framework usage graphs from app corpora | |
Sultana et al. | Evaluating micro patterns and software metrics in vulnerability prediction | |
de Boer et al. | Combining monitoring with run-time assertion checking | |
EP2535813B1 (en) | Method and device for generating an alert during an analysis of performance of a computer application | |
US20220179776A1 (en) | Systems and Methods for Automatic Test Generation | |
Sousa et al. | Preventing atomicity violations with contracts | |
Kirkov et al. | Source code analysis–an overview | |
Munsters et al. | Oron: Towards a dynamic analysis instrumentation platform for AssemblyScript | |
Correnson et al. | Engineering a formally verified automated bug finder |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |