关于Java你可能不知道的10件事

关于Java你可能不知道的10件事 

分享到： 24

本文由 ImportNew - Jerry Lee 翻译自 Jooq。欢迎加入翻译小组。转载请参见文章末尾的要求。

呃，你是否是写Java已经有些年头了？还依稀记得这些吧： 那些年，它还叫作Oak；那些年，OO仍是个热门话题；那些年，C++同窗们以为Java是没有出路的；那些年，Applet还风头正劲……

但我打赌下面的这些事中至少有一半你还不知道。这周咱们来聊聊这些会让你有些惊讶的Java内部的那些事儿吧。

1. 其实没有受检异常（checked exception）

是的！JVM才不知道这类事情，只有Java语言才会知道。

今天，你们都赞同受检异常是个设计失误，一个Java语言中的设计失误。正如 Bruce Eckel 在布拉格的GeeCON会议上演示的总结中说的， Java以后的其它语言都没有再涉及受检异常了，甚至Java 8的新式流API（Streams API）都再也不拥抱受检异常 （以lambda的方式使用IO和JDBC，这个API用起来仍是有些痛苦的。）

想证实JVM不理会受检异常？试试下面的这段代码：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

publicclassTest {       // 方法没有声明throws     publicstaticvoidmain(String[] args) {         doThrow(newSQLException());     }       staticvoiddoThrow(Exception e) {         Test.<RuntimeException> doThrow0(e);     }       @SuppressWarnings("unchecked")     static<EextendsException>     voiddoThrow0(Exception e)throwsE {         throw(E) e;     } }

不只能够编译经过，而且也抛出了SQLException，你甚至都不须要用上Lombok的@SneakyThrows。

更多细节，能够再看看这篇文章，或Stack Overflow上的这个问题。

2. 能够有只是返回类型不一样的重载方法

下面的代码不能编译，是吧？

1 2 3 4

classTest {     Object x() {return"abc"; }     String x() {return"123"; } }

是的！Java语言不容许一个类里有2个方法是『重载一致』的，而不会关心这2个方法的throws子句或返回类型实际是不一样的。

可是等一下！来看看Class.getMethod(String, Class...)方法的Javadoc：

注意，可能在一个类中会有多个匹配的方法，由于尽管Java语言禁止在一个类中多个方法签名相同只是返回类型不一样，可是JVM并不由止。 这让JVM能够更灵活地去实现各类语言特性。好比，能够用桥方法(bridge method)来实现方法的协变返回类型；桥方法和被重载的方法能够有相同的方法签名，但返回类型不一样。

嗯，这个说的通。实际上，当写了下面的代码时，就发生了这样的状况：

1 2 3 4 5 6 7 8

abstractclassParent<T> {     abstractT x(); }   classChildextendsParent<String> {     @Override     String x() {return"abc"; } }

查看一下Child类所生成的字节码：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

// Method descriptor #15 ()Ljava/lang/String; // Stack: 1, Locals: 1 java.lang.String x();   0 ldc <String"abc"> [16]   2 areturn     Line numbers:       [pc:0, line:7]     Local variable table:       [pc:0, pc:3] local:thisindex:0type: Child   // Method descriptor #18 ()Ljava/lang/Object; // Stack: 1, Locals: 1 bridge synthetic java.lang.Object x();   0 aload_0 [this]   1 invokevirtual Child.x() : java.lang.String [19]   4 areturn     Line numbers:       [pc:0, line:1]

在字节码中，T实际上就是Object类型。这很好理解。

合成的桥方法其实是由编译器生成的，由于在一些调用场景下，Parent.x()方法签名的返回类型指望是Object。 添加泛型而不生成这个桥方法，不可能作到二进制兼容。 因此，让JVM容许这个特性，能够愉快解决这个问题（实际上能够容许协变重载的方法包含有反作用的逻辑）。 聪明不？呵呵～

你是否是想要扎入语言规范和内核看看？能够在这里找到更多有意思的细节。

3. 全部这些写法都是二维数组！

1 2 3 4 5

classTest {     int[][] a()  {returnnewint[0][]; }     int[] b() [] {returnnewint[0][]; }     intc() [][] {returnnewint[0][]; } }

是的，这是真的。尽管你的人肉解析器不能立刻理解上面这些方法的返回类型，但都是同样的！下面的代码也相似：

1 2 3 4 5

classTest {     int[][] a = {{}};     int[] b[] = {{}};     intc[][] = {{}}; }

是否是以为这个很2B？想象一下在上面的代码中使用JSR-308/Java 8的类型注解。 语法糖的数目要爆炸了吧！

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

@Target(ElementType.TYPE_USE) @interfaceCrazy {}   classTest {     @Crazyint[][]  a1 = {{}};     int@Crazy[][] a2 = {{}};     int[]@Crazy[] a3 = {{}};       @Crazyint[] b1[]  = {{}};     int@Crazy[] b2[] = {{}};     int[] b3@Crazy[] = {{}};       @Crazyintc1[][]  = {{}};     intc2@Crazy[][] = {{}};     intc3[]@Crazy[] = {{}}; }

类型注解。这个设计引入的诡异在程度上仅仅被它解决问题的能力超过。

或换句话说：

在我4周休假前的最后一个提交里，我写了这样的代码，而后。。。

【译注：而后，亲爱的同事你，就有得火救啦，哼，哼哼，哦哈哈哈哈～】

请找出上面用法合适的使用场景，仍是留给你做为一个练习吧。

4. 你没有掌握条件表达式

呃，你认为本身知道何时该使用条件表达式？面对现实吧，你还不知道。大部分人会下面的2个代码段是等价的：

1	Object o1 =true?newInteger(1) :newDouble(2.0);

等同于：

1 2 3 4 5 6

Object o2;   if(true)     o2 =newInteger(1); else     o2 =newDouble(2.0);

让你失望了。来作个简单的测试吧：

1 2	System.out.println(o1); System.out.println(o2);

打印结果是：

1 2

1.0 1

哦！若是『须要』，条件运算符会作数值类型的类型提高，这个『须要』有很是很是很是强的引号。由于，你以为下面的程序会抛出NullPointerException吗？

1 2 3 4 5 6

Integer i =newInteger(1); if(i.equals(1))     i =null; Double d =newDouble(2.0); Object o =true? i : d;// NullPointerException! System.out.println(o);

关于这一条的更多的信息能够在这里找到。

5. 你没有掌握复合赋值运算符

是否是以为不服？来看看下面的2行代码：

1 2	i += j; i = i + j;

直觉上认为，2行代码是等价的，对吧？但结果即不是！JLS（Java语言规范）指出：

复合赋值运算符表达式 E1 op= E2 等价于 E1 = (T)((E1) op (E2)) 其中T是E1的类型，但E1只会被求值一次。

这个作法太漂亮了，请容许我引用Peter Lawrey在Stack Overflow上的回答：

使用*=或/=做为例子能够方便说明其中的转型问题：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

byteb =10; b *=5.7; System.out.println(b);// prints 57   byteb =100; b /=2.5; System.out.println(b);// prints 40   charch ='0'; ch *=1.1; System.out.println(ch);// prints '4'   charch ='A'; ch *=1.5; System.out.println(ch);// prints 'a'

为何这个真是太有用了？若是我要在代码中，就地对字符作转型和乘法。而后，你懂的……

6. 随机Integer

这条实际上是一个迷题，先不要看解答。看看你能不能本身找出解法。运行下面的代码：

1 2 3

for(inti =0; i <10; i++) {   System.out.println((Integer) i); }

…… 而后要获得相似下面的输出（每次输出是随机结果）：

92
221
45
48
236
183
39
193
33
84

这怎么可能？！

.

.

.

.

.

.

. 我要剧透了…… 解答走起……

.

.

.

.

.

.

好吧，解答在这里(http://blog.jooq.org/2013/10/17/add-some-entropy-to-your-jvm/)， 和用反射覆盖JDK的Integer缓存，而后使用自动打包解包（auto-boxing/auto-unboxing）有关。 同窗们请勿模仿！或换句话说，想一想会有这样的情况，再说一次：

在我4周休假前的最后一个提交里，我写了这样的代码，而后。。。

【译注：而后，亲爱的同事你，就有得火救啦，哼，哼哼，哦哈哈哈哈～】

7. GOTO

这条是个人最爱。Java是有GOTO的！打上这行代码：

1	intgoto=1;

结果是：

1 2 3

Test.java:44: error: <identifier> expected     intgoto=1;         ^

这是由于goto是个还未使用的关键字，保留了为之后能够用……

但这不是我要说的让你兴奋的内容。让你兴奋的是，你是能够用break、continue和有标签的代码块来实现goto的：

向前跳：

1 2 3 4 5

label: {   // do stuff   if(check)breaklabel;   // do more stuff }

对应的字节码是：

1 2 3

2 iload_1 [check] 3 ifeq6         // 向前跳 6 ..

向后跳：

1 2 3 4 5 6

label:do{   // do stuff   if(check)continuelabel;   // do more stuff   breaklabel; }while(true);

对应的字节码是：

1 2 3 4

2 iload_1 [check] 3 ifeq9 6 goto2         // 向后跳 9 ..

8. Java是有类型别名的

在别的语言中（好比，Ceylon）， 能够方便地定义类型别名：

1	interfacePeople => Set<Person>;

这样定义的People能够和Set<Person>互换地使用：

1 2 3

People?      p1 =null; Set<Person>? p2 = p1; People?      p3 = p2;

在Java中不能在顶级（top level）定义类型别名。但能够在类级别、或方法级别定义。 若是对Integer、Long这样名字不满意，想更短的名字：I和L。很简单：

1 2 3 4 5 6 7 8

classTest<IextendsInteger> {     <LextendsLong>voidx(I i, L l) {         System.out.println(             i.intValue() +", "+             l.longValue()         );     } }

上面的代码中，在Test类级别中I是Integer的『别名』，在x方法级别，L是Long的『别名』。能够这样来调用这个方法：

1	newTest().x(1, 2L);

固然这个用法不严谨。在例子中，Integer、Long都是final类型，结果I和L 效果上是个别名 （大部分状况下是。赋值兼容性只是单向的）。若是用非final类型（好比，Object），仍是要使用原来的泛型参数类型。

玩够了这些恶心的小把戏。如今要上干货了！

9. 有些类型的关系是不肯定的

好，这条会很稀奇古怪，你先来杯咖啡，再集中精神来看。看看下面的2个类型：

1 2 3 4 5

// 一个辅助类。也能够直接使用List interfaceType<T> {}   classCimplementsType<Type<?superC>> {} classD<P>implementsType<Type<?superD<D<P>>>> {}

类型C和D是啥意思呢？

这2个类型声明中包含了递归，和java.lang.Enum的声明相似 （但有微妙的不一样）：

1	publicabstractclassEnum<EextendsEnum<E>> { ... }

有了上面的类型声明，一个实际的enum实现只是语法糖：

1 2 3 4 5

// 这样的声明 enumMyEnum {}   // 实际只是下面写法的语法糖： classMyEnumextendsEnum<MyEnum> { ... }

记住上面的这点后，回到咱们的2个类型声明上。下面的代码能够编译经过吗？

1 2 3 4

classTest {     Type<?superC> c =newC();     Type<?superD<Byte>> d =newD<Byte>(); }

很难的问题，Ross Tate回答过这个问题。答案其实是不肯定的：

1 2 3 4 5 6

C是Type<?superC>的子类吗？   步骤0) C <?: Type<?superC> 步骤1) Type<Type<?superC>> <?: Type （继承） 步骤2) C （检查通配符 ?superC） 步骤 . . . （进入死循环）

而后：

1 2 3 4 5 6 7 8

D是Type<?superD<Byte>>的子类吗？   步骤0) D<Byte> <?: Type<?superC<Byte>> 步骤1) Type<Type<?superD<D<Byte>>>> <?: Type<?superD<Byte>> 步骤2) D<Byte> <?: Type<?superD<D<Byte>>> 步骤3) List<List<?superC<C>>> <?: List<?superC<C>> 步骤4) D<D<Byte>> <?: Type<?superD<D<Byte>>> 步骤 . . . （进入永远的展开中）

