發表日期 4/3/2022, 10:20:34 AM
作者|Steve Hannah
翻譯|核子可樂
編輯|燕珊
2004 年 Google Maps 的麵世標誌著 Java 桌麵時代的終結,也改變瞭桌麵環境下“跨平台”的基本定義。
本文作者以個人視角對 Java 桌麵發展曆程做瞭迴顧,內容來自他在上世紀九十年代後期擔任 Java 開發者時的所見所感,主要講述曾經的“殺手級”桌麵語言 Java 是為何從 21 世紀開始頹勢盡顯、步入衰落的。值得一提的是,作者如今在做一款開發者友好型 Java 桌麵部署工具(jDeploy),其實他還是希望 Java 可以重拾風采,再度變得對桌麵開發具有吸引力。
本文是該迴顧係列文章中的第二篇,在上期文章中,作者迴顧瞭 Java 製霸桌麵的鴻圖如何在 1999 至 2005 的短短幾年間煙消雲散。當初的 Java 可謂誌得意滿、憑 Applet 小程序技驚四座,下決心要在互聯網時代下重新定義“桌麵”。互聯網的未來在於“跨平台”,而 Java 的血管中湧動的正是“跨平台”的血液,優勢在握!可遺憾的是,事後來看,此跨平台似乎並非彼跨平台。接下來,讓我們繼續跟著作者的腳步去看看,具體在 2004 至 2007 年間,Java 桌麵又經曆瞭什麼。
桌麵王朝的最後時光
2002 年左右,我在客服中心為客戶提供計算機與打印機技術支持。我和小夥伴們擠在小小的隔間裏,麵對著一款桌麵程序。通過這款軟件,我們可以快速查詢客戶和産品信息,並把通話中的重要信息記錄進去。
在典型的客服來電中,我們會詢問客戶的産品序列號,再把結果輸入係統。如果他們之前就打過電話,係統就會輸齣窗口,裏麵包含産品的完整曆史記錄和之前的求助細節。在參考其他同事留下的事由記錄後,我還能操作界麵中的選項卡和功能按鈕,例如幫客戶更換新機。
我不記得這款軟件叫什麼名字瞭,可能是為公司或者客服中心專門定製的吧。印象裏這應該是 PeopleSoft(仁科公司,2005 年已被甲骨文收購)的産品,但我也不太確定。總之,這款桌麵軟件運行在 Windows 2000 係統上,肯定不是 Web 應用程序。它其實挺復雜,裏麵包含不少菜單和錶單;不過一旦上手,整個使用體驗相當棒――速度快、反應靈敏,幾乎沒有任何延遲。以輸入電話號碼查詢客戶記錄為例,我們隻需要在“電話”字段裏輸入號碼,其餘空白錶格就會立刻被客戶信息填充完整。
據我所知,這款程序肯定不是用 Swing 編寫的。但如今全球各地無數公司都在使用由 Swing 編寫的企業級桌麵軟件,它們在使用體驗上跟我當初接觸的這款程序非常相似。換句話說,Swing 已經滿足瞭我們在 2001、2002 年那會對於桌麵業務軟件的全部期望和想象。
在工作半年之後,上邊來瞭新指示,要求我們用 Web 應用程序替換掉之前的桌麵軟件。據說新係統會讓我們的工作更輕鬆,但在第一節培訓課剛剛過去十分鍾後,我們就意識到這根本就是鬍說八道:新係統簡直爛透瞭!
我不太記得當時使用的是 IE 5.5 還是 IE 6 瞭,總之就是前 AJAX 時代的 Web 環境。現在在産品字段中輸入序號後,係統會彈齣一個窗口,上麵寫著“正在加載……請勿關閉此窗口”。幾秒後,窗口自行消失,客戶詳細信息齣現在錶單當中。反正每當需要從服務器獲取內容時,這個倒黴窗口就會跳齣來。領導還提醒我們彆隨便在瀏覽器裏點“刷新”,說是這樣會破壞係統狀態。於是每每齣現問題,我就隻能先登齣、再重新登錄。
我不太理解公司為什麼要用這款“傻瞭吧唧”的 Web 應用程序替代之前的桌麵軟件。可能是齣於成本考慮吧,畢竟跟桌麵軟件相比,Web 應用程序的開發和維護成本都更低。或者是軟件供應商強行施壓,比如“Web 纔是未來,每個人都必須接受!”但,真有這麼強勢的乙方嗎?
無論如何,這裏透露齣一個重要的信息: Web 應用程序還沒等發展完善,就已經開始蠶食桌麵軟件的生存空間。唯一的問題就是 Web 應用需要多久纔能追平桌麵軟件的使用體驗。而事實證明,用不瞭多久。
恐怖榖效應
再迴到 Java 這邊。熱情的支持者們正不斷擴大 Java 帝國的桌麵版圖,對 WORA(一次編寫、隨處運行)的熱情也引導他們最終邁嚮跨平台小程序與“本機”應用程序之間的秘密山榖。那時候的 Java IDE 主要麵嚮三大構建目標:
1. 小程序
2. Java Web 開發
3. 可執行 Jar 文件
是的,沒有直接開發本機應用程序的選項。雖然有第三方工具可以把 Jar 文件轉換為本機應用程序,但這類工具相當復雜而且操作流程極為繁瑣。隻有對自己最“狠”的人纔能堅持用得下去。而 Java 之所以有勇氣忽視這一點,靠的就是對未來的判斷――本機桌麵應用程序終於被淘汰。其實這個預言是正確的,隻是在時間上有所偏差。
從 2022 年的角度迴顧,Java 身上其實有很多顯而易見的問題。應用程序可以作為 Web 部署、也可以按本機部署,但這兩種形式都沒有一丁點“原生”感。Web 部署的小程序運行在自己的“沙箱”內並被集成到網頁當中,整個運行過程又慢又遲鈍。
HTML5 的崛起
雖然 Java 總想在 Web 和桌麵之間建起一道橋梁,但它自身卻被 Web 所裹挾。到 2002 年,很多企業開始把原本的桌麵軟件功能遷移到 Web 端。這些 Web 應用程序的構建、維護和部署成本確實比桌麵軟件低得多,代價就是在用戶體驗上做齣妥協。
大約也是在這個時候,Java 開始推崇“富互聯網應用”的概念,希望把好 Web 應用跟差 Web 應用區分開來。但到 2004 年 Google Maps 正式亮相時,Java 的小把戲徹底宣告破産。Google Maps 以令人震驚的效果為富 Web 應用程序樹立瞭標杆,而人傢用的是 HTML5。
我最近又看瞭一次 Bill Atkinson 第一次嚮蘋果愛好者們展示 MacPaint 的舊視頻。在他第一次通過鼠標用畫筆工具繪齣圖案時,現場一片“哇哦”和掌聲。這就叫開創性。我第一次看到 Google Maps 也是類似的感覺,地圖可以無縫縮放、萬嚮平移,壓根看不齣來任何拼接的痕跡。這裏使用的全新技術被稱為 AJAX(異步 JavaScript 與 XML),這也是人們第一次能夠在 Web 應用程序中嚮服務器後台無縫發齣請求。現在這一切當然被視為理所當然,可 2004 年那會,開發者需要絞盡腦汁纔能把那些讓人想吐的框架或者彈窗隱藏起來,確保不用刷新整個頁麵就能從服務器處加載新數據。
身為 Web 開發者,我當然對其中的無窮可能性心生嚮往。但從桌麵開發的角度看,這場曆史性的變革似乎沒有給桌麵、特彆是 Java 帶來任何影響。
在 HTML5 之前,“跨平台”的意思是“跨 Windows、Mac 和 Linux”,所以跨的範圍還是在桌麵範疇之內。當時我並沒意識到,但現在來看 HTML5 的亮相代錶著新平台時代的降臨――它將成為客戶端應用程序的客觀標準;更重要的是,Java 支持不瞭這個平台。突然之間,WORA 理念就齣現空白瞭――Swing 應用程序適用於一切平台,除瞭最重要的那個:網絡瀏覽器。
Java 開發者紛紛“外逃”
那 Java 桌麵開發者們都跑哪去瞭?方嚮主要有三:
1. 服務器
2. 瀏覽器(HTML5)
3. 桌麵應用
如果大傢對自己的基本定位首先是“Java 開發者”、其次是“客戶端開發者”,那最終應該會選擇 Java 在當下仍然占據主動的平台――服務器。如果你對麵嚮用戶開發(客戶端)更感興趣,而且主要看中 Java 的跨平台價值主張,那接下來的目標很可能是 HTML5 (Javascript/HTML/CSS)開發。如果你是鐵杆“保皇黨”(比如說我),那就繼續堅守 Java 桌麵開發,同時滿腹狐疑地看著自己這個圈子越來越小。
GWT:讓 Java 走進瀏覽器
2000 年初,JavaScript 開發工具尚處於起步階段。大多數 Web 開發者隻能使用文本編輯器來編寫.js 文件。簡單的驗證腳本和交互設計倒是沒問題,但這種粗糙的方法肯定不能擴展並支持大型企業應用程序項目。另外,當時的 JavaScript 語言還不具備開發者在重構等重要操作時所需要的功能,例如靜態類型。
相比之下,Java 已經擁有一套全麵的開發工具,能夠輕鬆擴展至任何規模的項目。到 2004 年,領先且成熟的 Java IDE 已經成為開發環境中的標杆,其中的靜態類型更是大大簡化瞭大型項目的維護難度。到這時,唯一的遺憾就是 Java 應用程序無法在網絡瀏覽器中運行(隻有小程序可以)。
為瞭解決這個難題,Google 打造齣 GWT(Google Web Toolkit)。這是一套 Java 到 JavaScript 的編譯器加運行時庫,允許開發者藉助 Java 那一整套領先的開發工具編寫應用程序,再把成果部署成 JavaScript 應用的形式在瀏覽器內原生運行。這套運行時庫包含諸多核心 Java API(例如 java.lang、java.util 等)的實現,確保業務邏輯能夠在 GWT 應用程序與服務器應用程序間順暢共享。
在用戶界麵方麵,GWT 也提供自己的功能部件,其實質就是以 Java 的形式將各部件與瀏覽器中的本機 HTML 部件相綁定。雖然我們還是沒法直接使用 Swing 代碼、大部分第三方庫也不在支持之列,但我們至少可以用到自己最熟悉的 Java 開發環境和核心 API。
所以這不能算是讓 Java 真正走進瞭瀏覽器――標準 JavaSE 庫仍然大部分不受支持,綫程等核心功能也無法起效。但至少對多數用例來說,這已經夠瞭。
Google 用 GWT 開發齣很多流行一時的 HTML5 應用程序,其中最著名的就是 Gmail,這個項目還催生齣一個規模不大、但卻相當活躍的開源社區。雖然影響力已經今非昔比,但這個社區直到現在也仍然存在。與此同時,JavaScript 工具的逐步改進也在擠占 GWT 的生存空間,過去十年來誕生的一係列更為現代的解決方案也允許我們在瀏覽器中更“無腦”地使用 Java。
服務器上的淘金熱
HTML5 的齣現顛覆瞭 Java 製霸桌麵的野心,但這裏也有好消息。由於不必分神於桌麵端,Java 在服務器端迎來瞭全麵發展。Java 做好瞭戰鬥準備、努力滿足開發者對後端服務的種種新需求――畢竟沒有後端,再好的 Web 應用也齣不來。
Java 在服務器端的受歡迎程度在接下來幾年中持續增長,也吸引到整個生態係統的高度關注。第三方庫不斷湧現,而 2005 年 Maven 的誕生也讓第三方庫的使用不再復雜繁瑣。無需額外下載、不必尋找依賴項,直接把片段粘貼到 pom 文件中,它就能自動下載一切相應依賴項。
Java 的開發工具也在不斷改進,這在很大程度上要歸功於 Java 在服務器端的優勢地位。這些改進也對桌麵開發者産生瞭積極影響,讓我們用上瞭跟服務器端相同的 IDE、編譯器、虛擬機和庫。然而,代錶 Java 世界“最後的堅持”的這幫桌麵開發者眼界還是沒能打開,仍在圍著 UI 庫的改進和部署打轉。
遇到問題時,我的習慣是上 Google 搜一搜,看看有沒有其他人遇到或者已經解決過相同的問題。但在 Swing 開發上,我發現最新的搜索結果也基本是 2005 年左右的內容瞭,之後基本再無新增。在找不到答案時,我偶爾會寫一篇問題分析博文。而在兩年後再次遇到類似問題時,我在 Google 上找到的就是自己兩年前那篇博文……說真的,現在還有喘氣的 Swing 開發者嗎?感覺真的說不好。
重新定義“桌麵應用”
從各個方麵來看,Web 的興起讓“桌麵應用”的概念清晰瞭起來。Java 最初的跨平台客戶端開發願景並沒有把瘦客戶端(主要與遠程服務器交互)跟本機完整桌麵應用程序區分開來。這不僅提高瞭理解難度,更讓安全模型的設計有些無所適從。Java 理解中的“平台”就是計算機本身,所以會使用笨拙的沙箱來限製可能引發安全威脅的 API 訪問,例如訪問文件係統。這是 Java 一切安全漏洞的根源,也是導緻 Java 被逐齣瀏覽器世界的原因。
這種基於“沙箱”的開發體驗相當糟糕,因為我們很容易意外“越界”並觸發安全異常。最終結果是,幾乎所有客戶端都會請求對係統進行“可信”訪問,這樣也就完全繞過瞭沙箱的限製。
相比之下,HTML5 在 Web 和桌麵之間設立瞭明確的邊界。Web 應用程序默認無權訪問客戶端計算機,而瀏覽器纔是那個“平台”,這就讓客戶端應用程序的安全保障變得更輕鬆、更易行。
經過此番變革,“桌麵”的範疇變得更小,以往很多被視為“桌麵應用程序”的軟件現在被劃入“客戶端應用程序”類彆。具體來講,如果應用程序隻負責在用戶與服務器交互時提供 UI,那它就屬於客戶端應用程序。“桌麵”這個概念現在指的就是那些以某種方式與本機設備相集成的應用程序,包括訪問文件係統(開發工具、文件轉換工具等)、調用瀏覽器中不存在的某些平台本機 API、以及執行算力密集型任務的軟件。
這倒不是說“客戶端”應用程序跟“桌麵”應用程序間就毫無交集――當然有,這兩者都涉及 GUI,而且不少現代桌麵應用程序也都需要接入服務器。所以無論是桌麵還是客戶端應用程序,都能享受到 GUI 工具包改進、媒體(音頻 / 視頻)及網絡等技術層麵的改進成果。
Java 桌麵的新徵程
2004 年,我曾在 Mac 和 Windows 上都開發齣一些商用級彆的 Java 桌麵應用程序。HTML5 對這類應用程序基本沒有任何直接影響。結閤自身需求,Swing 還是完全夠用,我用來構建本機捆綁包的各種桌麵部署工具也都能正常起效。
但很遺憾,科技行業就是個不進則退的世界。在接下來的幾年中,Web 平台一路突飛猛進、而 Swing 卻始終停滯不前。到 2007 年,Swing 已經到瞭不變革、就消亡的危難關頭。它需要響應 HTML5 這波曆史性潮流,而最終答案就是 JavaFX。這是一種新奇的 Java UI 工具包,能夠把 Java 帶入 GPU 加速、場景圖、3D 圖形、Web 視圖的現代新世界,同時支持 MP3 和 MP4 等現代音視頻編解碼器。
在下一篇文章中,我們將迴顧 JavaFX 的火爆人氣、深遠影響,以及 2011 年 Mac 應用商店齣現前 Java 領域的其他發展趨勢。彆小瞧 Mac 應用商店,它的齣現堪稱對 Java for Mac 桌麵開發生態的“斬首行動”。
(感興趣的朋友可以多留言,InfoQ 將根據大傢的需求繼續翻譯係列文章,以饗讀者)
https://jdeploy.substack.com/p/the-decline-and-fall-of-java-on-the-970