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時代，心里特別添堵。

就這樣，一幫人商量著，又琢磨出個新思路：做適配。平臺有這個控件，就直接用，保證效率；沒有，再造輪子，保證可用。就這樣，swt問世。eclipse的gui就是基于此。
swt是贊，不過這屬于改良，兩個根本問題仍在：
1. 跟操作系統api打交道不是Java的長項，效率仍然不能與c++等相提并論。
2. 到底要不要跨平臺。如果要跨平臺，swt接瀏覽器控件、接ActiveX控件的功能就成了形同虛設；而要是不想跨平臺，又何必使用Java呢，.Net在一旁已經恭候多時了。

（補充：原生控件在各平臺下還是會有些差異，感謝@馮東指點） @馮東：另一方面，即使每個平臺都支持的 control 也多多少少有些差異。比如同樣是文本框，Windows 和 Mac (Cocoa) 對待 non-English 輸入法選詞的語義就不同。再比如對 focus-lost 的處理二者也不同。所以 SWT 其實目前很難做到 Swing 那樣的跨平臺。跨平臺么，終究還是只能做到最大公約數，比如 x86 支持 4 級，Unix 只用兩級。可那是大家都同意不用的。在 UI 級別可沒有人能同意不用操作系統的某個功能。

除了技術本身，還有一個產業的問題，圍繞著GUI控件也存在一個生態環境，沒有豐富的領域、行業控件的支持，技術本身的戰斗力也會大打折扣。而Java這方面的生態較為薄弱。

綜上，如果一個GUI程序使用Java，通常都是有這些特征：
確實是想跨平臺
對界面并沒有太多效果的要求，界面效率也不是瓶頸
相比于其他GUI工具，開發人員對Java更為熟悉

比如，一些工具的管理界面，很符合

總結

以上是生活随笔為你收集整理的为什么很多人说 Java 不适合编写桌面应用？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。