什么是 Jakarta EE
Jakarta EE并不是新技术，他的前身就是大家熟悉的Java EE，老一辈的程序员可能还记得J2EE，是的，他们都是同一个东西，至于为什么会改来改去，这里面就有很多故事了。
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移交后代码就此封版，如果想修改代码，不好意思，请另起炉灶，所以，Oracle你移交的意义在哪？
那么从Java EE到Jakarta EE会给企业带来什么影响？下面我们一起分析。
名称的转变
这个对企业影响不大，对开发者影响也不大，你可以愉快用着Jakarta EE最新标准的同时跟同事说java ee发布新版本了。
命名空间的转变
如果你是用Maven进行开发，那么Java EE的依赖是这么定义的
|
1 2 3 4 5 6 |
<dependency> <groupId>javax</groupId> <artifactId>javaee-api</artifactId> <version>8.0.1</version> <scope>provided</scope> </dependency> |
我们可以看到groupId是javax，并且源码的结构如下：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
. └── 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描述是长这样的：
|
1 2 3 4 5 6 |
<dependency> <groupId>jakarta.platform</groupId> <artifactId>jakarta.jakartaee-api</artifactId> <version>9.0.0-RC2</version> <scope>provided</scope> </dependency> |
源码目录：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
. └── 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问题，不知道各厂商要怎么解决这个问题。
总之企业面临两难的境地，要么升级改系统源码，要么保持不变不升级，要么部分升级运维两套应用服务器，刀刀都要命。
未来
在如今各种诸如spring boot框架的包装下，在应用层面已经找不到Java EE的影子了，这些框架完全有能力抛弃jakarta自己实现，对于这些框架来说，跟随jakarta的意义似乎不大。对于企业来说，拥抱spring boot已经大势所趋，Java EE又搞出这么一件事，只会更加坚定企业转型的决心。对于开发者来说，Java EE已经是古董级的技术，Spring Boot不香吗，有什么理由去用jakarta EE。Oracle似乎也是看到了Java EE行将就木就索性移交出去，还能换取Eclipse基金会的董事会席位，但我还是看不懂Oracle对Java EE致命的这一刀目的何在，weblogic和中间件也是Oracle重要的两块业务，这两块业务都依赖Java EE，这么做只会两败俱伤。