Ken Wu's Blog

我们知道java的InetAddress会通过自身的cache缓存dns解析结果。
缓存的策略主要有两种，一种是缓存正确解析后的IP地址，还有一种是缓存解析失败后的状态。

这两种策略的时效配置都在 %JRE%\lib\security\java.security 这个文件里。
TTL=Time to Live

networkaddress.cache.ttl

缓存正常解析后的ip，如果在缓存时效内再次lookup时直接返回缓存结果。
缓存时间：

1，在启用 java security manager时，是永久缓存。(PS: jboss, tomcat等app server默认不启用 java security manager，资料见 这里)
2，不启用的话，默认是缓存30秒。
3，缓存时间 设为0的话，表示不缓存，设置-1表示永久缓存，正数表示缓存时间（秒）。

Read more…

ADAM BIEN这位老兄，最近在他的blog上发表了一篇关于“如何杀死一个OSGi项目”(How to kill a OSGi projcet)的主题，引来了无数口水。
说实话，我个人还是很赞同老兄的部分观点。 单从它提出的10个问题来看，有一半是大多数公司和开发人员正面临要解决的问题。
看来这位老兄，私下也是做了不少功课的，人猛才是王道。

参考他提出的10个问题，来看我们公司的使用情况，大致有三个方面被他说中了：

1，有状态的bundle想要做平滑热替换，需具备一定复杂性。
最近，一位公司同事正在实验某个带状态bundle的热替换工作，开发期间碰到了多处棘手的问题（实例状态的同步转移），幸好人牛，从他描述的实现逻辑来看，必然包含很复杂操作在里面。
可见有状态bundle的平滑热替换，很难简单实现。

2，当OSGi的bundle数量达到一定规模时，维护成本必将成为瓶颈。
这是一个趋势，值得庆幸的是，从我们公司项目的bundle数量来看，还未迈入“成年”。对策尚可暂缓考虑。

3，多个版本或相互依赖bundle间的测试必然会显著提高复杂性。
谁能推荐个好用的OSGi测试框架？

问题中还提到分发包的增量更新，RCP应用程序的暴露问题，貌似我们公司没用到。但看得出来，OSGi也不是万能的。成熟度还有待提高。。。要知道JDK7的jigsaw(JSR294 and 277)已在养精蓄锐了，从language, compiler, vm等底层入手做modularity的它，对OSGi造成的压力可不小啊。
希望将来有位猛男能够趟一趟这浑水，像我这样的迷茫者就可以随波逐流了。。。

在linux/unix下，你会怎么中止一个java进程？
你可能会回答 kill -9 pid，这是一种在多数情况下正确的做法。不过，这种方式过于暴力，如果用户对环境不熟悉，很容易造成致命的后果。
本文将分析kill -9产生问题的原因，并给出另一种标准的kill方式。

标准中断信号

在Linux信号机制中，存在多种进程中断信号（Linux信号列表）。其中比较典型的有 SIGNKILL（9） 和 SIGNTERM（15）.

SIGNKILL（9） 和 SIGNTERM（15） 的区别在于：
SIGNKILL（9） 的效果是立即杀死进程. 该信号不能被阻塞, 处理和忽略。
SIGNTERM（15） 的效果是正常退出进程，退出前可以被阻塞或回调处理。并且它是Linux缺省的程序中断信号。

由此可见，SIGNTERM（15） 才是理论上标准的kill进程信号。
那使用 SIGNKILL（9） 又有什么错呢？
Read more…

今早，发现了一个非常轻量级的xml解析生成工具。整个工具就2个类，一个XmlBuilder，一个XmlSlicer。
最重要的是，它是基于Fluent Interface设计的（连贯接口设计, 大大简化编码量)。

工具最大的特色如作者在主页上所说的一句话，Forget W3C, and terrible APIs。
下面是摘自官方的一个关于生成xml的例子:

Code

String xml = XmlBuilder.newXml("UTF-8", true)
    .openTag("xml").withAttribute("id", 1)
        .openTag("thisishow")
            .withValue("you can build")
        .closeTag()
        .openTag("your").withAttribute("xml", "nicely").toString(true);

项目主页：http://code.google.com/p/xmlzen/

在开源java工具包里，最有名的当属apache commons。其中，以commons lang包最为开发者熟知。
但是它作为第三方包存在，或多或少给开发者带来一些不便利。
面包牛奶总是会有的，从java7开始，lang包中的一些优秀工具方法，将被正式引入JDK。

下面是各个已确定被引入的工具类或方法说明。

1, 新增类 java.util.Objects (JDK对工具类的命名一向是以s结尾，例如Collections, Arrays)

A, 空指针安全的 equals, hashCode, toString, defaultNull 方法。
即入参传入NULL，工具方法不会抛空指针异常。
调用方法举例：
Boolean result = Objects.equals(obj1, obj2);

B, 比较对象的大小（需要实现Comparable）。
T Objects.max(T comparable1, T comparable2)
T Objects.min(T comparable1, T comparable2)
Read more…

在eclipse里，有个黄金快捷键组合 ctrl + shift + O，大家应该不陌生吧！
当你敲完类名后触发它，它会帮你自动完成import，很实用的一个快捷键。

在JDK1.5发布后，java里引入了一个新的语法，static import。
该语法的本意是，简化静态属性在调用时的代码量，提高可读性。

但在eclipse里，如果你不提供类名，直接敲你想要的静态成员名或方法名，eclipse是无从查找的。
于是有些人，可能就使用人肉输入 import static xxx。（我就是其中之一）

其实，为了解决这个问题，eclipse早就引入了静态类预设功能。该功能的入口是
Windows -> Preferences -> Java -> Editor -> Content Assist -> Favorites
只要设置包含静态成员或方法的类，在编码过程中，你就可以直接敲名字了（或使用 alt + / 补全）。

1，菱形语法（泛型实例化类型自动推断）

List<string> list = new ArrayList<>(); // 这个左右尖括号真的很像菱形</string>

2，在目前版本中，不可具体化的泛型（任意类型）可变参数，在编译时，会在调用处产生警告，JDK7里将这个警告挪到了方法定义处。

变化前：

static <t> List</t><t> asList(T... elements) { ... }
static List<callable <String>> stringFactories() {
    Callable<string> a, b, c;
    ...
     // 警告处
    return asList(a, b, c);
  }
</string></callable></t>

变化后：

// 警告处
static <t> List</t><t> asList(T... elements) { ... }
static List<callable <String>> stringFactories() {
    Callable<string> a, b, c;
    ...
    return asList(a, b, c);
  }
</string></callable></t>

Read more…