自從Java問世以來，在服務端開發方面取得了巨大的發展。但是在桌面/Web開發方面，一直沒有得到大的發展。從最初的AWT，到Swing，再到JavaFX，Java從來沒有在桌面/Web解決方案中取得重要席位，更別提占居主導地位了。
AWT
AWT(Abstract Window ToolKit，抽象窗口工具包)是SUN在1996年推出的UI框架。由於需要跨平台，所以AWT只能支持主流平台共有的界面組件和特性(交集），例如標簽、按鈕等，這就導致了AWT在組件豐富程度以及功能性等方面必然有欠缺。AWT通過創建一個與操作系統對應的Peer(對等組件)來實現組件在界面上的顯示，依靠操作系統本地方法實現圖形功能，屬於重量級的UI框架。也就是說，當我們使用AWT構建圖形界面時，實際上是調用操作系統圖形庫的功能，在不同的操作系統上有不同的表現。
AWT這種重型的UI框架，無論是歷史還是將來，都只會作為基礎設施，不會成為桌面應用的解決方案。
Swing
Swing是在AWT基礎上構建的UI框架，全部使用Java編寫。Swing提供了比AWT更輕量級、更豐富的UI組件，如樹、列表、表格等。AWT是基於操作系統本地方法，所以運行速度較快，Swing是基於AWT的Java程序，采用解釋方法執行。Swing繪制的界面在不同的操作系統上表現一致。雖然SUN推出Swing是希望解決AWT面臨的問題，然而並沒有。
國內很多開發人員對Swing頗有微詞，特別是.Net和基於JS的開發人員。即使Swing基於MVC優雅地對AWT進行輕量級封裝，但由於一直以來需要跨平台等問題，導致默認情況下Swing構造的應用界面巨丑無比——個人或一般的公司沒有能力也沒有必要實現復雜的LookAndFeel。同時，Swing一直存在易用性問題，沒有像Visual Studio這樣的IDE提供可視化支持，一個簡單的表格界面都需要手寫n多個類才能實現，實在是不勝其煩，特別是對於初學者來說更是如此。
國內很少使用原生Java來開發Web應用的，估計桌面應用都很少。但是Swing在國外還是有一定市場占有的，特別是一些大型的軟硬件公司，如IBM、Oracle等，他們的軟件跨平台特性是剛需，所以我們經常可以看到一些基於Swing實現的安裝程序、管理工具等等。
實際上，只要擁有一定的技術實力、願意付出足夠的資源和代價，Swing也可以做得很漂亮、易用性很好。比如說我們每天都要使用的Eclipse、IntelliJ IDEA，用友NC6，以及2BizBox ERP系統等。還有諸如s提供皮膚和UI組件的Substance、SwingX等第三方開源庫。
（上圖：IntelliJ IDEA)
（上圖：用友NC6)
（上圖：2BizBox ERP）
上述列舉的，是我見過的基於Swing實現的、效果比較炫酷的桌面應用和Web應用的代表。
相比於桌面應用，Swing在Web方面的應用效果印證了那句話：沒有最慘，只有更慘。要想讓Swing能夠在瀏覽器中運行，除了最基礎的JRE之外，還需要Applet作為Swing在瀏覽器中顯示的容器——Applet顯示在瀏覽器中，Swing顯示在Applet中。Applet能夠顯示在瀏覽器中，是基於Netscape公司當年提出的NPAPI(Netscape Plugin Application Programming Interface)技術，這家公司是最早實現瀏覽器商業化的，但早已經被巨硬公司用免費的IE給搞死了。讓我們永遠有免費的瀏覽器可以使用，這是微軟公司做過的好事之一，雖然它本意並非如此。
隨着時代的發展和技術的進步，人們對網絡安全的要求越來越高，對瀏覽器的安全性要求也越來越高。NPAPI這種十多年前的技術，已經明顯不能滿足如今的要求。Google Chrome已經連JRE都禁用了，這其中有沒有Oracle基於Java告Google侵權要求巨額賠償的因素就不得而知了；微軟公司也在IE中提升了對JRE的限制級別——以前還有“低”選項，如今是“較高”起步。
實際上，就我個人看來，當年Sun公司是有機會對Java的Web開發進行嘗試甚至試錯的——只要它願意。結果卻是Sun公司把Java一並賣給了Oracle。在IT硬件公司還沒有能夠把“賣服務”作為自己的利潤支撐時，像IBM、Sun這樣的公司，軟件是為硬件服務的，甚至可以買我的小型機送你軟件。
中肯一點說，基於Java的主流的MVC框架，其基本概念都和SWing有千絲萬縷的關系。如果作為企業內部網使用的管理型系統、網絡環境有保證、允許把一些前台UI類下載到客戶端（其實我認為這是優勢，應用的入口都是通過瀏覽器，以一點空間換取相對加快的UI響應速度，我認為還是非常值得的），使用Swing作為界面展現技術還是有優勢的。即使在廣域網環境中，如果能夠保證每客戶端與服務器之間有一定的帶寬、速率、安全性等前提條件，Swing也能夠有較好的表現。
Sun在發展Java桌面/Web能力方面一直心不在焉，也沒有實質性推動改進或重新制定Java與瀏覽器相關的協議和安全標准。反而是JavaScript、HTML5等腳本類語言伴隨着瀏覽器的發展，逐漸成為Web前端開發的主流。從AWT，到Swing，再到JavaFX，其提供的UI組件看上去都是為了解決“有沒有”的問題，並不沒有真正站在用戶，特別是企業級應用開發的角度上去考慮提供豐富、好用的組件，解決快速開發的問題。以最常見的表格為例，Swing要寫一堆代碼，如果不自己封裝，開箱即用、復用性幾乎為零。JavaFX應該說比較Swing有一些進步，但在數據類型、操作便利性方便，與企業級應用開發的基本要求仍相去甚遠，需要寫一堆的TableColumn，需要自己處理復雜數據類型等。再比如Swing的布局就過於技術化，易用性太差，擴展又太麻煩。界面越復雜，代碼的復雜越是呈非線性增長。
如上面幾個界面所示，Java在桌面開發方面，以Sun/Oracle的標准來講，恐怕是什么效果都能實現的，但從實際開發人員的角度來講，只有“狗帶”了。
既不注重協議和標准，又不注重易用性，讓我們這些不會寫JS的老程序員想起來就憤怒——寫了十多年的代碼了，突然發現自己不會寫界面。
從Java桌面/Web前端開發所處的尷尬地位，也能夠看出，前端真是不好搞。
UI端框架的技術實現並不比服務端更復雜，但服務端主要是基於標准的容器，跟CPU、內存、存儲、網絡等這些具有標准、規范的基礎設施打交道，而UI端的實現受制於操作系統，顯得規范性不足，各顯神通，所以就顯得更瑣碎、麻煩。有興趣的同學，可以自行看一下JLabel這種基礎Swing界面組件的實現代碼。給大家瞻仰一張相關的類圖：
只是一小部分主要的類和個別接口，這幾個類，源代碼超過5K行的也不少見。
SWT
SWT(Standard Widget Toolkit，標准窗口部件）是IBM推出的開源UI組件庫，希望解決AWT和Swing運用方面的問題。SWT的運用較廣泛，如Eclipse、WebSphere等安裝程序、MAT等。SWT提供了比Swing更豐富好用的界面組件以及特性，與AWT一樣，SWT通過Peer調用操作系統本地方法。同時，SWT通過使用特定操作系統的特性，加快UI組件響應時間，所以SWT需要為不同的操作系統准備安裝包，與AWT一樣，沒有Swing的LookAndFeel功能。來看一張IBM MAT的界面：
JavaFX
Sun在被Oracle收購前的2008年年底推出JavaFX 1.0，希望Java在RIA（RIch Internet Application）方面有所建樹。JavaFX 1.0是一種Script，個人感覺巨丑無比。Oracle在2011年與JDK8一起推出了基於原生Java重構的JavaFX2.0，放棄了原先采用JavaFX Script機制。在2014年，與JDK8一起發布了JavaFX8，從此JavaFX成為JDK的一部分。
關於JavaFX的詳細介紹以及特性，可以參考Oracle官網以及相關資料。之所以寫這些文章，並嘗試基於JavaFX開發一款應用框架，主要考慮到JavaFX和Swing、JavaScript相比，有以下優勢：
1、JavaFX與JDK已經結合在一起(特指從JDK1.8開始的JavaFX2.0)，JavaFX可以直接使用所有的Java資源，包括第三方類庫，這為開發提供了極大的便利——不再需要學習類似JS這類前台框架的語法和特性，從UI端到業務實現都使用Java，並且做到技術和經驗通用，能夠降低學習成本，開發人員也不必再分什么前后端，每個開發人員都可以具備從前做到后的基本技能。
2、有JRE就可以運行，有時候這是缺點，但在企業應用中應該是可以接受的。
3、提供比較豐富的基礎組件庫，如ListView、TableView、HTML編輯器等，能夠較便捷地設計UI基類和基本框架。
4、提供了較豐富、易用的布局器。如果沒有BorderPane（上下左右中布局）等特性，我們是不會使用JavaFX的。
5、提供了界面定義工具（Oracle Scene Builder），雖然還比較土，還沒有好意思提供Eclipse Plugin，但對我們來說已經基本夠用，況且我們也不會依賴Scene Builder來進行界面構建，而是使用基於Spring Bean實現的“模式+裝配”的方式實現界面構建。
6、支持使用CSS自定義界面風格，支持HTML5。
7、提供了較豐富的圖形組件。
8、原生打印支持。
9、便於實現Activiti流程圖定義、基於Excel的BI工具等對UI要求比較高的組件，這是我們比較想實現的基礎組件，在Swing上我們是不敢想象的，編碼工作量會十分巨大。
10、JavFX可以很方便地使用到Eclipse Plugin開發中，不需要進行額外的配置等工作，有利於開發基於Eclipse Plugin體系的可視化MDE開發工具。
使用JavaFX + Spring Bean裝配機制以利於實現UI模式化開發，是我們選擇JavaFX主要的情結。
當然，必須得忍受以下不便或問題：
1、客戶端必須安裝JRE。
2、JavaFX來得太晚，並且還不是很成熟。大家都在說RIA已經過時，必須使用HTML5了。要承擔被人指為“老古板”的風險。但是我們認為，企業級應用中，穩定、高效才是首先要追求的目標。
3、會在客戶端保存一些UI資源(jar包、配置信息等)作為Cache，以提升UI響應速度——雖然我們堅持認為在企業級應用中這是優點，但也有可能被攻擊為“不是純B/S”。
4、可能會存在安全性問題——雖然在企業級應用中，這是個大概率的偽命題。
嗯，以上四條我都看不見。