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。