Java混合化現狀和RIA趨勢分析

Java牴觸情結已經初步顯現，我們已經開始看到由此引起的一些根本性轉變。
        Bruce Tate的一些著作集中討論了Java的缺陷，並指出需要放棄一些還未實現的想法。諸如Jens Alfke's Thought Palace和Stephen Colebourne's Weblog中的部落格也頻繁提到這個問題。當然還有Steve Jobs的著名引用（引用自iPhone）：“Java不具有構建價值。人們不會再使用Java了。它只是個巨大的累贅”。產生這種牴觸的惟一原因就是，Sun始終以為Java是無所不在、無所不能。它曾經是令人歎服的，但是隻有語言的設計者和提倡者能認識到其中的問題，這種語言才能繼續發展。如果這種語言已經不再成功，仍然堅持稱讚它，這種行為本身就是一種否認。EJB已經對此作出了反應。EJB3小組最終承認EJB成本太高，並且也從Hibernate和Spring學習了經驗，但是還不足以解決問題。大多數人似乎都認為Hibernate和Spring比EJB3更加簡單和直觀，因此，對於這種過去成本過高的技術，很難再回到以前的看法了。
Java 5預設了這樣一個事實：Microsoft使用Ｃ＃實現了很多有趣的功能，而且Java 7中引入的特性支援這樣一種思想——Java現在正與C# 3.0玩追趕遊戲。競爭是不錯的，Java並沒有死。它在繼續發展，構建在JVM之上的新語言（如Ruby、Scala和Groovy）的出現是Java技術恢復活力的象徵。我 們想問這樣一個問題：為何Java applet未被當作RIA（富Internet應用程式）的客戶端標準在Internet上普及？這是一個非常尖銳的問題，因為Gosling及其團隊 打算放棄Java（從而摒棄許多考慮不周的決策），這將會引起Internet的變革。這就是AWT和Applets在最後時刻被拋棄的原因，據說從計劃到完成花了一個月時間。Bill Venners引用了Patrick Naughton的話：“這是一個時間問題，只需3個月時間就會波及整個Java領域。這是由我們發起的。”我之前就聽說過這句話1，而且在構建程式語言時，這種態度似乎總是錯誤的。您正在建立一個基本的體系結構，希望人們將會採納和使用多年。這就是需要謹慎思索的地方，而不是衝動。
        我能夠明白為何Green Team持有這種態度：這是Microsoft的方式。丟擲一個產品以吸引大眾的目光。這個產品不必是完美的；它只需要佔領市場空間就行了。隨著時間的推移，可以修復倉促推出的產品上的任何缺陷。這是一種敏捷的營銷方式。這種方法適用於動態語言。曾經最流行的語言之一Visual Basic，已經發展了許多年了。Python已經修復了一些對原有程式碼有害的缺陷，以優化該語言。據說，Ruby也計劃這麼做。但是對於包含大量程式碼（特別冗長的語言）的靜態語言來說，修復漏洞似乎不那麼奏效。所有程式碼都必須重新編譯，而且可能被更改，但是我認為，Java本來也可以採用Python的方法：如果不希望更改就不要更新。許多公司始終都沒有更新其Java版本。
       1. 1 特別是當我編寫Thinking in Java 時，許多人都說“已經有太多的Java圖書了，您的書不會有市場的，不值得這樣做。”

