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 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 Concurrency 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。