Java EE 7 三大新特性的介绍

Java EE 7 的简介

Java EE 作为一个企业应用的部署平台，具有很好的健壮性、能够提供强大的 Web 服务且非常易于部署。这些年来，通过其不断发展，它已大大简化了以服务器为中心的应用程序的开发、部署和管理，已经逐渐成为企业级开发的通用标准。

1999 年，Sun 正式发布了 J2EE 的第一个版本。但从 1999 年诞生的第一个 J2EE 版本一直到 J2EE 1.4 版本，虽然它已经具有了强大的功能，但仍不太被人们接受。这是因为连实现一个简单的 J2EE 程序，都需要大量的配置文件，非常不便使用。在 2002 年，J2EE 1.4 推出后，复杂程度更是达到了顶点，尤其是 EJB 2.0，开发和调试的难度非常大。

2006 年 5 月份 Sun 正式发布了 J2EE 1.5（现改名为 Java EE 5）规范，Java EE 5 的主基调为“简化开发”。即让开发者能够更方便、高效地使用 Java EE 技术。从 Java EE 5 开始，通过引入注释、EJB 3.0 的业务组件、更新的 Web 服务和加强的持久化模型，将重心转移到提高开发人员的生产力上来。

Java EE 6 进一步简化开发流程，增加平台的灵活性，从而更好地解决轻量级 Web 应用程序。此外，Java EE 6 开始与开源架构进行无缝集成，并对现有的技术做了精简。实践证明，Java EE 6 取得了巨大成功，成功的原因主要有下面几点：

• 截至 2013 年 5 月，已有超过 50 万人次从 Oracle 和其他行业的产商下载 Java EE 组件；
• 是企业开发人员的第一选择；
• 是应用开发平台的第一选择；
• 18 家应用服务器供应商以最快的速度兼容 Java EE 不同版本。

图 1. Java EE 7 新特性

Java EE 7 扩展了 Java EE 6，利用更加透明的 JCP 和社区参与来引入新的功能，如图 1（本图引用自 Java 官网）所示，主要包括加强对 HTML5 动态可伸缩应用程序的支持、提高开发人员的生产力和满足苛刻的企业需求。

1、提高开发人员的生产力

通过一个紧密集成的平台简化了应用架构，减少样板代码和加强对注释的使用来提高效率，另外借助标准 RESTful Web 服务对客户端的支持提高了应用程序的可移植性。

2、加强对 HTML 5 动态可伸缩应用程序的支持

基于其可扩展的基础架构，Java EE 7 推动了对 HTML 5 应用的构建和支持。在新的平台中，借助具有行业标准的 JSON 简化了数据分析和交换，并通过低延迟和双向通信的 WebSockets 减少了响应时间。以及利用改进的 JAX-RS 2.0 更好地支持异步的、可扩展的、高性能的 RESTful 服务，从而更好地支持多用户的并发操作。

3、满足苛刻的企业需求

为更好地满足企业的需求，Java EE 7 提供了许多新功能：

• 细化批处理作业，形成可管理的区块，以实现不间断的 OLTP 性能；
• 简化多线程并发任务的定义，以提高可扩展性；
• 以及提供具有选择性和灵活性的事务应用程序等。

Java EE 7 开发的开放性，使得 Java 社区、供应商、组织和个人都能参与其中。19 个来自世界各地的用户组，包括来自北美、南美、欧洲和亚洲，都参与了“采用 JSR”计划，提供了宝贵的反馈意见和代码示例以验证 Java 规范 (JSR) 的 API。

在最新发布的 Java EE 平台中都大大简化了访问集装箱服务的 API，同时大大拓宽了服务范围。Java EE 7 继续秉承了简化性和高效性的趋势，并进一步拓宽了平台范围。下面就针对 Java EE 7 的三大新特性进行详细的剖析。

回页首

提高开发人员的生产力

从 Java EE 5 开始，重心就一直放在提高开发人员的生产力上。这对于 Java 开发者来说非常重要，因为这使得使用 Java EE 进行开发更加便捷，更重要的是能够满足快速管理和生产的需求。鉴于此，Java EE 7 大大提高了开发人员的生产力。首先，减少了编写大量核心业务逻辑所需要的样板代码。其次，该平台引入更多的注释 POJOS 来降低 XML 配置的复杂性。最后，Java EE 7 使用更紧密集成的技术，提供一个更加无缝的开发体验。

减少冗余代码