Web陷入混亂
      能夠發現可能性固然不錯，然而缺點是很難確定何時出現故障。Web的概念非常有遠見，但大部分web是失敗的。是的，我們已經能夠使web工作，但是很難說它“執行良好”。具體來講，使用HTML、CSS和JavaScript的任何應用程式都難於開發並且成本昂貴，而且似乎不可能在不同瀏覽器上獲得相同的外觀。甚至簡單的頁面也會因字型問題而看起來不同。
      如果您使用Firefox，有多少您訪問的站點由於只針對Internet Explorer (IE)建立而至少有部分內容難以讀取？在我看來情況越來越糟了；我看到更多（不是更少）站點不能很好地相容Firefox，以至於我將認真地考慮轉向IE。
      CSS並沒有實現它許下的美好承諾。許多年過去了，它在各種瀏覽器上的實現仍然不一致。只要使用HTML和CSS，您就總是想知道自己建立的應用程式是否會在其他瀏覽器上產生不符合期望的效果。除IE或Firefox之外，其他瀏覽器的情形還會更糟。
      JavaScript也在web初期出現了，但是瀏覽器的混戰導致了JavaScript的不一致性和難於使用。Ajax的關鍵元素之一在於，已經有人開始解決跨平臺JavaScript問題，因此您不用考慮不同瀏覽器之間經常出現的不一致。這種方法存在兩個問題。第一個問題是JavaScript的功能有限。儘管Ajax可以充分利用JavaScript的功能，但它的功能也非常有限。第二個問題是，我們依靠Ajax庫來處理跨瀏覽器問題。如果想要編寫自己的程式碼，必須精通這些問題，而且到那時Ajax的許多功能都沒有用了。Ajax極大地改善了使用者體驗，但它也存在侷限性，我猜想我們已經瞭解了Ajax將提供的絕大部分功能了。
       更令人印象深刻的是Google Web Toolkit (GWT)，為了加速開發過程，它將型別檢查Java轉換為跨平臺JavaScript。首先用Java編寫程式碼，然後用GWT將其編譯為跨瀏覽器JavaScript。然後，JavaScript變成了能夠在所有平臺上執行的中間程式碼。但是這讓Google的智囊團不得不解決本來不應該出現的問題。而且，如果沒有所需的庫，您仍然必須解決跨平臺JavaScript問題，才能編寫新程式碼。縱使GWT如此高明，我覺得它也會被JavaScript和瀏覽器的內在限制搞得筋疲力盡。
       我們確實看到了一些令人驚奇的基於Ajax的工具，比如GMail和其他Google工具，它們正在不斷地誘惑我。這種現象非常好，但這是您希望在web上看到的最好結果嗎？您已經看到，如果沒有這個限制，這些應用程式就非常接近理想結果了，即使它們不能持續工作（是的，我知道Google工具還“處於測試階段”）。例如，在GMail中，您按下‘r’鍵後應該能回覆訊息。有時候這是可行的，但常常行不通，這非常使人惱火。而且更常見的情況是，當我使用像GMail這樣的web應用程式時，Ctrl-C複製操作也不起作用了。Windows、Firefox、JavaScript或其他軟件中都會出現這種問題，但它似乎與web應用程式有關，而且這種情況至少持續了一年。坦白來講，我並不關心為什麼會出現問題，相信任何其他使用者也不會關心。如果這麼簡單的事情都出現問題，其前途不容樂觀。
       對於造就瞭如今的web的一連串錯誤決策，我們必須付出多少努力才能補救？

富Internet應用程式

        我們想問這樣一個問題：為何Java applet未被當作RIA（富Internet應用程式）的客戶端標準在Internet上普及？
        這 是一個非常尖銳的問題，因為Gosling及其團隊打算放棄Java（從而摒棄許多考慮不周的決策），這將會引起Internet的變革。這就是AWT和 Applets在最後時刻被拋棄的原因，據說從計劃到完成花了一個月時間。Bill Venners引用了Patrick Naughton的話：“這是一個時間問題，只需3個月時間就會波及整個Java領域。這是由我們發起的。”我之前就聽說過這句話1，而且在構建程式語言 時，這種態度似乎總是錯誤的。您正在建立一個基本的體系結構，希望人們將會採納和使用多年。這就是需要謹慎思索的地方，而不是動。
       我 能夠明白為何Green Team持有這種態度：這是Microsoft的方式。丟擲一個產品以吸引大眾的目光。這個產品不必是完美的；它只需要佔領市場空間就行了。隨著時間的推 移，可以修復倉促推出的產品上的任何缺陷。這是一種敏捷的營銷方式。這種方法適用於動態語言。曾經最流行的語言之一Visual Basic，已經發展了許多年了。Python已經修復了一些對原有程式碼有害的缺陷，以優化該語言。據說，Ruby也計劃這麼做。
       但是對於包含大量程式碼（特別冗長的語言）的靜態語言來說，修復漏洞似乎不那麼奏效。所有程式碼都必須重新編譯，而且可能被更改，但是我認為，Java本來也可以採用Python的方法：如果不希望更改就不要更新。許多公司始終都沒有更新其Java版本。

    
