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不再提供免費版，也不提供電子版。
