关于java-ee:Jakarta-EE-Java-EE的终结者

什么是 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 的终结者