認識JavaFX

認識JavaFX

作者：蔡學鏞 2007年12月13日 星期四

注意：本文章內容是依據alpha版技術做描述，讀者閱讀時可能已經和實際現況有所差異。
雖然Ajax方興未艾，但RIA（Rich Internet/Interface Application）也已經揭開序幕，同樣是Web Client端的技術，RIA的崛起勢必會造成Ajax的消褪，但消長的速度目前很難預期。在未來RIA的時代，Client端具有更好看的外觀，更佳的互動性，值得我們期待。

RIA技術的市場，目前是三強鼎立的局面：
Sun的JavaFX，目前是alpha版。
Adobe的AIR/Flash（前身為Apollo），目前是beta版，估計2008年推出正式版。
微軟的WPF/Silverlight，WPF已經是正式版

三大平台的異同

對於「使用者」來說，這RIA三強共同的特點是：更美觀的GUI、更好的人機互動；在瀏覽器內和瀏覽器外執行皆可；上線和離線執行皆可；都意圖同時支援各種裝置（PC、手機…）。
對於「開發者」來說，這三者共同的特點是：Client端的「GUI描述」和「程式邏輯」分開，「GUI描述」改用宣告（declarative）的方式。但是三者的開發理念仍有不同之處。我認為從語言的角度來看，JavaFX比另外兩者先進，因為JavaFX使用DSL（Domain-Specific Language），而非XML。

我之所以將JavaFX歸類為DSL（Domain-Specific Language），是因為JavaFX Script語言是Sun專門為「設計GUI」而設計出來的語言。JavaFX前身為F3，意思是Form Follows Function，顧名思義，就是設計GUI的意思。換句話說，這個語言的Domain就是GUI設計，它專精於GUI設計，而GUI正是RIA的重點。

但是我宣稱JavaFX是DSL，這可能會引發爭議。因為JavaFX的功能強大，能做的事顯然不只有GUI，這使得JavaFX又像是一個general-purpose的語言。

GUI設計方法的演進

這十年來，在GUI設計上，我們經歷過幾個主流階段：
GUI設計和程式邏輯混雜在一起
GUI設計和程式邏輯切割，使用XML描述GUI
GUI設計和程式邏輯切割，使用DSL描述GUI
在GUI設計和程式邏輯混雜在一起的時代，我們用imperative語言（C++、Java、C#）編寫GUI。通常我們會透過雙向（2-way）GUI設計工具（例如JBuilder、Visual Studio）的協助，讓我們可以用拖曳（drag-n-drop）的方式，產生出imperative語言的程式碼。對於這種自動產生出來的程式碼，我們最好不要徒手修改，否則可能會造成雙向GUI設計工具無法瞭解程式碼。因此，像JBuilder這樣的工具會將產生的程式碼獨立於建構子（constructor）之外，放在一個專門的jbInit()方法內，並希望編程員不要徒手修改此方法。

上面這種作法的缺點是，將GUI設計和程式邏輯混雜在一起。而GUI設計和程式設計是不同的專業領域，最好分開由各自的專家負責。除此之外，GUI的設計也比較偏宣告（declarative）的方式，而不是主流語言使用的命令（imperative）方式。

於是WPF和AIR的作法，允許我們將GUI設計的部分獨立出來，使用XML來描述（而不是使用imperative語言）。XML可以當作描述語言，但有一些嚴重的缺點：
檔案不適合徒手編寫，最好要有工具的協助。以RIA來說，就算沒有GUI設計工具可用，至少也要有XML樹狀編輯工具可用。要編程員使用文字編輯器編寫XML檔案，是很不人道的作法。編程員也是人呀！（哽咽）
XML冗長。一件簡單的事情，使用別的文字格式，可以簡短地描述；如果使用XML格式，檔案大小暴增。
XML缺乏彈性。XML適合用來描述結構性的資料，但不適合描述以外的東西。使用XML做非它所擅長的事，只會讓XML變得更冗長，更容易出錯。
XML有這麼多缺點，為何WPF和AIR會選擇使用XML當GUI的描述語言。他們會告訴你：「XML可以方便資料交換」。XML可以方便資料交換，這一點無庸置疑，但是我相當懷疑他們選擇XML做資料描述是為了「方便資料交換」，我認為真正的原因是：
為了方便WPF/AIR的開發工具與平台剖析XML檔案。
各個平台和程式庫內，都具有XML剖析器，所以可以輕易地讀寫XML格式的資料，不需要另外編寫剖析器（parser）。這雖然是很大的好處，但開發工具廠商和平台廠商享有這種好處的同時，身為編程員的我們卻被犧牲了…我們因此得在許多沒有必要的場合和XML打交道。

