Java EE 8主要功能

banq發表於2018-12-13

Java EE 8包含與Java開發人員相關的大量更改。這是構成Jakarta EE基礎的版本。事實上,在Eclipse Foundation的管理下發布的Jakarta EE 8可能會與Java EE 8有密切聯絡。我們將在本文中高階概述Java EE 8的變化,包括檢視一些有代表性的程式碼示例。
Java EE 8的一個獨特特徵是:它已成為Java歷史上最受社群意見驅動的主要技術釋出之一。Java EE 8的範圍不是由一個,而是由兩個獨立的開發人員調查決定的 - 一個是在Java EE 8開發之前進行的   ,另一個是在  Java EE 8釋出之後進行的
因此,Java EE 8是一個功能完備的版本,特別適合於那些不需要基於雲原生的細粒度微服務功能的應用程式。這些功能已透過Eclipse MicroProfile計劃引入Java EE生態系統,並可能標準化為Jakarta EE 9或更高版本。

Servlet 4
Servlet 4是Java EE 8中最重要的變化之一.Servlet 4的主要目標是為伺服器端Java提供HTTP / 2支援。HTTP/2是協議的基本現代化,它將網際網路保持在一起。
因為支援HTTP/2主要是協議層更改,所以可以由Servlet 4執行時透明地處理,而無需任何API更改。

JSON-B(用於JSON繫結的Java API)
使JSON成為平臺的一等公民自Java EE 7以來一直是一個目標。使用JSON不需要安裝或配置另一個庫。為此,在Java EE 7中引入了一個名為JSON-P(Java API for JSON Processing)的低階解析API .Java EE 8引入了一個基於更高階別註釋的宣告性JSON繫結API,稱為JSON-B,它真的讓人感覺到就像JSON一樣,它與Java EE中的Java序列化一樣原生。
我們的想法是,將POJO轉換為JSON或從JSON轉換應該只是預設工作,而無需新增任何註釋。

JSON-P 1.1
JSON-P在Java EE 7中功能相當完善。在Java EE 8中,JSON-P在Web標準空間中整合了更新功能,例如JSON-Pointer,JSON-Patch和JSON-Merge / Patch。

SSE(伺服器傳送的事件)
SSE是HTML 5中鮮為人知的部分.SSE允許透過HTTP進行伺服器到客戶端的事件流傳輸。在引擎蓋下,SSE只是一個長期存在的HTTP連線,它使用專門的內容型別:text / event-stream。事件通常是隨著時間的推移從伺服器傳送到客戶端的不同JSON物件。SSE對“股票程式碼”型別的應用程式和監視控制檯很有用。使用JAX-RS 2.1,Java EE 8中的伺服器和客戶端都支援SSE。服務端程式碼如下:

