尽管目前公布的细节仍然有点简略，Java EE 6 的大致方向已经变得更明朗了，并且反映出 Java EE 标准的角色正在转变。一些开源项目，例如 Struts，Hibernate 和 Seam，最初被视为一个完整的企业计算栈，被越来越广泛的企业采用来弥补目前版本 Java EE 的不足。在某些情况下，这些开源项目轮流影响了下一版规范的修订。同样，对于提供一个完整的解决方案，Java EE 的角色变得更轻了，而对于提供一个鲁棒的基础代码集合，使软件提供商和开源开发者能够依托其上构建自己的应用，Java EE 的角色变得更重了。 JSR 316 ——做为下一个 Java EE 版本修订的庞大（umbrella）JSR，通过使可拓展性成为专家组的一个核心目标，看起来把这个新的关系放到了一个更加正式的根基上。另外这个规范承认，Java EE 已经变得庞大而且复杂，建议既要对规范中特定元素进行修剪，还要引入使用偏好（profile）以针对特定开发组织提供其关注的 EE 功能子集。它还要建立在先前的版本所做的简化工作的基础上，这些简化工作包括使用注解来进一步削减对外部配置文件的依赖。
修剪采用的方式与 Java SE6 采用的方式相同，有一个 Blog 对此做了描述。这是作为一个多阶段过程来进行的，一个待修剪候选可能在一个发布中被声明出来，但在下一个发布中就可能被降级为可选组件，而所有这一切完全取决于社区的反应。JSR 建议了两个最初的修剪候选——一是 JAX-RPC [JSR 101，基于 XML 的 RPC 的 Java API ]，它已经被 JAX-WS [ JSR 224，基于 XML 的 Web Services 的 Java API ] 有效的取代了，二是 EJB CMP，目前已经被 Java 持久化 API （JPA）[起初是作为 JSR 220，Enterprise JavaBeans 3.0 的一部分来定义的] 替代了。在对 Artima 采访的过程中，EE6 规范的领导者 Roberto Chinnici 和 Bill Shannon 暗示目前没有被广泛采用的 JAXR API [ JSR 93， 用于 XML Registries 1.0 的 Java API] ，一个访问 web service 注册表的 API，可能被添加到修剪的候选名单中。
尽管大部分修剪是无可置疑的，Sun 对 profile（使用偏好）的使用还是引发了一些争议。SpringSource 的 CEO Rod Johnson 理所当然的喜欢它们：
“最终，用户将会有权力货比三家，决定什么才是他们真正想要的，而不是由一个规范委员会在用户开始构建应用两年之前去决定他们的意志。”Johnson 说，“现在到了用一些健康的竞争取代一个苏联式的命令经济的时候了。”
但是 OSGi 的布道者 Peter Kriens 对此不以为然：
“要解决众口难调的问题，Sun 提议多创建一些尺寸，叫做 profile。肯定能适合所有的情况吗？好吧，profile 在 J2ME[Java 2 Micro Edition] 中尝试过了，我认为它们失败了。”
EE6 计划中的第一个 profile 是 Web profile，关注于 web 应用开发人员。在引入这个新的 profile 的同时，这个规范还会定义一些规则，用来为其它的细分市场创建额外的 profile，例如电信业或者金融业的应用。
可拓展性的技术细节不是那么清楚，即便 JSR 制定了一些野心勃勃的目标：“我们相信使更多这样的技术在 Java EE 应用服务器上清楚的分层或者接插到 Java EE 应用服务器是令人向往的，”JSR 316 这样提到。通过增加更多的可扩展点和更多的服务提供者接口，这些额外的技术可以清楚高效的接插到这个平台的实现中，并且用户使用起来就如同将它们构建到系统中一样便利。
这种方式的一个例子是 JSR 196：Java 容器的认证服务提供者接口，J2EE 1.4 最初计划中 API 的三重奏之一。它提供了一个标准服务提供者接口来使认证机制提供者能够被集成到容器中。使用这个接口的提供者会被用来建立容器访问决策的身份认证，包括那些在容器中调用其他容器组件时所使用的身份认证。2007 年 10 月这个规范最终发布并且可以下载了。
如同1.4 的最初计划那样，Java EE 6 也应该最终看到以下两组API 的正式发布：适合用于管理环境的定时器API；一个容器可管理的编程模型，提供给那些使用容器管理的线程池并发执行的工作。这两组API 是由IBM 和BEA 联合开发的，并得到了BEA WebLogic 和IBM WebSphere 的支持，具体的描述在这里（PDF 文档）。
EE 6 中还计划包含两组新的 API。其一是深受 JBoss 的 Seam 和 Google 的 Guice 影响的 WebBeans，它的目标是通过统一 web 层与事务层的组件模型，简化基于 web 的应用程序的 Java EE 编程模型。另外，WebBeans 规范提供了一个会话模型和持久化上下文，其提供了细粒度的状态管理，并允许一系列的 web 事务（一个会话）被当作一个工作单元来对待。 Jacob Orshalick 详细描述了 Seam会话模型与超时处理的细枝末节。通过一个声明和四部分（一， 二，三， 四）的详尽描述，Gavin King 为 WebBeans 模型做了全面广泛的说明。
尽管 WebBeans JSR 得到了广泛积极的反响，IBM 在 JSR 316 的表决中还是持有一些异议：
“我们对 JSR 299 似乎要选择的方向很关心，这个方向超越了其提到的集成 JSF 和 EJB 组件的许可。并且我们相信，如果它在这个方向上继续努力，最终会使它从 Java EE 6 中被去除。我们不相信我们的客户会觉得采用需要添加一个别的组件模型定义的 Java EE 6 是一件容易的事。”
第二组新的 API 是 JSR 311，一组 RESTful Web Services 的 Java API 。它已经产生了一些毁誉参半的反响。一篇 InfoQ 早些时候的文章对社区反应做了一个不错的概述。Brian Leonard 的 blog 和相关的链接提供了这个提议的更多细节，Bill Burke 提供了一些反馈。
在 Java EE 6 中会看到对很多核心 API 的修订。主要的更改计划有：
- Java 持久化 API（JPA）：2.0 版的 JPA 会将 API 的能力进行扩展，主要包括
- 扩充对象 / 关系映射功能，包括在整合已有映射选项时具有更大的灵活性，支持嵌入对象的集合，可排序的列表，访问类型的组合，以额外的元数据支持 DDL 生成等等。
- 扩充 Java 持久化查询语言的查询能力
- 标准化实体拆分与融合的附加约定以及持久化上下文管理。
- 标准化查询配置和实体管理配置的“提示”集合
- 扩充 Java EE 环境中可插拔性的协定
- Servlets : 尽管 Servlet 在持续流行，可自 J2EE 1.4 以来 Servlet 的 API 就没有进行过一次大的修订。3.0 版本的 Servlet API 的目标是：
- 提高 Web 框架的可插拔能力
- 通过注解（Annotation）和泛型来提高易用性，这包括可以通过注解来决定是否使用 web.xml。
- 增加异步支持（Comet）来提供非阻塞的输入 / 输出，请求处理延后处理以及响应关闭延后处理。
- 改善安全能力，包括登入 / 登出支持和 servlet 自注册。
- JavaServer Faces 2.0 ：这是这个规范第二个主要的发布，其目标为
- 通过去除对配置文件的依赖以及引入 JSP 标记处理函数的自动化生成来改善易用性，
- 增加对声明式渲染器（renderers）的支持
- 通过改变请求处理生命周期和允许视图的部分更新来增强对 AJAX 的支持。
- 使开发者开发定制组件更容易。
最后，还有更多的较小的修改：
- 以简化 EJB 组件模型为目标的 Enterprise JavaBeans 。EJB3.1 中会看到可选的本地业务接口的引入，使只使用一个 bean 类来开发本地 EJB 组件成为可能。它也将允许不需要 ejb-jar 部署描述文件就能把 EJB 组件打包 / 部署到一个.war 文件。
- Java EE 连接器体系结构，关注于使开发更加便捷，并对规范做综合的改善。
- JAX-WS: 细节尚未公布。
很多 API 没有为 Java EE 6 作出最后的修剪。有两件事值得注意，其一是 JSR 168，Java Portlet 规范，其被几个主要的门户运营者所拥护；另一个是 JSR 208, Java 业务集成 (JBI) ，一个服务仲裁规范，目前已经被除 BEA 和 IBM 之外的所有厂商支持。
EE 6 规范有一个相当有竞争力的时间表，最终的发布瞄准了 2008 年第四季度。
评论