因此當我看到F3時，眼睛為之一亮。今年五月JavaOne會議上正式讓F3公開亮相，並更名為JavaFX。Sun宣稱JavaFX包括了JavaFX Script Language與JavaFX Mobile。所謂的JavaFX Mobile就是在mobile裝置上「執行JavaFX程式」的平台。你可以把JavaFX mobile想像成Flash Lite或.NET Compact Framework。目前JavaFX Mobile的資訊相當少，應該只是一個先期的構想，所以我們關注的重點放在JavaFX語言的部分即可，本文章只要提到JavaFX，都是指JavaFX語言。

JavaFX相較於XML（MXML、XAML），優點是：
JavaFX檔案適合徒手編寫
JavaFX檔案相當簡短
JavaFX具有很大的彈性

你可以理解前兩點，但是第三點提到「JavaFX具有很大的彈性」，這就需要特別解說了。XML只適合描述樹狀結構化的描述性資料，但是JavaFX是一個語言，而不是一種格式，所以當然比XML更有彈性。想用XML描述一般編程語言能做的事，只會事倍功半。

JavaFX語言特色

另外，由於JavaFX是一個編程語言，我們也可以把JavaFX拿來和Java做比較，JavaFX比Java更簡單、好學、寫程式更快。

DSL有一個好處，就是目標明確，語法簡單。JavaFX讓Java走上一條簡化的道路，或許JavaFX的FX，是Fixed的意思吧！但是C# 3.0 與 LINQ卻帶領C#走向一個越來越複雜的道路。我最近一直在懷疑，C#是不是打算向C++或Ada看齊，把自己變成一個超級複雜的語言。在程式語言的理念上，我比較認同Eiffel、Python、REBOL，維持語言的簡單性。因此，我相當喜歡JavaFX。

JavaFX除了比Java和WPF/AIR簡單之外，JavaFX之所以吸引我，是因為我本來就是Functional語言的愛好者，而JavaFX具有相當多「常見於Functional語言」的特色，包括了：函式可以被視為資料、宣告式語法、list處理。附帶一提，最近Functional語言的觀念似乎有進入主流的趨勢，不只JavaFX，連LINQ/C#也加入許多functional語言的特色。JavaFX的Querying Array方式，簡直和LINQ/C#的語法一樣。

JavaFX具有相當多Functional語言（例如Miranda、Haskell、Common LISP、REBOL、ML）常見的特色，甚至支援Pure Function（類似Eiffel）。我知道大多數的編程員都沒用過任何Functional語言，這實在是很可惜。我建議大家去用用Functional語言，只要用過，很可能會喜歡上這類語言。如果你是.NET愛好者，我建議你從微軟的F#語言開始。

你可以用JavaFX的語法，把程式寫得很像傳統的Java程式，但如果這樣，就表示你沒有用到JavaFX裡面的Functional語言特色，那麼使用JavaFX也就沒有意義了。我要強調，這些原本常見於Functional語言的特色，正是JavaFX魅力之所在。C# 3.0固然也有這些新特色，但是加諸於原本就複雜的C#語言之上，只會讓語言更複雜。

對於原本就會Java語言的人，可能會比較關心JavaFX和Java在市場定位上的差異：

JavaFX抽象層次更高，程式更好學、好寫、好讀。你可以將Java看成JVM的系統語言，把JavaFX看成JVM的高階語言。
JavaFX初期只能用解譯器（Interpreter），你可以將它看成JVM的Scrip解譯式語言，將Java看成編譯式語言。（但是未來Sun會提供JavaFX編譯器，以提昇效率。儘管如此，JavaFX解譯器將會是JVM內建的一部份，不會因為JavaFX編譯器的出現而消失。關於JavaFX的編譯與解譯，下一節有詳細的解釋。）

JavaFX的原理