@Path("tickers"public class StockTicker {  
    @Resource ManagedExecutorService executor; 
 
  
 
    @GET @Produces("text/event-stream") 
    public void getQuotes( 
            @Context SseEventSink sink,  
            @Context Sse sse) { 
        executor.execute(() -> { 
 
            ... 
 
            sink.send(sse.newEvent(stockqoute)); 
 
            ... 
 
        }); 
    } 
}


在示例中,瀏覽器將使用“tickers”端點連線到伺服器,通常使用JavaScript SSE客戶端API。JAX-RS 2.1端點在後臺執行緒中生成一系列股票報價更新,並使用Sse事件構建器實用程式透過SSE事件接收器連線管道將它們傳送到客戶端。除了端點和客戶端之間的一對一連線外,JAX-RS 2.1還支援向多個連線的客戶端廣播相同的SSE事件。

Java EE安全性
在Java EE 8之前,保護Java EE應用程式主要是透過面向管理員(如控制檯GUI嚮導)的應用程式之外的配置工具完成的。這種方法的主要缺點是它在Java EE實現中不是很容易移植,儘管一些安全需求非常普遍。新Java EE安全性API的目標是透過引入完全可嵌入的身份驗證和授權,使通用,簡單的安全性需求可移植。這是透過完全包含註釋和CDI來實現的。在較高的層次上,引入了三個新功能:

  • 可以透過簡單註釋指定應用程式是使用基本,基於表單還是自定義身份驗證。
  • 可以透過簡單的註釋來指定身份驗證和授權(身份)資料儲存在資料庫或LDAP目錄中。參考實現還包括內建的嵌入式身份儲存。如果內建標識儲存不夠,則可以在應用程式中使用簡單的CDI bean作為標識儲存。
  • 透過CDI注入提供通用安全上下文。此上下文提供了有關當前登入使用者的資訊的控制程式碼,可以在任何地方使用,包括自定義安全攔截器。這是現有@RolesAlllowed 註釋的補充  。


CDI 2
CDI 2的一個關鍵變化是普通Java SE環境中的引導機制的標準化。這意味著將CDI分為三個部分 - 核心,Java SE和Java EE。這些更改使CDI可以被更多技術採用 - 在Java EE內部和外部。例如,這些變化使CDI成為MicroProfile計劃的核心技術。CDI 2的另一個關鍵變化是使事件完全非同步

事件傳送pub:

@Inject
@CargoInspected
Event<Cargo> cargoInspected; 

public void inspectCargo(TrackingId trackingId) {  
    cargoInspected.fireAsync(cargo); 
} 


接受方sub:

public void onCargoInspected(@ObservesAsync @CargoInspected Cargo cargo) {
...
}


inspectCargo 方法在其內容cargoInspected.fireAsync呼叫後立即返回,不會等待 fireAsync結果,接受方onCargoInspected觸發是在另外一個執行緒, 從CDI 2開始,事件也可以分配優先順序。(banq注:這個方法四年前在jdon框架中實現了,基於Distuptor,Jdon框架直接支援DDD,而JavaEE竟然對DDD熟視無睹,繼續支援JPA,其實JPA沒有Spring Data JDBC對DDD支援得更好)

CDI 2還對其可擴充套件性API進行了幾處簡化,以進一步鼓勵CDI外掛生態系統。最後,CDI 2適應Java SE 8的功能,例如lambdas、completable future、Stream等。

已經為Java EE 8到JMS 2.1定了一個關鍵的向CDI看齊功能。JMS 2.1旨在建立基於CDI的JMS偵聽器模型來替換EJB訊息驅動的bean。同樣,可以透過Java EE Con​​currency Utilities向所有CDI bean提供諸如@Asynchronous和@Schedule之類的EJB註釋。不幸的是,Oracle決定停止Java EE 8的這項工作。這可能是作為Jakarta EE 9的一部分完成的工作。幸運的是,一些棄用EJB的工作是在Java EE 8中完成的,例如修剪CORBA互操作性。

MVC
Java空間中最古老的Web框架 - Struts - 是基於MVC的
Struts建立者Craig McClanahan幫助建立了JSF,並支援一種高度抽象的基於元件的方法,該方法最接近原始的Smalltalk MVC模式。雖然JSF繼續擁有強大的追隨者,但即使在Craig建議轉向JSF之後,基於action的框架仍在繼續向前發展。
最近,一些開發人員認為基於action的方法特別適合以HTML 5 / JavaScript為中心的Web生態系統。出於這些原因,除了JSF之外,Java EE 8還計劃包含一個新的基於action的框架 - 簡稱為MVC。
在Java EE中構建MVC相對簡單,因為大多數基本部分已經存在。CDI,Bean Validation和JPA可用於該模型。Facelets和JSP可用於檢視(此外,MVC參考實現支援Velocity,FreeMarker,Thymeleaf等)。大多數控制器功能可以使用JAX-RS。
儘管MVC規範已經取得了快速進展,但Oracle決定停止這項工作。但是,Oracle將這項工作捐贈給社群,MVC現在幾乎已經透過社群完成,並且它也被轉移到Eclipse Foundation。儘管Java EE 8沒有定義MVC標準,但Jakarta EE可能包含MVC實現。

總結
Java EE 8包含許多對社群和行業很重要的重要功能。此外,Java EE將落實到Jakarta EE中,在Eclipse Foundation下走向更加開放的未來。參考實現也有GlassFish 5完全相容Java EE 8,Payara 5包括所有Java EE 8功能。此外,Open Liberty,WebSphere Liberty和WildFly現在都支援Java EE 8。可以有理由地相信JBoss EAP和TomEE也在支援Java EE 8或Jakarta EE 8。
 

相關文章