Java EE 6(JSR 316)的提案已经发布。此次发布版的两大主题是可扩充性和概要：
……这个新发布版本致力于欢迎并支持那些技术，将它们包含在整个Java EE愿景中，同时继续简化Java开发平台，以更好的服务于更多的开发者。为此，我们给新版本提出两项目标 —— 拓展性和概要。
拓展性(Extensibility)
对于Java EE平台来说，并不适宜在没有限制的情况下，把所有Web开发和企业应用开发者认为有趣且有用的技术都包含进来。相反，我们认为应该让更多技术清楚地叠放在Java EE应用服务器上层，或者作为应用服务器的插件。通过增加拓展功能点并提供更多的服务接口，这些额外的功能可以简洁高效地加载到平台实现上面，让它们跟平台内建的设施一样便于开发者使用。
概要(Profiles)
Java EE的范围已经延伸的如此广泛，以至失去了原先所遵循的价值观。为了重新将Java EE的目标定位到特定类型的开发者和应用程序，我们提案引入Java EE平台“概要”。像是JCP定义的那样，概要将会引用Java EE平台，并且可能包含Java EE平台技术的一个子集，以及不属于Java EE基础平台的一些附加JCP技术。除了定义Java EE基本平台规范，这个规范还将定义在概要中引用Java EE平台技术的规则。
这个专家组同时也会定义Java EE Web概要的第一个版本——面向Web应用开发的Java EE平台子集。这个概要将为Java EE平台提供一个更平缓的入门，同时只提供被大多数Web应用开发者所需要的技术，而不是那些有时会使得开发者产生迷惑的企业级技术……
该提案还主张使用概要配置来减少日益膨胀的Java平台规模。有人建议，在Java SE专家组中使用的过程同样可以应用在Java EE之上：
平台的第N个发布版本的纲领性专家组(Umbrella EXPert Group，UEG)可以提议移除指定的特性。该发布版本的规范将上述提案记录在案。
第N+1发布版本的UEG专家组有权决定是否在本发布版中移除该特性，是作为必要的成份将其保留，还是保持其“有待取消”的状态让下一个UEG专家组来决定。
提案列举了一系列JSR提议作为Java EE 6新特性的候选，例如JSR-237《应用服务器的工作治理器》和JSR-299《Web Beans》等。除此之外，还有此前列入的技术如Servlets，EJB和JSF等内容。诸如JSR-168《Portlet规范》，JSR-170《Java内容仓库API》，JSR-225《XQuery Java API(XQJ)》等众多应用程序接口，则被推迟到未来的发布版本再考虑。
Interface 21的CEO Rod Johnson就新的提案撰写了长篇评论，公布他们将支持JSR的提案：
Java EE(长期以来一直被称作J2EE)在创造Java中间件市场中扮演了重要的角色。然而，在将近十年的过程中，存在于这个平台上的严重问题已经出现，例如：
对符合Java EE规范的服务器的需要被夸大了，它们支持一系列庞杂的功能，然而对于广大用户来说，只有很少一部分人对这些功能感爱好
企业需求已经发生改变，因为J2EE原先“为所有应用建立统一模型的”理念已经显得越来越不适应形势了
事实上，由于开发框架(尤其是开放源代码框架)的出现，企业级Java应用开发的能力已大大加强，使得开发者更具有生产力并且应用产品更具有效率和可维护性
来自于Ruby on Rails甚至是.NET等开发框架的新生挑战，表明在追求快速变化和创新的时代里，每隔2-3年才慢悠悠地发布一个版本将会给整个平台带来危险。
Java EE 6对平台进行了重要的修正，有潜力解决所有这些问题。同时它也有可能解决另外的问题：事实上，假如Java EE开发商需要确保那些大多数消费者从没使用的功能，即意味着他们很难跟上规范的新变化，对于平稳地升级来说将是个重大挑战，而且在Java EE市场上有新加入竞争者的可能性几乎是零。最后一点说的是，在用户看来，责任重大并不是EE厂商慢吞吞的借口。此时此刻，就我所知，BEA是市场上所有领导厂商中唯一获得J2EE认证的，尽管Java EE 5规范已经发布了一年多;这充分证实了发布一个新平台版本的困难性。Java EE 5最有价值的部分，比如说JPA，在WebLogic最终版发布前几个月就已经完成，但由于在一些大多数WebLogic用户可能从来不会使用的的部分还存在技术问题，而无法发布一个正式版的产品……我认为，企业Java社区应该欢迎Java EE 6的到来，也应该欢迎Sun公司与时俱进，为加强企业级Java整体平台所采取的举措。在J2EE/Java EE中有许多很好的特性，但一些因素导致这些特性变得复杂晦涩起来。相信Java EE 6将会改变这一切!
