- 曾几何时在业务分层结构中的 VO 或 DTO 层充斥着无数的标准 JavaBean 类, 那些碍手脚的 getter/setter 方法简值不忍直视. 或许 JavaBean 设定规范的用意是当某些属性为只读时不提供 setter 方法, 而实际使用时, 因 getter/setter 都同时具备, 那么 JavaBean 的所有私有属性又何异于公有属性呢.
更别说对于某些形式的属性名, 若属性名为xCoordinate时, 它所对应的 getter 方法分别是getxCoordinate(),一般的 IDE 都会为它自动生成getXCoordinate()方法, 这是错误的. 实际上getXCoordinate()对应的属性名是XCoordinate.
所以 Play Framework 1 以及 Play Framework 2.4.6 之前的版本采用了字节码增强的技术, 实现了像 Objective-C 的 @property 的特性, 即只要声明公有属性, 编译器为该属性生成默认的 getter/setter 方法, 您也可以手工去覆盖个别默认的 getter/setter 方法.
因此在 Play Framework 中书写的的 model 类就只需要属性了, 像1public class User { 2 public int id; 3 public String name; 4 public String email; 5 public String address; 6}
就这么简单, 想像一下如果我们为一个众多属性的 model 类补全所有的 getter/setter 方法读起来有多恐怖. Read More 虽说 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