程序员的职业素养真是完全不能相信的东西

事情要从一次面试说起，面试官问了这么一个问题，在JDK下面这个方法中：

public static > void sort(List list) 

这里面>有什么用？

美好的愿景

很明显，从语义上来说，sort方法要对一个List排序，这个List中的元素类型为T，sort方法要求这个T类型必须是可比较的。这个可比较的含义是说，任意两个T类型的对象，可以通过compareTo方法来确定大小。理想情况下，一个T类型实现了Comparable接口的话，那么对于任意两个属于T类型的对象x和y，都可以通过compareTo方法来确定大小。因此，方法写成如下形式即可。

public static  void sort(List list) 

Comparable接口的无奈

可是现实世界里，并不是T类型实现了Comparable接口就可以和T类型比较，而是T类型实现Comparable之后，可以和E比较。尽管T实现Comparable毫无道理可言，但是在语法上是正确的。
所以对于下面这个类，只能说代码写得烂，作者职业素养低，而编译器却无能为力，令人扼腕叹息。

public class Bar implements Comparable

Java泛型系统出来背一次锅

为了将这样的类拒之门外，sort方法写成下面这样岂不是很好？sort需要的T类型，是一个能和T类型比较的类型，真是天衣无缝啊。

public static > void sort(List list) 

但是有这样一种情况，假设有个类型S，S实现了Comparable，然后T继承了S，那么T就具备了和S比较的能力。但是这时T能通过编译么？答案是不能，因为在编译器看来，T只具备和S比较的能力，不具备和T比较的能力。尽管T是S的子类，但是编译器不认为如果一个类型具备了和S比较的能力，就具备了和T比较的能力。听上去感觉有点不合理，就好比经常有猎头问我：“好了，我现在知道你会用hadoop、spark这些来搞大数据了，那么请问你会Java么？”

这个就是Java泛型系统的一个坑特性——不具备协变、逆变的能力，所以尽管Integer是Number的子类，List却不是List子类，一个能比较Number的比较器也不能被当做一个Integer的比较器。

所以最终用>对T进行了约束，这样不管T的Comparable是自己实现的也好，还是继承的也好，都可以海纳百川有容乃大的被sort方法接受了。

美中不足

但是>约束能力还是不够强，因为它在语义上表示的是“T能够和super T的任何类型比较”，所以下面这个类还是可以编译通过的，除了你的同事会对你的编程水平和职业素养产生质疑。

public class Bar extends RuntimeException implements Comparable

就像equals和hashcode的代码契约一样，如果编译器在语法层面完全无法提供检查，只能靠程序员的职业素养来产生良好的代码，真是令人太不开心了。