深入理解Collections API

　　return -r1.hireDate().compareTo(r2.hireDate());

　　两种方法同样可取。使用哪一种，全由你自己。

　　以上程序中的 Comparator ，在对 List 进行排序时，效果很好。但有一个小的缺陷：它不能被用来对一个排序的 对象集 (如TreeSetM) 进行排序，因为它生成一个严格的部分（strictly partial） 排序。这意味着这个comparator 使不相等的对象相等。特别的，它会使任意两个雇用日期相同的雇员成为相等。当你为一个 List 排序时，这没关系，但当你使用 Comparator 为一个sort排序的对象集 排序时， 这就是致命的了。如果你将多个雇用日期相同的雇员用Comparator插入到一个TreeSet之中，那么只有第一个将被添加到 set，第二个将被作为一个复制元素而忽略。

　　为解决这个问题，你必须做的一切就是修整 Comparator 使之生成一个 total ordering（完整排序）。 换句话说，修整 Comparator 是为了使在使用compare 时被认为相等的唯一元素即是那些在使用equals 时被认为相等的元素。 实现这个目的的途径是做一个两部分（two-part）比较 (就象我们为 Name 做的那样)，这里的第一部分是我们真正感兴趣的（此案例中为雇用-日期），而第二部分是可唯一识别的对象属性。在此案例中，雇员号是作为第二部分使用的明显的属性。请看下面的 Comparator :

　　最后注意一点，你可能被引诱用更简单的程序来替代 Comparator 中最后的 return 语句:

　　return r1.employeeNumber() - r2.employeeNumber();

　　不要这样做，除非你能绝对保证不出现一个负的雇员数！这个技巧不可普遍使用，因为一个带正负号的整数类型，即使再大，也不足以表示两个任意的带正负号的整数的差值。如果 i 是一个大的正整数，j 是一个大的负整数，i-j 将溢出并返回一个负整数。 Comparator 的结果违反了我们一直在讲的四个技术限制之中的一个限制（传递性），并导致可怕而玄妙的故障。 这并不是一个纯技术问题；搞不好，它会伤着你。