原文發布于2013年5月14日

　　在 2003 年用 Java 編程比現在要更痛苦一些。比如說，J2SE 1.5 還沒有發布，也就是說一些現在大家認為理所當然的特性，比如泛型容器、static import、Annotation，都是不存在的；Integer 和 int 是不能自動轉換的；枚舉只是整數換了個寫法沒有任何類型安全機制……我還在 2003 年第 6 期《程序員》雜志發表了一篇文章，介紹 J2SE 1.5 的新特性。而在項目里，不管是浙江省財政廳的項目，還是杭州市工商局的項目，我們用的都還是 J2SE 1.3。

　　更大的挑戰——或者說，樂趣——是框架乃至編程思想的不統一。幾年以后，當 Java 企業應用開發徹底成熟，所有人都知道 SSH（Spring+Struts+Hibernate，后來 Struts 終于被 SpringMVC 取代），連培訓學校也拿這幾樣東西來作為就業敲門磚。可是在 2003 年，Martin Fowler 那篇“Dependency Injection”還沒發表，關于“什么是好的容器框架”還遠遠沒有定論。且不提 Apache Avalon 這樣的容器——照現在的眼光來看，Avalon 根本算不上一個合格的容器，但你必須意識到它是 Java 1.3 之前的作品，這樣才能理解為什么它會存在并進入這個討論——Spring 之外還有 Paul Hammant 和 Jon Tirsen 的 PicoContainer 在與之競爭成為事實標準。而當時還在 0.x 版本的 Spring（當年 10 月 Spring 才發布 1.0 版本），其功能也并不比單純專注對象容器的 Pico 豐富。

　　Web 框架的情況更加混亂。Struts 被使用最多同時也被詬病最多；Rickard Oberg 剛做出了 WebWork，大家還沒充分意識到它的好處。更麻煩的是，其時整個 J2EE 社區并未——像今天這樣——達成一個共識說“MVC 是好的”，于是其他種種構造 Web 應用的方式以及相應的框架層出不窮：有人相信 Web 開發也應該走“組件化”道路，于是有了面向組件的 Web 框架（例如 Tapestry ）；有人認為 Portal 才是未來 Web 的發展方向，于是有了形形色色的 Portlet 容器（例如 JetSpeed ）；甚至還有人嘗試用“XML 文檔 +XSLT 轉換”的方式來實現 Web 應用。當年最火的全功能 Web 框架還是 Turbine ，到如今它給我們留下的也就只剩 Velocity 了——恰恰 Velocity 所代表的“view template engine”在當時還沒有被廣泛接受，更多人仍然習慣于在 JSP 里直接寫上一大堆 Java 代碼。當時有人笑稱，每周都會有一個新的 Web 框架在 TSS 上發布——其時最具影響力的 J2EE 網上社區 TheServerSide.com 被簡稱“TSS”，由此可見那時的企業軟件世界是有多愛三字母縮寫詞。InfoQ 的創始人 Floyd Marinescu 當時還在 TSS 做內容主管呢。

　　持久化框架的情況也好不到哪兒去。Hibernate 倒是已經發布了 2.0 版本，不論功能還是性能都已接近成熟；可是 Hibernate 與 ADO 之間的爭論正在如火如荼地展開著，究竟應該選一個剛開始熱門的開源框架還是選一個“標準”也頗讓人頭疼；同時也別忘了另一邊，很多程序員更愿意用簡單的 SQL 來操作數據庫，而不是在對象與關系數據的映射中絞盡腦汁；再加上 2003 年普遍的“XML 熱病”，真的有很多人相信可以把企業應用中的數據持久化成 XML 從而拋棄關系型數據庫——你也可以說這是 NoSQL 的早期萌芽，總之當時這些思想只是讓事情變得更復雜而已。

　　當你談論 2003 年的 J2EE 世界時，千萬別忘了這里還有 EJB。實際上，EJB 2 才是當時 J2EE 的正統——再提醒一下讀者們，Spring 還在 0.x 的階段，Rod Johnson 那本旗幟般的“without EJB”還沒寫出來呢。曾經有 IBM 的咨詢師來跟我們討論應用架構，聽說我們完全沒用 EJB 時都連連搖頭。如果不是石一楹堅持不用 EJB，也許我會走上一條相當不同的技術路線。后來我一直對 EJB 不怎么上手（雖然還翻譯過一本與 EJB 關系不少的書），倒是輕量級 J2EE 架構接受起來駕輕就熟，不得不說是種運氣。

　　仿佛是嫌事情還不夠復雜，那時很多企業對開源軟件抱持一種不信任的態度，所有框架都愿意自己開發，似乎只要“not invented here”的東西就不可靠——這樣的企業現在也有，畢竟數量少多了。這里固然有心態的原因，同時技術上的原因也不應該忽視。J2SE 1.3 引入了動態代理（dynamic proxy）技術，以 Rickard Oberg 為代表的一幫天才開發者們立即敏銳地意識到：這是一件框架開發的利器——在與 JBoss Group 決裂之前，Oberg 是 JBoss 的首席架構師，可以說是他一手創造了 JBoss；同時他也是 AOP 和 Interception 的狂熱愛好者，因為他早早地看到了這些元編程技巧在框架開發中的重要意義，而動態代理則正是讓 Java 不依賴于外部的、非標準的代碼生成技術（例如 AspectJ、CGLib 等）實現動態元編程的基礎設施。其結果是，從 Java 1.3 開始，很多新的框架顯著地變得更優雅、更少侵入性——Java 1.3 之前的“老”框架，例如 Avalon、Turbine，與這些后來者比起來就顯得相形見絀。然而這種優雅同時也意味著更難理解其內部運作機制，有時對著一個漂亮的框架就仿佛在看一場精彩的魔術，愉悅之余也難免有些心里犯嘀咕。正處在這場轉變之中的企業和團隊，希望自己動手開發框架從而獲得更多安全感，也是情有可原。

　　不過這種復雜、混亂與缺乏信心對于程序員來說倒未嘗不是好事。短短的幾個月時間里，我的項目主管帶著我把 J2EE Web 應用的全套框架——對象容器、持久化、Web MVC——都實現了一遍。這個過程不僅讓我的技術水平突飛猛漲，而且還讓我交了不少朋友：因為我比較喜歡顯擺，做出點東西就在網上談論，一來二去就結識了一些與我有著同樣困惑的同行。在這些“以技術會友”的新朋友之中，最有趣的是一個叫 DreamHead 的家伙。這人每每寫郵件長篇大論洋洋千言，博客也是一副正襟危坐的范兒。我們討論的主要就是這些基礎框架與架構，沒想到類似的話題我竟然與他一直討論了十年。