Java EE 7来了，8还会远吗

Oracle在6月份发布了Java EE 7，新特性包括实现HTML5动态可伸缩的应用、Spring标准化的Batch、JMS 2.0等，那么Java EE 8有什么值得我们期待的功能吗？国外开发者列举了期望在Java EE 8中实现的新特性，值得国内社区关注。

在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接口，所以开发者可以不再需要定义beans.xml文件就可以简单的使用CDI bean。
3. 满足大部分所期盼的企业级需求——两项新的JSR直接解决了一些相当重要的企业级需求。第一个是Batch API，由IBM主导。Batch API非常适合无交互的、面向大容量的和长时间运行或计算密集型的任务。我们预计该API将在企业级客户中非常的流行。除了Batch API之外，我们同样增加了Concurrency Utilities API来帮助并行地执行更多的任务。Java EE是一个托管环境，所以不允许应用去创建它们自己的线程。Concurrency Utility API使得开发者可以创建线程池来并发地执行任务。

国外开发者期望在Java EE 8实现的新特性包括：

1. 改进CDI（上下文与依赖注入），Java EE 8应该支持所有JSF组件，包括转换器和验证器，以及JASPIC组件。Java EE 7中的CDI也没有考虑到JASPIC组件，在此之中注入操作将无法工作。即使http请求和会话在Servlet Profile SAM中可用，但是当SAM被调用时，相应的CDI作用域也不会被建立。这意味着它甚至不能通过bean管理器以编程方式来检索请求或会话bean作用域。CDI绝对不应该只专注于在其他规范中已经解决的那些问题，其他规范还可以在CDI之上来实现它们各自的功能，这意味着它们可以作为CDI扩展。以Java EE 7中的JSF 2.2为例，该规范中的兼容CDI的视图作用域可作为CDI扩展来使用，并且其新的flow作用域也可被立即实现为CDI扩展。
   
   此外，JTA 1.2现在也提供了一个CDI扩展，其可以声明式地应用到CDI托管的bean中。此前EJB也提供了类似的功能，其背后技术也使用到了JTA，但是声明部分还是基于EJB规范。在这种情况下，可以通过JTA来直接处理其自身的声明性事务，但是这需要在CDI之上进行。
   
   尽管从EJB 3版本开始，EJB Bean已经非常简单易用了，同时还相当强大，但问题是：CDI中已经提供了组件模型，EJB beans只是另一个替代品。无论各种EJB bean类型有多么实用，但是一个平台上有2个组件模型，容易让用户甚至是规范实现者混淆。通过CDI组件模型，你可以选择需要的功能，或者混合使用，并且每个注解提供了额外的功能。而EJB是一个“一体”模式，在一个单一的注解中定义了特定的bean类型，它们之间可以很好地协同工作。你可以禁用部分不想使用的功能。例如，你可以关闭bean类型中提供的事务支持，或者禁用@Stateful beans中的passivation，或者禁用@Singleton beans中的容器管理锁。
2. 标准化的缓存API，JCache缓存API原本将包含在Java EE 7中，但不幸的是，该API错过了重要的公共审查的最后期限，导致其没能成为Java EE 7的一部分。 如果该规范能够在Java EE 8计划表的早期阶段完成，就有可能成为Java EE 8的一部分。这样，其他一些规范（如JPA）也能够在JCache之上重新构建自己的缓存API。
3. 管理对象（administrative objects）的应用内替代品。对于在应用服务器上运行许多外部程序的大企业而言，这可以是一个大的优势——你通常不会想去打开一个外部获得的应用程序来改变它连接的数据库的相关细节。在传统企业中，如果在开发人员和操作之间有一个强大的分离机制，这个概念也是有益的——这可以在系统安装时分别设置。 但是，这对于在自己的应用服务器部署内部开发的应用程序的敏捷团队来说，这种分离方式是一个很大的障碍，不会带来任何帮助。同样，对于初学者、教育方面的应用或者云部署来说，这种设置也是非常不可取的。
   
   从Java EE 6的@DataSourceDefinition开始，许多资源（早期的“管理对象”）只能从应用程序内部被定义，比如JMS Destinations、email会话等。不幸的是，这并不适用于所有的管理对象。 不过，Java EE 7中新的Concurrency Utils for Java EE规范中有明确的选项使得它的资源只针对管理对象。如果在Java EE 8中，允许以一个便携的方式从应用程序内部配置，那么这将是非常棒的。更进一步来说，如果Java EE 8中能够定义一种规范来明确禁止资源只能被administrative，那么会更好。
4. 平台范围内的配置。Java EE应用程序可以使用部署描述文件（比如web.xml）进行配置，但该方法对于不同的开发阶段（如DEV、BETA、LIVE等）来说是比较痛苦的。针对这些阶段配置Java EE应用程序的传统的方法是通过驻留在一个特定服务器实例中的“管理对象”来实现。在该方法中，配置的是服务器，而不是应用程序。由于不同阶段会对应不同的服务器，因此这些设置也会随之自动改变。
   
   这种方法有一些问题。首先在AS端的配置资源是服务器特定的，这些资源可以被标准化，但是它们的配置肯定没有被标准化。这对于初学者来说，在即将发布的应用程序中进行解释说明比较困难。对于小型开发团队和敏捷开发团队而言，也增加了不必要的困难。对于配置Java EE应用程序，目前有很多可替代的方式，比如在部署描述符内使用（基于表达式语言的）占位符，并使部署描述符（或fragments）可切换。许多规范已经允许指定外部的部署描述符（如web.xml中可以指定外部的faces-config.xml文件，persistence.xml中可以指定外部的orm.xml文件），但是没有一个统一的机制来针对描述符做这些事情，并且没有办法去参数化这些包含的外部文件。
   
   如果Java EE 8能够以一种彻底的、统一平台的方式来解决这些配置问题，将再好不过了。似乎Java EE 8开发团队正在计划做这样的事情。

读者对Java EE 8有何期望？ 是否已经开始尝试Java EE 7的新特性呢？