Java EE 7 一直在致力于减少在核心业务逻辑代码运行前必须执行的样板代码。减少样板代码的三大核心区域是默认资源、JMS 2.0 和 JAX-RS 客户端 API。默认资源是一个新的功能，要求平台提供商预配置一个默认的数据源和一个默认的 JMS 连接工厂。这可以让开发人员直接使用默认的资源而无需进行额外的定义。JMS2.0 在可伸缩性和可移植性上经历了重大的改进，减少了冗余代码，已运用在无数的产品部署上，事实证明它是一个良好的规范，能够较好地满足企业的需求。

更多带注释的POJO

通过注释 Java EE 使开发人员更专注于 Java 对象的编程而无需关注繁琐的配置。

CDI 现在默认情况下已不需要使用 beans.xml 文件就可以直接使用。开发人员可以不需要任何配置而是简单的使用 @Inject 来注入任何 Java 对象。包括新的资源注释 @JMSDestinationDefinition 和 @MailSessionDefinition ，使得开发人员在源代码中就可以指定元数据资源，简化了 DevOps 体验。

更紧密集成的平台

Java EE 6 引入了 Managed Beans 1.0 作为第一步来朝着 EJBs、JSF Managed Beans 和 CDI beans 发展。Java EE 7 继承了这一点，例如，对 JSF Managed Beans 进行了改进来更好支持 CDI Beans。Java EE 7 为平台引入了易用的 EJB 容器管理事物，使用基于 CDI 拦截器的解决方案来保证事务可用在 CDI managed beans 和其它 Java EE 组件中，把注释 @Transactional 应用到任何 CDI bean 或者任何支持事务的方法中。

Bean Validation 在 Java EE 7 中使用广泛，现在可以用于方法级别的验证，包括内置和自定义的约束。约束可被应用于方法的参数以及返回值。约束也可以使用灵活渲染和违反约束的字符串格式的 Java EE 的表达语言。

Bean Validation 也延伸到 JAX-RS 2.0。注释约束可以应用到公共构造函数的参数、方法参数、字段和 bean 的属性。此外，他们还可以修饰资源类、实体参数和资源的方法。例如，约束可以通过 @ POST 和 @ PUT 应用于 JAX-RS 方法参数来验证表单提交的数据。

通过精简现有技术来简化Java EE

Java EE 7 中新增加了许多新的特性，有些老的特性和功能已经被更简单的特性所替代或直接弃用。Java EE 6 为过时技术的弃用和功能的修剪引入了一个正式的流程，以下的 API 在 Java EE 7 中已成可选，但在 Java EE 8 中将会被移除：

• Java EE Management (JSR-77)，原本是用于为应用 服务器创建监控管理的 API，可各大供应商对此 API 热情并不高涨；
• Java EE Application Deployment (JSR-88)，JSR 88 是当初用于 J2EE 应用程序在应用 服务器上进行配置和部署的标准 API 。可是该 API 始终没有得到众供应商的支持；
• JAX-RPC，是早期通过 RPC 调用和 SOAP web services 进行交互的编程模型。由于 Web services 成熟后从 RPC 模型中分离出来，被更加健壮和具备更多特性的 JAX-WS API 所替代；
• EJB 2.x Entity Beans CMP，复杂、笨重、过度复杂的 EJB2.* 的 Entity Bean 模型已经被 Java EE 5 的基于 POJO 的流行轻量级 JPA 持久层模型所代替。

回页首

对 HTML 5 动态可伸缩应用程序的支持

HTML5 是包括 HTML、JavaScript 和 CSS3 在内的一套技术组合，它加快了开发人员创建高度互动的应用程序的步伐。开发出的应用程序都是以高度互动的方式提供实时的数据，如聊天应用程序，比赛实况报导等，并且这些应用程序只需要编写一次，就可以应用在桌面、移动客户端等不同设备上，具有非常好的跨平台性。这些高度动态的应用程序，使得用户可以在任何地点任何时间进行访问，从而对服务器端向客户端传送数据的规模提出了更高的要求。Java EE 7 在更新现有技术如 JAX-RS 2.0、Java Server Faces 2.2、和 Servlet 3.1 NIO 基础上，又借助新的应用技术 WebSockets 和 JSON 处理为支持动态应用程序 HTML5 奠定了坚实的基础。

低延迟数据交换：Java API for WebSocket 1.0

越来越多的 web 应用程序依赖于从中央服务器及时获取并更新数据。基于 HTTP 的 WebSockets 为解决低延迟和双向通信提供了一种解决方案。在 WebSocket API 的最基层是一个带注释的 Java 对象（POJO），如清单 1 所示：

