Anil Gaur 揭秘 Oracle 在接管 Java 后的首个 EE 版本 —— Java EE 7 的发布

Oracle 官方于 6 月 12 日以在线研讨会的形式发布了 Java EE 7。在此之前，InfoQ 曾与 Oracle 的软件开发副总裁 Anil Gaur 就本次发布的内容以及对未来的计划进行了探讨。

InfoQ: 考虑到这是 Oracle 接管 Java 后的首个 Java EE 版本，发布的过程与 Java EE 6 相比将有何不同？

自 Java EE 5 开始，我们一直在项目 GlassFish 下以开源项目的方式进行 Java EE 参考实现的开发。在 Oracle 的管理与经营下，JCP 过程也同样变得更加透明。Oracle 和 JCP 成员急切地希望让更广泛的 Java 开发者社区更早地融入到这个过程当中，以便于他们可以在规范开发完之后对其进行审查并提供反馈。一项 JSR 必须遵守一定的规则才能在透明的方式下运行，而我们曾提交了 JSR 348 来对这一规则进行定义。现在所有由 Oracle 主导的 JSR 都将遵守这个过程。专家组开放了一个电子邮件别名来进行技术讨论，而所有的临时规范草案都可以在项目主页上访问到。

所有的 Java EE 7 规范都是按照 JSR 348 所定义的规则进行开发的，参与者除了 JCP 专家组和 Java EE 供应商之外，还包括广泛的社区。我可以很欣慰地说，这种透明的方式工作得非常之好，而就本次发布的社区参与度来说，我们看到了显著的提升。

InfoQ: 鉴于对云的支持被丢弃之后，Java EE 7 还有哪些重要的主题？

事实上，我们针对 Java EE 7 开辟了三个顶级主题：

1）实现 HTML5 动态可伸缩的应用

开发者们一直以来都通过采用 HTML5 在浏览器中快速地创建更丰富的用户体验。为了促进这种方式，我们引入了对 WebSocket 的支持，并将其作为在 Java EE 和浏览器之间创建低延迟、双向通信通道的一种手段，而通过这种方式，用户将可以完全掌控通信的协议。另一方面，针对 HTTP 之上的 RESTful 服务，我们引入了异步 API，通过在后台执行 RESTful 业务逻辑而非限制在单个线程上来提升可伸缩性。RESTful 服务通常使用 JSON 来交换信息，Java EE 7 引入了一组 JSON 处理的 API，通过使用类 StAX 的方式以及 DOM 对象模型的类似方式来解析 JSON 格式的数据。最后，JSF 引入了一组对 JSF 非常友好的标记，这意味着如果现在你只是想看看某个页面渲染后的外观，便可以将 JSF 页面直接渲染到 web 浏览器中，而无需执行 JSF 应用。
2）提升开发者的生产力

Java EE 7 为开发者们带来了显著的生产力提升。举个例子，我们减少了大量的样板代码，从而让开发者可以更加专注于核心的业务逻辑。举个更具体的例子，JMS 2.0 利用注解、依赖注入、AutoCloseable 接口（译者注：一个被简化的用于资源自动关闭的接口，其中的 close 方法由托管于 try-with-resources 语句的对象自动调用）以及默认的资源定义来减少开发者需要花费的精力，仅仅只需要几行代码就可以简单地实现地将一个消息放入队列的操作。默认的资源定义，比如像 JMS 连接工厂和数据源这样的资源都具有默认的定义方式，所以在将应用部署到 Java EE 运行时环境中时将只需更少的配置。一个呼声很高的特性是我们添加了标准的 RESTful 客户端 API，这样一来开发者们将可以有效地进行 RESTful 请求调用而不需使用专有的客户端 API。我们在提升 JSR 的集成度上也做了很多的工作，从而使 Java EE 7 成为一个更加综合的平台。对于 Bean Validation，目前可以在方法声明处使用以校验参数和返回值。除了 EJB 之外，容器管理的事务现在也已经可用。事务拦截器和新的 @Transactional 注解使得事务可以被应用于任何受托管的 bean 方法，使该方法成为一个事务型方法。最后，默认启用了 CDI(Java EE 的上下文和依赖注入)，所以开发者可以不再需要定义 beans.xml 文件就可以简单的使用 CDI bean。

