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