什么是 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的依赖是这么定义的

<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问题，不晓得各厂商要怎么解决这个问题。

总之企业面临两难的地步，要么降级改零碎源码，要么放弃不变不降级，要么局部降级运维两套应用服务器，刀刀都要命。

将来

在现在各种诸如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，这么做只会两败俱伤。

参考

Jakarta EE - Java EE的终结者