Question

几乎各种语言或多或少都提供过一些语法糖来方便程序员的代码开发，这些语法糖虽然不会提供实质性的功能改进，但是它们或能提高效率，或能提升语法的严谨性，或能减少编码出错的机会。不过也有一种观点认为语法糖并不一定都是有益的，大量添加和使用“含糖”的语法，容易让程序员产生依赖，无法看清语法糖的糖衣背后，程序代码的真实面目。

总而言之，语法糖可以看做是编译器实现的一些“小把戏”，这些“小把戏”可能会使得效率“大提升”，但我们也应该去了解这些“小把戏”背后的真实世界，那样才能利用好它们，而不是被它们所迷惑。

10.3.1　泛型与类型擦除

泛型是JDK 1.5的一项新增特性，它的本质是参数化类型（Parametersized Type）的应用，也就是说所操作的数据类型被指定为一个参数。这种参数类型可以用在类、接口和方法的创建中，分别称为泛型类、泛型接口和泛型方法。

泛型思想早在C++语言的模板（Template）中就开始生根发芽，在Java语言处于还没有出现泛型的版本时，只能通过Object是所有类型的父类和类型强制转换两个特点的配合来实现类型泛化。例如，在哈希表的存取中，JDK 1.5之前使用HashMap的get()方法，返回值就是一个Object对象，由于Java语言里面所有的类型都继承于java.lang.Object，所以Object转型成任何对象都是有可能的。但是也因为有无限的可能性，就只有程序员和运行期的虚拟机才知道这个Object到底是个什么类型的对象。在编译期间，编译器无法检查这个Object的强制转型是否成功，如果仅仅依赖程序员去保障这项操作的正确性，许多ClassCastException的风险就会转嫁到程序运行期之中。

泛型技术在C#和Java之中的使用方式看似相同，但实现上却有着根本性的分歧，C#里面泛型无论在程序源码中、编译后的IL中（Intermediate Language，中间语言，这时候泛型是一个占位符），或是运行期的CLR中，都是切实存在的，List＜int>与List＜String>就是两个不同的类型，它们在系统运行期生成，有自己的虚方法表和类型数据，这种实现称为类型膨胀，基于这种方法实现的泛型称为真实泛型。

Java语言中的泛型则不一样，它只在程序源码中存在，在编译后的字节码文件中，就已经替换为原来的原生类型（Raw Type，也称为裸类型）了，并且在相应的地方插入了强制转型代码，因此，对于运行期的Java语言来说，ArrayList＜int>与ArrayList＜String>就是同一个类，所以泛型技术实际上是Java语言的一颗语法糖，Java语言中的泛型实现方法称为类型擦除，基于这种方法实现的泛型称为伪泛型。

代码清单10-2是一段简单的Java泛型的例子，我们可以看一下它编译后的结果是怎样的。

代码清单10-2　泛型擦除前的例子

public static void main（String[]args）{
Map＜String,String>map=new HashMap＜String,String>()；
map.put（"hello"，"你好"）；
map.put（"how are you?"，"吃了没？"）；
System.out.println（map.get（"hello"））；
System.out.println（map.get（"how are you?"））；
}

把这段Java代码编译成Class文件，然后再用字节码反编译工具进行反编译后，将会发现泛型都不见了，程序又变回了Java泛型出现之前的写法，泛型类型都变回了原生类型，如代码清单10-3所示。

代码清单10-3　泛型擦除后的例子

public static void main（String[]args）{
Map map=new HashMap()；
map.put（"hello"，"你好"）；
map.put（"how are you?"，"吃了没？"）；
System.out.println（（String）map.get（"hello"））；
System.out.println（（String）map.get（"how are you?"））；
}

当初JDK设计团队为什么选择类型擦除的方式来实现Java语言的泛型支持呢？是因为实现简单、兼容性考虑还是别的原因？我们已不得而知，但确实有不少人对Java语言提供的伪泛型颇有微词，当时甚至连《Thinking in Java》一书的作者Bruce Eckel也发表了一篇文章《这不是泛型！》^[1]来批评JDK 1.5中的泛型实现。

在当时众多的批评之中，有一些是比较表面的，还有一些从性能上说泛型会由于强制转型操作和运行期缺少针对类型的优化等从而导致比C#的泛型慢一些，则是完全偏离了方向，姑且不论Java泛型是不是真的会比C#泛型慢，选择从性能的角度上评价用于提升语义准确性的泛型思想就不太恰当。但笔者也并非在为Java的泛型辩护，它在某些场景下确实存在不足，笔者认为通过擦除法来实现泛型丧失了一些泛型思想应有的优雅，例如代码清单10-4的例子。

代码清单10-4　当泛型遇见重载1

public class GenericTypes{
public static void method（List＜String>list）{
System.out.println（"invoke method（List＜String>list）"）；
}
public static void method（List＜Integer>list）{
System.out.println（"invoke method（List＜Integer>list）"）；
}
}