安裝問題
         Java已經存在10年了，而且applet並不是與web互動的主要方式。我認為主要原因在於安裝問題，這是另一個未被重視的Java問題。老實說，為什麼我們喜歡Ajax？
         這 顯然不是因為JavaScript易於使用——JavaScript的跨平臺問題是過去人們不願使用它的原因。Ajax的流行是因為，我們知道客戶端已經 安裝了必需的軟體。人們必須首先解決JavaScript的跨平臺問題，但是如果Java Runtime Environment (JRE)很容易安裝，所有人都只需建立Java applet就行了。但事實不是這樣的，applet沒有這麼流行，因而每個人都轉向使用Ajax。所以，Ajax變成了大家喜愛的RIA技術。
        盡 管藉助ECMAScript標準化會使情況得到好轉，但是與JavaScript相比，我仍然更願意使用Java程式設計，主要原因在於JavaScript 的不一致性。也許八年內當前版本的ECMAScript將會成為幾乎所有瀏覽器的標準。但是當前版本的JavaScript已經可以使用了（儘管其實現比 較隨意），並且不存在安裝問題。我認為這很好地印證了一點：Java未能接手RIA語言的原因在於其安裝問題。
         儘管多年來已經對Java進行了各種各樣的修補，但我認為根本問題在於，所有嘗試解決安裝問題的人都只是站在技術的角度，而沒有從真正需要的角度考慮：外 部使用者的體驗。例如，我曾經被Linux發行版困擾，因為它的安裝很麻煩。我幾乎每隔一年安裝一次Linux，而且一旦安裝，安裝程式就開始詢問問題。只 有精通Linux的人才知道這些問題的答案。我甚至無從下手，因此只有放棄並在來年再嘗試。然後Red Hat誕生了（至少，我認為它是第一個關注安裝體驗的產品），而且安裝Linux時不會詢問問題，或者至少給出一些合理的預設設定。Linux正是從那時 開始流行的。（最近，Ubuntu在解決Linux的友好性問題上似乎處於領先地位。）
         安 裝JRE需要使用者回答問題。對於精通JRE的人來說，這些問題的答案很簡單或者是顯而易見的，但是對於其他web使用者來說，這些問題會讓他們不知所措。在 文章Sun Never Sets on Java Security Updates中，InfoWorld的Ed Foster評論並舉例說明了Java的安裝問題。儘管這篇文章主要是對更新的抱怨，但也對舊版本的Java很不滿。Ryan Tomayko也寫了一篇部落格，討論了Java的安裝問題。
          Java Network Launch Protocol (JNLP)是Java WebStart的基礎，它本來應該解決這些問題,建立易於安裝的桌面應用程式。我認為JNLP未被廣泛使用的原因可以在https: //aerith.dev.java.net/上找到，這是“Cool JavaOne Demos”的一個頁面。如果單擊頁面上的JNLP版本連結，它將開始啟動、下載一些東西並詢問您問題。然後就沒有下文了。沒有錯誤訊息或任何資訊告訴你 發生了什麼。重複嘗試還是會產生相同的結果，只是速度快些，因為需要的檔案已經下載下來了。至少，我的體驗是這樣的。如果您能夠正常使用，那麼就更糟了 ——它只能隨機地在一些平臺上執行，而在另一些上就不行。這樣的產品如何除錯呢？
         使 用Java構建GUI應用程式並不是不可能，但是10年過去了，applet、Java WebStart和常用應用程式仍然存在安裝問題。10年之後，人們不再信任它了。如果10年之後不會出現這種情況，我敢說某些人會認為這個問題不值得修 復。即使他們修復了，由於使用者已經有了如此多的糟糕體驗，需要經過多年才能重新建立起之前的信任。
       

Java applet和應用程式體驗
         AWT 最初的使用者體驗沉重打擊了Sun對Java的狂熱吹噓，而且我認為applet到現在還未恢復元氣。結果，Java永遠不會成為RIA的主流。即使在現 在，仍然不能在web站點上方便地執行Java applet。他們失敗了，而且還不知道錯在哪裡。更糟糕的是，他們甚至會阻止Firefox開啟新視窗，直到我重新啟動計算機。
