对Java很熟悉 但这四件事你未必知道

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

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

今天，大家都赞同受检异常是个设计失误，一个Java语言中的设计失误。正如 puce Eckel 在布拉格的GeeCON会议上演示的总结中说 的， Java之后的其它语言都没有再涉及受检异常了，甚至Java 8的新式流API（Streams API）都不再拥抱受检异常 （以lambda 的方式使用IO和JDBC，这个API用起来还是有些痛苦的。） 想证明JVM不理会受检异常？试试下面的这段代码：  

public class Test { 
 
    // 方法没有声明throws 
 
    public static void main(String[] args) { 
 
        doThrow(new SQLException()); 
 
    } 
 
    static void doThrow(Exception e) { 
 
        Test.<RuntimeException> doThrow0(e); 
 
    } 
 
    @SuppressWarnings("unchecked") 
 
    static <E extends Exception> 
 
    void doThrow0(Exception e) throws E { 
 
        throw (E) e; 
 
    } 
} 

不仅可以编译通过，并且也抛出了SQLException，你甚至都不需要用上Lombok的@SneakyThrows。 更多细节，可以再看看这篇文章，或Stack Overflow上的这个问题。  

2. 可以有只是返回类型不同的重载方法

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

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

是的！Java语言不允许一个类里有2个方法是『重载一致』的，而不会关心这2个方法的throws子句或返回类型实际是不同的。 但是等一下！来看看Class.getMethod(String, Class...)方法的Javadoc： 注意，可能在一个类中会有多个匹配的方法，因为尽管Java语言禁止在一个类中多个方法签名相同只是返回类型不同，但是JVM并不禁止。 这让JVM可以 更灵活地去实现各种语言特性。比如，可以用桥方法(pidge method)来实现方法的协变返回类型；桥方法和被重载的方法可以有相同的方法签名， 但返回类型不同。 嗯，这个说的通。实际上，当写了下面的代码时，就发生了这样的情况：  

abstract class Parent<T> { 
 
    abstract T x(); 
 
} 
 
class Child extends Parent<String> { 
 
    @Override 
 
    String x() { return "abc"; } 
 
} 

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

// 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: this index: 0 type: 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. 所有这些写法都是二维数组！

class Test { 
 
    int[][] a()  { return new int[0][]; } 
 
    int[] b() [] { return new int[0][]; } 
 
    int c() [][] { return new int[0][]; } 
 
} 

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

class Test { 
 
    int[][] a = {{}}; 
 
    int[] b[] = {{}}; 
 
    int c[][] = {{}}; 
 
} 

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

@Target(ElementType.TYPE_USE) 
 
@interface Crazy {} 
 
  
 
class Test { 
 
    @Crazy int[][]  a1 = {{}}; 
 
    int @Crazy [][] a2 = {{}}; 
 
    int[] @Crazy [] a3 = {{}}; 
 
  
 
    @Crazy int[] b1[]  = {{}}; 
 
    int @Crazy [] b2[] = {{}}; 
 
    int[] b3 @Crazy [] = {{}}; 
 
  
 
    @Crazy int c1[][]  = {{}}; 
 
    int c2 @Crazy [][] = {{}}; 
 
    int c3[] @Crazy [] = {{}}; 
 
} 

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

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

[[153751]]

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

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

 

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

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

Object o1 = true ? new Integer(1) : new Double(2.0); 

等同于：  

Object o2; 
if (true) 
    o2 = new Integer(1); 
else 
  o2 = new Double(2.0); 

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

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

打印结果是：  

1.0 
1 

哦！如果『需要』，条件运算符会做数值类型的类型提升，这个『需要』有非常非常非常强的引号。因为，你觉得下面的程序会抛出NullPointerException吗？  

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

关于这一条的更多的信息可以在这里找到。