清单 1. 带注释的 Java 对象（POJO）

 @ServerEndpoint("/test") 
 public class TestEndpoint{ 
 @OnOpen 
	 public void onOpen(...){ } 
 @OnClose 
	 public void onClose(...){ } 
     @OnError 
 public void onError(...){ } 
 @OnMessage 
 public void testMessage(String message,...){ } 
 }

通过注释 @ServerEndpoint 来指定一个 URI。诸如客户端连接、接收消息和客户端断开这样的回调函数都可以用注释来指定。WebSocket API 的最基层支持发送和接收简单文本和二进制信息。API 的简单性也使得开发人员可以快速入门。

当然，功能丰富的应用拥有更复杂的需求，因此需要支持对最基础的网络协议进行控制和自定义，而 WebSocket API 正好能够满足以上需求。另外，WebSocket 利用现有 Web 容器的安全特性，开发人员只需付出较少的代价就可以建立良好的保密通信。

简化应用数据分析和处理：Java API for JSON Processing 1.0

JSON 作为一个轻量级的数据交换格式被应用在许多流行的 Web 服务中用来调用和返回数据。许多流行的在线服务都是使用基于 JSON 的 RESTful 服务。在 Java EE 7 之前，Java 应用程序使用了不同的类库去生成和解析 RESTful 服务中的 JSON 对象。然而，现在这个功能已被标准化。

通过 Java API 中的 JSON Processing 1.0，JSON 处理过程标准化为一个单一的 API，应用程序不需要使用第三方的类库。这样使得应用程序更小更简便。同时 API 包括了支持任何转换器和生成器实现的插件，使得开发人员可以选择最好的实现方式去完成工作。

可扩展的RESTful服务：JAX-RS 2.0

JAX-RS 2.0 增加了异步响应处理，这对于支持对数据有着高要求的 HTML5 客户端的扩展是至关重要的。异步处理是一种更好更有效利用线程处理的技术。在服务器端，处理请求的线程在等待外部任务去完成时应该避免阻塞，从而保证在这一时间段内到达的其他请求能够得到响应。

同样的，在客户端，一个发出请求的线程在等待响应的时候也会发生阻塞，这影响了应用程序的性能。新的 JAX-RS 2.0 异步客户端 API 使得客户端调用 RESTful 可以和其他客户端活动并行执行。异步的好处是使得一个客户端可以同时调用多个后台服务，对于一个使用者来说减少了总体的延迟时间。

同时为了增强 RESTful 服务，JAX-RS 2.0 开发人员可以使用过滤器和实体拦截器。这样开发人员就可以使用标准的 API 来实现过滤和拦截功能，使开发过程变得更加便捷和高效。

增强开发的易用性：JSF 2.2

JavaServer Faces (JSF) 是一种用于构建 Web 应用程序的 Java 新标准框架。它提供了一种以组件为中心来开发 Java Web 用户界面的方法，从而简化了开发。在这个版本中，JSF 增加了对 HTML5 的支持。JSF 2.2 增加了一个叫“pass-through elements”的新功能。并为现有的元素增加了一系列的新属性，如输入元素“tel”、“range”和“date”等。不幸的是，现有的 JSF 组件不能识别这些新的属性，因此 JSF 应用程序会忽略这些属性不能进行使用，直到创建专有的解决方案。对于“pass-through elements”，JSF 渲染器将会忽略这些元素，只是把它们传给支持 HTML5 的浏览器，这使得可以利用现有的 JSF 组件来利用 HTML5 的特性来正常渲染。

JSF 引入了一个新的 pass-through 命名空间 http://xmlns.jcp.org/jsf/passthrough 映射到“p:”，任何组件的 name/value 对都可以以“p:” 开始，然后传给浏览器。如清单 2 所示，HTML 5 “type=color”不需要 JSF 组件的任何解析就可以传递给浏览器。

 <h:inputText Value=”#{bean.color}” P:type=”color” />

HTML5 的动态性使得服务器端处理信息更新的请求不断增多。在 Java EE 6，Servlet 异步 I/O 通过移除“一个请求需要一个线程”的限制，使一个线程可以处理多个并发请求。这可以使 HTML5 客户端快速得到响应。但是，如果服务器端读取数据的速度比客户端发送的速度要快，那么可能会由于缓慢的客户端连接而不能提供更多的数据导致线程阻塞，这样就限制了扩展性。在 Java EE 7 中使用新的事件驱动 API Servlet 3.1 从客户端读取数据将不会造成阻塞。如果有数据可用时，Servlet 线程将会读取和处理这些数据，否则就去处理其他请求。

