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. 所有管理對象（administrative objects）的應用內替代品
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目前尚處于規劃初期，但愿上面提到的大多數特性能夠以某種方式加以解決?？赡?#8220;無處不在的CDI”的幾率會大一些，此方面似乎已經得到了很大的支持，且事情已經在朝著這個方向發展了。
標準化緩存API也非常有可能，它幾乎快被包含在Java EE 7中了，但愿其不會再次錯過規范審查的最后期限。
此外，“現代化的安全框架”這一特性已經被幾個Java EE開發成員提到，但是此方面工作尚未啟動。這可能需要相當大的努力，以及大量其他規范的支持，這是一個整體性問題。順便說一句，安全框架也是Antonio Goncalves關于Java EE 7愿望清單中的第4個提議，希望Java EE 8可以解決這一問題。