为什么很多人说 Java 不适合编写桌面应用

Java的桌面程序并不少，其中最为知名的莫过于Eclipse。在Linux和Mac下，Java程序的比例远高于Windows下。

不过，“Java不适合写桌面应用”的说法有一定道理，论调的主要背裂搭景是供Windows下使用的企业桌面应用的开发。由于一些历史和定位的原因，对于这种GUI程序的需求，Java的优势不明显，劣势比较明显。

这事还得从Java的传统，“跨平台一致性”说起。

在写后台逻辑的时候，跨平台是好东西。很多公司都是在Windows下开发，在Linux下部署，方便。

但涉及到GUI的时候，跨平台就成了个“看上去很美”的东西。理论上，我写个窗口，在Windows和Mac下都一样能用，那是多么美好的事啊。但实际上，每个平台提供的GUI控件多多少肆皮拿少有点差别，一坚持跨平台，麻烦就来了，该支持多少控件，怎么支持呢。

一开始，Java的思路是：那简单啊，有原生控件干嘛不用，至于不跨平台的，就不支持呗，又坚持了原则，又回避了问题。这一代的gui库，awt，就此诞生。

因为Java一开始是一根筋想推广Applet的，只是“顺便”也支持本地应用，设计成这样不能说不合适，毕竟，握扒HTML也是同样的思路，只支持几种最基本的控件。

但对于想开发复杂点界面的人来说，就有麻烦了。想来个目录树吧，对不起，不支持；想来个进度条吧，对不起，不支持。旁边放着Delphi和VB这么方便的东西，哥干吗受这气啊。

这样一来，Java自己也觉得说不过去了。但又要跨平台，又要提供丰富的控件支持，那就只有另起炉灶，开始用第二种思路：自己动手、丰衣足食，自己重写一套GUI控件，代替 *** 作系统的原生控件。这一代的gui库，叫做swing。

这也是一个想“彻底”解决问题的思路，但是要付出代价。

代价之一就是效率。我们可以参考一下另一个相同思路的产品——flash。为了实现矢量动画，在flash的那个小框里，图是一帧一帧地算出来的。接下来的事情我们都知道了：复杂的flash动画极耗cpu；iPhone说，您太耗电了，俺就不支持了；Adobe说，那好吧，那俺也不费心折腾移动版flash了。

自己画出来的控件毕竟不能跟原生控件比效率，尤其是在早期Java优化还不够完善的时候。而且，自力更生的目的只是为了平台兼容，不是为了更好的效果，这事儿其实怎么想怎么亏。

代价之二就是效果。自己画的控件毕竟只是模拟，还是会有细节差别。比如著名的毛玻璃效果，这不是简单套样式就能套出来的。

而且，各个平台控件的风格本来就不一样，虽然swing提供了几种外观，但大部分程序出于偷懒或是跨平台一致考虑，还是使用默认外观。默认外观跟平台不一致倒也不是问题，主要是别比平台效果土。我用着win7，一个程序非让我感觉回到xp时代，心里特别添堵。

其实也没有你想象得那么少，但是确实不如C/C++开发的软件多，感觉有几个原态拿因：

1、环帆伍搭境依赖问题，JAVA的软件要依赖JRE/JDK，无论在Windows还是Linux平台上基本都不是预装的，而且要命的是这玩意儿体积还比较大；

2、JAVA在桌面应用程序方面确实有点弱，而个人PC现在离不开桌面应用；

3、运行速橘悄度确实要略慢于native code的C/C++，当然也没慢得那么离谱，不过内存占用确实要大很多；

桌面程序的王者，当然首推微软系列了，毕竟WIndows系统在当今来讲普遍率还是很高的，自家的东西功能自由度还是很高的！

由于桌面程序都受系统平台限制，所以Java的出现就是为了抛离这种限制，尽管Java者后来也为这个Desktop很努力，但是要想达到另大多人满意的程度难度还是很高的。想想芹差册，在Windows系统中要封装Windows系列的API，在Linux系统中要封装Linux的相关API，仅仅有这些还不够，还要有一个便捷性的可视化编程界面才可以满足大部分开发者的要求......

再说，在数据库系统编程方面，还有另外一个至少在庆丛今后几年当中几乎不可超越的皇者：Delphi，所以JAVA要想在桌面程序进行超越，难度还嫌宏是很高的...

---