對“applet已經死了”的常見回應是“它們沒有死。我一直都在使用它們。”applet並不是一無是處；人們仍然在用它建立出色的產品。Java Posse每週都會釋出一個或多個applet。上面的論斷應該理解為“對於web RIA來說，applet已經死了”。JRE和任何特定applet的安裝過程並不足以說服任何人將它們用於通用的web站點。
        Java的缺陷同樣也影響到了桌面應用程式，applet也是一樣。我曾經使用過一個叫做Memorex exPressit的Java產品，它的UI非常難看而且缺陷很多。我還使用過Logitech IO鋼筆支援軟體（用.NET編寫的），它執行流暢而且外觀漂亮，與Memorex exPressit形成鮮明對比。您也許會說Memorex程式設計人員缺乏經驗，但是Logitech軟體只是一個執行良好的小型應用程式，無需程式設計人員付出任何辛苦的勞動，然而，在我用過的使用Java編寫的應用程式中，幾乎沒有一個易於使用。Eclipse是一款非常優秀的軟體，但我覺得其背後一定飽含著“艱辛的勞動”。
         Corel曾經試圖使用Java建立一個文書處理程式（我忘記了他們是想移植WordPerfect還是從頭開始編寫）。顯然他們的行動太早了，因為他們僅具有AWT。但是如果您聽過Sun的誇張宣傳，就會覺得這是正確的選擇。不過沒關係，無論如何它還是能工作的，因為這類失敗已經使人們不敢使用Java了。
         OpenOffice不是用Java編寫的，而是用C++編寫的。我相信這不是因為程式設計人員想要與C++的跨平臺問題做鬥爭。而是因為C++快速，或許是因為可以更直接地控制底層平臺。儘管發展方向始終由Sun掌控（多年以前，我參加了一個記者招待會，Gosling在會上說“Java始終跟C++一樣快或者更快”，這句話一直困擾著我），但是Java並不能解決所有問題。什麼我們喜歡Ajax？這顯然不是因為JavaScript易於使用——JavaScript的跨平臺問題是過去人們不願使用它的原因。Ajax的流行是因為，我們知道客戶端已經安裝了必需的軟體。人們必須首先解決JavaScript的跨平臺問題，但是如果Java Runtime Environment (JRE)很容易安裝，所有人都只需建立Java applet就行了。但事實不是這樣的，applet沒有這麼流行，因而每個人都轉向使用Ajax。所以，Ajax變成了大家喜愛的RIA技術。
         儘管藉助ECMAScript標準化會使情況得到好轉，但是與JavaScript相比，我仍然更願意使用Java程式設計，主要原因在於JavaScript的不一致性。也許八年內當前版本的ECMAScript將會成為幾乎所有瀏覽器的標準。但是當前版本的JavaScript已經可以使用了（儘管其實現比較隨意），並且不存在安裝問題。我認為這很好地印證了一點：Java未能接手RIA語言的原因在於其安裝問題。
         儘管多年來已經對Java進行了各種各樣的修補，但我認為根本問題在於，所有嘗試解決安裝問題的人都只是站在技術的角度，而沒有從真正需要的角度考慮：外部使用者的體驗。
          例如，我曾經被Linux發行版困擾，因為它的安裝很麻煩。我幾乎每隔一年安裝一次Linux，而且一旦安裝，安裝程式就開始詢問問題。只有精通Linux的人才知道這些問題的答案。我甚至無從下手，因此只有放棄並在來年再嘗試。然後Red Hat誕生了（至少，我認為它是第一個關注安裝體驗的產品），而且安裝Linux時不會詢問問題，或者至少給出一些合理的預設設定。Linux正是從那時開始流行的。（最近，Ubuntu在解決Linux的友好性問題上似乎處於領先地位。）
         安裝JRE需要使用者回答問題。對於精通JRE的人來說，這些問題的答案很簡單或者是顯而易見的，但是對於其他web使用者來說，這些問題會讓他們不知所措。在文章Sun Never Sets on Java Security Updates中，InfoWorld的Ed Foster評論並舉例說明了Java的安裝問題。儘管這篇文章主要是對更新的抱怨，但也對舊版本的Java很不滿。Ryan Tomayko也寫了一篇部落格，討論了Java的安裝問題。
         Java Network Launch Protocol (JNLP)是Java WebStart的基礎，它本來應該解決這些問題,建立易於安裝的桌面應用程式。我認為JNLP未被廣泛使用的原因可以在https://aerith.dev.java.net/上找到，這是“Cool JavaOne Demos”的一個頁面。如果單擊頁面上的JNLP版本連結，它將開始啟動、下載一些東西並詢問您問題。然後就沒有下文了。沒有錯誤訊息或任何資訊告訴你發生了什麼。重複嘗試還是會產生相同的結果，只是速度快些，因為需要的檔案已經下載下來了。至少，我的體驗是這樣的。如果您能夠正常使用，那麼就更糟了——它只能隨機地在一些平臺上執行，而在另一些上就不行。這樣的產品如何除錯呢？
         使用Java構建GUI應用程式並不是不可能，但是10年過去了，applet、Java WebStart和常用應用程式仍然存在安裝問題。10年之後，人們不再信任它了。如果10年之後不會出現這種情況，我敢說某些人會認為這個問題不值得修復。即使他們修復了，由於使用者已經有了如此多的糟糕體驗，需要經過多年才能重新建立起之前的信任。

