Oracle 在 6 月份发布了 Java EE 7，新特性包括实现 HTML5 动态可伸缩的应用、Spring 标准化的 Batch、JMS 2.0 等，那么 Java EE 8 有什么值得我们期待的功能吗？国外开发者列举了期望在 Java EE 8 中实现的新特性，值得国内社区关注。
在 Java EE 7 中，比较明显的改进包括：
- 实现 HTML5 动态可伸缩的应用——开发者们一直以来都通过采用 HTML5 在浏览器中快速地创建更丰富的用户体验。为了促进这种方式，我们引入了对 WebSocket 的支持，并将其作为在 Java EE 和浏览器之间创建低延迟、双向通信通道的一种手段，而通过这种方式，用户将可以完全掌控通信的协议。另一方面，针对 HTTP 之上的 RESTful 服务，我们引入了异步 API，通过在后台执行 RESTful 业务逻辑而非限制在单个线程上来提升可伸缩性。RESTful 服务通常使用 JSON 来交换信息，Java EE 7 引入了一组 JSON 处理的 API，通过使用类 StAX 的方式以及 DOM 对象模型的类似方式来解析 JSON 格式的数据。最后，JSF 引入了一组对 JSF 非常友好的标记，这意味着如果现在你只是想看看某个页面渲染后的外观，便可以将 JSF 页面直接渲染到 web 浏览器中，而无需执行 JSF 应用。
- 提升开发者的生产力——Java EE 7 为开发者们带来了显著的生产力提升。举个例子，我们减少了大量的样板代码，从而让开发者可以更加专注于核心的业务逻辑。举个更具体的例子，JMS 2.0 利用注解、依赖注入、AutoCloseable 接口，所以开发者可以不再需要定义 beans.xml 文件就可以简单的使用 CDI bean。
- 满足大部分所期盼的企业级需求——两项新的 JSR 直接解决了一些相当重要的企业级需求。第一个是 Batch API，由 IBM 主导。Batch API 非常适合无交互的、面向大容量的和长时间运行或计算密集型的任务。我们预计该 API 将在企业级客户中非常的流行。除了 Batch API 之外，我们同样增加了 Concurrency Utilities API 来帮助并行地执行更多的任务。Java EE 是一个托管环境，所以不允许应用去创建它们自己的线程。Concurrency Utility API 使得开发者可以创建线程池来并发地执行任务。
国外开发者期望在 Java EE 8 实现的新特性包括：
-
改进 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 中的容器管理锁。
-
标准化的缓存 API，JCache 缓存 API 原本将包含在 Java EE 7 中，但不幸的是，该 API 错过了重要的公共审查的最后期限，导致其没能成为 Java EE 7 的一部分。 如果该规范能够在 Java EE 8 计划表的早期阶段完成，就有可能成为 Java EE 8 的一部分。这样，其他一些规范（如 JPA）也能够在 JCache 之上重新构建自己的缓存 API。
-
管理对象（administrative objects）的应用内替代品。对于在应用服务器上运行许多外部程序的大企业而言，这可以是一个大的优势——你通常不会想去打开一个外部获得的应用程序来改变它连接的数据库的相关细节。在传统企业中，如果在开发人员和操作之间有一个强大的分离机制，这个概念也是有益的——这可以在系统安装时分别设置。 但是，这对于在自己的应用服务器部署内部开发的应用程序的敏捷团队来说，这种分离方式是一个很大的障碍，不会带来任何帮助。同样，对于初学者、教育方面的应用或者云部署来说，这种设置也是非常不可取的。 从 Java EE 6 的 @DataSourceDefinition 开始，许多资源（早期的“管理对象”）只能从应用程序内部被定义，比如 JMS Destinations、email 会话等。不幸的是，这并不适用于所有的管理对象。 不过，Java EE 7 中新的 Concurrency Utils for Java EE 规范中有明确的选项使得它的资源只针对管理对象。如果在 Java EE 8 中，允许以一个便携的方式从应用程序内部配置，那么这将是非常棒的。更进一步来说，如果 Java EE 8 中能够定义一种规范来明确禁止资源只能被 administrative，那么会更好。
-
平台范围内的配置。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 的新特性呢？
评论