Let's Swing Java

今天是我在Sun的最后一天，这个博客也就要关闭了。目前还没有找到合适的博客网站，先把博客移回http://blog.sina.com.cn/swingjava。如果有了新的博客地址，我会在那上面通知大家。

谢谢大家一直以来的关注！

After working in Sun for more than three years, I decided to move on to pursue other career opportunities. I've handed in my resignation and will be leaving Sun on Jan. 11th, 2008. I've spent the past 3 years in Sun ERI working as a Java SE engineer on Java security and networking, and it's been a wonderful time.

Thank you Sun. Thank you ERI. It is always sad to say goodbye. But every story has an ending as well as an beginning. I'll miss you all.

-William Chen

Native toolkits including SWT and AWT do not support Look And Feel mechanism. They bind their components to operating systems, which have both pros and cons. One of the cons is that they cannot support pluggable Look And Feel. Handling the drawing process to operating system deprives of their ability to customize component look and feel. This prevent them from providing Look And Feel mechanism. Look And Feel mechanism is becoming more and more indispensable in GUI toolkit ...

To conclude the article, I'll give a list of pros & cons for each of them from a technical perspective.

AWT

AWT is a deprecated toolkit by Sun. However, it does has advantage. In many areas other than desktop environment such as mobile or embedded device, AWT has many advantages ...

最近忙着准备一个technical forum presentation，在公司内部举行的。由于很久就答应我们经理做一个这样的TOI的，因此一直在忙着准备一个关于Java GUI方面的技术演讲，所以博客不经常更新了。最近对swing_designer也在做着重构，也发现使用OSGi真的很不错，但是原来的项目修改的地方很多，只能慢了下来。另外月末我们经理来中国看望我们，也得思考思考如何汇报一下目前中国Java市场的状况。希望她能把我们的声音传给Sun的上层，为Java在中国的传播做一点自己力所能及的贡献...

和一个朋友聊天时谈到了OSGi，突然觉得swing_designer这个项目是最适合用OSGi模式开发的。这个项目里存在很多适合component和service的模型，因此打算把这个项目改造成OSGi架构的。今天仔细阅读了一遍OSGi R4的规范，发现其DS是比较适合这个项目的。由于之前在设计这个系统时就有意的做好了各种分割，接口设计的也比较合理，粗略估计了一下，代码修改改不会太多。重构好了之后的swing_designer应该是一个能使用OSGi插件机制方便的扩充平台，不仅仅能扩充自定义组件，还能扩充自定义布局管理器、自定义border、自定义属性编辑器等。

其实OSGi的确是一个不错的技术标准，希望Sun能给OSGi在Java更高的地位。一直以来人们都认为OSGi和Sun的对立，就像Eclipse同NetBeans的对立一样尖锐。但根据我所了解的情况，Sun并没有敌视OSGi，只是对于在Java中纳入OSGi的态度过于谨慎。我觉得Sun肯定是要最后完全纳入OSGi的，问题就是速度问题。Sun在JSR 277和JSR 291的意思应该解释为，不赞同在JVM一个级别支持OSGi，但愿意在更高应用层支持OSGi。在Sun看来，JSR 277存在层次比OSGi更低，它可以为JSR 291所提的OSGi标准提供更好的支持。而在更低层次支持OSGi一方面存在技术上的原因，另一方面会忽略了其他技术的支持。总之一句话，JSR 277和JSR 291不存在像OSGi拥护者想像的那种激烈竞争关系，而是相辅相成的关系，他们存在于不同的层面，JSR 277为OSGi的实现提供底层支持。这一点就连JSR 291的专家组组长也是这么认为的。当然我希望JSR 277和JSR 291能够更好的沟通，避免不必要的重叠和竞争设计。

关于JSR 277和OSGi之争，我觉得最好搁置，求同存异，毕竟将OSGi这种高层标准放到JVM层来实现的确不合适。希望这两个JSR能较好的处理好两者的关系，不要让他们形成竞争关系，而应该使他们成为合作关系。

这两天回家了，参加了舅舅的葬礼。回来看到这么多网友的留言，让我很感动，谢谢大家的关心！

舅舅得的是胃癌，治疗了三年，前不久恶化，对他是一种痛苦的折磨。现在终于解脱了，对他来说或许更好。只是我们这些亲人们都不免要难过。

人都免不了那天。如果真的有死后境界，难说会怎么看待自己的一生。想起了《倚天屠龙记》中小张无忌引用《庄子》的那几句话：生死修短，岂能强求？予恶乎知悦生之非惑邪？予恶乎知恶死之非弱丧而不知归者邪？予恶乎知夫死者不悔其始之蕲生乎？或许人生真的就是做大梦，而死去只不过是醒大觉。生亦何哀，死亦何苦。与其做这种重病缠身的痛苦噩梦，还不如早早醒来。

真希望舅舅就是这样醒来了，并后悔这恶梦实在做得太长了。

而我们仍然要继续各种各样的梦。