跨平臺還遠遠不夠
          多年來，我一直在努力解決像Hands-On Java CD這類產品的跨平臺問題。這與RIA問題是相同的，因為我希望安裝過程能夠儘可能簡單，希望所有功能都能夠無縫運轉，而且不希望遇到平臺問題。我的解決方案在很多情形下能夠生效，但有時客戶會給我發電子郵件說，這種方案在他們的計算機上行不通，我不知道問題出在哪裡。我能做的最好的事情就是讓他“在其他計算機上試試”，而且這常常能解決問題……無論是什麼問題。我永遠不希望聽到這類問題；我只希望所有功能都能夠生效。
          我的主要目標是建立一個slide-and-audio內容交付系統，就像您在Hands-On Java CD ROM或Thinking in C中看到的一樣。Java曾經宣稱“只需編寫一次就能在任何地方執行”，它是一個很有吸引力的競爭者。不幸的是，Linux對它的支援來得太晚了（而且 Mac的支持也比較晚）。Linux和Mac使用者也許只是少數，但是他們能直言不諱地提出意見。
          遺憾的是，Java不支援MP3和多媒體。正如Java Posse的Dick Wall曾經多次指出的，Java Media Framework (JMF)被忽略了許多年。在我最初做決定的時候，沒有對任何壓縮聲音格式的支援（與MP3相比，我更喜歡使用其他格式）。即使到現在，也只有開源軟體能夠支援MP3，理論上講很不錯，但是我不想對其進行測試並找出平臺問題——我希望它能夠執行；我惟一希望從客戶那裡聽到的回應是“這太好了！”
似乎惟一能夠使用的只有RealPlayer，所以我使用它播放第二版的HOJ CD。但是RealPlayer在安裝過程中總是試圖讓您購買付費版本；我必須告訴人們如何找到免費版本。而且它非常霸道——它取代了MP3，儘管您告訴它不要這麼做。
         儘管如此，RealPlayer也不可靠。它的安裝偶爾會出現問題，我收到了很多這樣的電子郵件。我不知道問題的根源，而客戶通常會認為是CD出了問題。Daily Show使用RealPlayer多年了，它不但因為總是開始和停止而使人苦惱（所有媒體都不能預先下載，只能線上觀看），而且在圖片左側總是存在拖尾。現在Comedy Central已經轉變為一個新系統，但這隻能間歇性地執行。所以我只能期待它們在YouTube上釋出了。

