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