Let's Swing Java

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

更根本的原因来自于界面设计工具的使用了Renderer技术，即界面设计工具使用现成的组件来渲染设计好的界面。而这些界面组件同IDE界面是位于同一个虚拟机内的，同一虚拟机内同一时刻只能有一个外观处于激活状态。因此这些组件的外观只能是该LnF下的外观，渲染出来的设计界面也就只能和宿主IDE一致。

有两种办法解决这个问题。第一种，设计界面所在的虚拟机和IDE运行环境的虚拟机不在同一个虚拟机，即全新启动一个虚拟机，并将该虚拟机内产生的界面图像通过IPC(比如Socket等机制）传输回给IDE的界面设计工具，并最后渲染出来。这样的缺点是内存消耗非常大，由于要在两个虚拟机之间频繁的传递缓冲图片，速度也是很慢。优点是可以使用独立干净的JVM作为设计结果界面的容器，可以独立设置外观等全局性的参数。另外如果宿主IDE是一个SWT程序，比如Eclipse，这种方式能够轻松解决SWT和Swing架构不兼容的问题，使得其能比较简单的实现Swing组件的绘制。采用这种方式的典型代表是VE。

第二种是设计界面组件和宿主IDE在同一个虚拟机内，但在渲染设计组件之前，将外观临时设置为所需的外观，然后调用SwingUtilities.updateComponentTree来改变设计组件树的外观，渲染完了之后，把老的外观在设置回去。以前版本的JBuilder的界面设计工具应该就是使用这种方式改变外观的。这种方式界面渲染速度快，控制简单。缺点是有些设计不好的LnF，会改变一些系统级别属性，而且无法恢复，这样会造成IDE的界面受到影响。

NetBeans没有使用上面两种，因此它并没有解决这个问题，而是不允许用户设定外观。如要设定外观需要用户自己在代码中添加。这就是为什么在设计时是Windows的外观，在运行时却是Metal的外观的原因。

Swing_Designer最近的修改添加了对于外观定制的支持。它采用第二种机制，目前只提供Windows、MetaLookAndFeel和JGoodies的Plastic3DLookAndFeel和PlasticXPLookAndFeel四种外观。下面是运行时截图：