1、空前繁榮的開源世界
大致2000年以前，Java世界還是Sun一言九鼎，唯我獨尊的時代。Sun發佈的任何規範和標準都無一例外地被Java社區有意無意的追捧着，Java世界沉浸在一片歌功頌德，前擁後簇的氛圍裏。IBM，Bea，Oracle這些Java陣營的代表者也都爲能最先最快實現Sun的各種規範而彈冠相慶。
但這三四年來，Java的列車駛進了春秋戰國百家爭鳴，百花齊放的時代，Apache，JBoss，opensymphony，Eclipse，Codehaus等開源組織個個門庭若市，車水馬龍。Java世界似乎天天在過年--張燈結綵，新桃換舊符。打開theserverside.com網站，每天映入眼簾是一條條各種開源項目發佈、升級的新聞。雖然嘈雜了些，但卻異彩紛呈，驚豔四座。在Java世界裏，十室之內必有隱士，十步之內必有芳草，有才華的程序員太多了，抑或懷才的程序員被獨裁式的統治壓抑太久了，一旦找到了海德公園，龐涓、孫臏、蘇秦、張儀式的高手紛紛走出隱居的鬼谷，在開源舞臺上勁舞一支，高歌一曲，用一個個開源項目彰顯着自己獨特的魅力。
從客戶端到數據庫，從頁面流程控制到業務流程控制，從全文搜索到地圖搜索，從論壇到博客，在各種應用領域你都可以方便地找到多個相似的Java開源框架。開源框架的空前繁榮有力的促進了Java技術的交流和分享。一些面向開源的社區，論壇紛紛建立，國內比較著名的就有滿江紅開源論壇、中文Spring論壇、JavaScud開源平臺、JavaEye社區等，宣講、爭論、協作、互動，無數激情和智慧碰撞出耀眼的火花。
隨着開源項目的日益增多，國內甚至出現了象open-open.com Java開源大全的彙總整理網站，它如一個開源項目的大集市，將開源項目分類整理，提供簡要的描述說明信息，方便使用者瞭解、查詢和比較。
開源項目的繁榮還爲技術圖書業創造了機會，不管是國外的Amazon，還是china-pub或dearbook，開源框架或產品的技術圖書，如Spring，Hibernate，Struts，Eclipse等等都成爲榮登榜首的暢銷先鋒。
這場幾乎來源於民間的開源颶風給開發者和CTO們的思路和決策帶來了巨大的影響，據Bea的調查，全球排名前2000家軟件開發公司中有70%以上在使用一種或多種開源框架--多達28%的公司在開發環境中使用了一種以上的應用服務器。
同時開源也給走傳統路線的Java巨頭們帶來戰略性的影響：Sun去年宣佈將其旗艦產品--Solaris開源；去年IBM向第三方廠商開放了其高性能通用並行文件系統（GPFS）的源代碼；Unisys也改變企業戰略定位投入開源懷抱等等不勝枚舉，它們紛紛將營利模式從原來的產品銷售調整爲支持與服務。
2、開源框架帶來的煩惱
雖然開源的框架、類庫越來越豐富，可供選擇的替代者越來越多，但Java程序員卻感覺自己慢慢陷入到了技術的漩渦之中：因爲他們發現只要一段時間不關注開源社區，就有潮水般陌生的技術框架、專業術語、英文縮略詞挾裹着一團團亢奮的熱浪將自己淹沒，讓他們覺得隨時都有被Java世界拋棄的危險。許多年紀稍大的程序員甚至覺得職位轉換，甩掉技術幹管理已經時不我待。
選擇的困惑
雨後春筍般湧現的開源框架都聲稱自己是最好的，有過多次因盲從於技術鼓吹而失望傷心的經歷後，現在的開發者都變得成熟理智了，他們不會輕易相信某個框架自身的承諾，不會輕易附和他人的宣傳，這確實是件好事。爲了作出理智的選擇，他們往往要自己親自摸索以做出評判。
有時，我們會發現向上司推薦一個框架已經變成一件困難的事情，因爲上司會冒出各種各樣的問題：如Webwork比Struts好在哪裏？Hibernate和iBatis有什麼區別？OpenWFE比之jBpm有什麼優勢等等。所以要確定一個框架時，往往需要將相似的框架都研究一遍，以便有充足的理由讓上司相信我們的選擇是最優的。
但是，要將同類的框架都做一次研究並比較優劣並非易事，如開源工作流引擎就有Willow，OpenWFE，jBpm，Werkflow，OSWorkflow等不下30餘種的框架，炫耀的聲音一個比一個響亮。每種框架都有自己的設計思路和實現方案，況且這種技術預研性的工作，又不可能在項目週期內佔用太多的時間，而不深入預研又不可能客觀地作出評判，所以往往是熬紅的雙眼依然帶着迷茫的目光。
此外，用人單位爲了減少新員工的培訓時間，對求職者往往有明確的框架使用技能和經驗的要求。求職者爲了能找到一個好工作，不得不逼迫自己學習更多的框架，以便讓自己擁有更多的求職機會。
搭配的困難
開源的繁榮雖然給各個領域都造就了許多優秀的框架，如Spring，Struts，Hibernate，Lucene、OSCache等等，但卻沒有出現一個一站式，統管全局的整合開發框架。開發者在享用大餐之前，事先得充當大櫥的角色，將這些鹽，油、醬、菜按合理的方式調配好。
雖然，我們一直強調整體大於單個的總和，但是如何將單個"個體"正確的組合成發揮更大效應的"整體"卻並非易事。因爲這些單獨的框架都由不同的團隊開發，框架與框架之間存在天然的阻抗，這種框架和框架之間的"代溝"需要額外配置和編碼才能彌合。
每個框架都擁有自己的配置文件，框架的整合經常帶來配置的災難，如將Spring和Struts整合時，不僅Struts本身的配置文件一個不能少，在Spring中還需要每個Action提供配置信息，而且兩者需要遵守一定的契約。
相互搭配的框架和框架之間經常會出現相似的或重複的功能，如何取捨，如何使用往往讓開發者們爲難。如Spring本身提供了AOP方法返回結果的緩存功能，而Hibernate本身也提供二級緩存，究竟兩者都使用呢，還是擇一而從？往往中間又會引出很多爭論。
框架整合的問題已經日益突出，我們可以在各開源論壇或社區發現大量有關討論的主題。
目前也出現了一些試圖解決的框架整合問題的開源項目，如國外的AppFuse，國內的SpringSide，爲框架的整合提供了專業的指導。但是並沒有很好的解決現實開發中的實際需要。這些整合框架爲了增加通用性，網都撒得太大，導致整合框架本身象一個龐然大物，讓人望而生畏，定製性和靈巧性上都存在不足，降低了它們的實用性，所以這些整合性的開源項目往往降格爲指導性的實例。
升級的困擾
活躍的框架每天都在升級改造，豐富功能。其次由於開源框架在一定程度上存在隨意性，往往導致框架在實際使用後，發現大量隱含的Bug，所以有時對某個框架的升級變得不可避免。開源框架比之Sun正規的規範有着更加靈活的升級方式，高低版本不兼容的問題已經成爲司空見慣的事情。如著名的Hibernate，其3.0版本和2.0版本的包名都發生了徹底的變化，剛發佈的Acegi和低版本也存在很大的差異，無法兼容。
一個整合性的框架由多個出自於不同團隊的框架組成，整合框架在這些組合框架之上高位運行，底層框架的升級變化就造成了組合框架水漲船高的局面，整合框架脆弱的穩定性很容易被打破。
組合框架的升級還直接帶來了開發團隊學習的壓力，爲了熟悉框架新功能和改進，在開發工作之餘，他們不得不努力壓榨自己的業餘時間不斷地充電學習。總是某個框架新功能學習還未完成，另一個框架的新版本又在一陣歡呼聲中閃亮登場，讓開發人員發現自己所有的努力只是一場騎牛追馬遊戲。
3、開發者如何走出迷局
框架的爆炸性增長和技術更替一日千里的速度，讓剛剛從傳統J2EE迷局中走出來的開發者重新墮入了新的困境之中。有許多切身體驗的開發者在網上大倒苦水，甚至有許多聲音在吶喊，希望重新回到JSP+JavaBean＋JDBC那個純真的年代中去。
框架的作者們本想還軟件開發一個清新美滿的世界，不想個體性的良性企盼變成了一種整體性的混亂紛爭。在紛繁複雜的開源世界如何走出迷局和困境，把握自己技術航船的方向，是每個開發者們冥思遐想的事情。
重點學習 觸類旁通
每個人的時間是有限的，對於週期緊，進度急，加班趕的開發者來說更加如此，使得開發者不可能 "識遍天下字，讀盡人間書"逐個學習框架。選擇好適合自己、適合項目的框架進行重點學習尤爲重要。不但要掌握技術細節，更要理解框架的原理和思想，這樣在接觸相關框架時，我們才能觸類旁通，慧眼識真。
如果你深入理解了Struts框架的MVC的原理和思想，在接觸Tapestry，Spring MVC等框架時，你會發現兩者只是形上的區別，而非質上的差異，即使因現實需要確實要轉換框架時，也可以輕鬆平滑地過渡。
不求最好 但求適用
開發人員往往都是完美主義者，吹毛求疵，帶着濃重的偏執狂傾向。是的，偏執狂是優秀程序員的一個特點，時下《只有偏執狂才能生存》也正在大賣熱賣，Rod Johnson，Gavin King，Oberg也都是偏執狂。
但在有進度工期壓力的情況下，我們不得不向實現妥協。對於公司來說，利潤永遠都是第一位的，不管用不用框架或用什麼框架，只要能如期保質保量完成用戶的所有功能需求，就是最好的項目。客戶永遠看不到，也不關心你使用了哪個優秀的技術和框架。
所以，在實際的開發中，也許我們常常需要委曲內心的衝動，只要目前的框架能滿足需求，我們沒有必須象服裝界一樣趕追時髦，一切不求最好，但求適用。
如果Spring Template JDBC已經很好的滿足了目前的需求，就沒有必要一定要上Hibernate，如果自己開發的簡要列表控件效果不錯，就無須轉換爲ExtremeTable。新框架的學習需要代價，但這種代價的價值在實際發揮功效之前是不被肯定的。況且看似不合時宜的那些簡單而古老的技術也可以做出強大的系統，如世界上最大的java項目--巴西全國醫療系統，就是構建在JSP＋JavaBean＋Servlet之上。
注重積累 搭建平臺
我們常常發現一些軟件公司自身沒有任何積累，完全寄希望於這些整合框架解決所有的問題。開源框架解決的都是某個領域的通用性問題，每個公司由於其所處行業，服務用戶的不同，要求公司擁有自己的解決方案，框架的通用性和公司的個性化需求是存在矛盾的。
軟件公司應該加強自身的積累，在這些框架的基礎上搭建好符合自身需求的快速開發平臺，屏蔽掉底層框架的複雜功能和細枝末節，降低對開發人員的技能要求，以便新員工能夠快速參與到項目中，而無需進行一個個開源框架的學習。
雖然這種積累和平臺的建設會耗費額外的工作量，但首先它是一個循序漸進的過程，其次這種任務僅由兩三個技術突出的技術人員承擔，帶來的好處是直接降低了其他開發人員使用難度和技術要求，在一定程序上避免了開源框架的所帶來的不穩定性影響。
4、小結
開源的繁榮帶來了豐富的框架，有力的推動了業界的發展，同時我們也看到，這種繁榮所帶來的驚喜背後緊跟着許多困惑的眼神，迷失在繁榮的混亂之中的開發者們希望走出困惑，走出迷局。
如何在嘈雜喧鬧的開源世界把握方向尋求突破，不管是對於開發者還是軟件公司的決策者都值得深深的思考。