Flash解決方案
        所以，這就是我的問題。可能10年之後，Java仍不能夠佔領RIA領域。可能Ajax只是“JavaScript本來期望的執行方式”，但是瀏覽器、HTML和CSS的侷限性似乎限制了它的發展空間。我們將使用什麼來構建RIA？
        對於我而言，我只是希望有這樣一個系統，它能夠解決我的所有 UI問題，而不只是一些問題。如果我打算學習它，我不希望在開始開發時卻碰壁了。這種情況已經發生很多次了。顯然，惟一的解決方案是Flash。Flash總是與所有跨平臺多媒體體驗和使用者介面相關。人們非常熟悉和喜歡Flash，而且它安裝在幾乎所有計算機上。它值得信任、穩定而且可靠。
          Flash的安裝對於每個人來說都非常簡單。不需要回答問題或執行特殊操作；它執行良好。這就是為什麼它這麼流行了。當前和以後的Flash版本都會在3個平臺上（是的，除了64-bit Linux，但是正在解決這個問題，而且其使用者通常都有不止一臺計算機，因此他們還有備選方法）同時釋出。標準的Flash安裝能夠播放MP3和各種視訊型別，因此不用擔心“編寫一次就能在任何地方執行……除了用於多媒體”。
          而且不可否認，Flash產生的使用者介面非常友好。Flickr和Picasa都使用什麼？不是Java、不是Ajax，而是Flash。Google Video是用Ajax編寫的，它肯定不能用於所有地方，因為他們購買了使用Flash的YouTube。甚至最頑固的Swing支持者也暗地裡希望自己的UI能有這麼漂亮，尤其是不需要Swing要求的所有額外工作。
          有一個非常不錯的Flash web應用程式叫做Gliffy，它效仿了Visio（它是用OpenLaszlo建立的，我將在稍後提及）。沒有人能夠想到用Ajax創建這樣的軟體，即使使用HTML、CSS和JavaScript模仿更加簡單的Microsoft Paint的人也想不到。非常不錯，但是您會認為這已經接近這些技術的功能極限了，而Flash才剛剛開始。除了Paint克隆有點緩慢和笨拙之外，各個瀏覽器上的UI也不一致。即使在JavaScript和諸如Ajax、JSON、GWT和其他技術的限制內完成了令人驚訝的成就，仍然存在著限制。我們每天都要面對這些限制，但是它們並沒有消失。

解決UI問題
         GUI程式設計的一個困難之處在於選擇GUI庫。有時候有一個標準庫，但是不能進行更改。在Java中，我們首先使用AWT，後來證明這是錯誤的，因此我們不得不忍受開發出來的Swing，直到IBM和Eclipse加入並提供了一個額外選擇SWT。在Python中，有許多GUI庫，包括內建的Tkinter（它克服了安裝問題）、WxPython、Qt等等。特定於Windows的庫也有類似的選擇，但是如果想要建立跨平臺應用程式，這些庫都用不了。
        如果研究這些GUI庫，跟我一樣，您需要獲取大量不是很深入的知識。每個庫都需要花時間學習，每個庫都有自己的特點，某些活動在一個庫中非常簡單，但是在另一個庫中只是有可能實現。每個庫都用不同的方式看待GUI程式設計。我寧願學習一種解決方案，然後用於所有的應用程式。通過這種方法，我就不用學習GUI解決方案，然後開始深入研究。理想情況下，這將會是一個在所有平臺上都產生一致結果的真正的程式語言。我相信要解決使用者介面問題，需要一種專注於使用者體驗的特定於域的語言。對於我來說，基於Flash技術（比如Flex）是此問題的最佳解決方案。（我正在安排與Adobe簽訂一份顧問協議，以幫助他們向大眾培訓Flex的知識。但是很久以前我就確信Flash，特別是Flex是使用者介面問題的最佳解決方案，在Adobe表示對我的幫助感興趣之前我就開始編寫這篇文章了）。

