1. 其实没有受检异常(checked exception) JVM才不知道这类事情,只有Java语言才会知道。 今天,大家都赞同受检异常是个设计失误,一个Java语言中的设计失误。 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; 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周休假前的最后一个提交里,我写了这样的代码,然后。。。 【译注:然后,亲爱的同事你,就有得火救啦,哼,哼哼,哦哈哈哈哈~】 请找出上面用法合适的使用场景,还是留给你作为一个练习吧。 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);