關于JavaEE 6的依賴注入一直是各廠商和社區中的熱議話題，近日，JSR宣布JSR-299采用了JSR-330的注解，兩者都將成為Java EE 6的一部分。今年初，Google Guice和剛剛被VMware收購的SpringSource宣布將合作提出一套標準的用于依賴注入的注解，即JSR-330。但這些注解與JSR-299卻并不一致，隨后引發了眾多的爭論，不過現在一切都已經塵埃落定。

有不少人針對JSR-299與JSR-330的沖突談到了自己的一些看法，列舉如下：

◆Gavin King：我認為引入另一套語義上與299相同的注解完全是個錯誤，而且其嘗試解決的問題也與299大同小異。
Bob Lee：雖然299對于那些小型的Java EE應用來說很適合，但其全局配置以及不直接的天性使之很難適應于數百萬代碼行的應用，就像Google所開發的。我們能夠在Guice上輕松支持299風格的注解，但卻無法通過299實現Guice的全部功能，因此沒有理由放棄Guice而轉向299。就我個人來說，我認為你們在299上已經進行了不少的創新，但卻沒有完全理解用戶代碼是需要維護的這個事實。

◆Alex Miller：向JSR 299領域進軍是個危險的信號。

◆Antonio Goncalves：我希望我們不要打響一個新的戰役，就像Java Module（JSR 277）和Modularity Support（JSR 294）之間那樣。

◆Rickard Öberg說出了反對意見：相對于泛泛的使用@Inject這樣的注解，我們選擇使用能代表目標對象范圍的注解，因為什么都是也意味著什么都不是。
 
JSR-330已經通過了JSR評審的投票，但眾多投票者都強調了兩個規范的和諧相處：

◆Sun：我們希望該JSR能與JSR-299共同努力以便為SE和EE平臺達成一個一致、全面的依賴注入標準。這個標準務必先于該JSR的公共預覽版發布前形成。

◆Red Hat：我們認識到該草案是有社區支持的，因此打算在專家組發布公共草案時再發表最終意見。如果該JSR與JSR-299之間能達成某種一致（這種一致性會為依賴注入定義一種輕量級的模型），那我們會毫不猶豫地投出贊成票。Red Hat承諾會為這種一致性貢獻自己的一份綿薄之力。

◆Ericsson：我們支持為標準化Java SE的依賴注入所付出的努力，但更想強調的是保持與JSR 299的一致性對于Java SE和EE都是非常重要的。

◆IBM：我們也認為這樣一份描述SE應用的依賴注入規范是很有必要的，然而所提出的注入模式卻與EE平臺中的定義有出入。SE/EE的注入模型必須要形成一個單獨可擴展的編程模型：為SE定義一套核心功能并通過EE的功能對其進行擴展。因此，要是不統一的話，IBM是不會支持JSR 299或是330的。

◆Oracle：雖然支持該JSR，但Oracle嚴重關注該草案的完整性及其與JSR 299的分歧，因為這可能會導致平臺的分裂。因此，我們期望在該JSR的公共預覽版發布前能與JSR 299達成一致。我們相信JSR 250的一個修訂或是維護版會比較適合發布依賴注入相關的注解。最終我們希望這種一致性的努力會讓SE和EE平臺的依賴注入保持一致，形成一個標準化的機制以滿足各種需求。
 
目前這些規范之間的沖突已經得到解決。JSR-330（面向Java的依賴注入）以及JSR-299（面向Java EE平臺的上下文與依賴注入）已經達成一致了，后者將采取前者的注解，兩者都將成為Java EE6的一部分。

什么是依賴注入

依賴注入就是使類型之間的依賴關系可配置，也就是在運行時通過配置文件等手段確定類型之間的依賴關系。而沒有使用依賴注入的時候類型之間的關系是硬編碼在程序中的。

【編輯推薦】

1. Apache對JavaEE 6說“不”
2. Java EE 6新特性嘗鮮：EJB 3.1重要變化總覽
3. Java EE 6遙遙無期 預覽版兩極分化
4. 漫漫征途 Java EE 6離我們還有多遠
5. Java EE 6草案提交 新特性一覽