原本的Java程式執行方式，是先將Java源碼，經由編譯器轉成Java Bytecode，再經由Class Loader解讀Bytecode格式變成JVM內部的格式，放在記憶體中。其中Java編譯器作用的期間是編譯期（Compile-Time），而Class Loader作用的時間是Run-Time，如圖1所示。

JavaFX的作法是，沒有編譯期。直接在執行期，由JavaFX解譯器將JavaFX源碼轉成Java Bytecode，再由Class Loader載入記憶體，如圖2所示。有時候你會在JavaFX的文件上看到JavaFX解譯器一詞，就是指圖2的概念。

其實，圖2的說法只是為了方便解說，事實上根本沒有所謂的「JavaFX解譯器」。實際的狀況比較像圖3，由一個特殊的Class Loader負責將JavaFX源碼轉成JVM要的內容。此Class Loader差不多是圖2「JavaFX解譯器」加上「原有的Class Loader」的綜合體，只是Class Loader內部在轉換時，不會產生中間的Java Bytecode。

依照圖3的執行狀況，執行期的Class Loader負擔相當重，因為將源碼轉成內部格式相當耗費計算資源，這使得JavaFX程式「一開始」的執行效率不彰，比一般的Java程式差（但是等JavaFX源碼都載入之後，效率就會和一般的Java一樣了）。為了提升載入的效率，Sun會提供JavaFX編譯器，可以直接將JavaFX源碼編譯成bytecode，如圖4所示。

JavaFX的疑慮

即使使用JavaFX編譯器，JavaFX程式依然得面對一些效率問題：
Java本身的效率問題
JVM啟動時間過長的問題
JavaFX語言相當高階，能否編譯出有效率的Java Bytecode，有待觀察

除了效率之外，JavaFX的前途並非萬里無雲，至少我就發現下面的隱憂：
Java社群幾乎都集中在非Windows平台的Server端。熟悉前端技術（Swing/Java2D）的人才相當少。想使用JavaFX開發RIA，依然必須對Swing/Java2D有一定的知識才行。
我之前對Swing的印象是：bug超多（不過我已經很多年沒有寫Swing程式了，或許這幾年下來，Swing已經變穩定了）
JRE大小的問題。雖然和.NET臃腫的體積相比，JRE（Java Runtime Environment）顯得相當輕巧；但是和AIR/Flash的Runtime相比，JRE又顯得臃腫。對於RIA的應用來說，執行環境的大小，以及開發出來的應用的大小，都很重要。想要和AIR/Flash抗衡，這方面Java還有改進的空間。
Java多媒體的支援能力很差。近幾年，串流媒體相當流行，如果不能支援串流媒體，對於JavaFX來說會是一大打擊。這方面，我完全看不到Java有什麼招架之力。
JavaFX的敵人很強：.NET已經崛起、Flash勢力又太龐大，這些都會壓縮JavaFX的發展空間。
AIR支援完整的Web前端技術（JavaScript/HTML/CSS），可以取代Web瀏覽器。Java只有部分支援Web前端技術，所以不能執行JavaScript（除非使用3rd Party廠商的產品，例如WebRenderer）。

老狗的新把戲

JavaFX的出現，證明了老狗也會玩新把戲。雖然這把戲來得有一點晚，但總算是搭上了RIA列車。或許我應該說，來得早不如來得巧。雖然我在前面列出總總的隱憂，但這新把戲還是讓我印象深刻，我決定投入一陣子看看（原因在於我太討厭XML，又太喜歡Functional語言）。

Sun目前已經做好JavaFX在NetBeans和Eclipse的插件了（Plug-In），所以雖然JavaFX還在alpha階段，但是你今天就可以開始用它寫程式了。我們可以預期，未來兩大Java商業開發工具（IntelliJ、JBuilder）也可能會支援JavaFX，包括GUI Designer、Refactoring。

『美麗的鞋子，不合腳又有什麼用？』

藝人田麗的前夫陳定中和她離婚時，所說的這句關於鞋子的比喻，我覺得相當傳神。婚姻如此，技術不也是？有人喜歡Adobe AIR，有人決定使用Microsoft WPF，有人比較想用JavaFX。公司政策、長期以來對某公司的偏好/偏惡、轉換成本、主流程度、顧客要求 ... 每個公司的考量點都不一樣，大家都是挑選現階段最適合自己的技術。

