虽说 Java 的支持泛型以及近期 Lambda 表达式的加入, 在对类型进行推断上已经很强大了, 但在类型声明的时候仍然略显冗余, 最主要的一点是 Java 不能像 Scala 那样在声明变量有赋值的情况下进行类型推断. 我们先来看下 Java 已经为我们所进行的改进:
1List<String> strings = new ArrayList<String>(); //刚引入泛型时我们是这样 2List<String> strings = new ArrayList<>(); //后来变成这样了, 可以钻石符号推断, Java 7 3 4List<String> list = new ArrayList<>(); 5list.addAll(new ArrayList<>()); //根据 list.addAll() 上下文推断要创建的类型是 new ArrayList<String>(), Java 8 6 7interface Foo { 8 void dodo(); 9} 10Foo foo = () -> System.out.println("Foo:dodo()"); //Java 8 Lambda 可以根据 Lambda 表达式的签名推断出接口类型 11foo.dodo();在 Java 7 的泛型方法其实也是可以通过声明类型与方法参数来推断要返回的具体类型的. Read More
- 对于面向对象的语言不知道除了 Java 还有没别的语言会拿怎么比较两个字符串相等频频作为面试题来考. 原本是在编程语言中两个字符串内容是否相等时用
==比较时却可能是不对的. 在 Java 中1"ab" == "ab" //true 2"ab" == "new String("ab") //false 3"ab" == String.value("ab") //true 4new String("ab").equals(new String("ab")) //true 5new String("ab").intern() == new String("ab").intern() //true
在 Java 中明明看到两个字符串内容一样用==进行比较多数时候不是你想要的结果, 只有用equals()方法才是王道. 使用 Java 的字符串必须了解它内部是怎么存储的. 比于上面的结果我不作细说, 主要涉及到字符串常量池及内部状态,==比较引用,equals()比较内容.
Java 还常常对equals比较字符串津津乐道, 而我仍然认为它是语言设计上的一个缺陷, 所以 JVM 上的其他编程语言如 Groovy, Scala 纷纷倒勾, 无一不是用==来比较字符串的内容, 它们也提供字符串引用的比较, 但多少人实际关心两个字符串的引用是否相同呢, 反正字符串设计的是 Immutable 的.
若说是因为 Java 不支持操作符的重载, 但可以像 Scala, Groovy 那样在编译器上下功夫的. 最终我想依然是受累于 100% 源代码与二进制的兼容性, 改进的话会造成早先代码的行为错乱. Read More - Java 语言由于一直要保持源代码及二进制的向后兼容, 所以尽管语法上有了很大的演进, 但有些东西仍然无法触及. 不像有些新生代的语言设计时可以博采众长, 或者像 Scala 那种语言向后兼容性的要求没这么苛刻, Scala 只要保持主, 次版本相同时的兼容性. Java 则不同, 1.0 的代码或字节码放到 1.8 下还要能跑.
实际应用中在多个语言切换时, 很自然的会对其他语言与 Java 进行横向对比. 感觉 Java 语言有几个缺陷, 不在此篇中一一列举, 只把第一个不足之处道来.
Java 没有 Here Document 的支持, Here Document 又称 heredoc, hereis, here-string, here-script, 再通俗点讲就是多行字符串(multiline string). 在 Java 中如果要定义多行字符串, 需要连串的加号及换行符(\n), 如下1String content = "This is a\n" 2 + "multiline\n" 3 + "string content"
曾经为了寻求 Java 对 Here Document 的支持, 尝试过 Java 的 APT(Java Annotation Processing Tool), 定义注解 @HereDocument 使用注释, 编译时带-processor参数, 但是注释中的格式很容易被 IDE 给自动格式化掉, 见 Java 的多行字符串 Here Document 的实现. 所以这种尝试很快就放弃了, 因为项目中用 Java 和 Scala 混合编程, 真正需要 Here Document 的地方直接用 Scala 代码就行了. Read More - 在 Scala 和 Java 混合编程时免不了需要进行集合类型在两种语言间相互转换，更多的是在 Scala 调用 Java 的方法时把 Scala 的集合转型为 Java 的集合。典型场景是：
1public void process(java.util.List<String> orderIds) { 2 ...... 3}
上面定义的 Java 方法，如果要在 Scala 中调用它，不考虑两种语言的集体类型转换的话，可以直接传入 Java 代码要求的类型，像这样1val orderIds = new java.util.ArrayList[String] 2orderIds.add("SJ001") 3process(orderIds)
这样当然可以，但不能享受到 Scala 语言中集合使用的便利性，如快捷的构造，丰富的怪异的方法(++, ::, ## 等)。所以希望此时 Scala 中调用process()能接近这种方法1process(List("SJ001", "SJ002"))
特别是当 Java 接受一个 java.util.Map 时，能在 Scala 里直接传入Map("key1" -> "value1", "key2" -> "value2")就方便许多。
用方法来完成 Scala 和 Java 间对应集合类型的转换当然没问题，但别忘了 Scala 还支持隐式转换，那就是只要在 Scala 代码中引入 collection.JavaConversions._ 对于上面的方法在 Scala 中就可以直接传入 Scala 的 List() 了。也就是 Read More - Java 7 首次引入了 fork/join 框架，但一直未曾直接尝试. 而且基本上也很少在实际项目中直接写 fork-join 的代码，在我们使用第三方组件时倒是间接会接触到 fork/join 框架。譬如 Akka 的 fork-join-executor, sbt 执行测试用例时也是默认 fork/join 并发执行。fork-join 可以帮助我们把计算任务粒度细化，并更有效的利用多 CPU 内核。
fork-join 与 map-reduce 有些相妨，在 Java 7 时代我其实是忽视了它的存在。目今正在了解 Java 8 的 parallelStream 时，因为它的底层实现也是 fork/join, 所以有兴致去稍加体验一下。fork/join 的算法简单来讲就是递归对半去细化计算任务，及到不能细化时由多内核(线程)去计算被拆分的任务，最后反方向把结果汇总。
下面是从 《Java 8 IN ACTION》中截的一个说明 fork/join 的处理过程 Read More 初学 Java 的人很不经意间就会把常量定义在接口中，大概唯一的理由是接口不能实例化，而使用接口中定义的常量也是不用附着在实例上的。 这主要还是 JDK 本身给我们做了很多这样的榜样, 如 java.io.ObjectStreamConstans， 多是出现在 Enum 类型到来之前。
其实 Java 的接口常量是一种反模式，理由如下：
1. 接口是不能阻止被实现或继承的， 也就是说子接口或实现中是能够覆盖掉常量的定义(重名)，这样通过父，子接口(或实现) 去引用常量是可能不一致的
2. 同样的，由于被实现或继承，造成在继承树中可以用大量的接口, 类 或实例去引用 同一个常量，从而造成接口中定义的常量污染了命名空间。(Java 编译器竟然允许使用实例去引用类变量)
3. 接口暗含的意思是：它是需被实现的，代表着一种类型，它的公有成员是要被暴露的 API。而在接口中定义的常量说不上是 API4. 这点有些重复，Java 允许通过子类去引用父类中定义的常量，各级对像实例去引用父类的常量，所以这会造成相当的混乱不堪。定义的常量不能保证单一的引用方式。
参见： Effective java 第 19 条: 接口只用于定义类型
既然接口中不适于定义常量，那么该在何处为常量安家呢？接口为 实现/继承 而生，如果放在类中，并且这个类是 final，且封闭掉构造方法就行。 于是我们先前的接口常量定义 Read More
- 使用过 Java 反射的大多都知道, 想要修改某个类或对象的私有变量的值的话, 在调用 set 设置新值之前执行一下 setAccessible(true) 即可。这样利用的 Java 的反射就能绕过 private 的限制 ，不再有 IllegalAccessException 异常了。这是一个 trick, 调用 Java 的私有方法也能这么做，有些人或许或这样来测试 Java 私有方法。
提前说一句：在修改 final 型值时，要特别留意它的常量值本身是否被编译器优化内联到某处，否则你会看到虽然没什么异常，但取出的还是原来的值。后面会稍为深入的讲到。
例如下面是一段完整的代码, 由于调用了 setAccessiable(true), 所以能成功把 OneCity 的私有属性 name 的值改为 "Shenzhen"： Read More - 因为写过类似下面的一段代码来实始化一个匿名实例看上面的
1package cc.unmi; 2 3public class Test { 4 public String name; 5 6 public static Test buildTest(final String name) { 7 Test test = new Test(){{ 8 this.name = name; //希望把 buildTest() 方法参数中的 name 赋给 this.name 9 }}; 10 System.out.println(test.name); // 仍然是 null 11 return test; 12 } 13}buildTest()方法中的this.name = name希望能把方法参数 final String name 中的 name 值赋值给 this.name, 但是无效，this.name = name 是在把自己赋给自己。 Read More - 对于一个 Java 方法 foo(int id, String name); 我们如何能在代码中获得形式参数名 id 和 name 呢？
我们知道通过反射 APIMethod.getGenericParameterTypes()可以获得方法的参数类型，但是对于参数名一般就是 arg0, arg1, arg2 ..., 因为 Java 编译时把形式参数名擦除了。所以对完全擦除了形式参数名的字节码应该是没办法了，但我们自己写的类还是有能力去管控的。
对于自己写的类，有两种办法获得形式参数名，分别是
1) Java8 的 -parameters 编译参数，然后用 Java8 新引入的反射 API Parameter
我们先在 Java8 下运行下面的代码 Read More - Java 和 Scala 都支持变参方法, 写在最后的位置上，最基本的调用方式也都是一样的，一个个罗列过去。也可以传入数组参数，因为变参本质上就是一个数组，就是把 ... 开始位置到最后一个参数都收纳到数组中去，所以变参之所以要放在最后的位置上，且一个方法中最多只能有一个变参类型。
这里主要是对比 Scala 对变参方法的调用，基本调用法当然是没问题的，但是在传入数组作为变参的参数列表与 Java 相对时就稍有变化了。
另外提一下，如果想传入 List 作为变参列表，而不是整体作为变参的第一个元素就是调用集合的 toArray() 方法转换成一个数组传入。
下面看 Java 中对变参方法的调用，参数列表和数组1public class JavaVarArgs { 2 public static void main(String[] args) { 3 foo("a", "b", "c"); 4 foo(new String[]{"d", "e"}); 5 } 6 7 public static void foo(String...params) { 8 System.out.println(params + " : " + params.length); 9 for(String s: params) { 10 System.out.println(s); 11 } 12 } 13}
Read More