英文原文：Java EE 8: A bird’s eye view

"期待 JakartaEE 8？ 在本文中，Reza Rahman探讨了Java EE 8的一些主要变化和新特性，这是即将推出的 Jakarta EE 8的基础。通过更多Web标准和CDI对齐，Java EE 8将更加简洁。"

Java EE 8 包含与 Java 开发人员相关的大量改动。这是构成 Jakarta EE 的基础。事实上，Jakarta EE 8-在 Eclipse Foundation 的管理下发布的，与 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或更高版本。

重要主题

Java EE 8有几个可区分的主题。 在深入了解功特点细节之前，让我们先简要介绍一下这些主题。

• Web标准对齐

            HTTP / 2，SSE，JSON

• CDI对齐

            CDI 2，JSF 管理 bean 修剪，注入 JSF 工件，JPA 中的 CDI 支持

• 简单

            安全性，EJB 修剪

• Java SE 8对齐

            JSF，JPA，JAX-RS，JMS，Bean 验证，JSON-P，CDI

Java EE与Java EE 7中的Java EE标准一致，其中包括WebSocket 1.0，JSON-P 1.0，JAX-RS 2中的超媒体支持和JSF 2.2 HTML / 5对齐等更改。 Web标准对齐主题在Java EE 8中持续使用，其中Servlet 4支持HTTP / 2，JAX-RS 2.1支持SSE（服务器发送事件），JSON-B的引入和JSON-P的重大改进。

自Java EE 6引入以来，CDI已成为关键的Java EE技术。最终目标是使CDI成为Java EE中的核心编程模型。在Java EE 7中，JSF，JMS，Bean Validation和JTA等技术改进了它们与CDI的一致性。 Java EE 8继续使用JSF 2.3，JPA 2.2和 Security 1.0 这一主题。此外，CDI 2本身引入了自CDI 1.0以来该技术的最重要变化（CDI 1.1和CDI 1.2具有重要但更微小的变化）。

主题的简化性始于Java EE 5，并 Java EE 8 继续使用。在每个版本中，尽可能简化平台的每个可能剩余角落。 Java EE 7 中的一个很好的例子就是JMS 2。在Java EE 8中，最重要的例子是Security 1.0。由于这些变化，现在Java EE 8的安全性可能比其他任何主要服务器端技术都要简单。

Java EE 总是尽可能多地利用 Java SE 中改进。最明显的例子是Java SE 5全面采用注释，EJB 3 / Java EE 5成为第一主流技术。在Java SE 8和Java EE 8技术中有许多引人注目的变化，如JSF2.3，JPA 2.2，JAX-RS 2.1，Bean Validation 2和JSON-P 1.1，有效地适应了这些变化。

Servlet 4

Servlet 4 是 Java EE 8 中最重要的变化之一。Servlet 4 的主要目标是为服务器端 Java 提供 HTTP/2 支持。 HTTP/2 是保持互联网连接协议的基本现代化。

HTTP 最初设计时考虑到了一个非常简单的 Web  - 一个请求只能生成一个响应，可能是带有一些超链接的纯 HTML 页面。如今的网络要复杂得多。单个页面包含许多可能的相关资源 - 图像，样式表，脚本，视频等。因此，性能有所下降，因为每个依赖资源都是通过单独的 HTTP 请求检索的。 HTTP/2 旨在通过修复此阻抗不匹配来提升 Web 性能。HTTP/2 允许通过单一初始 TCP 连接从服务器传输多个资源来实现此目的。连接中的每个资源由多路复用进入独立、适当优先级的流中。HTTP/2 还使用二进制成帧来显着改善带宽使用以及跨相关资源的共享/压缩报头。最后，HTTP/2 还有一种所谓服务器推送的机制，用于主动向下发送来自服务器的所有相关资源和初始页面请求，而浏览器甚至不解析任何 HTML。

由于这些主要是协议层更改，所以它们可以由 Servlet 4 运行时透明地处理，而无需任何 API 更改。 Servlet 4 认证测试表明容器已经正确实现了 HTTP/2 。由于不存在 HTTP/2 的其他认证过程，因此 Servlet 4 认证测试非常重要。 Servlet 4 确实引入了一个简单的，向后兼容的 API 更改来启用服务器推送。然而，在 JSF 2.3 / Java EE 8 用户的情况下，即使这种变化也在较低层次上被透明地吸收。

JSON-B（JSON 绑定的 Java API）

