1.2　傳統企業級應用技術的不足

傳統Java企業級應用所使用的技術并不能適應當前互聯網公司的發展需求，其不足之處接下來將一一介紹。

1.2.1　規范太重

Java針對企業級應用市場推出的規范稱為Java EE，目前新版本是Java EE 8，而Java SE版本已經是Java 15版本。換言之，Java EE的發布遠遠落后于Java SE的發布，而且曾經Java EE是“復雜、難用”的代名詞。

傳統的Java EE系統框架是臃腫、低效和脫離現實的。當時，Sun公司推崇以EJB為核心的Java EE開發方式。但EJB本身是一種復雜的技術，雖然很好地解決了一些問題（比如分布式事務），但在許多情況下增加了比其商業價值更大的復雜性問題。

傳統Java EE應用的開發效率是低下的，應用服務器廠商對各種技術的支持并沒有真正統一，導致Java EE應用并沒有真正實現“Write Once，Run Anywhere”的承諾。

出現這些問題的原因是Java EE和EJB的設計都有著“以規范為驅動”的本質。標準委員會所指定的規范并沒有針對性地解決問題，反而在實際開發中引入了很多復雜性。畢竟，成功的標準都是從實踐中發展來的，而不是由哪個委員會創造出來的。

1.2.2　學習成本太高

傳統的Java EE的很多規范都是違反“帕累托法則”的。“帕累托法則”也稱“二八定律”，是指花較少的成本（20%）來解決大部分問題（80%），而架構的價值在于為常見的問題找到好的解決方案，而不是一心想要解決更復雜、更為罕見的問題。EJB的問題就在于，它違背了這個法則——為了滿足少數情況下的特殊要求，它給大多數使用者強加上了不必要的復雜性，使開發者難以上手。

早期的EJB 2.1規范中，EJB的目標定位有11項之多，而這些目標沒有一項是致力于簡化Java EE開發的。同時，EJB的編程模型非常復雜，要使用EJB需要繼承非常多的接口，而這些接口在實際開發中并不是真正為了解決問題。

1.2.3　不夠靈活

EJB依賴于容器，所以EJB在編寫業務邏輯時是與容器耦合的，編程模型不夠靈活。同時，與容器耦合的方式必然會導致開發、測試、部署的難度增大。同時，也拉長了整個開發的周期。

由于編寫程序需要依賴具體的容器實現，因此，“Write Once，Run Anywhere”變成了“一次編寫，到處重寫”。特別是實體Bean，基本上遷移一個服務器就相當于需要重新編寫，相應的測試工作量也增加了。

1.2.4　發展緩慢

EJB規范中對實體映射的定義太過于寬泛，導致每個廠商都有自己的ORM實現，引入特定廠商的部署描述符，又因為Java EE中除Web外，類加載的定義沒有明確，導致產生了特定廠商的類加載機制和打包方式。同時，特定廠商的服務查找方式也是有差異的。這在一定程度上加大了開發的難度，使得移植變得困難。

規范如果不能解決開發者的實際問題，開發者自然不會買賬，這種規范遲早會被市場淘汰。所以，Java EE的很多規范都停滯不前，發展緩慢。事實上，盡管JCP在這方面做出了一些努力，但仍然無法趕上現代IT市場快速發展的步伐。從2013年6月發布Java EE 7以來，出現了很多新興技術，比如NoSQL、容器、微服務和無服務器架構，但它們都未能被包含在Java EE當中。

Oracle公司也意識到了發展緩慢的問題，所以在2017年9月宣布將Java EE 8移交給開源組織Eclipse基金會管理，期望通過開源的方式來“活化”Java EE。