什麼是Flex？
         一般而言，Flash內容和應用程式是使用Flash著作工具建立的，該工具的當前版本為Flash 8 Professional（這容易混淆，但是在10年前就決定為這個工具賦予與執行時相同的名稱了）。還有一個工具稱作Macromedia Director，這是一個針對CD-ROM的多媒體制作工具，它比Flash更早，輸出一種Shockwave格式的檔案，這種檔案在一個外掛或ActiveX控制元件中執行，這種控制元件與Flash內容很相似，卻是一個完全不同的控制元件。Shockwave也有自己的強盛時期，而且一直都被廣泛使用，特別是在遊戲中；但是Flash比Shockwave更輕量型，而且應用更加廣泛。
         Flex是一種通過程式設計開發Flash應用程式的方式。它包括一種叫做MXML的說明性XML語言和一種叫做ActionScript的程式語言，前者用於使用者界面佈局，後者是ECMAScript 的一個擴充套件集（也就是標準化的JavaScript），還包括一些額外特性，比如可選的靜態型別檢查。ActionScript是一種跨多平臺執行的語言，因此無需擔心各個平臺的差異。由於它基於ECMAScript，所以JavaScript知識能夠派上用場。所有MXML元件都是用ActionScript編寫的，如果想要編寫自己的元件，也可以使用它。Flex應用程式被直接編譯為SWF（Flash二進位制碼），然後由Flash執行時進行Just-In-Time (JIT)編譯，這可以提升其速度。
         成本是最初阻礙我使用Flex的主要考慮因素，主要是因為讀者都不願意或無法支付這些費用。在最早版本的Flex中，必須購買伺服器版本才能建立靜態SWF。伺服器版本是針對動態內容設計的，對於從資料庫或類似程式建立動態SWF的大型企業來說，花這些錢當然是值得的。但是對於只想嘗試一下Flex的人來說，沒有理由花這些錢。如果一般人沒有一個合理的實驗方法，包括建立靜態SWF以從他們自己的伺服器交付，那麼我將很難推薦Flex。但是，現在您可以下載免費的命令列Flex編譯器建立靜態SWF，也可以從您的web站點交付這些SWF，無需支付任何費用。編譯器、框架和偵錯程式都是免費的，所以沒有理由不使用Flex。
可以購買Flex Builder IDE幫助建立Flex應用程式。這是構建在Eclipse平臺之上的（而不是從頭建立一個新的GUI開發系統——一種明智的方法）。它擁有我們預期的常用功能，比如自動編譯、上下文幫助、除錯，以及GUI佈局工具。開始設計時，可以使用佈局工具快速入門，但是我發現，設計好草案之後再進行手動調優會更有用。
        以下是我過去遇到的一些問題：儘管針對Windows和Mac的Flash播放器總是同時釋出，但是針對Linux的Flash的釋出時間會晚很多。我最初不知道，直到我推出了Thinking in C eSeminar的第一個測試版並收到Linux和Mac使用者對Flash的抱怨時才知道。通過一番調查之後，我決定向後移植應用程式（這是可行的，而且Flash 7包含了所有需要的功能）。這對於我來說似乎是最好的解決方案，因為我不需要等到新版本的Flash發布，而且不用擔心Linux。我使用Flash的一個主要目的是讓應用程式具有跨平臺的透明性，以及將安裝問題最小化。但是，Flash 9及其以後的版本，所有播放器的釋出間隔只有數週，Flash的後續版本也會採用這種策略。因此現在您不用擔心任何人抱怨了。使用Flex構建您的UI，它一定會“正常執行”。

將Flex用作圖形DS
        Flex的一個最吸引人的地方是，Flash一開始就是根據UI的思想建立的。在一個非常真實的感覺中，它是一種針對圖形、多媒體和UI的特定於域的語言，而大多數其他解決方案都是一種後來才新增上UI庫的語言。由於這個設計目標，Flex和Flash提供了一種用於構建使用者體驗的完整、無限制、靈活的工具。從程式設計人員的時間投資立場來看，您只需學習一種用於構建UI的語言，無需擔心以後碰到問題或限制——問題包括：
         • 安裝問題
         • 功能限制
         • 陡峭的學習曲線
可以使用許多奇特的元件——Flex Framework（免費下載的一部分）附帶了超過100個元件。還有一個活躍的元件建立者市場，包括開源的和付費的。Adobe建立了一個這樣的庫：Flex Charting Components（在幾百美元以內），但是還有很多吸引人的圖表元件。
         當然，Ajax的一個最有趣的方面在於，代表“非同步（asynchronous）”的“A”。這允許資訊在客戶機和伺服器之間流動，而無需重新整理整個頁面。對於Flash，Flex Data Services 提供了一個更完善的版本。這是一個用於資料管理的釋出/訂閱API。Flex Data Services在客戶機和服務器之間自動執行快取和更新，無需編寫額外的程式碼就能產生最佳的使用者體驗。這允許處理實時資料、構建協作應用程式，以及整合企業訊息傳遞。可以在單個CPU上免費使用Flex Data Services；如果您的應用程式需要多個CPU，那麼您會被當作一個企業，並且需要一定的許可費用。
        我之前提到過Gliffy，它是使用OpenLaszlo構建的。在Flex編譯器和框架變得免費之前，OpenLaszlo非常有吸引力。但是OpenLaszlo小組已經決定，他們將通過將DHTML與Flash結合提供大多數人能夠接受的技術，這消化了DHTML的侷限性。Flex吸引我的原因是，它允許我執行在常用瀏覽器中不能執行的操作，而且無論在哪裡，這些操作都會產生相同的結果。另外，Flex比OpenLaszlo發展更快，這是因為它利用了Flash 9中的JIT編譯器。因為現在Flex是免費的，沒有理由不使用它。

