英文原文： Java EE 8 wish list 編譯：王果 （2013年7月發表於CSDN資訊）
Java EE 7已於6月中旬正式發佈，新版本提供了一個強大、完整、全面的堆棧來幫助開發者構建企業和Web應用程序——爲構建HTML5動態可伸縮應用程序提供了支持，並新增大量規範和特性來提高開發人員的生產力以及滿足企業最苛刻的需求。
下面的這個圖表包含了Java EE 7中的各種組件。橙色部分爲Java EE中新添加的組件。
儘管新的平臺包含了諸多新的特性，但是開發者對此似乎並不滿足，儘管他們中的大部分還沒有遷移到Java EE 7（或許是由於Java EE 7的特性還不完善），但是這並不影響他們對於Java EE 8特性的設想。
比如，在Java EE 6發佈（2009年12月10日發佈）後，開發者Antonio Goncalves認爲該版本並沒有解決一些問題，因此寫了一個希望在Java EE 7中包含的 特性清單。有趣的是，他寫的4個特性中，其中有2個（flows和batch）已經包含在Java EE 7中了，而第3個特性（caching）原本也計劃包含其中，但由於開發進度關係，在Java EE 7最終發佈前被捨棄。
此舉促使開發者 Arjan Tijms也寫了一個他希望在Java EE 8中出現的特性清單，如下。
- 無處不在的CDI（Contexts and Dependency Injection for Java EE，上下文與依賴注入）
- 更深入的Pruning（修剪）和Deprecating（棄用）
- 一個標準的緩存API
- administrative objects（管理對象）的應用內替代品
- 綜合的現代化的安全框架
- 平臺範圍內的配置
下面就來詳細闡述這些特性的必要性。
1. 無處不在的CDI
實際上這意味着2種不同的東西：使CDI可以用在目前不能用的其他地方、基於CDI來實現和改造其他規範中的相關技術。
a. 使CDI可以用在其他地方
與Java EE 6相比，Java EE 7中的CDI的適用範圍已經擴大了很多，比如CDI注入現在可以工作在 大多數JSF組件（artifacts）中，比如 基於bean validation的約束驗證器。不幸的是，只是大部分JSF組件，並非所有的，比如轉換器和驗證器就不行，儘管 OmniFaces 1.6將支持這些特性，但最好是在Java EE 7中能夠開箱即用。
此外，Java EE 7中的CDI也沒有考慮到 JASPIC組件，在此之中注入操作將無法工作。即使http請求和會話在Servlet Profile SAM中可用，但是當SAM被調用時，相應的CDI作用域也不會被建立。這意味着它甚至不能通過bean管理器以編程方式來檢索請求或 會話bean作用域。
還有一種特殊情況是，各種各樣的平臺artifacts可以通過一些替代的註解（如@PersistenceUnit）來注入，但早期的注入註解（@Resource） 仍然需要做很多事情，比如DataSource。即使Java EE 7中引入了artifacts（如任務調度服務），但也不得不通過“古老”的@Resource來注入，而不是通過@Inject。
b. 基於CDI來實現和改造其他規範中的相關技術
CDI絕對不應該只專注於在其他規範中已經解決的那些問題，其他規範還可以在CDI之上來實現它們各自的功能，這意味着它們可以作爲CDI擴展。以Java EE 7中的JSF 2.2爲例，該規範中的 兼容CDI的視圖作用域可作爲CDI擴展來使用，並且其新的flow作用域也可被立即實現爲CDI擴展。
此外，JTA 1.2現在也提供了一個CDI擴展，其可以聲明式地應用到CDI託管的bean中。此前EJB也提供了類似的功能，其背後技術也使用到了JTA，但是聲明部分還是基於EJB規範。在這種情況下，可以通過JTA來直接處理其自身的聲明性事務，但是這需要在CDI之上進行。
儘管從EJB 3版本開始， EJB beans已經非常簡單易用了，同時還相當強大，但問題是：CDI中已經提供了組件模型，EJB beans只是另一個替代品。無論各種EJB bean類型有多麼實用，但是一個平臺上有2個組件模型，容易讓用戶甚至是規範實現者混淆。通過CDI組件模型，你可以選擇需要的功能，或者混合使用，並且每個註解提供了額外的功能。而EJB是一個“一體”模式，在一個單一的註解中定義了特定的bean類型，它們之間可以很好地協同工作。你可以禁用部分不想使用的功能。例如，你可以關閉bean類型中提供的事務支持，或者禁用@Stateful beans中的passivation，或者禁用@Singleton beans中的容器管理鎖。
如果EJB被當做CDI的一組擴展來進行改造，可能最終會更好。這樣就會只有一個組件模型，並且具有同樣有效的功能。
這意味着EJB的服務，如計時器服務（ @Schedule、 @TimeOut）、 @Asynchronous、 @Lock、 @Startup/@DependsOn和@RolesAllowed都應該能與CDI託管的bean一起工作。此外，現有EJB bean類型提供的隱式功能也應該被分解成可單獨使用的功能。比如可以通過@Pooled來模擬@Stateless beans提供的容器池，通過@CallScoped來模擬調用@Stateless bean到不同的實例中的行爲。
2. 更深入的Pruning（修剪）和Deprecating（棄用）
在Java EE平臺中，爲數衆多的API可能會令初學者不知所措，這也是導致Java EE如此複雜的一個重要原因。因此從Java EE 6版本開始就引入了 Pruning（修剪）和Deprecating（棄用）過程。在Java EE 7中，更多的技術和API成爲了可選項，這意味着開發者如果需要，還可以包含進來。
比如我個人最喜歡的是JSF本地託管bean設施、JSP視圖處理程序（這早在2009年就被棄用了），以及JSF中各種各樣的功能，這些功能在規範文件中很長一段時間一直被描述爲“被棄用”。
如果EJB組件模型也被修剪將會更好，但這有可能還爲時過早。其實最應該做的是繼續去修剪EJB 2編程模型相關的所有東西，比如在Java EE 7中依然存在的home接口。
3. 一個標準化的緩存API
JCache緩存API原本將包含在Java EE 7中，但不幸的是，該API 錯過了重要的公共審查的最後期限，導致其沒能成爲Java EE 7的一部分。
如果該規範能夠在Java EE 8計劃表的早期階段完成，就有可能成爲Java EE 8的一部分。這樣，其他一些規範（如JPA）也能夠在JCache之上重新構建自己的緩存API。
4. 所有管理對象（administrativeobjects）的應用內替代品
Java EE中有一個概念叫“管理對象（administrative objects）”。這是一個配置在AS端而不是在應用程序本身中的資源。這個概念是有爭議的。
對於在應用服務器上運行許多外部程序的大企業而言，這可以是一個大的優勢——你通常不會想去打開一個外部獲得的應用程序來改變它連接的數據庫的相關細節。在傳統企業中，如果在開發人員和操作之間有一個強大的分離機制，這個概念也是有益的——這可以在系統安裝時分別設置。
但是，這對於在自己的應用服務器部署內部開發的應用程序的敏捷團隊來說，這種分離方式是一個很大的障礙，不會帶來任何幫助。同樣，對於初學者、教育方面的應用或者雲部署來說，這種設置也是非常不可取的。
從Java EE 6的@DataSourceDefinition開始，許多資源（早期的“管理對象”）只能從應用程序內部被定義，比如JMS Destinations、email會話等。不幸的是，這並不適用於所有的管理對象。
不過，Java EE 7中新的 Concurrency Utils for Java EE規範中有明確的 選項使得它的資源只針對管理對象。如果在Java EE 8中，允許 以一個便攜的方式從應用程序內部配置，那麼這將是非常棒的。更進一步來說，如果Java EE 8中能夠定義一種規範來明確禁止資源只能被administrative，那麼會更好。
5. 綜合的現代化的安全框架
在Java EE中，安全一直是一個棘手的問題。缺乏整體和全面的安全框架是 Java EE的主要缺點之一，尤其是在討論或評估競爭框架（如Spring）時，這些問題會被更多地提及。
並不是Java EE沒有關於安全方面的規定。事實上，它有一整套選項，比如JAAS、JASPIC、JACC、部分的Servlet安全方面的規範、部分EJB規範、JAX-RS自己的API，甚至JCA也有一些自己的安全規定。但是，這方面存在相當多的問題。
首先，安全標準被分佈在這麼多規範中，且並不是所有這些規範都可以用在Java EE Web Profile中，這也導致難以推出一個綜合的Java EE安全框架。
第二，各種安全API已經相當長一段時間沒有被現代化，尤其是JASPIC和JACC。長期以來，這些API只是修復了一些小的重要的問題，從來沒有一個API像 JMS 2一樣被完整地現代化。比如，JASPIC現在 仍然針對Java SE 1.4。
第三，個別安全API，如JAAS、JASPIC 和JACC，都是 比較抽象和低層次的。雖然這爲供應商提供了很大的靈活性，但是它們不適合普通的應用程序開發者。
第四，最重要的問題是，Java EE中的安全機制也遭遇到了“管理對象”中同樣的問題。很長一段時間，所謂的Java EE聲明式安全模型主要認證過程是在AS端按照供應商特定方式來單獨配置和實現的，這再次讓安全設置對於敏捷團隊、教育工作者和初學者來說成爲一件困難的事。
以上這些是主要的問題。雖然其中一些問題可以在最近的Java EE升級中通過增加小功能和修復問題來解決。然而，我的願望是，能夠在Java EE 8中，通過一個綜合的和現代化的安全框架（儘可能地構建在現有安全基礎上）將這些問題解決得更加徹底。
6. 平臺範圍內的配置
Java EE應用程序可以使用部署描述文件（比如web.xml）進行配置，但該方法對於不同的開發階段（如DEV、BETA、LIVE等）來說是比較痛苦的。針對這些階段配置Java EE應用程序的傳統的方法是通過駐留在一個特定服務器實例中的“管理對象”來實現。在該方法中，配置的是服務器，而不是應用程序。由於不同階段會對應不同的服務器，因此這些設置也會隨之自動改變。
這種方法有一些問題。首先在AS端的配置資源是服務器特定的，這些資源可以被標準化，但是它們的配置肯定沒有被標準化。這對於初學者來說，在即將發佈的應用程序中進行解釋說明比較困難。對於小型開發團隊和敏捷開發團隊而言，也增加了不必要的困難。
對於配置Java EE應用程序，目前有很多可替代的方式，比如在 部署描述符內使用（基於表達式語言的）佔位符，並使部署描述符（或fragments）可切換。許多規範已經允許指定外部的部署描述符（如web.xml中可以指定外部的faces-config.xml文件，persistence.xml中可以指定外部的orm.xml文件），但是沒有一個統一的機制來針對描述符做這些事情，並且沒有辦法去參數化這些包含的外部文件。
如果Java EE 8能夠以一種 徹底的、統一平臺的方式來解決這些配置問題，將再好不過了。似乎Java EE 8開發團隊 正在計劃做這樣的事情。這將會非常有趣，接下來就看如何發展了。
結論
Java EE 8目前尚處於規劃初期，但願上面提到的大多數特性能夠以某種方式加以解決。可能“無處不在的CDI”的機率會大一些，此方面似乎已經得到了很大的支持，且事情已經在朝着這個方向發展了。
標準化緩存API也非常有可能，它幾乎快被包含在Java EE 7中了，但願其不會再次錯過規範審查的最後期限。
此外，“現代化的安全框架”這一特性已經被幾個Java EE開發成員提到，但是此方面工作尚未啓動。這可能需要相當大的努力，以及大量其他規範的支持，這是一個整體性問題。順便說一句，安全框架也是Antonio Goncalves關於Java EE 7願望清單中的第4個提議，希望Java EE 8可以解決這一問題。