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