1. 类型转换

1
2
3
4
5

object AsnLoader {
  ...
  def batchLoadFile(files: List[String]): Map[String, AsnModule] = files.foldLeft(Map[String, AsnModule]())((x, y) => x ++ load(y))
  ...
}

这里的List是Scala里的类，从Java里面调这个方法是不行的，所以需要弄一个wrapper方法：

1
2
3

import collection.JavaConversions._
...
def batchLoadFile(files: java.util.List[String]): java.util.Map[String, AsnModule] = batchLoadFile(asScalaBuffer(files).toList)

虽然asScalaBuffer本身就是个implicit，但是这里仍需要显示调用一下，否则编译器会认为batchLoadFile(file: java.util.List[String])更符合调用匹配规则，结果就变成了无限递归……

Java里面这样调用：

1

AsnLoader.batchLoadFile(list);

这样看起来解决问题了，但是Eclipse的Scala插件会报一个莫名其妙的函数签名错误，其实根本就没错，直接maven或者用Intellij都是对的，Eclipse插件太烂或者太老。无奈只好把函数名也一起改了：batchLoadFileJ，这样就可以了。如果还不是很明白，去看看JavaConversions里面的implicit。

把Java的Map转换成Scala的immutale map稍微曲折了些，先转换成mutable map，再调用toMap方法转换成immutable map。

2. 构造方法

1
2
3
4
5

class DefaultTransformer(private val asnModule: AsnModule, private val dependencies: Map[String, AsnModule] = Map.empty,
                         private val repository: Map[String, AsnModule] = Map.empty,
                         private val messageHandler: MessageHandler = ConsoleMessageHandler(false)) {
  ...
}

这里面的Map都是Scala的Map，所以从Java里不能直接调用，而Scala的构造方法又比较特别，重载的话只能减少参数个数而不能改变类型。这时候就需要companion object上场了。

1
2
3
4
5
6

object DefaultTransformer {
  def apply(asnModule: AsnModule,
                 dependencies: java.util.Map[String, AsnModule],
                 repository: java.util.Map[String, AsnModule],
                 messageHandler: MessageHandler) = new DefaultTransformer(asnModule, dependencies, repository, messageHandler)
}

Java这样调用：

1

Transformer transformer = DefaultTransformer.apply(...);

3. Scala的bug

嗯，XML在什么语言里都是让人恶心的东西，即使Scala已经尽力做好了：https://issues.scala-lang.org/browse/SI-4865。

jrubyc可以把一个Ruby的class编译成Java的，看看下面的例子：

Bar.java

1
2
3
4
5

package com.honnix.foo;
 
interface Bar {
    int getValue();
}

BarImpl.rb

1
2
3
4
5
6
7
8
9
10
11

java_package 'com.honnix.foo'
require 'java'
 
class BarImpl
  include Java::com.honnix.foo.Bar
 
  java_signature 'int getValue()'
    def get()
      1
    end
end

> javac Bar.java
> jrubyc --javac -cp com.honnix.foo BarImpl.rb

这样基本上就差不多了。

不过看看生产的Java代码，就知道这样玩儿的效率恐怕成问题。其实就是先build出来一个Ruby代码的巨大字符串，然后给交给Ruby引擎去跑，最后返回结果。

不管怎么说，只是这是一个方案，接下来就是要考虑怎么把Java的Document转成Ruby喜欢的格式，再转回来。

一个简单的例子：

1
2
3
4

private static <T> T test(T a) {
    Person<T> person = new Person<T>(a);
    return person.getName();
}

调用的时候这样：

1

test(1);

是不是认为编译器编译的时候会自动将T转换成Integer？我们来看看javap的结果：

1

invokestatic	#22; //Method test:(Ljava/lang/Object;)Ljava/lang/Object;

看到什么了？没有Integer，只有Object！

如果这样设计test()：

1
2
3
4

private static <T extends Number> T test(T a) {
    Person<T> person = new Person<T>(a);
    return person.getName();
}

结果就是：

1

invokestatic	#23; //Method test:(Ljava/lang/Number;)Ljava/lang/Number;

所以是不是可以得出结论，javac根本就不看调用的时候传入什么类型的东西，只看方法定义？

你完全可以这样写：

1
2
3
4

private static Object test(Object a) {
    Person<Object> person = new Person<Object>(a);
    return person.getName();
}

只是前者看上去比较牛逼罢了，其实效果完全相同。

到这里下：https://connect.apple.com/，右边找Dowloads->Java。

需要ADC，没有的话自己注册一个，也不花钱。

10.6 update 2之前是叫Developer Document，update 3之后就叫Developer Package了。找需要的下。装好之后在这里：/Library/Java/JavaVirtualMachines/<version>/Contents/Home。同样是src.jar和docs.jar，另外还有苹果自己的一个appledocs.jar。

说来惭愧，jfetion做了很久了，但是自己一直都没弄个什么应用出来，一直在用的smsd还是最早的时候用C写的。今天老婆出去逛街，闲来无事，用Scala重写了一遍，已经可以正常工作了，其它的功能慢慢加吧。

基本想法很简单，后台启一个daemon，监视某个文件夹，如果里面有.sms文件，就把里面的内容发送给相应的人，当然必须是飞信上面的好友。

顺便说一下，Snow Leopard的Java默认是64位的，而libfetion没有Mac上64位的版本，所以要么在系统设置里面更改Java的默认设置，要么运行的时候给个参数：java -d32 …

