java 移位运算的陷阱

起因：
源于在java.util.BitSet的源码中发现这样一条语句：
1L << bitIndex
当bitIndex为64时，上面语句的返回值为1，据此猜测java的移位运算使用的是循环移位规则，内容可以参考上一篇博客 "JDK源码 - BitSet的实现" http://robblog.iteye.com/admin/blogs/568845

上面的结论是错误的。先说说教科书上说的移位运算：

// 左移: 向左移动，右边补0
for (int i = 0;i < 8 ;i++)  
	System.out.print( (1 << i) + " ");
output
1 2 4 8 16 32 64 128 

// 右移: 向右移动，如果符号位(int型为32位)为0，左边补0，符号位为1，左边补1
// 符号位为1的右移
for (int i = 0;i < 8 ;i++)  
	System.out.print( Integer.toHexString(0x40000000 >> i) + " ");
output
40000000 20000000 10000000 8000000 4000000 2000000 1000000 800000 

// 符号位为1的右移
// 最高4位为1000， 右移1位，变成1100也就是c,
for (int i = 0;i < 8 ;i++)  
	System.out.print( Integer.toHexString(0x80000000 >> i) + " ");
output
80000000 c0000000 e0000000 f0000000 f8000000 fc000000 fe000000 ff000000

上面的通用法则没有错，但是有一个限制，对int型，移位的位数不超过32，对long型，移位的位数不超过64。现在进行如下测试:

System.out.println(Integer.toHexString(0x80000000 >> 31));
// output: ffffffff
System.out.println(Integer.toHexString(0x80000000 >> 32));
// output: 80000000

0x80000000在右移31位后，每个位都成了1（也就是-1），按照这个想法，右移32位理所当然的还是-1，可是右移32位后，得到的结果却又这个数本身。

通过对int，long类型数据左右移进行测试，发现：
java对移位运算"a <<||>> b"的处理，首先做 b mod 32||64运算， 如果a是int型，取mod 32，如果a是double型，取mod 64，然后再使用上面提到的通用移位运算规则进行移位。

到这里，就可以理解为什么在BitSet类中是
1L << bitIndex
这条语句，因为熟悉jdk的Programer知道，再写 1L << (bitIndex % 64) 对jdk来说是多余的。

处理的规则发现了，但仍然有个疑问：
- jdk为什么这样做? 虽然90%的程序员不会遇到这个问题。