请想一想，上面这段代码是否正确，能否编译执行？也许你已经有了答案，这段代码是不能被编译的，因为参数List＜Integer>和List＜String>编译之后都被擦除了，变成了一样的原生类型List＜E>，擦除动作导致这两种方法的特征签名变得一模一样。初步看来，无法重载的原因已经找到了，但真的就是如此吗？只能说，泛型擦除成相同的原生类型只是无法重载的其中一部分原因，请再接着看一看代码清单10-5中的内容。

代码清单10-5　当泛型遇见重载2

public class GenericTypes{
public static String method（List＜String>list）{
System.out.println（"invoke method（List＜String>list）"）；
return""；
}
public static int method（List＜Integer>list）{
System.out.println（"invoke method（List＜Integer>list）"）；
return 1；
}
public static void main（String[]args）{
method（new ArrayList＜String>()）；
method（new ArrayList＜Integer>()）；
}
}

执行结果：

invoke method（List＜String>list）
invoke method（List＜Integer>list）

代码清单10-5与代码清单10-4的差别是两个method方法添加了不同的返回值，由于这两个返回值的加入，方法重载居然成功了，即这段代码可以被编译和执行^[2]了。这是对Java语言中返回值不参与重载选择的基本认知的挑战吗？

代码清单10-5中的重载当然不是根据返回值来确定的，之所以这次能编译和执行成功，是因为两个method()方法加入了不同的返回值后才能共存在一个Class文件之中。第6章介绍Class文件方法表（method_info）的数据结构时曾经提到过，方法重载要求方法具备不同的特征签名，返回值并不包含在方法的特征签名之中，所以返回值不参与重载选择，但是在Class文件格式之中，只要描述符不是完全一致的两个方法就可以共存。也就是说，两个方法如果有相同的名称和特征签名，但返回值不同，那它们也是可以合法地共存于一个Class文件中的。

由于Java泛型的引入，各种场景（虚拟机解析、反射等）下的方法调用都可能对原有的基础产生影响和新的需求，如在泛型类中如何获取传入的参数化类型等。因此，JCP组织对虚拟机规范做出了相应的修改，引入了诸如Signature、LocalVariableTypeTable等新的属性用于解决伴随泛型而来的参数类型的识别问题，Signature是其中最重要的一项属性，它的作用就是存储一个方法在字节码层面的特征签名^[3]，这个属性中保存的参数类型并不是原生类型，而是包括了参数化类型的信息。修改后的虚拟机规范^[4]要求所有能识别49.0以上版本的Class文件的虚拟机都要能正确地识别Signature参数。

从上面的例子可以看到擦除法对实际编码带来的影响，由于List＜String>和List＜Integer>擦除后是同一个类型，我们只能添加两个并不需要实际使用到的返回值才能完成重载，这是一种毫无优雅和美感可言的解决方案，并且存在一定语意上的混乱，譬如上面脚注中提到的，必须用Sun JDK 1.6的Javac才能编译成功，其他版本或者ECJ编译器都可能拒绝编译。

另外，从Signature属性的出现我们还可以得出结论，擦除法所谓的擦除，仅仅是对方法的Code属性中的字节码进行擦除，实际上元数据中还是保留了泛型信息，这也是我们能通过反射手段取得参数化类型的根本依据。

[1]原文地址：http://www.anyang-window.com.cn/quotthis-is-not-a-genericquot-bruce-eckel-eyes-of-the-generic-java/。

[2]测试的时候请使用Sun JDK 1.6的Javac编译器进行编译，其他编译器，如Eclipse JDT的ECJ编译器，仍然可能会拒绝编译这段代码，ECJ编译时会提示“Method method（List＜String>）has the same erasure method（List＜E>）as another method in type GenericTypes”。

[3]在《Java虚拟机规范（第2版）》（JDK 1.5修改后的版本）的“§4.4.4 Signatures”章节及《Java语言规范（第3版）》的“§8.4.2 Method Signature”章节中分别定义了字节码层面的方法特征签名，以及Java代码层面的方法特征签名，特征签名最重要的任务就是作为方法独一无二且不可重复的ID，在Java代码中的方法特征签名只包括了方法名称、参数顺序及参数类型，而在字节码中的特征签名还包括方法返回值及受查异常表，本书中如果指的是字节码层面的方法签名，笔者会加入限定语进行说明，也请读者根据上下文语境注意区分。

[4]JDK 1.5对虚拟机规范修改：http://jcp.org/aboutJava/communityprocess/maintenance/jsr 924/index.html。

10.3.2　自动装箱、拆箱与遍历循环

从纯技术的角度来讲，自动装箱、自动拆箱与遍历循环（Foreach循环）这些语法糖，无论是实现上还是思想上都不能和上文介绍的泛型相比，两者的难度和深度都有很大差距。专门拿出一节来讲解它们只有一个理由：毫无疑问，它们是Java语言里使用得最多的语法糖。我们通过代码清单10-6和代码清单10-7中所示的代码来看看这些语法糖在编译后会发生什么样的变化。

代码清单10-6　自动装箱、拆箱与遍历循环

public static void main（String[]args）{
List＜Integer>list=Arrays.asList（1，2，3，4）；
//如果在JDK 1.7中，还有另外一颗语法糖[1]
//能让上面这句代码进一步简写成List＜Integer>list=[1，2，3，4]；
int sum=0；
for（int i：list）{
sum+=i；
}
System.out.println（sum）；
}

