说明
下面记录一下 JavaSE、JavaEE、JavaMe 的区别。
为什么会有 java 2 的名称
1998年12月，SUN公司发布了JDK1.2，开始使用Java 2 这一名称。
目前，Java 2平台有3个版本，它们是适用于小型设备和智能卡的Java 2平台Micro版（Java 2 Platform Micro Edition，J2ME）、适用于桌面系统的Java 2平台标准版（Java 2 Platform Standard Edition，J2SE）、适用于创建服务器应用程序和服务的Java 2平台企业版（Java 2 Platform Enterprise Edition，J2EE）。
后来又改名为 JavaEE。
Java SE
Java SE（Java Platform，Standard Edition）。Java SE 以前称为 J2SE。它允许开发和部署在桌面、服务器、嵌入式环境和实时环境中使用的 Java 应用程序。Java SE 包含了支持 Java Web 服务开发的类，为 Java Platform，Enterprise Edition（Java EE）提供基础。
JavaSE是Java的核心，也就是 Java的主要部分。用于开发桌面应用程序和基于web的应用程序。它提供了从基本对象到高级类的所有东西，这些类被用于网络、数据库访问、安全、xml解析、gui开发。除了这些核心的api之外，它还提供了虚拟机JVM、开发工具、部署技术等。
从 Oracle 官网，下载 JDK，并安装完成，就是一个 JavaSE 的环境了。
JDK8下载地址：https://www.oracle.com/java/technologies/downloads/#java8
安装完成后，查看 java 版本。
image.png
Java EE 与 JavaEE（注意名字之间是否有空格）
JavaEE 与 J2EE 可以理解为同一个东西。
Java EE是一个抽象的规范。具体实现称为应用服务器，如GlassFish、WildFly、WebLogic等。当你从Oracle站点下载JavaEE时，它将给你提供大量文档和示例。例如：GlassFish服务器等。因此，它们只是提供了Java Enterprise Edition规范的实现。你还可以使用其他的实现，比如RedHat WildFly，它也遵循这些规范。因此，J2EE是1999年-2003年JavaEE的抽象规范的版本名称。EJB遵循JavaEE规范，所以EJB属于JavaEE。
Oracle 官网中 JavaEE 的实现方案。
image.png
JavaEE（Java Platform，Enterprise Edition）。这个版本以前称为 J2EE。企业版本帮助开发和部署可移植、健壮、可伸缩且安全的服务器端 Java 应用程序。Java EE 是在 Java SE 的基础上构建的，它提供 Web 服务、组件模型、管理和通信 API，可以用来实现企业级的面向服务体系结构（service-oriented architecture，SOA）和 Web 2.0 应用程序。
JavaEE 号称有十三种核心技术。它们分别是：JDBC、JNDI、EJB、RMI、Servlet、JSP、XML、JMS、Java IDL、JTS、JTA、JavaMail和JAF。
J2EE是一种利用Java 2平台来简化企业解决方案的开发、部署和管理相关的复杂问题的体系结构。J2EE技术的基础就是核心Java平台或Java 2平台的标准版，J2EE不仅巩固了标准版中的许多优点，例如”编写一次、随处运行”的特性、方便存取数据库的JDBC API、CORBA技术以及能够在Internet应用中保护数据的安全模式等等，同时还提供了对 EJB（Enterprise JavaBeans）、Java Servlets API、JSP（Java Server Pages）以及XML技术的全面支持。其最终目的就是成为一个能够使企业开发者大幅缩短投放市场时间的体系结构。
J2EE体系结构提供中间层集成框架用来满足无需太多费用而又需要高可用性、高可靠性以及可扩展性的应用的需求。通过提供统一的开发平台，J2EE降低了开发多层应用的费用和复杂性，同时提供对现有应用程序集成强有力支持，完全支持Enterprise JavaBeans，有良好的向导支持打包和部署应用，添加目录支持，增强了安全机制，提高了性能。
JavaEE 包含了对一系列标准(接口)的实现。
如果你要用这些接口，恐怕要使用JavaEE服务器而不仅仅是一个 Servlet 容器。
Oracle JavaEE 文档地址：https://www.oracle.com/cn/java/technologies/java-ee-glance.html
Spring 与 JavaEE
Spring是一个分层的JavaSE/EE full-stack(一站式) 轻量级开源框架。
Spring是一个开源的框架Spring是于2003 年兴起的一个轻量级的Java 开发框架，由Rod Johnson 在其著作Expert One-On-One J2EE Development and Design中阐述的部分理念和原型衍生而来。
Spring 目前主要依赖 JavaSE，依赖部分JavaEE（常见依赖：Servlet-api、JPA、Bean Validation等。一般都是用到时，使用 maven 引入）。
可以说 Java EE 是企业级开发的官方标准，也可以说 Spring 是企业级开发的实际标准。
Spring遵循所有的JavaEE规范吗？严格的说不是。Spring是一个独立的框架，它替代并改进了JavaEE的许多部分，你可以将Spring视为一个集成平台，允许你使用所有JavaEE技术。这意味着你不一定需要完整的fledge JavaEE应用服务器来支持，你可以在像Tomcat这样的简单的servlet容器上运行它。Spring是一个独立的集成平台，在JavaEE中有改进和替换，也允许你使用JavaEE技术。
Spring 官方宣布 Spring Framework 6 和 Spring Boot 3 计划将基于更高的基线于 2022 年的第四季度发布通用可用版本：
Java 17+（目前 Spring Framework 5.3.x 的基线是 Java 8-17）
Jakarta EE 9+（目前 Spring Framework 5.3.x 的基线是 Java EE 7-8）
基于 Spring Framework 6 和 Spring Boot 3 的应用程序在运行时方面至少需要 JDK 17，并且需要 Tomcat 10 / Jetty 11（为了兼容 Jakarta EE 9）环境。
更重要的是，应用程序的源代码可能需要一些改变：例如，在 Jakarta EE 9 中，只要涉及到 Servlet API、JPA、Bean Validation 等功能，就需要将 javax 改为 jakarta 命名空间。
JavaEE行业认可的标准API框架；它主要基于注释和CDI；用于WEB开发的JFC MVC框架；用于进程数据库操作的JPA实现；JTA API和实现；基于EJB容器和POJO的实现；Oracle许可证。
基于ioc和aop；基于xml配置，目前使用的是注解；使用spring dao框架连接到数据库，基于模板设计patter；提供抽象层以支持各种JTA实现供应商；与不同的Java厂商的不同支持不同的功能，这样容易与struts2等集成；提供端到端平台构建web应用程序，实现使用DI和AOP的松散耦合；开放源码许可。
J2EE和Spring继续相互影响并相互鼓励。
J2EE在Spring中激发了新的增强。
spring的实现重点与J2EE的标准化和可移植性
springsource社区与Java社区过程的主要区别在于其不同的动机。springsource的创新来自于解决现实世界问题的需要。解决方案以解决问题为导向，这样下一个步骤和整个项目就可以尽可能快速和顺利地实现。JCP有点像公司，创新和决策与解决方案如何导致标准技术规范相关联。另外，像Oracle、IBM、RedHat
甚至SpringSource参与JCP。大多数Java规范请求都 需要很长的路径才能实际实现。例如，jsr303:Bean验证需要三年才能完成。也许在这个领域，速度并没有那么重要，因为大多数大型企业项目不会经常发生变化，而且会有更长的生命周期。他们甚至可能不想要所有罪行的、但未经证实的技术。J2EE的另一个论点是可移植性。简而言之，J2EE是一组规范，在你的应用程序中使用的东西可以被拉入你选择的任何J2EE兼容的容器中，简单地说，用一些常规 的方法来包装业务逻辑 ，为CRUD操作 提供持久性，然后从14个J2EE供应商中选择。理想情况下，你应该能够在不同服务器之间移动代码。这有时行得通，首先，现在只有三个供应商支持J2EE7，所以很多都变得无关紧要了。其次，有些实现是特定于供应商的，并且仍然需要时间和资源来让项目在不同的环境中运行。当然，这取决于项目的复杂性，一个简单的示例应用程序将从任何一个开始，但不是一个复杂的。另一方面，spring只支持VMWARE,它被认为是其他库的包装器，将他们耦合在一起，提供更容易的访问和配置功能–如果你知道如何做到这一点的话。但是spring应用程序可以在一个成熟的J2EE服务器上运行，也可以在轻量级JSP容器中运行，比如Jetty,Tomcat,Netty,避免了巨大的开销。spring甚至可以在独立模式下有运行，因为spring引导模块可以包装Jetty或Tomcat。对J2EE与Spring的大多数比较测试都存在缺陷。只有良好的负载和压力测试，以及持续的基准测试才能真正分析应用程序中的瓶颈。事实上，一个或另一个容器可能更适合于任何特定的情况。
JavaEE 与 Spring 对比
JAVA EE
javaEE是一个开发分布式企业级应用的规范
javaEE 基于注解和CDI
利用web开发的JFC MVC框架
用于进程数据库操作的JPA（java持久层API）实现
基于EJB（javaee服务器端组件模型）和pojo的实现
Spring
基于IOC和AOP
基于XML配置(注释)
使用Spring DAO框架(基于模板设计patter)连接到数据库
提供抽象层以支持各种JTA(事务API)实现供应商
提供端到端平台构建web应用程序，实现使用DI和AOP的松散耦合
开放源码许可
Spring 与 EJB
EJB 和 Spring 是实现企业级业务处理的两种解决方案，EJB 是重量级解决方案，Spring 是轻量级解决方案。
Jakarta EE
Jakarta EE 并不是新技术，他的前身就是 Java EE。为什么会改名字呢？
1998年12月，SUN公司发布了JDK1.2，开始使用Java 2 这一名称，第二年Sun公司联合IBM、Oracle、BEA等大型企业应用系统开发商共同制订了一个基于Java组件技术的企业应用系统开发规范，名字很自然就取为Java 2 Platform Enterprise Edition简称J2EE，后面的事情大家也知道，JDK版本升的很快，J2EE名称如果跟着Java版本走必然会给开发人员造成困惑不利于该技术的推广，终于在2006年，SUN公司在发布Java 5后正式将J2EE改名为Java EE(Java Platform, Enterprise Edition)，很多早期j2ee开发者虽然现在用的是最新的java ee标准但他们还是认为自己在用j2ee，当然，只是名称的改变并没有给开发者带来什么麻烦，相比之下下面这个就是要命。
2009年，Oracle宣布收购SUN，Java相关技术自然归Oracle所有，在2017年，Oracle 宣布开源 Java EE 并将项目移交给 Eclipse 基金会，但Oracle移交的很不痛快，提了很多要求，其中就包括不能再使用Java EE这个名称，虽然有点无理但Eclipse基金会还是接受了这个要求并且改名为Jakarta EE，经历了从j2ee到java ee的改名再经历一次似乎也无所谓，但要命的是Oracle要求Jakarta EE不能修改javax命名空间，这个就意味着java ee移交后代码就此封版，如果想修改代码，不好意思，请另起炉灶。
命名空间的转变
如果你是用Maven进行开发，那么Java EE的依赖是这么定义的
<dependency>
<groupId>javax</groupId>
<artifactId>javaee-api</artifactId>
<version>8.0.1</version>
<scope>provided</scope>
</dependency>
我们可以看到groupId是javax，并且源码的结构如下：
.
└── javax
├── annotation
├── batch
├── decorator
├── ejb
├── el
├── enterprise
├── faces
├── inject
├── interceptor
├── jms
├── json
├── mail
├── management
├── persistence
├── resource
├── security
├── servlet
├── transaction
├── validation
├── websocket
├── ws
└── xml
所有的源码都定义在javax.*这个路径下，根据Oracle的要求Jakarta EE不能修改javax命名空间，那么Jakarta EE只能将代码中javax修改为jakarta，因此最新版本Jakarta Maven描述是长这样的：
<dependency>
<groupId>jakarta.platform</groupId>
<artifactId>jakarta.jakartaee-api</artifactId>
<version>9.0.0-RC2</version>
<scope>provided</scope>
</dependency>
源码目录：
.
└── jakarta
├── activation
├── annotation
├── batch
├── decorator
├── ejb
├── el
├── enterprise
├── faces
├── inject
├── interceptor
├── jms
├── json
├── jws
├── mail
├── persistence
├── resource
├── security
├── servlet
├── transaction
├── validation
├── websocket
├── ws
└── xml
可以看到除了顶层包名称不一样下面的定义都一样，那么包路径更改会有什么影响？影响非常大。
所有java ee应用服务器比如Weblogic，GlassFish等如果要支持最新版本的jakarta ee就必须修改源码重新编译，并且如果支持了jakarta ee就无法支持java ee，也就是无法向前兼容，Tomcat虽然只是Servlet容器但是Servlet本身就是Java EE的一部分，因此也逃不过修改的命运。据说Tomcat可以对应用进行自动代码转换以支持jakarta，因此在不远的将来我们可以看到各种奇技淫巧去兼容jakarta，是不是想起了被IE支配的恐惧。
企业如果需要用到jakarta ee最新特性必须修改现有代码，修改并不复杂，就是把代码中import javax.替换为import jakarta.，修改完重新编译打包部署，似乎很简单，事实上没那么简单。
对企业来说，保持应用服务器处于最新版本是必须的，因为新版本可能修复了老版本的漏洞，并且性能上也可能有一定的提升，但如果升级应用服务器的同时也要修改源码代码就很大，修改的成本，带来的风险并不是所有企业都能接受的。
假设修改了一个应用，那么就需要部署到新版本应用服务器上，由于新服务器不兼容老应用因此需要运维两套应用服务器，运维成本提高，两套应用服务器也可能涉及license问题，不知道各厂商要怎么解决这个问题。
总之企业面临两难的境地，要么升级改系统源码，要么保持不变不升级，要么部分升级运维两套应用服务器，刀刀都要命。
Java ME
Java ME（Java Platform，Micro Edition）。这个版本以前称为 J2ME。Java ME 为在移动设备和嵌入式设备（比如手机、PDA、电视机顶盒和打印机）上运行的应用程序提供一个健壮且灵活的环境。Java ME 包括灵活的用户界面、健壮的安全模型、许多内置的网络协议以及对可以动态下载的连网和离线应用程序的丰富支持。
Java ME 有自己的类库，其中 CLDC 使用的是专用的 Java 虚拟机叫做 KVM。