关于JAVA EE的论述，JAVA EE和Spring的论述在第二、三章节。

目录

1.JAVA的发展史

2.JAVA EE

3.JAVA EE和Spring

---

1.JAVA的发展史

JAVA语言于1995年面世，主要开发者为——James Gosline，后被称为JAVA语言之父。最早该语言叫Oak，在注册商标时，发现Oak已经被人使用，由于开发小组的成员当时在喝一款叫做JAVA的咖啡，于是将该语言命名为Java。至今JAVA的图标还是一杯咖啡。

JAVA分为两部分：

• JRE
• JDK

JRE:

Java Runtime Environment （Java运行环境），里面包括JVM——Java Virtual Machine （Java虚拟机）和一些基本的类库。

JDK：

Java Development Kit（ Java 开发工具包），里面包括JRE，并额外增加了Java开发所必须的工具和类、库。一般说的JAVA版本就是指JDK的版本。

随着开发领域的细分，JAVA为了适应这种趋势，在1999年将JDK拆为3个版本：

• J2SE
• J2ME
• J2EE

J2SE：

JAVA标准版，也称为JAVA SE。包含JAVA最通用的类库。

J2ME：

JAVA移动版，针对移动手机、机顶盒、外设，此类与硬件开发相关的场景。

J2EE：

面向企业版，现在已经改名为Java EE。

2.JAVA EE

99年sun公司为了避免开发的混乱，希望能在企业级应用上定一个规范，大家使用JAVA开发企业级应用时都遵循这种规范，使得系统具有清晰的层级便于维护和扩展，这个规范就是：

企业级应用是容器+组件的方式来提供服务的。

企业级开发其实要涵盖的东西很多，比如要涵盖网络通信、安全、多线程并发等等，这些问题要是都在企业级开发中每次都由开发人员去处理是很麻烦的，于是sun公司希望这些基础的共性的东西由容器去管理，而个性化的东西，如业务由组件去管理，由容器+组件的方式来提供服务。为了上面这个思想下诞生的东西能形成一个生态，于是sun公司定义了一系列规范，规定了容器该怎么做？做什么？组件该做什么？怎么做？容器和组件怎么合在一起？这一系列的规范就是JAVA EE规范。

整个JAVA EE其实分成两大块，容器和组件，各个开发商去根据规范开发容器，如tomcat、jetty等。开发者去开发组件，运行在容器中。由于容器满足了统一的规范、组件满足了统一的规范、容器和组件如何合在一起跑也满足了统一的规范，这样组件就可以跑在不同的容器中：

JAVA EE发展至今规范已经有四十多种，其一开始推出的规范有13个：

JDBC、EJB、JAVA RMI、JNDI、JMAPI、JMS、JTS、JMF、Annotation、JavaBeans、javaFX、JMX、JPA

这13个规范被称为JAVA EE十三大规范，有时也被简称为JAVA十三大规范，但JAVA十三大规范这种说法并不准确，这十三大规范只是针对J2EE场景的。

3.JAVA EE和Spring

一开始的时候按照标准的全套JAVA EE标准实现的架构如下：

后端服务器有两个，Web Container负责产生HTML页面、EJB Container负责业务逻辑，两个服务器之间通过RMI来相互调用。

 

2002年10月份，rod johson出了一本书《export one to one J2EE Development without EJB》，其中提出了一个疑问EJB Container中能做的事情，Web Container里完全可以做，那为什么一定要EJB Container?于是他自己写了一个框架并且利用此框架完整的开发出了一个系统，他自己这个框架里第一次提出了IOC和AOP。

rod johson此次尝试相当于是只采用了Web Container+ 自己的IOC和AOP，也就是说他只采用了一部分JAVA EE规范，舍弃掉了他觉得不合适的。

这本书影响很大，大家突然反应过来，其实完全按照JAVA EE规范来开发其实是很繁琐的，完全可以只采用一部分JAVA EE规范也可以做出一个系统。

后来根据rod johson书里的框架他和另外两个合作者一起做出了Spring。

Spring的出现颠覆了JAVA开发的体系架构，尤其是IOC，堪称大杀器，将后端业务逻辑从重量级的EJB中解放出来，经过无数实践大家基本上已经确定采用部分JAVA EE+Spring是JAVA企业级开发的最佳解决方案。按道理JAVA官方应该摒弃掉JAVA EE中已经被大家抛弃的部分，吸纳Spring重构整个JAVA EE的架构，但是很有意思的一幕出现了，JAVA官方很要面子，死不悔改，坚持在自己的规范里首推EJB承载后端业务逻辑的开发，直至如今也是这样。

但是spring的IOC这个设计实在是太优秀了不服又不行，怎么办？抄！于是JAVA抄Spring也推出了自己的IOC，但是又不能明面上叫IOC，于是改名为DI，这也就是为什么现在谈到IOC这个概念的时候经常会出现IOC/DI（控制反转/依赖注入）这种叫法，其实本质上就是一种东西，只是spring和JAVA EE的实现不同而已。目前spring和JAVA EE呈现出一种相互促进的趋势，彼此都在借鉴（互抄）对方优秀的特性。