1.2　传统企业级应用技术的不足

作为一门受欢迎的编程语言，Java在经历了20多年的发展后，已然成为企业级应用开发的首选“利器”。在2018年11月的TIOBE编程语言排行榜 中，Java位居榜首，可见开发者对于Java的厚爱。

图1-2所示为2019年2月的编程语言排名。

大型互联网公司也大多选择Java作为主力开发语言，包括Google、IBM、Oracle等外企，以及京东、百度、阿里巴巴等国内名企。Java以其稳定性而著称，特别是“Write Once, Run Anywhere”（一次编写，各处运行）的特性，非常符合互联网企业快速推出产品、部署产品的需求。

但是，传统Java企业级应用所使用的技术，并不能适应当前互联网公司的发展需求，其不足之处总结如下。

1.2.1　规范不实用

Java针对企业级应用市场推出的规范称为Java EE，目前最新的版本是Java EE 8。但曾几何时，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的很多规范都是违反“帕累托法则”的。“帕累托法则”也称“二八定律”，是指花较少的成本（10%～20%）解决大部分问题（80%～90%），而架构的价值在于为常见的问题找到好的解决方案，而不是一心想要解决更复杂、更罕见的问题。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外，类加载的定义没有明确，导致产生了特定厂商的类加载机制和打包方式。同时，特定厂商的服务查找方式也是有差异的，这在一定程度上加大了开发的难度，使得移植变得困难。

规范如果不能解决开发者的实际问题，开发者自然不会买账，这种规范迟早会被市场淘汰。事实上，尽管JCP（Java社区进程）在这方面做出了一些努力，但仍然无法赶上现代IT市场快速发展的步伐。从2013年6月发布Java EE 7以来，出现了很多新兴技术，如NoSQL、容器、微服务和无服务器架构，但它们都未能被包含在Java EE中。

Oracle公司也意识到了Java EE发展缓慢的问题，所以在2017年9月宣布将Java EE 8移交给开源组织Eclipse基金会管理，期望通过开源的方式来“活化”Java EE。 B5obEII1HKoOt8tcalrEBTvCbvHqAMGP9jkuG+WHGoCT8xOoakO4F1Yc60JYHhwi