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將會改變這一切!