代码清单10-7　自动装箱、拆箱与遍历循环编译之后

public static void main（String[]args）{
List list=Arrays.asList（new Integer[]{
Integer.valueOf（1），
Integer.valueOf（2），
Integer.valueOf（3），
Integer.valueOf（4）}）；
int sum=0；
for（Iterator localIterator=list.iterator()；localIterator.hasNext()；）{
int i=（（Integer）localIterator.next()）.intValue()；
sum+=i；
}
System.out.println（sum）；
}

代码清单10-6中一共包含了泛型、自动装箱、自动拆箱、遍历循环与变长参数5种语法糖，代码清单10-7则展示了它们在编译后的变化。泛型就不必说了，自动装箱、拆箱在编译之后被转化成了对应的包装和还原方法，如本例中的Integer.valueOf()与Integer.intValue()方法，而遍历循环则把代码还原成了迭代器的实现，这也是为何遍历循环需要被遍历的类实现Iterable接口的原因。最后再看看变长参数，它在调用的时候变成了一个数组类型的参数，在变长参数出现之前，程序员就是使用数组来完成类似功能的。

这些语法糖虽然看起来很简单，但也不见得就没有任何值得我们注意的地方，代码清单10-8演示了自动装箱的一些错误用法。

代码清单10-8　自动装箱的陷阱

public static void main（String[]args）{
Integer a=1；
Integer b=2；
Integer c=3；
Integer d=3；
Integer e=321；
Integer f=321；
Long g=3L；
System.out.println（c==d）；
System.out.println（e==f）；
System.out.println（c==（a+b））；
System.out.println（c.equals（a+b））；
System.out.println（g==（a+b））；
System.out.println（g.equals（a+b））；
}

阅读完代码清单10-8，读者不妨思考两个问题：一是这6句打印语句的输出是什么？二是这6句打印语句中，解除语法糖后参数会是什么样子？这两个问题的答案可以很容易试验出来，笔者就暂且略去答案，希望读者自己上机实践一下。无论读者的回答是否正确，鉴于包装类的“==”运算在不遇到算术运算的情况下不会自动拆箱，以及它们equals()方法不处理数据转型的关系，笔者建议在实际编码中尽量避免这样使用自动装箱与拆箱。

[1]在本章完稿之后，此语法糖随着Project Coin一起被划分到JDK 1.8中了，在JDK 1.7里不会包括。

10.3.3　条件编译

许多程序设计语言都提供了条件编译的途径，如C、C++中使用预处理器指示符（#ifdef）来完成条件编译。C、C++的预处理器最初的任务是解决编译时的代码依赖关系（如非常常用的#include预处理命令），而在Java语言之中并没有使用预处理器，因为Java语言天然的编译方式（编译器并非一个个地编译Java文件，而是将所有编译单元的语法树顶级节点输入到待处理列表后再进行编译，因此各个文件之间能够互相提供符号信息）无须使用预处理器。那Java语言是否有办法实现条件编译呢？

Java语言当然也可以进行条件编译，方法就是使用条件为常量的if语句。如代码清单10-9所示，此代码中的if语句不同于其他Java代码，它在编译阶段就会被“运行”，生成的字节码之中只包括“System.out.println（"block 1"）；”一条语句，并不会包含if语句及另外一个分子中的“System.out.println（"block 2"）；”

代码清单10-9　Java语言的条件编译

public static void main（String[]args）{
if（true）{
System.out.println（"block 1"）；
}else{
System.out.println（"block 2"）；
}
}

上述代码编译后Class文件的反编译结果：

public static void main（String[]args）{
System.out.println（"block 1"）；
}

只能使用条件为常量的if语句才能达到上述效果，如果使用常量与其他带有条件判断能力的语句搭配，则可能在控制流分析中提示错误，被拒绝编译，如代码清单10-10所示的代码就会被编译器拒绝编译。

代码清单10-10　不能使用其他条件语句来完成条件编译

public static void main（String[]args）{
//编译器将会提示“Unreachable code”
while（false）{
System.out.println（""）；
}
}

Java语言中条件编译的实现，也是Java语言的一颗语法糖，根据布尔常量值的真假，编译器将会把分支中不成立的代码块消除掉，这一工作将在编译器解除语法糖阶段（com.sun.tools.javac.comp.Lower类中）完成。由于这种条件编译的实现方式使用了if语句，所以它必须遵循最基本的Java语法，只能写在方法体内部，因此它只能实现语句基本块（Block）级别的条件编译，而没有办法实现根据条件调整整个Java类的结构。

除了本节中介绍的泛型、自动装箱、自动拆箱、遍历循环、变长参数和条件编译之外，Java语言还有不少其他的语法糖，如内部类、枚举类、断言语句、对枚举和字符串（在JDK 1.7中支持）的switch支持、try语句中定义和关闭资源（在JDK 1.7中支持）等，读者可以通过跟踪Javac源码、反编译Class文件等方式了解它们的本质实现，囿于篇幅，笔者就不再一一介绍了。