Let's Swing Java

这几篇文章是我近期做的一个技术演讲的发言稿，共四篇。

Java GUI toolkits have always been a controversial topic. The same type of debates also happened in other languages such as Smalltalk. In fact there exist such debates on every platform-independent language. It is especially prominent in Java because Java is the most dominating language today...

[Read More]

The above comparison is mainly conducted in API level. Let's continue the comparison with focus on implementation details. In all the difference between Swing and SWT/AWT is that Swing is purely implemented in Java, while SWT and AWT is a mixture of Java and JNI. Of course, their target is same, to provide a cross-platform APIs. However to achieve this, SWT and AWT has to sacrifice some components and some features so that they can provide a universal APIs ... [Read More]

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 ...

[Read More]

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 ...

[Read More]

最近看了一个朋友的博客文章《打造专业外观-九宫图》，冒出个想法来：做一款能够可视化设计Swing LookAndFeel的工具...[Read More]

和一个朋友聊天时谈到了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能较好的处理好两者的关系，不要让他们形成竞争关系，而应该使他们成为合作关系。

上周末对Swing_Designer做了进一步的改动。这次的改动主要是添加功能，没做重构，另外还修改了一些bug。添加的功能包括...[Read More]

尽管NetBeans Matisse以其出色的功能和易用性赢得了许多开发者的青睐，但仍有许多人不满意。除生成代码不能方便修改外，还有个原因是设计时界面和运行时界面外观不一致。其实，这是有深层次原因的。在同一个虚拟机内，外观设置是全局性的，也就说如果要设定设计界面的外观，必然会影响整个IDE的外观。假设把设计的界面由Windows改换成Metal，那么整个IDE的界面也会变成Metal外观。 ...[Read More]

昨天本来打算写作GUI系统的绘图部分的，但搜刮了半天只写出了个提纲，绘了两张示意图片。真是觉得写一篇好的文章要比做一个大项目还要难。这是我们程序员固有的毛病，一肚子货却总是说不出来。延迟到今天还是觉得材料没有准备够，因此就说说swing_designer的最新情况吧...[Read More]

经常看到有人打听如何实现JTreeTable，即Swing的树表组件。今天又有朋友问这个问题。我抽时间在网上搜了一下，就找出很多实现方法来，其中 一个是来自Sun官方网站的解决方案。其基本思路使用JTree作为JTable中一列的TableCellRenderer和 TableCellEditor。这个方法简单实用，是个不错的实现方法。这篇文章在...[Read More]