3）满足大部分所期盼的企业级需求

两项新的 JSR 直接解决了一些相当重要的企业级需求。第一个是 Batch API，由 IBM 主导。Batch API 非常适合无交互的、面向大容量的和长时间运行或计算密集型的任务。我们预计该 API 将在企业级客户中非常的流行。除了 Batch API 之外，我们同样增加了 Concurrency Utilities API 来帮助并行地执行更多的任务。Java EE 是一个托管环境，所以不允许应用去创建它们自己的线程。Concurrency Utility API 使得开发者可以创建线程池来并发地执行任务。

InfoQ: Cache 错过了 EE 7 的最后期限，这是不是意味着我们需要等到 EE 8 才能使用它？有没有可能将它的实现放入 EE 7 标准服务器来使用它？

我们正在为赶在 Java EE 8 之前完成 Cache API 而努力工作中，我们预计 Java EE 平台将会有一个增量的过程来帮助开发者在 Java EE 7 之上使用新的 API。

InfoQ: 结合 Java EE 6 的托管 bean 以及在 Java EE 5 中引入的基于注解的编程模型，貌似允许开发者最终在任何组件上选取和采用由 EE 容器提供的任何服务。那么 EE 7 是否还是会继续加强这一思想呢？

是的，我们在这个方向上还会继续前进。最好的例子就是对 Java EE 中的托管 bean 的整体调整。我前面提到的事务拦截器，就是一个你可以以更加灵活的方式应用事务的例子。而对于 Bean Validation 的应用则更为普遍，只要你需要就可以使用它们。在 JSF 规范中强烈推荐使用 CDI bean 来取代使用 JSF 托管 bean。当然，CDI bean 是默认启用的。好吧，我想要再次强调的就是，如果你需要就使用它们吧。

InfoQ: Java EE 6 的另一个关键特性就是可移植扩展。这项特性在 EE 7 中是否有更进一步的挖掘？

可移植扩展被使用在 Java EE 中和用户应用的每个地方。在 Java EE 7 中，JMS、Bean Validation 以及 JTA 都具有可移植扩展。同时也诞生了一个名为 DeltaSpike 的 Apache 项目，专注于可移植扩展。HK2（在 GlassFish 中）使用了可移植扩展，该可移植扩展允许客户端代码使用 CDI 来注入 HK2 服务。

当然，围绕 Java EE 7 也不可避免地出现了一些争论。与 JCache 和对云的支持特性被推迟一样，Java Message Service 2.0 规范也被 London Java Community 批评为不够进取，相关的说明可以参见最终的发布投票。

LJC(伦敦 Java 社区) 支持该 JSR 所完成的技术工作，但是认为自 JMS1.1 发布以来消息领域发生了非常大的革新，而该 JSR 本应该更加富有进取心以及涉及更广泛的范围。LJC 将消息领域视为有可能并且需要进一步标准化的方向之一，并呼吁关心该领域的 JCP 成员能够对其可能性进行进一步的探索。

InfoQ 联系到了 Ben Evans 和 Martijn Verburg 进行了更深入的了解。Evans 告诉我们

我想要的（消息）功能例如：

• 对等（peer-peer）消息拓扑
• 有线兼容（wire compatible）的消息格式
• AMQP（译者注：Advanced Message Queuing Protocol，RabbitMQ 便是该协议的一个开源实现）
• 对超低延迟消息传递的提升

此外，我认为 EG(专家组) 在对 API 的更新方式上过于保守——比如说，对泛化的缺乏。

Verburg 补充道：