為什麼我又回來使用Java？這可以說是造化弄人。當初我可是花很多時間研究Java Swing / Java 2D/ Java 3D，一直沒派上用場，有一點不甘心。但是後來發現.NET CLR比Java VM好，所以跳到.NET技術陣營，成為Java人眼中的全民公敵。這只不過是挑選適合自己現階段的技術，幹嘛弄得像是把異教徒送上斷頭臺一般的宗教狂熱。我一直到現在還是不太清楚當初我的頭是怎麼被砍掉的。

下一個熱門的技術領域是RIA，但WPF和AIR都使用傳統語言（C#與ActionScript）搭配XML，而JavaFX卻是專門為RIA打造出來的DSL（Domain Specific Language），於是我又回到Java陣營。你可以說我有自我毀滅的傾向：Java正紅的時候，我卻跳進.NET；現在WPF和AIR炒得正火熱，我卻挑了一個最冷門的JavaFX；我甚至還花許多時間在更冷門的Curl和REBOL（這兩個語言都是在Tiobe編程語言需求排名榜百名以外，幾乎沒人在用的語言）。你可以說我的審美觀特殊，但是我的回答是『美麗的鞋子，不合腳又有什麼用』。

但我還是要提醒你，在企業內部選擇開發技術時，必須理智大於情感，如果你目前要開發RIA應用，我認為AIR/Flash還是比較保險的選擇，而WPF/Sliverlight次之，至於JavaFX可以暫時不用考慮。

JavaFX編譯器神龍見首

畢竟JavaFX還是Alpha階段的技術，所以變動的機會很高。「Java FX編譯器」的概念，現在已經有了雛形。Sun已經開發出JavaFX的編譯器，並將它開放出來，但此編譯器還在相當早期的階段，距離100%完成還有相當遙遠的距離。JavaFX編譯器的目的是將JavaFX劇本（script）轉譯成JVM類別檔（也就是bytecode格式）。目前只能編譯簡單的「非GUI類」JavaFX劇本。（所以幾乎沒啥用途！）

根據JavaFX大將Chris Oliver初步的實驗顯示，JavaFX編譯後的執行效能比解譯的方式提升6~20倍。（現在你可以體會JavaFX解譯的效能有多差了。）
儘管以後有了JavaFX編譯器，JavaFX解譯器依然會扮演很重要的角色，包括：
開發階段：讓我們可以不需要編譯手續，直接執行。
執行階段：讓程式可以多一些變化。DOM之於JavaScript，相當於JVM之於JavaFX。
JVM與AVM效率評比

我們之前也看過Adobe宣稱，ActionScript 3.0（AIR使用的語言）比前一代效率最高提升10倍。但我真正感興趣的是，JavaFX和ActionScript 3.0的執行效率相較之下會是如何？根據Chris Oliver初步的實驗顯示，Hotspot的JVM和Tamarin的AVM（ActionScript VM），效率比較之下，JVM比AVM快了25倍。甚至連Mozilla Rhino JavaScript引擎的效率都還比AVM快1.8倍。AVM的效率這麼差，讓我滿詫異的，尤其是不久前才聽Adobe工程師宣稱AVM效率比JVM好。或許我不應該這麼詫異，如果你還記得幾年前J2EE寵物店和.NET寵物店的效能評比爭議，你應該要知道，由競爭雙方任何一方公布的效能評比結果，總是會失之偏頗。

AVM或許執行效率比Hotspot JVM差，但是啟動速度絕對比JVM快許多，且執行時消耗的記憶體也會比Java少，且對於圖形動畫的能力也肯定比JVM好許多。當然這些真相都是JavaFX陣營不會主動揭露的。

圖形介面和動畫是RIA技術很重要的一部份。AIR和Silverlight的動畫效果都很不錯，那麼JavaFX的動畫效果呢？目前看來，似乎表現得比AIR和WFP差。而且用JavaFX寫出來的程式似乎體積都不小。

JavaFX語言