回页首

满足苛刻的企业需求

Java EE 十几年来一直努力满足企业的需求，使用 Java 连接器连接到企业服务端、使用 Java 事务支持事务处理、使用 Java 消息服务让系统间可以进行相互通信。现在企业希望利用开发人员的 Java 技能编写基于标准的 API 并能够跨平台运行的批处理应用程序。企业也需构建高度可扩展的应用来满足更高的服务要求并提高现有资产的利用率。Concurrency Utilities 使得 Java EE 开发人员编写可扩展的应用程序成为可能。

在Java平台中，提高批处理应用程序的效率使开发过程变得更加便捷和高效

绝大部分的 Java EE 应用都是在线用户驱动的系统，但同时有一些需要进行批处理的服务器端应用程序，尤其是离线分析和 ETL 等。这些面向批处理的应用程序是非交互式的、需要长时间运行，这些任务通常需要大量计算，同时可以按顺序或者并行执行，并可以通过特定的事件启动或者定时调度。批处理较适合选择闲置的时间进行处理，这样可以有效利用计算机资源。

以前，对于批处理程序没有标准的 Java 编程模型。现在，批处理应用程序为 Java 平台提供了如图 2 非常容易理解的模型。批处理过程包括任务、步骤、存储库、读取 - 处理 - 写入模式和工作流等。

如图 2 所示，一个任务 job 代表一系列执行离散业务流程但又密切相关的步骤。步骤可以按顺序或者并行执行。同时，在同一个工作流，当前步骤是可选的，基于前一步骤的运行结果决定当前步骤将被执行或者跳过。另外，步骤可以根据实际的需要被重新执行。存储库 (repository) 存储了当前任务的信息，比如任务的最后执行时间。通过操作员 (operator) 可以对任务进行排序、开始、停止、暂停和取消操作。

图2. 用步骤描述工作

回页首

Java EE 8 展望

在 Java EE 7 发布后，开发人员对此似乎并不满足，对 Java EE 8 的新特性提出了一些设想与展望：

• 改进 CDI（Contexts and Dependency Injection for Java EE，上下文与依赖注入）。Java EE 8 应该支持所有 JSF 组件，包括转换器和验证器，以及 JASPIC 组件。
• 更深入的修剪 Pruning（）和 Deprecating（弃用）。应该延续 Java EE 6 和 Java EE 7 修剪与弃用的步伐，比如可以修剪 EJB 编程模型相关的所有东西。
• 标准化的缓存 API。JCache 缓存 API 原本将包含在 Java EE 7 中，但由于该 API 错过了重要的公共审查的最后期限，导致其没能成为 Java EE 7 的一部分。
• 平台范围内的配置。Java EE 应用程序可以使用部署描述文件（比如 web.xml）进行配置，但该方法对于不同的开发阶段（如 DEV、BETA、LIVE 等）来说比较麻烦，因为不同阶段会对应不同的服务器，从而导致配置也要随之改变。 期望 Java EE 8 能够以一种彻底的、统一平台的方式来解决这些配置问题。
• 综合的现代化的安全框架。在 Java EE 中，安全一直是一个棘手的问题。缺乏整体和全面的安全框架是 Java EE 的主要缺点之一，尤其是在讨论或评估竞争框架（如 Spring）时，这些问题会被更多地提及。期望在 Java EE 8 中，能够构建一个综合的和现代化的安全框架。

Java EE 8 目前尚处于规划初期，但愿上面提到的大多数特性能够以某种方式加以解决。

回页首

结束语

Java EE 平台为企业开发人员开发高效率、灵活性和易用性的 Web 应用提供了一个平台与机遇。经过 13 年的努力为成千上万的企业提供关键业务应用程序，Java EE 在企业应用程序包和部署平台中始终保持领先。Java EE 作为企业计算的行业标准，使开发人员能够充分利用新兴用法、模式和框架技术的优势来提高应用程序的可移植性、安全与再用价值等。最新发布的 Java EE 7 新特性中加强了对 HTML 5 动态可伸缩应用程序的支持、提高了开发人员的生产力和进一步满足了企业的苛刻需求。Java EE 7 使得开发人员可以使用依赖注入和默认资源的样本文件来减少代码的编写；更好地支持最新的 Web 应用和框架，拥有更好的扩展性和更丰富的功能；使得企业从便捷式批处理等新功能中获益。