时至今日，业内需要重点强调的一个思想是通信协议不能将用户锁定在一个特定的语言或平台上。这在编程世界日益分化的生态系统中犹为重要。在很多情况下，一个队列或是消息总线被设计为多个系统关注的架构分离点，可是却要将它们锁定在某种 Java 的特定方式上。你可以给出人们一个合理的技术理由来完全避免使用此类技术。

所以例如像 AMQP 那样支持跨语言互操作的特性肯定是我们想要看到有所改进的一个方面。

同样地，在 JVM 领域里还有着各式各样其他更加轻量级的消息传递架构，如果能出现一个天然去雕饰的删减版 JMS 我想势必也会有所帮助。

即便如此，我们仍然认为 JMS 2.0 在开发者生产力方面有着很大的改进，所以也鼓励 JMS 开发者尽快向 JMS 2.0 迁移。

我们将这部分内容请教了 Gaur，他告诉我们

JMS 2.0 在 Java EE 7 中已经改头换面。但我们相信仍有很大的改进空间，并且我们也会继续进行对 JMS 规范的改进工作。这些被延期了的问题将会在下一个版本发布前由专家组重新进行评估。此外，等到 Java EE 8 的路线图变得更成熟一点时，我们将会邀请社区的成员为 JMS 的下个版本贡献他们自己的建议。我希望 London Java Community 将能够从一开始就参与进来。

最后，我们问及了 Gaur 关于他对我们将在 Java EE 8 中可能看到内容的预测，特别提到了 NoSQL 和一个面向动作（action-orientated）的 web 框架这两个想法。

由于关于云的相关特性大都从 Java EE 7 推迟到了更晚的版本，所以部分云的特性必定会出现在 Java EE 8 中。举个例子，一个应用现在可以将它需要的安全权限定义在 permissions.xml 文件中，该文件与该应用是绑定的。但是如果 Java EE 运行时不能兑现这些权限，该部署将会失败。相比于只是在运行时单纯的失败有一种更好的选择！就是我前面提到的默认资源定义，这在云的环境中也可以凑效。被部署的应用可以简单地依赖于由 PaaS 供应商定义的默认资源定义，例如映射到例如供应商提供的数据库这样的资源上。JPA 2.1 添加了模式生成支持，所以将应用部署到一个绿地云（Greenfield cloud）环境时，可以同样生成数据库模式并预先安装好一个数据库。随着我们逐渐步入 Java EE 8 甚至更加深远，我们将会在如何让部署到云环境 Java EE 中的应用变得更容易移植这一方面继续进行研究。

对于 NoSQL，我们想尽可能避免过早的对这个领域进行标准化，因为该领域仍在经历着大量的创新和变革，所以这是待定的（TBD）。我们会在一些已经开始进展的 JSR 上继续工作，比如 JCache、状态管理（State Management）和 JSON 绑定（JSON Binding）。我们正在考虑一个配置服务（Configuration Service），它将可以提升在 Java EE 现已提供的服务之上的 DevOps 体验。从一个较高的层面来说，这是关于从开发工件（development artifacts）中分离出配置工件（configuration artifacts）的功能。举个例子，一套不同的配置可以被应用于开发、测试和生产环境，而不会对开发工件产生影响。云绝对是我们所考虑的一部分，因为我们想要将“编写一次到处运行”（Write Once Run Anywhere）同样地应用在云上，就好比应用已经部署在数据中心一样。我认为对于其他领域我们还需要进一步调查，正如你所提到的，我们想要提升 web 开发者的开发体验。我们在 Java EE 7 中取得了显著的进展，并且我们也知道还有更多的工作可以做好，从而提升利用 Java EE 已有服务来开发端到端（end-to-end）的移动或桌面应用的体验。

你将可以在 6 月 12 日的在线研讨会中了解到更多关于Java EE 的内容。

查看英文原文： Q&A With Oracle Vice President of Software Development Anil Gaur on the Java EE 7 Release