希望有兴趣的加入，共同为项目智能化管理jar包而努力 第二篇

 

想听听大家对于我这个想法的一些看法，喷也好，赞也罢，希望留下您宝贵的建议！

 

有共同想法并且想实现的请入群 2500261120

 

在使用autort插件时，首先要到autort服务器下载所有的jar包快照。里面存在了检索jar的相关信息。

 

在第一篇我们专门介绍过如何划分java类中出现的某一串字符，想了解的或者不知道我要干什么的请点这里 。其实说白了，也就是系统的整个类的组织及查询方式。Trie树可以在我们知道类全名的情况下尽快找到所需要的类。

 

当通过类全名找到存储某个类的Node时，此Node中有个map属性，key为类名，而值保存了这个类在版本迭代过程中的所有快照。类似于Git用快照来保存文件迭代的过程。不同的是，这里的快照是类的快照，而不是文件。类似如下形式：

 

一个类的不同快照会使用List列表来存储，因为版本的迭代发布本来就是有先后顺序的。快照的具体json结构如下：

 

{
   serialVersion:快照支持的一系列版本，这些版本都是连续的
   type:{
   modifiers:修饰符
   type:表示类型，如1代表类，2代表interface，3代表枚举，4为注解定义
   name:内部类的写法为outer.innter
   extends:全类名的形式
   implements:[] 多个类全名的形式
   types:[] 存储多个type
   fields:1[
       {
        modifiers:方法修饰符
        declType:方法返回类型，也是全类名的形式
        name:方法名称
       }
       ...
   ]
   methods:[
       {
         modifiers:方法修饰符
         returnType:方法返回类型，也是全类名的形式
         name:方法名称
         throws:全类名的形式
         arguments:[] 多个全类名的形式
       }
       ...
   ]
    }
}

首先介绍一下serialVersion属性。

 

举个例子，spring-core从开始发布版本至今共有90个版本。假如某个类A在1.2.8版本之前一直没有变化，那么这个serialVersion代表着之前的所有版本（共25个）。

 

假如在2.0进行API调整或者类重构时，这个类发生了变化，也就是快照中保存的某个或者多个属性发生了变化，比如某个方法的参数类型改变了，那么需要再生成一个快照结构，代表这次的变化。假如这次重构后经历了10次版本迭代仍然没有变化，那么这个结构中的serialVersion标识这10个版本。

 

如果下一次重构时，这个类变换了类路径，那么它将做为相应类路径下一个新建的类开始存在。而原来的快照只保存之前的35个版本快照。

 

下面重点来看一下type属性。

 

modifiers修饰符的定义：

 

 

例如某个类的修饰符有public和final，那么modifiers的值为 PUBLIC|FINAL

 

extends为字符串形式，存储了这个类可能继承的其它类。如果为空，默认为Object

 

implements类型为数组，存储值必须为全名，以方便通过Trie树迅速查找到这些接口相关的信息。可以为空。

 

types属性。这个属性中存储了多个type结构，这个type结构可能是类（包括抽象类）、接口、枚举类和注解定义类。

 

无论这个内部的结构有什么修饰符都需要存储相关的信息。和我们后面将要提到的属性与方法略有不同，属性与方法是通过不同的修饰符选择性存储。

 

举个例子：

 

public class Father01 {
	private class A{
		public int a = 2;
	}
	public class B extends A{

	}
}

类A虽然是private，但是B继承了A。客户端的代码如下：

 

public class Son01 extends Father01{
	public void test(){
	    B b = new B();
	    int x=b.a; // 使用了嵌套类A中声明的属性
	}
}

但是在块内Block定义的类就不需要保存了，因为封闭性较好，通常情况下无法被外部使用。接口，枚举类与注解定义类不能在块内定义。

 

 

剩下就是fields与methods了，目前private与默认访问控制符修饰的变量与方法不建立快照相关信息。

 

如果程序通过反射操作了三方包中的一些类属性，那么快照中需要存储所有的方法（包括构造方法）与变量，因为反射可以获取到类所有相关的信息。这会使快照的数据量变大并且快照数量变多，目前暂不考虑。

 

下面来说一说方法中的throws异常吧。

 

修改了某个公有方法抛出的异常。由原来的某个不受检查异常变为了受检查的异常，那么这一版本jar包就已经不满足我们程序的要求了，autort会通过检测将这一版本排除在可选择范围之外。

 

需要说明的是，并不是修改了方法抛出的异常就会为type新建快照，但是从某个检查异常修改为另外的检查异常，即使两者之间有继承关系，也一定会建立新的快照。不会对Error与RuntimeException的异常进行信息保存与处理，因为这些异常不会让现有的一些程序出错。

 

如下实例：

 

 

public void test() throws ReflectiveOperationException,NullPointerException{  ...   }
public void testException(){
   try {
        test();
   }catch (ReflectiveOperationException e) {
        e.printStackTrace();
   }
}

 

test方法新增加了一个非检查异常NullPointerException并且在testException方法中调用了这个方法，但是并不需要修改相关调用的代码。

 

 

其实我只说了需要存储哪些信息，并没有说为什么要选择性存储这些信息，我们可以思考一个问题：我们的程序使用了第三方jar包提供的相关功能，一搬情况下也就是下面几种：

 

（1）调用一个方法，使用new关键字创建对象时也看作调用它的构造方法，返回类型为构造方法所在的类类型。

（2）调用一个变量

（3）继承了三方的类或者实现了三方定义的接口

 

快照中需要存储足够的信息，当客户通过如上一种或多种方式使用了jar包功能时，可以通过扫描分析这些代码并结合快照中jar包类迭代的信息，快速找到当前代码合适的版本。

 

 

最终一个整体的存储结构大概如下图所示。

需要说明的是，一个jar包就需要有这样的一个结构来组织和存储相关的信息，主要是考虑到不同jar包会有类全名（包路径和类名）相等的情况，更重要的是会通过这样的结构来选择性加载到内存。