1. 将I/O逻辑从RpcClient中抽取出来到RpcConnection中，得益于此，使得同一个client多次方法调用间可以使用不同的connection（连接池实现起来就更自然了）
2. 一些类名称做了修改，含义更清晰。SimpleSerializer重命名为JDKObjectSerializer，SimpleRpcServer重命名为BIORpcServer
3. JDKObjectSerializer的网络传输方式也增加了length field header，终于和其他Serializer的格式一致（NettyRpcServer/NettyRpcConnection也可以使用JDKObjectSerializer了）
4. 增加了Logger接口定义以及一些常用日志组件的LoggerAdapter，并且提供了日志组件自动检测机制（LoggerHolder类，检测顺序：slf4j–>commons-logging–>log4j–>java.util.Logger）

通过SocketChannel.socket().setSoTimeout(timeout)设置读超时，对于SocketChannel.read(buffer)操作来说是不会有任何效果的，如果SocketChannel设置了blocking mode的话会一致阻塞直到有可读取的内容或EOF。

有人就此给Sun提了个bug（http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4614802）， 但Sun不认为这是个bug：

Not a bug.  The read methods in SocketChannel (and DatagramChannel) do not
support timeouts.  If you need the timeout functionality then use the read
methods of the associated Socket (or DatagramSocket) object.

既然Sun不认为这是个bug只能自己使用的时候注意了（有人说起码是个Javadoc的bug， absolutely！）

这段时间在做PushServer时，需要对编码过的邮件标题及发信人进行解码，然而开发的时候发现Javamail无法对UTF-7等编码解码，会抛出UnsupportedEncodingException。查看过JDK中rt.jar的部分代码，也看过javamail的部分代码，总结原因如下：JDK本身并不支持UTF-7字符集。关于这个bug（传送门），很早之前就有人反馈过给SUN了，但SUN已经明确表示不会修复这个bug，所以要想支持UTF-7字符集就必须自己写对应的Charset。

当然，秉承不重复发明轮子的精神，如果有人已经提供了这样的类的话我们就没必要再自己重新实现了。确实已经有人做了这样的事，jcharset（传送门）这个项目已经提供了UTF-7、UTF-7-OPTIONAL等字符集的实现方式，只需要下载jcharset.jar并将其放到${JAVA_HOME}/jre/lib/ext/下即可（这是SUN JRE的一个bug），这样就已经可以对UTF-7编码的字符串进行解码了。需要注意的是jcharset项目是在GPL许可下发布的，若只是需要添加UTF-7字符集的支持的话，可以考虑jutf7项目（传送门），这个项目是在MIT许可下发布的，这样做2次开发之类的都方便。若需要自己添加其他字符集的支持，可以参考jcharset、jutf7等项目。