保持領先
VMware 提供培訓和認證,為您的進步注入動力。
瞭解更多招聘資訊是衡量技術實際採用情況的良好指標。它們表明公司是否正在花錢,從而能夠區分實質內容和炒作;它們表明開發人員獲取和發展相關技能的重要性(這是技術永續發展的重要因素);它們還為公司採用特定技術的安全性提供了很好的指導。
因此,作為招聘資訊聚合網站 Indeed.com 的 jobtrends 網站是一個重要的資源。它允許跟蹤一段時間內招聘需求的數量趨勢,並便於比較各種技術。
有時,這些趨勢可能具有戲劇性的影響。Indeed.com 顯示,在 2007 年 11 月,Spring 在 Java 招聘資訊中作為技能要求超越了 EJB。截至昨天,Spring 的相關職位數量為 5710 個,而 EJB 為 5030 個。
比較絕對職位數量,我們可以看到趨勢線以及它們交叉的位置
考慮到大量的遺留 EJB,這令人驚歎。據推測,現在很少有新專案使用 EJB 了。
比較各自增長率的“相對”圖表更加有趣,顯示了這兩種技術之間的鮮明對比
我們看到 EJB 的需求停滯不前或正在下降,而 Spring 的需求正以不斷增長的速度增長。
當然,Spring 和 EJB 並非互斥。使用 Spring 並不會妨礙您使用 EJB,反之亦然。在某些情況下,EJB 提供的有用服務可能是使用 Spring 的應用程式所需要的。在不使用 Spring 的情況下使用任何版本的 EJB 都意味著放棄許多寶貴的額外能力。事實上,很大程度上是支援 EJB 的遊說者(出於某種原因)將這兩種技術視為直接競爭對手。
這兩種技術之間的重疊是顯著且不斷增長的,但增長速度不及 Spring 需求增長的速度
雖然這不是一個完全對等的比較,但將 Spring 和 EJB 視為企業 Java 應用程式核心元件模型的替代方案是合理的。而且很明顯,現在哪一個正在崛起。
我必須承認有一定的個人滿足感,考慮到我自 2003 年初以來一直在預測 EJB 將成為遺留技術,並且在 此之前 就認為 EJB 被過度使用。在 《不用 EJB 的 J2EE》 一書中,我詳細分析了 EJB 模型的缺點以及它如何未能實現其既定目標或滿足開發者和客戶的需求。那時,這樣的說法極具爭議性。
EJB 3.0 在一定程度上有所改進,但仍然太少、太遲:其 DI 能力低於實際世界所需的證明;攔截 API 認識到需要解決橫切關注點,但提供的解決方案是目前為止最無能、最笨拙且最容易出錯的(這是我一直想寫部落格的主題);它揹負著與現已無關的上一代技術向後相容的包袱;完整的 EJB 合同(比“簡化程式設計模型”長數百頁)規定了一個複雜且開銷過大的執行時環境;儘管有語法糖,它未能解決 EJB 中的許多缺點,例如啟動操作、單例和過時的執行緒模型。最後,在基礎設施不斷變化的時代,它實際上與應用伺服器環境緊密繫結。
我可以滔滔不絕地講述這些缺點,但招聘數字反映了數千家公司的實際經驗和結論。
請注意,我這裡談論的是會話 Bean 和訊息驅動 Bean;JPA 現在是一個獨立的規範,基於現代技術,並且正在證明其價值。
EJB 的衰落對整個行業以及個人開發者意味著什麼?
坦白說,EJB 時代是個反常現象。EJB 未能解決本世紀初的問題;對於未來的問題,它更加不適用。EJB 的大多數最初前提現在已被否定;該規範對向後相容性的堅持並不能為其帶來的權衡付出代價辯護。它的衰落是進入一個嶄新、更流暢的世界的自然結果,在這個世界中,OSGi 等技術以及樸實的 Servlet API 被證明更加相關。當然,由於絕對數字仍然很高,EJB 不會在短時間內完全消失。但趨勢線清楚地表明,它正在成為遺留技術。
在我們宣佈 SpringSource Spring 認證計劃 之前,招聘要求中出現這一里程碑是及時的。現在 Spring 是市場上如此重要的技能,對於僱主和開發者來說,有一個明確衡量 Spring 知識的標準非常重要。
關於 Spring 發展勢頭的進一步證明,最近由行業領先網站釋出的 2007 年統計資料給出。在 ServerSide 上,排名前 5 的文章中有 2 篇 關於 Spring,其中包括排名第一的文章。在 InfoQ 上,排名前 10 的文章中有 3 篇關於 Spring,其中排名第一的文章(我的 Spring 2.0 Update)的頁面瀏覽量是下一篇最受歡迎文章的 4 倍。