桌面上的Flex
         當然，如果我的夢想是能夠深入學習一種GUI系統，那麼這個工具會是Flex嗎？因為它最初就是設計用於web RIA的？
          Flex UI可以發起與它的伺服器或者它選擇的任何其他伺服器的通訊。伺服器不能發起與Flex UI的通訊，這一點很重要，因為可以保證安全性（這類似於計算機上有一個開放埠）。
但是，Flex UI不僅能夠與伺服器通訊，它還能與本地應用程式通訊。因此，可以用自己喜歡的任何語言（甚至是像Python或Ruby這樣的動態語言）建立應用程式，然後使用Flex構建一個漂亮的UI。
         Adobe正在開發一個叫做Apollo的新工具，這是一個跨OS執行時，它支援使用Flex建立桌面RIA。這意味著您的Flex技能可以進一步用於建立流暢的桌面應用程式，而且它也意味著可以更輕鬆地構建在web和桌面上都 能執行的應用程式（我曾經見過支援其他語言來實現這個功能的昂貴且難用的工具）。

結束語
        我們顯然不能等待Sun修復Java的所有問題。最終，開源Java也許會對修復Java缺陷產生巨大影響。例如，Java Media Framework (JMF)中的工作可能會恢復。或許有一天會修復安裝問題。這完全有可能，但如果您現在就需要解決問題，那麼解決方案是對該語言的各部分各取所長。我們已經這麼做了。您沒有堅持為一個應用程式使用一個資料庫；您使用一個專門的系統，比如MySQLOracle。Sun能夠直接支援針對混合Java/JRuby程式設計的JRuby開發。我們將會看到其他具有特殊用途的語言將會出現，用以解決專門問題。如果專門的系統能夠更好地解決這個問題，為什麼要堅持為UI使用一個Java庫呢？
       正如TurboGears-Flex demo I created with James Ward所示，可能使用一種像Python（或者Java、Ruby、C#或其他）語言作為後端並使用Flex構建使用者介面。這甚至可以在桌面應用程式上實現（使用即將釋出的Apollo工具能實現更多）。

更多資訊
        您可以在Adobe.com web站點和http://www.flex.org/上了解關於Flex的所有資訊。這是一個非常豐富的站點，其中包含大量示例、教程和螢幕錄影。它們甚至有一個線上Flex編譯器，可以立即嘗試。還有一個James Ward提供的關於使用Flex開發的深入簡報。還有另一個正在製作的螢幕錄影，展示瞭如何將Flex作為Java伺服器應用程式的前端使用；當它完成之後，我會在Developer Center中通知大家。下載Flex（試用或者購買）。您現在可以在伺服器（可以在其硬體上執行Linux）上建立低成本、功能強大的Java組合，以及在客戶機上建立互動式Flash介面。

關於作者
        Bruce Eckel編寫了許多關於計算機程式設計的著作和文章。他經常舉行鍼對計算機程式設計人員的演講和講座，他是ANSI/ISO C++標準委員會的建立成員。他最著名的著作是Thinking in Java和Thinking in C++，適用於物件導向程式設計經驗很少的程式設計人員。大多數評論家都認為這些著作比大多數關於Java或C++的介紹性文章更有價值，而且更加適用於教學。他的這兩本著作都可以免費下載。但是，他的最新著作Thinking in Java, Fourth Edition不再提供免費版，也不提供電子版。

 

注：以上內容來自網路，本人不承擔任何連帶責任

文章轉自：http://news.csdn.net/n/20080229/113994.html