Hibernate 之父Gavin King[1]建議開發者升級到Java EE 6 平台，並指出，目前各種不願意升級的觀點其實是沒有根據的。
Java EE 6 發布後，我看到了很多反對升級到新平台的觀點。這些反對觀點大多是由Tomcat / Jetty 以及一些開源框架（例如Hibernate 與Spring）的使用者提出。
當然，選擇非標準、開源技術有許多好處。另外，在EE 6 中，你可以使用你感興趣的開源框架，Servlet 3 與CDI 可以無縫整合第三方框架。因此，沒有理由不使用EE 6。儘管如此，我還是看到有人說：
升級到EE 應用伺服器很困難
這似乎是具體組織的政治問題，而不是實際的技術問題。當然，升級伺服器（例如GlassFish 或JBoss）是非常瑣碎的任務。 （升級第三方框架就更痛苦了。）一些組織機構對伺服器升級有著非常重量級的過程，而對於伺服器內運行的框架的升級過程卻沒有如此重的過程控制。因此，對於開發團隊來說，升級第三方框架反而更容易。
我認為發展更有說服力、更好的過程才是最重要的，而不是放棄Java EE。將你的應用程式運行在老舊、過時的伺服器平台上存在著許多風險，過程不應該鼓勵這樣的實踐。
但從實務角度來看，幾乎每一個人都準備好最近就升級到Servlet 3。無論你在使用Tomcat、Jetty、JBoss、GlassFish、Resin、WebLogic、Oracle 或WebSphere，都意味著伺服器的升級。這是升級到EE 6 Web Profile 的絕佳機會，黃金時機。
EE 應用程式伺服器太龐大了
反對理由是EE 伺服器包含了許多（目前）使用不到的功能。反對者的論點通常涉及了討論jar 包大小、Servlet 引擎+第三方框架與EE 應用伺服器所佔用的磁碟空間大小的比較。其實，這樣的論點是有問題的：
討論的磁碟佔用、磁碟空間用$ 衡量其實是微不足道的，而且應用war 套件比伺服器安裝套件的大小重要得多，伺服器其實包含了很多功能來盡量降低war 的大小。
另外，我認為最有說服力的是Java EE 6 Web Profile 更本來不龐大。一旦經過認證的Web Profile 伺服器投放市場，我們就可以在大的EE 應用程式伺服器與小型的Servlet 容器中間找到一個平衡點。
糟糕的J2EE 與EJB2！
隨著JCP 的標準化進程，這個問題其實早已不存在了：
1. EJB2 從出現到現在已經8 年了！它依然是你的最佳選擇？
2.不錯的規範已經透過JCP 不斷的標準化而合併了，可以非常確定地使用其中一些規範。不過，JCP 在規範標準化上也不是100% 成功的。
3. 所有在EE 6 平台上工作的人都討厭EJB2 與J2EE。這就是為什麼有人不斷地加入JCP 來幫助修復這些問題。例如，Hibernate 的創始人，本文的作者。你真的想給他上一課關於EJB2 的問題？ :-)
4.實體Bean（Entity Beans）的人幾乎現在都退休了！
事實上，Java EE 6 Web Profile 已經夠用了。如果你不親自嘗試Java EE 6，你是無法真正感受到EE6 對開發的好處的。
應用程式伺服器可移植性太神秘了！
真的嗎？我們看到很多人將應用程式分割後部署在不同的應用程式伺服器上？噢，我看過，這意味著100% 完美地進行應用程式0 改變移植，一種柏拉圖式的理想可移植性。我了解對於絕對真理與柏拉圖式理想的弱點，不過還是讓我們先看看例子。
這是一個非常典型的可移植性問題視圖：
9% 的程式碼，85 % 的外部元資料在不同伺服器平台上完全相容，剩下1% 與15% 能夠適當進行分割
0% 的程式碼，80% 的外部元資料綁定在了非標準、單一廠商的容器體系結構上
當我劃分這些點時，我突然想將本節主題從應用伺服器可移植性太神秘了改成我根本不在乎容器可移植性。主題改變的想法印證了伺服器可移植性問題的確存在，並且這對於許多組織機構來說非常有用。
我一直想看到非EE 6 技術維護者對EE 6 的真實評論。上文中提到的一些論點不是來自真實世界的，所以很難引發EE 平台上應用開發實際技術問題的討論。 JCP 最近一輪規範似乎已經離開了反EE 陣營（暫時性離開？），但缺乏成功的事實支撐。
編註：
[1] Gavin King：Hibernate 的創始人，EJB3 專家委員會成員，JBoss 核心成員之一，Seam 框架的領導人，JSR-299（CDI）規範領導人，也是《Hibernate in Action》一書的作者。
來源：You should upgrade to Java EE 6