例如定义新异常类型。一般来说，自己定义的异常都属于checked异常，大都从Exception继承过来，所以也大都需要定义多个构造方法。如果用Java来定义，没什么好说的，重载就行，但是用Scala的话就有点麻烦。Scala规定所有重载的构造方法都必须调用或间接调用默认构造方法，所以必须使用如下的方法。

1
2
3
4
5

class MyException(message: String, cause: Throwable) extends Exception(message, cause) {
  def this(message: String): = this(message, null)
  def this(cause: Throwable): = this(null, cause)
  def this: = this(null, null)
}

当然，这样是可以工作的，但是仔细看看Throwable的实现就会发现如果传入的cause为null话会导致异常栈的丢失。而且最恶心的是Throwable没有提供相应的setter/getter，我们能做的就是调用构造方法。
所以我就想出了下面的怪招。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

object SpcException {
  def apply(message: String, cause: Throwable): Exception =
    (new SpcException1(message, cause)).asInstanceOf[Exception]
 
  def apply(message: String): Exception =
    (new SpcException2(message)).asInstanceOf[Exception]
 
  def apply(cause: Throwable): Exception =
    (new SpcException3(cause)).asInstanceOf[Exception]
 
  def apply(): Exception =
    (new SpcException4).asInstanceOf[Exception]
}
 
trait SpcException
 
class SpcException1(message: String, cause: Throwable)
    extends Exception(message, cause) with SpcException
 
class SpcException2(message: String)
    extends Exception(message) with SpcException
 
class SpcException3(cause: Throwable)
    extends Exception(cause) with SpcException
 
class SpcException4 extends Exception with SpcException

基本思想是定义一个trait，然后定义四种异常，每种都从该trait扩展并提供不同的默认构造方法，同时定义一个singleton，提供四种不同的apply方法用来构造四种不同的异常。这样就可以解决之前的问题，虽然不怎么好看。

现在在上班，晚上回去放上来。

首先是对几个Reachable作定义（其实是从Java Doc抄来的，翻得我实在不爽，直接看Java Doc吧） ：

1. Strongly Reachable──一个对象是strongly reachable的，当且仅当它能够被某个线程reach到而不需要通过任何的Reference Object
2. Weakly Reachable──一个对象是weakly reachable的，当且仅当它不是strongly reachable的，而且仅通过Soft Reference就可以被查找到
3. Phantom Reachable──一个对象是phantom reachable的，当且仅当它既不是strongly reachable的，也不是weakyly reachable的，它已经被finalized了，而且有一些Phantom Reference指向它

Phantom Reference：

• 如果在ReferenceQueue里面读到了一个Phantom Reference对象，说明该reference的referent已经被finalized了，如果它是finalizable的（这样的话需要两次GC才能在ReferenceQueue里面读到），否则一但referent成为phantom reachable的时候reference就被放入ReferenceQueue中。
• 实验表明，如果referent是finalizable的话，要经过两次GC之后才能在ReferenQueue里面读到Phantom Reference，第一次GC时，referent被finalized，但Phantom Reference不会被放到队列中。
• 如果new一个Phantom Reference的时候不传给它一个ReferenceQueue，那这个reference几乎没有任何用处，因为PhantomReference.get()永远返回null。
• 需要注意的是，GC不会调用PhantomReference.clear()，如果不对它显示地进行clear，那么它所引用到的对象就一直以finalized过的状态待在堆里而不被真正的回收，除非所有指向它的Phantom Reference都被clear了，或者它本身变为unreachable了。这一点和Weak Reference以及Soft Reference都不一样。
• Phantom Reference一般用来处理一些cleanup的事情：监视某个对象，如果它被finalized之后，释放资源。例如：一个大的图片对象被finalized之后，那么用来读取和处理它的其它一些资源就可以被释放掉了。

Weak Reference：

• 如果在ReferenceQueue里面读到了一个Weak Reference对象，并不能说明该reference的referent已经被finalized了
• 所有对象的finalization都由一个FinalizeQueue来处理，这个queue本身就是一个线程；当GC发现一个对象是Weakly Reachable的时候，就会把它的reference放到ReferenceQueue中，而把这个对象放到FinalizeQueue中；这两个动作的先后顺序我还不是很清楚，但似乎不是特别重要，这里只要知道由这么两件事情应该就足够了
• GC会主动调用WeakReference.clear()，这一点和Soft Reference相同。这样，即使没有ReferenceQueue我们也可以知道一个对象什么时候被GC发现成为weakly reachable，只要WeakReference.get() == null就可以了。
• Weak Reference一般用来实现一些容器，我们不需要对容器的引用显示地清理（container[i] = null）以防止内存泄露。比较有名就是JDK中的WeakHashMap，它的key是Weak Reference，当key成为weakly reachable的时候，key&value在就会被清除出去。这样一来，我们可以用map保存对象引用，以及它的一些附加信息，当这样对象不再是strongly reachable的时候，我们不必手工清理map，一切都交给GC去做了。

Soft Reference：

• Soft Reference和Weak Reference非常类似，只有一点最大的区别：当一个对象变成Soft Reachable状态的时候，它不一定被GC回收（或者说有很大可能不会被回收），具体行为由虚拟机实现决定，唯一能保证的是，在虚拟机抛出OutOfMemory异常之前，这个对象肯定已经被回收了。
• Soft Reference的这个特定使得它非常适合做cache，用Soft Reference引用一个大对象，这个对象在某些时候是strongly reachable的，而有些时候又不需要，那么由虚拟机来确定什么时候回收它吧，如果它被回收，那么SoftReference.get()出来的东西就是null，这时候只要再重新实例化一个对象就可以了。