从 JavaEE7 开始，就树立了将 JSON 变成平台的一等公民的目标。开发者可以不用安装或者配置其他第三方库直接使用 JSON。为了实现这个目标，在 Java EE 7 中引入了一个称之为 JSON-P（JSON 处理的 Java API）的底层的解析 API。Java EE 8 又引入了一个更高级别的注解，它基于声明式的 JSON 绑定 API，即 JSON-B，用起来就像是 Java EE 中本地的序列化一样。这个想法是说不需要增加额外的注解，POJO 与 JSON 就可以相互转化。JSON-B 的确只包含了少部分的注解用来自定义映射关系，比如 @JsonbProperty（用来重命名字段）以及 @JsonbTransient（用来在序列化时忽略被注解字段）。下面代码示例实际展示了这些概念。

@GET ... 
 
@Produces("application/json") 
 
public Person getPerson(...) { 
 
    ... 
 
    Person duke = new Person(); 
 
    duke.setName("Duke"); 
 
    duke.setGender("Male"); 
 
    phones = new HashMap<>(); 
 
    phones.put("home", "650-123-4567"); 
 
    phones.put("mobile", "650-234-5678"); 
 
    duke.setPhones(phones); 
 
  
 
    return duke; 
 
}

在上面的例子中，Person 的 POJO 没有任何 JSON-B 注释。因为 JAX-RS 2.1 集成了 JSON-B 在 Java EE8 （和 JSON-P）中，Person的 POJO 将在 HTTP 响应中自动转换为下面的 JSON，因为输出被指定为 “application / json” 类型。

{"name":"Duke", 
 
 "gender":"Male", 
 
 "phones":{ 
 
     "home":"650-123-4567", 
 
     "mobile":"650-234-5678"}}

 

JSON-P 1.1

在 Java EE 7 中 JSON-P 已经是一个相当完整的特性了。在 Java EE 8 中 JSON-P 合并了 Web 标准空间上的升级，如 JSON-Pointer、JSON-Patch 以及 JSON-Merge/Patch。JSON-Pointer 提供了在 JSON 结构中通过类 URL 路径的形式查找字段值的能力。JSON-Patch 是一个和 HTTP PATCH 十分类似的概念，它允许通过命令修改 JSON 文档的部分内容（命令本身也是 JSON 对象）。JSON-Patch 依赖 JSON-Pointer 完成 JSON 结构中的位置引用。JSON-Merge/Patch 类似于 JSON-Patch，不过它提供了进行 JSON 结构合并和差异比较的能力。

示例代码是最好展示和理解这些功能的方式，那咱们就从下面的 JSON 结构开始：

[{"name":"Duke", 
 
  "gender":"Male", 
 
  "phones":{ 
 
      "home":"650-123-4567", 
 
      "mobile":"650-234-5678"}}, 
 
 {"name":"Jane", 
 
  "gender":"Female", 
 
  "phones":{ 
 
      "mobile":"707-555-9999"}}]

下面的代码段展示了 JSON-Patch 命令如何修改上面的 JSON 结构的。第一个命令是更新“Duke”的手机号码。第二个命令是从 persons 列表中删除“Jane”。/0/phones/mobile 和 /1 就是 JSON-Pointer 的示例。除了替换和删除，JSON-Patch 还支持添加、移动、复制和测试等操作。

[{"op": "replace", "path":"/0/phones/mobile",  
 
    "value":"650-111-2222"}, 
 
 {"op": "remove", "path":"/1"}]

下面的代码演示了 JSON-P 1.1 如何实现这些 JSON-Patch 的操作。target 对象中保存了 persons 数组的 JSON-P 结构。如你所见，JSON-P API 通过 builder 形式工具方法实现了这些操作。

JsonPatchBuilder builder = new JsonPatchBuilder(); 
 
JsonArray result = builder 
 
    .replace("/0/phones/mobile", "650-111-2222") 
 
    .remove("/1") 
 
    .apply(target);

SSE(服务器端事件)

SSE是HTML5中鲜为人知的一部分。SSE允许基于HTTP的服务器端到客户端的事件流。究其内核，SSE只是使用了特定内容类型（text/event-stream）的HTTP长连接。事件通常是按时间从服务器发送到客户端的不同JSON对象。SSE十分适合“股票实时数据”类型应用以及监控平台的应用场景。在Java EE 8中，JAX-RS 2.1同时实现了服务器端和客户端对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)); 
 
            ... 
 
        }); 
 
    } 
 
}

在这个例子中，浏览器通常可以采用JavaScript SSE客户端API，通过“tickers”端点连接到服务器端。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 注释的补充。

本文中的所有译文仅用于学习和交流目的，转载请务必注明文章译者、出处、和本文链接。 2KB翻译工作遵照 CC 协议，如果我们的工作有侵犯到您的权益，请及时联系我们。

2KB项目（www.2kb.com，源码交易平台）,提供担保交易、源码交易、虚拟商品、在家创业、在线创业、任务交易、网站设计、软件设计、网络兼职、站长交易、域名交易、链接买卖、网站交易、广告买卖、站长培训、建站美工等服务