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更為熟悉