目前JavaFX語言規格尚未定案，還有變動的可能。如果你對JavaFX語言感興趣，你可以閱讀下面網址的文件：https://openjfx.dev.java.net/JavaFX_Programming_Language.html，或者簡體中文版：https://openjfx.dev.java.net/JavaFX_Programming_Language_CN.html。繁體中文版呢？很抱歉，現在網路上的簡繁體中文資訊量已經嚴重地向簡體中文傾斜，你必須試著習慣看簡體中文了。

JavaFX程式庫

Windows Forms類別不適合用描述的方式處理，所以才會有WPF類別的出現。類似的狀況也出現在JavaFX上。由於，Java Swing 與 Java 2D不適合用描述的方式（例如沒有binding），所以JavaFX特別設計了javafx.*類別，我們稱它為JavaFX程式庫。

JavaFX程式可以直接使用既有的Java程式庫，但是這樣的好處不多（還是有一些好處，例如：使用JavaFX的Object Literal語法，可以簡化物件的初始化設定）。JavaFX程式最好能搭配特別為JavaFX設計的程式庫。目前Java Swing以及Java 2D已經出現JavaFX版本，未來我們可以預期Java 3D也會推出JavaFX版本。由於Java 3D是高階的「場景描述圖」（Scene Graph），類似VRML和Web 3D，比OpenGL和DirectX高階許多。以往編寫Java 3D程式相當囉唆，如果真有JavaFX版本的Java3D API，應該會對於3D應用的推廣會有一些幫助。

JavaFX開發工具

雖然Sun同時提供Eclipse和NetBeans版本的JavaFX Plug-in，但顯然Sun比較偏好NetBeans，所以NetBeans的JavaFX Plug-In修正速度比較快，而且開發操作範例也是以NetBeans為描述對象。所以，在JavaFX正式版釋出之前，如果想使用JavaFX IDE，或許NetBeans會是比Eclipse更好的選擇。但是在JavaFX正式版釋出之後，應該就沒有這個問題。

你也可以不使用Eclipse和NetBeans IDE，而是使用JavaFXPad。你可以從http://download.java.net/general/openjfx/demos/javafxpad.jnlp取得JavaFXPad。JavaFXPad本身就是一個JavaFX應用，JavaFXPad視窗畫面被分成上下兩部份，你可以在下面的文字編輯器內鍵入JavaFX程式，上面會出現程式的執行結果。如果你讀過Charles Petzold的「Application = Code + Markup」，你會發現JavaFXPad和Petzold的XAML Cruncher程式有異曲同工之妙。JavaFXPad視窗畫面如圖5所示。

你甚至可以不使用Eclipse、NetBeans、JavaFXPad，只使用CLI（命令列介面）搭配你自己熟悉的任何編輯器，也可以開發出JavaFX應用。那麼你必須：
下載JavaFX Shell
將JavaFX Shell設定到作業系統的路徑（PATH）
用文字編輯器編寫JavaFX Script（你的JavaFX Script一定要是一個Frame，否則無法執行。）
透過JavaFX Shell Script（批次檔）來執行你的JavaFX Script。
因為太麻煩，所以我不建議你使用CLI的方式開發（或學習）JavaFX。

異想天開：結合三方優勢

單純地將JavaFX看成一個語言（不管JavaFX程式庫與Java程式庫），有沒有可能將JavaFX語言用在AIR或WPF上。答案是可能的，雖然目前尚未有這樣的產品（畢竟連JavaFX本身都還在alpha階段），但是我希望以後可能會有JavaFX->ActionScript轉換器與JavaFX->C#轉換器。

如果能在最強大的開發工具（Visual Studio）上，用最好的語言（JavaFX）為最好的平台（AIR）開發應用，該有多好！

最後的叮嚀

這幾個月以來，從F3到JavaFX，看著JavaFX的成長，感覺像是在一個生命的孕育過程中，欣賞它的超音波照片。我要強調，JavaFX目前只是在alpha階段，雖然大方向都已經底定，但仍有一些地方在修正中。本系列文章所提到的任何技術資訊，隨時都可能過時。對於alpha技術使用者來說，常會遇到這樣的問題，所以在alpha階段的技術，只適合做技術評估和提前研究，不適合開發軟體，否則可能會疲於奔命。一般來說，還是等到beta階段，我們再用它來開發軟體，會比較保險一些。

轉自蔡學鏞【言程序】部落格http://jerrylovesrebol.blogspot.com/2007/12/javafx.html