从Sun Javac的代码来看,编译过程大致可以分为三个过程,分别是:
- 解析与填充符号表过程
- 插入式注解处理器的注解处理过程
- 分析与字节码生成过程
在jdk中是通过javac将.java文件编译为.class文件。Javac编译动作的入口时com.sun.tools.javac.main.JavaCompiler类,上述三个过程的代码逻辑集中在这个类的compile()和compile2()方法里,其中主体代码如图10-5所示,整个编译最关键的处理就由图中标注的8个方法来完成,下面我们来看看这8个方法实现了什么功能。
图10-5
2.2解析与填充符号表
解析步骤由图10-5中的parseFiles()方法(图中的过程1.1)完成,解析步骤包括了经典程序编译原理中的词法分析和语法分析两个过程。
1.词法,语法分析
词法分析是将源代码的字符流转变为标记(Token)集合,单个字符是程序编写过程的最小元素,而标记则是编译过程的最小元素,关键字,变量名,字面量和运算符都可以成为标记,如“int a=b+2”这句代码包含了6个标记,分别是int,a,=,b,+,2,虽然关键字int由三个字符构成,但是它只是一个Token,不可再拆分。在javac的源码中,词法分析过程由com.sun.tools.parser.Scanner类来实现。
语法分析是根据Token序列来构造抽象语法树的过程,抽象语法树(AST,Abstract Syntax Tree)是一种用来描述程序代码语法结构的树形表示方式,语法树的每一个节点都代表着程序代码中的一个语法结构(Construct),例如包,类型,修饰符,运算符,接口,返回值甚至连代码注释等都可以 是一个语法结构。
图10-6是Eclipse AST View插件分析出来的某段代码的抽象语法树视图,读者可以通过这张图对抽象语法树有一个直观的认识。在Javac的源码中,语法分析过程由com.sun.tools.javac.parser。Parse来实现,这个阶段产出的抽象语法树由com.sun.tools.javac.tree.JCTree类来表示,经过这个步骤之后 ,编译器就基本不会再对源码文件进行操作了,后续的操作都建立在抽象语法树上。
2.填充符号表
完成了语法分析和词法分析后,下一步就是填充符号表的过程,也就是图10-5中enterTrees()方法(图中的过程1.2)所做的事情。符号表(Symbol Table)是由一组符号地址和符号信息构成的表格,读者可以把它想象成哈希表中K_V值对 的形式(实际上符号表不一定是哈希表实现,可以是有序符号表,树状符号表和栈结构符号表等)。符号表中所登记的信息在编译的不同阶段都要用到。在语义分析中,符号表所登记的内容将用于语义检查(如检查一个名字的使用和原先的说明是否一致)和产生中间代码。在目标代码生成阶段,当对符号进行地址分配时,符号表是地址分配的依据。
在Javac源码中,填充符号表的过程由com.sun.tools.javac.comp.Enter类实现,此过程的出口是一个待处理列表(To Do List),包含了每一个编译单元的抽象语法树的顶级节点,一级package-info.java(如果存在的话)的顶级节点。
2.3注解器处理
JDK1.5之后,Java语言提供了对注解的(Annotations)的支持,这些注解与普通的java代码一样,是在运行期间发挥作用的。。在JDK1.6中实现了JSR-269规范,提供了一组插入式注解处理器的标准API在编译期间对注解进行处理,我们可以把它看作是一组编译器的插件,在这些插件里面,可以读取,修改,添加抽象语法树中的任意元素。如果这些插件在处理注解期间对语法树进行了修改,那么编译器将回到解析及填充符号表的过程重新处理,直到所有的插入式注解处理器都没有再对语法树进行修改为止,每一次循环称为一个Round,也就是上文中图10-4的那个回环过程。
图10-4
有了编译器注解处理的标准API以后,我们的代码才有可能干涉编译器的行为,由于语法树中的任意元素,甚至包括代码注释都可以在插件之中访问到,所以通过插入式注解器实现的插件功能有很大的发挥空间。只要有足够的创意,程序猿可以使用插入式注解处理器来实现许多原本只能在编码中完成的事情本章最后有一个使用插入式注解处理器的简单实战。
在Javac源码中,插入式注解处理器的初始化过程是在initPorcessAnnotations()方法中完成的,而它的执行过程则是在processAnnotations()方法中完成的,这个方法判断时候还有新的注解处理器需要执行,如果有的话,则通过com.sun.tools.javac.processing.JavacProcessingEnvironment类的doProcessing()方法生成一个新的JavaCompiler对象对编译的后续步骤进行处理。
2.4语义分析与字节码生成
语法分析之后,编译器获得了程序代码的抽象语法树表示,语法树能表示一个结构正确的源程序的抽象,但无法保证源程序是符合逻辑的。而语义分析的主要任务是结构上正确的源程序进行上下文有关性质的审查,如进行类型审查。举个例子,假设有如下的三个变量定义语句:
int a = 1;
boolean b = false;
char c = 2;
后续可能出现的赋值运算如下:
int d = a + c;
int d = b + c;
char d = a + c;
后续代码中如果出现了如上三种赋值运算的话,那它们都能构成正确的语法树,但是只有第一种的写法在语义上是么有问题的,能够通过编译,其余两种在Java语言中是不合逻辑的,无法编译(是否合乎语义逻辑必须限定在具体的语言与具体的上下文环境中才有意义。如在C语言中,a,b,c的上下文定义不变,第二,三种写法都可以被正确编译的)。
1.标注检查
Javac的编译过程中,语义分析过程分为标注检查和数据及控制流分析两个步骤,分别由图10-5的attribute()和flow()方法attribute()和flow()方法(分别对应图中的过程3.1和过程3.2)完成。
标注检查步骤检查的内容包括诸如变量使用前是否已被声明,变量与赋值之间的数据类型是否能够匹配,等等。在标注检查步骤中,还有一个重要的动作称为常量折叠,如果我们在代码中写了如下定义:int a = 1+2;
在语法树上仍然能看到字面量“1”,“2”和操作符“+”号,但是在经过常量折叠后,它们将会被折叠为字面量“3”,如图10-7所示,这个插入式表达式(Infix Expression)的值已经在语法树上标注出来了(ConstantExpressionValue:3)。由于编译器间进行了常量折叠,由于编译期间进行了常量折叠,所以在代码里面定义"a=1+2"比起定义“a=3”并不会增加程序运行期哪怕仅仅一个CPU指令的运算量。
标注检查步骤在Javac源码中的实现类是com.sun.tools.javac.comp.Attr类和com.sun.tools.javac.comp.Check类。
图10-7 常量折叠
2.数据及控制流分析
数据及控制流分析是对程序上下文逻辑更进一步的验证,它可以检查出诸如程序局部变量在使用前是否有赋值,方法的每条路径是否都有返回值,是否所有的受查异常都被正确处理了等问题。编译时期的数据及控制流分析与类加载时的数据及控制流分析的目的基本上是一致的,但校验范围有所区别,有一些校验项只有在编译器或运行期才能进行。下面举一个关于final修饰符的数据及控制流分析的例子,见代码清单10-1所示。
//方法一带有final修饰
public void foo(final int arg){
final int var = 0;
//do something
}
//方法二没有final修饰
public void foo(int arg){
int var = 0;
//do something
}
这两个foo()方法中,一个方法的参数和局部变量定义使用了final修饰符,另外一个则没有,在代码编写时程序肯定会受到final修饰符的影响,不能再改变arg 和var变量的值,但是这两段代码编译出来的Class文件是没有任何区别的,通过第6章的讲解我们已经知道,局部变量与字段(实例变量,类变量)是有区别的,它在常量池中没有CONSTANT_Fieldref_info的符号引用,自然就没有访问标志(Access_Flags)的信息,甚至可能连名称都不会被保留下来(取决于编译时的选项),自然在Class文件中不可能知道一个局部变量是不是被声明为final了。因此,将局部变量声明为final,对运行期是没有影响的,变量的不变性仅仅由编译器在编译期间保障。在Javac的源码中,数据及控制流分析的入口是图10-5中的flow()方法(图中的过程3.2),具体操作由com.sun.tools.javac.comp.Flow类来完成。
3.解语法糖
语法糖(Syntactic Sugar),也称语法糖衣语法,是由英国计算机科学家彼得·御寒·兰达(Peter J·Landin)发明的一个术语,指在计算机语言那种添加的某种语法,这种语法对语言的功能并没有影响,但是更方柏霓程序猿使用。通常来说使用语法糖能够增加程序的可读性,从而减少程序代码出错的机会。
Java在现代编程语言之中属于“低糖语言”(相对于c#及许多其他JVM语言来说),尤其是JDK1.5之前的版本,“低糖”语法也是Java语言被换衣已经“落后”的一个表面理由。Java中最常用的语法糖主要是前面提到过的泛型(泛型并不一定都是语法糖实现,如c#的泛型就是直接由CLR支持的),变长参数,自动拆装箱,等等,虚拟机运行时不支持这些语法,它们在编译阶段被还原回简单的基础语法结构,这个过程就成为解语法糖。Java的这些语法糖被解除后是什么样子,将在下一节中详细描述。
在Javac的源码中,解语法糖的过程由的desugar()方法触发,在com.sun.tools.javac.comp.TransTypes类和com.sun.tools.javac.comp.Lower类中完成。
4.字节码生成
字节码生成时Javac编译过程的最后一个阶段,在Javac源码里面由com.sun.tools.javac.jvm.Gen类来完成。字节码生成阶段不仅仅是把前面各个步骤所生成的信息(语法树,符号表)转化成字节码写到磁盘中,编译器还进行了少量的代码添加和转换工作。
例如前面章节中多次提到的实力构造器<init>()方法和类构造器<clinit>()方法就是在这个阶段被添加到语法树之中的(请注意这里的实例构造器并不是指默认构造函数,如果用户代码中没有提供任何构造函数,那编译器将会添加一个没有参数,访问性(public,protected或private)与当前类一致的默认构造函数,这个工作在填充符号表阶段就已经完成,这两个构造器的产生过程实际上是一个代码收敛的过程,编译器会把语句块(对于实力构造器而言是“{}”块,对于类构造器而言是“static{}”块),变量初始化(实例变量和类变量),调用父类的实例构造器(仅仅是实例构造器<clinit>()方法中无须调用父类的<clinit>()方法,虚拟机会自动保证父类构造器的执行,但在<clinit>()f方法中经常会生成调用java.lang.Object的<init>()方法的代码)等操作收敛到<init>()和<clinit>()方法之中,并且保证一定是按先执行父类的实力构造器,然后初始化变量,最后执行语句块的顺序执行,上面所述的动作由Gen.normalizeDefs()方法来实现。除了生成构造器以外,还有其他的一些代码替换工作用于优化程序的实现逻辑,如把字符串的加操作替换为StringBuffer或StringBuilder(取决于目标代码的版本是否大于或等于JDK1.5)的append()操作等。
完成了对语法树的遍历和调整以后,就会把填充了所有所需信息的符号表交到com.sun.tools.javac.jvm.ClassWriter类手上,由这个类的writeClass()方法输出字节码,生成最终的Class文件,到此为止整个编译过程宣告结束。
4实战
通过阅Javac编译器的源码,我们知道编译器在把Java程序源码编译为字节码的时候,会对Java程序源码做各方面的检查校验。这些校验主要以程序“写得对不对”为出发点,虽然也有各种WARNING的信息,但总体来说还是较少去校验程序“写的好不好”。有鉴于此,业界出现了许多针对程序“写得好不好”的辅助校验工具,如CheckStyle,FindBug,Klocwork等。这些代码校验工具有一些是基于Java的源码进行校验,有一些是通过扫描字节码来完成,在本节的实战中,我们将会使用注解处理器API来编写一款拥有自己编码风格的校验工具:NameCheckProcessor。
当然,由于我们的实战都是为了学习和演示技术原理,而不是为了做出一款能媲美CheckStyle等工作的产品来,所以NameChackProcessor的目标也仅定为对Java程序命名进行检查,根据《Java 语言规范(第三版)》中第6.8节的要求,Java程序命名应当符合下列格式的书写规范:
- 类(或接口):符合驼式命名法,首字母大写。
- 方法:符合驼式命名法,首字母小写。
- 字段
- 类或实例变量:符合驼式命名法,首字母小写。
- 常量:要求全部由大写字母或下划线构成,并且不能以下划线开头。
4.2代码实现
要通过主机处理API实现一个编译器插件,首先需要了解这组API的一些基本知识。我们实现注解处理器的代码需要继承抽象类javax.annotation.processiong.AbstractProcessor,这个抽象类中只有一个必须覆盖的abstract方法:“process()”,它是Javac编译器在执行注解处理器代码时要调用的过程,我们可以从这个方法的第一个参数“annotations”中获取到此注解器索要处理的注解集合,从第二个参数“roundEnv”中访问到当前这个Round中的语法树节点,每个语法树节点在这里表示为一个Element.在JDK1.6新增的javax.lang.model包中定义了16类Element,包括了Java代码中最常用的元素,如:“包(PACKAGE),枚举(ENUM),类(CLASS),注解(ANNOTATION_TYPE),接口(INTERFACE),枚举值(ENUM_CONSTANT),字段(FIELD),参数(PARAMETER),本地变量(LOCAL_VARIABLE),异常(EXCEPTION_PARAMETER),方法(METHOD),构造函数(CONSTRUCTOR),静态语句块(STATIC_INIT,即static{}块)”,实例语句块(INSTANCE_INIT,即{}块),参数化类型(TYPE_PARAMETER,即泛型尖括号内的类型)和未定义的其他语法树节点(OTHER)".除了process()方法的传入参数之外,还有一个很常用的实例变量“processingEnv”,它是AbstarcProcessor中的protected变量,在注解处理器初始化的时候(init()方法执行的时候)创建,继承了AbstractProcessor的注解处理器代码可以直接访问到它。它代表了注解处理器框架提供的一个上下文环境,要创建新的代码,向编译器输出信息,获取其他工具类等都需要用到这个实例变量。
注解处理器除了process()方法及其参数之外,还有两个可以配合使用的Annotations:@SupportedAnnotationTypes和@SupportedSourceVersion,前者代表了这个注解处理器对那些注解感兴趣,可以使用“*”作为通配符代表对所有的注解都感兴趣,后者指出这个注解处理器可以处理那些版本的Java代码。
每一个注解处理器在运行的时候但是单例的,如果不需要改变或生成语法树的内容,processs()方法就可以返回一个值为false的布尔值,通知编译器这个Round中的代码未发生变化,无须构造新的JavaCompiler实例,在这次实战的注解处理器中只对程序命名进行检查,不需要改变语法树的内容,因此process()方法的返回值都是false.关于注解处理器的API,笔者就简单介绍这些,对这个领域有兴趣的读者可以阅读相关的帮助文档。