認識JavaFX

红薯 发布于 2009/02/12 18:47
阅读 975
收藏 2

作者:蔡學鏞

注意:本文章內容是依據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應用。那麼你必須:

  1. 下載JavaFX Shell
  2. 將JavaFX Shell設定到作業系統的路徑(PATH)
  3. 用文字編輯器編寫JavaFX Script(你的JavaFX Script一定要是一個Frame,否則無法執行。)
  4. 透過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

加载中
0
寒羁人
寒羁人
@红薯 ,链接失效了
红薯
红薯
内容捯饬过来了
0
Credo-Zhao
Credo-Zhao
最近开发swing了要,看看是不是用javafx
OSCHINA
登录后可查看更多优质内容
返回顶部
顶部