尽管目前公布的细节仍然有点简略，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 SE 6采用的方式相同，有一个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采访的过程中，Java EE 6规范的领导者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]中尝试过了，我认为它们失败了。”

Java EE 6计划中的第一个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文档）。

Java 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的修订。主要的更改计划有：

1、Java持久化API（JPA）：2.0版的JPA会将API的能力进行扩展，主要包括：

◆扩充对象/关系映射功能，包括在整合已有映射选项时具有更大的灵活性，支持嵌入对象的集合，可排序的列表，访问类型的组合，以额外的元数据支持DDL生成等等。
◆扩充Java持久化查询语言的查询能力
◆标准化实体拆分与融合的附加约定以及持久化上下文管理。
◆标准化查询配置和实体管理配置的“提示”集合
◆扩充Java EE环境中可插拔性的协定

2、Servlets：尽管Servlet在持续流行，可自J2EE 1.4以来Servlet的API就没有进行过一次大的修订。3.0版本的Servlet API的目标是：

◆提高Web 框架的可插拔能力
◆通过注解（Annotation）和泛型来提高易用性，这包括可以通过注解来决定是否使用web.xml。
◆增加异步支持（Comet）来提供非阻塞的输入/输出，请求处理延后处理以及响应关闭延后处理。
◆改善安全能力，包括登入/登出支持和servlet自注册。

3、Java Server Faces 2.0：这是这个规范第二个主要的发布，其目标为：

◆通过去除对配置文件的依赖以及引入JSP标记处理函数的自动化生成来改善易用性，
◆增加对声明式渲染器（renderers）的支持
◆通过改变请求处理生命周期和允许视图的部分更新来增强对AJAX的支持。
◆使开发者开发定制组件更容易。

最后，还有更多的较小的修改：

1、以简化EJB组件模型为目标的Enterprise JavaBeans。EJB3.1中会看到可选的本地业务接口的引入，使只使用一个bean类来开发本地EJB组件成为可能。它也将允许不需要ejb-jar部署描述文件就能把EJB组件打包/部署到一个.war文件。
2、Java EE 连接器体系结构，关注于使开发更加便捷，并对规范做综合的改善。  
3、JAX-WS：细节尚未公布。

很多API没有为Java EE 6作出最后的修剪。有两件事值得注意，其一是JSR 168，Java Portlet 规范，其被几个主要的门户运营者所拥护；另一个是JSR 208, Java业务集成(JBI)，一个服务仲裁规范，目前已经被除BEA和IBM之外的所有厂商支持。

Java EE 6规范有一个相当有竞争力的时间表，最终的发布瞄准了2008年第四季度。