试着在你的Eclipse中编译上面的代码，会Crash！（别担忧，我已经提交了一个Bug。）

咱们继续深挖下去……

在Java中有些类型的关系是不肯定的！

若是你有兴趣知道更多古怪Java行为的细节，能够读一下Ross Tate的论文『驯服Java类型系统的通配符』 （由Ross Tate、Alan Leung和Sorin Lerner合著），或者也能够看看咱们在子类型多态和泛型多态的关联方面的思索。

10. 类型交集（Type intersections）

Java有个很古怪的特性叫类型交集。你能够声明一个（泛型）类型，这个类型是2个类型的交集。好比：

1 2	classTest<TextendsSerializable & Cloneable> { }

绑定到类Test的实例上的泛型类型参数T必须同时实现Serializable和Cloneable。好比，String不能作绑定，但Date能够：

1 2 3 4 5

// 编译不经过！ Test<String> s =null;   // 编译经过 Test<Date> d =null;

Java 8保留了这个特性，你能够转型成临时的类型交集。这有什么用？ 几乎没有一点用，但若是你想强转一个lambda表达式成这样的一个类型，就没有其它的方法了。 假定你在方法上有了这个蛋疼的类型限制：

1	<TextendsRunnable & Serializable>voidexecute(T t) {}

你想一个Runnable同时也是个Serializable，这样你可能在另外的地方执行它并经过网络发送它。lambda和序列化都有点古怪。

lambda是能够序列化的：

若是lambda表达式的目标类型和它捕获的参数（captured arguments）是能够序列化的，则这个lambda表达式是可序列化的。

但即便知足这个条件，lambda表达式并无自动实现Serializable这个标记接口（marker interface）。 为了强制成为这个类型，就必须使用转型。但若是只转型成Serializable …

1	execute((Serializable) (() -> {}));

… 则这个lambda表达式再也不是一个Runnable。

呃……

So……

同时转型成2个类型：

1	execute((Runnable & Serializable) (() -> {}));

结论

通常我只对SQL会说这样的话，可是时候用下面的话来结束这篇文章了：

Java中包含的诡异在程度上仅仅被它解决问题的能力超过。

 
原文连接：  Jooq 翻译：  ImportNew.com -  Jerry Lee
译文连接：  http://www.importnew.com/13859.html
[  转载请保留原文出处、译者和译文连接。]