關於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
[  轉載請保留原文出處、譯者和譯文連接。]