本文已被 https://yourbatman.cn收录； 女娲Knife-Initializr工程可公开访问啦；程序员专用网盘 https://wangpan.yourbatman.cn；技术专栏源代码大本营： https://github.com/yourbatman/tech-column-learning；公号后台回复“ 专栏列表”获取全部小而美的 原创技术专栏

你好，这里是Java方向盘，我是方向盘(YourBatman)，坐稳扶好，开始发车。

📚前言

最近通过面试高密度的接触了不少Javaer，工作年限普遍在5-12年间，这个区间是大部分公司开发者的中坚力量，能够代表一定的技术主旋律。在交流过程中我夹带私货的大都问了类似“用过Java EE吗？Servlet和Java EE什么关系？了解JEP吗？”这样的问题，笔者将得到的所有回答浓缩总结成一句话：听过没用过。

什么是Jakarta EE？它并非新技术，“前身”是你熟悉的Java EE，你可能表示没听过但绝对直接or间接的使用过。若是如此，建议先移步阅读本系列第一篇文章：从Java EE到Jakarta EE，企业版Java的发展历程。

1998年，Sun公司发布JDK 1.2，并第一次启用J2EE这个名称，开始瞄准企业级开发规范；2004年，Sun公司发布JDK 5，并且启用Java EE这个名称，将J2EE改名为Java EE，从该版本开始Java EE不再像以前那样只注重大型商业系统的开发，而是更关注小到中小型系统的开发，简化这部分系统开发步骤，这得益于JDK的Annotation机制；2017年08月底（2017年8月，Java EE 8发布），Oracle宣布开源Java EE想让它变得更敏捷，并将项目移交给Eclipse基金会，至此Java EE改名为Jakarta EE。

2010年，IBM斥资65亿美金收购Sun未果，随后甲骨文 74亿美金抢购成功！自此宣布Sun时代的结束，Java商标全归入Oracle旗下。随即Oracle马上对Google提起诉讼，告它使用Java API构建Android系统要求近90亿美金赔偿金，最终Google胜诉

然而Oracle本性尽显，本次交割得非常不痛快，提了很多要求，其中就包括不能继续使用Java EE这个名称，虽然看起来有点无理但Eclipse基金会还是接受了，毕竟一个名字而已关系貌似也没那么大，所以被迫改名为Jakarta EE了嘛。

如果你以为这样就结束了，就图样图森破，太“看不起”Oracle了。最要命的当属这个要求：不允许再使用javax命令空间。这意味着，Java EE 8将成为绝唱，彻底封版，后续版本不可能再向下兼容。换句话理解：使用可以，Eclipse基金会想在上面改代码，修复bug或者升级，休想！！！

看到这你是否不禁想c一句：Oracle你这是移交了个寂寞吗？作为开发者是否可以“团结起来”，咱不用Java EE了还不行吗？

✍正文

Oracle的一顿猛如虎操作，让开发者彻底失去了Java EE。Eclipse基金会则自立门户，另起炉灶开启Jakarta EE项目。

对于Jakarta EE，从它的官网https://jakarta.ee能看到Eclipse基金会接手后共发布过三个版本：

• Jakarta EE 8：2019年9月发布，交接过来后发布的首个版本。特征总结为：

  • ①：内容完全同2017年8月发布的Java EE 8，无功能修改
  • ②：对GAV坐标做了变化，如老的javax.servlet:javax.servlet-api:4.01变更为jakarta.servlet:jakarta.servlet-api:4.02。这是本次版本升级的主要目的，把GAV坐标先扭过来
  • ③：命名空间依旧是javax，也就是说和Java EE 8是完全兼容的

• Jakarta EE 9：2020年11月发布。这一次，是阻断式升级。特征总结为：

  • ①：GAV同Jakarta EE 8
  • ②：再无javax命名空间，而是全新的jakarta命名空间。如：javax.servlet.Servlet改为jakarta.servlet.Servlet
  • ③：所有EE技术大版本号均升1。如：Servet 4.01升为Servlet 5.0.0，用以告知开发者其向下不兼容性

• Jakarta EE 9.1：2021年5月发布，增加JDK 11运行时支持。特征总结为：

  • ①：不新增API，保持和Jakarta EE 9一样
  • ②：基线版本（最低编译版本）依旧为JDK 8，但增加了JDK 11的运行环境
  • ③：相关技术的版本号基本没变化（只有少部分有小版本号+1情况）

总的来讲，若想升级到Jakarta EE 9+版本，麻烦还是较大的。作为开发者的我们，该何去何从呢？本文就来分析下这给开发者带来的转变，佐证笔者为何得出结论：开发者已无理由再用Java EE。

升级到Jakarta EE有哪些转变

当然，这里指的是升级到Jakarta EE 9+版本。由于它是阻断式升级，盘点清楚哪些转变将非常重要。

✌名称

旧名称：Java EE；新名称：Jakarta EE。

除了对品牌有影响（毕竟是全新品牌嘛），对公司企业的影响不大，对开发者的影响也基本可忽略。

✌GAV坐标

这里以Maven的GAV坐标为例。

Java EE 8的GAV坐标：

<dependency>
    <groupId>javax</groupId>
    <artifactId>javaee-api</artifactId>
    <version>8.0.1</version>
</dependency>

Jakarta EE的GAV坐标：

<dependency>
    <groupId>jakarta.platform</groupId>
    <artifactId>jakarta.jakartaee-api</artifactId>
    <version>8.0.0</version>
</dependency>

解释一下，也许你从未导入过甚至都没见过这两个API，它就是Java EE/Jakarta EE技术的集大成者：一个API包含所有EE技术，如servlet、ejb、el、validation等等。

对它陌生是因为绝大多数真实使用场景下，开发者并不会在一个project里面用全这些技术，而是按需导入独立的API。

从截图可以看到Jakarta EE 8的命名空间依旧是javax.*，但就像上面所描述的，若仅停在Jakarta EE 8的话，那便岁月静好，一片和谐。但是，一旦升级到Jakarta EE 9+版本，景象就是这样子的：

顶层命名空间改变！这就是接下来要说的内容。

✌命名空间

如果说👆🏻两项转变对企业和开发者的影响微乎其微，那么命名空间的不兼容的影响将是巨大的，甚至致命的。这无异于直接是釜底抽薪呀，顶层包名都不一样了，所有模块均受到彻彻底底的影响。

命名空间不兼容的具体表现

“自古”以来不缺由于不向下兼容最终作死了的技术，那作为标准的Java企业级技术这次迎来这么大的阻断式升级，会有哪些具体表现呢？我们可以从下面这几个角度窥探一下

✌所有服务器需要重新编译

Java EE服务器类型众多，由于命名空间的变化，所有的服务器均需要重新编译、发版。如：

• Eclipse的GlassFish：已适配。作为官方推荐的服务器，永远最先适配
• Red Hat的WildFly：已适配。截止稿前已有preview版本适配了新命名空间
• Oracle的WebLogic：未适配。
• IBM的WebSphere：未适配。

下图列出了截止稿前，已对Jakarta EE 9新命名空间做了适配的服务器（若是Jakarta EE 8旧命名空间的话远不止这么多哦，证明不少服务器厂商还没行动呢）：

Tips：你没看错，那个logo写着中文字的是2002年就已创办的中国公司： 中创软件商用中间件股份有限公司

Tomcat呢？？？嗯，Tomcat并非Java EE容器，而只是一个Servlet容器（Web容器）而已，所以不可能出现在这个列表里。但Apache Tomcat实现了四个 Jakarta EE规范：

1. Jakarta Servlet
2. Jakarta Standard Tag Library（JSTL）
3. Jakarta WebSocket
4. Jakarta Authentication

Apache Tomcat作为全球使用最广泛（市占率超6成）的Web应用服务器，响应速度还是非常快的：

简而言之，Tomcat从10.x版本开始全面拥抱jakarta.*命名空间，9.x及以下版本用于保持对javax.*命名空间的支持。

✌企业自身代码修改

企业自己的project代码需要将import javax.*替换为import jakarta.*，修改并不复杂，看起来很简单实则不简单。

中大型企业的项目、服务成百上千个，你还会觉得简单吗？

有些代码承接着巨大的流量不能有半点闪失，虽说仅仅只是改了“不影响逻辑”的代码，但这带来的风险是企业必须付出更多的人力去规避的。

✌运维体系的修改

对于企业应用来讲，一般会保持定期升级应用服务器的习惯。但由于存在新服务器不兼容老的应用的问题，所以部署系统可能就需要两套，成倍的增加了运维的成本。另外，使用两套服务器的话，是否要缴纳双倍的费用给服务提供商呢？这也是个问题~

以上列出企业若要升级到新版Jakarta EE需要面临的至少三大难题，如若不能低成本的“破解”，你觉得还有升级的必要吗？

什么叫不用Java EE？

作为一个Java开发者，肯定听过Java EE这个名词，但大多数人都会回答没用过，我并不诧异，因为你大概率一直在使用Spring/Spring Boot。如果说用过Spring Boot就等于用过Java EE，我觉得太过于牵强了，就像总不能说每个开车的司机都用过内燃机、把玩过轮胎是一样的道理。

如今在诸如Spring Boot这样的框架包装下，应用层已经找不到Java EE的踪影了。所以“年轻的”面试者说没用过Java EE并不会让人觉得奇怪，毕竟在天朝互联网企业中Spring已然成为实际的开发标准，且在持续侵蚀着Java EE的市占率，拥抱Spring Boot开发已是大势所趋。

对于新一代开发者来讲，Java EE已经是古董级技术，随着Spring技术栈的普及，已经没有什么理由再去使用Java EE/Jakarta EE技术，面向Spring编程会更高效。

估摸Oracle也是看形势不对，索性就交出了Java EE顺带还混得个Eclipse基金会董事会席位，何乐而不为呢？但是，它不再让继续使用javax命名空间这行为实在太不讲武德了，这件事引起了众多开发者的反感。但，谁又惹得起呢，毕竟它乃是最擅长发律师函的Oracle呀！

Spring与Jakarta EE

Spring和Jakarta EE什么关系？

这个问题有点不太好回答，可以说它俩是竞争关系，也可以说Spring是基于Jakarta EE构建的；可以说Jakarta EE是企业级开发的 官方标准，也可以说Spring是企业级开发的实际标准。它俩浓情蜜意这么多年，早已不可分割，所以新的Jakarta EE要想得到更多的覆盖率，很重要的一点就是得看看Spring对它的支持程度，方可快速普及。

2021年9月1日，一年一度的Spring One大会在线上举行，Spring项目拥有者Pivotal公司发布了Spring Framework 6.0以及Spring Boot 3.0的RaodMap，最重磅的变化莫过于这两个

1. 基于Java 17。话外音：不再支持Java 8、Java 11
2. 基于Jakarta EE 9。话外音：不再支持Java EE，不再支持javax命名空间

以Spring现在的影响力和能力，笔者觉得它完全有能力自立门户，不带Jakarta EE一起玩了。但是Spring一直秉持着不重复造轮子的理念，成长于社区反哺于社区，一起维护更好的生态环境，这不就是对Java开发者最大的“负责”么。

对于开发者而言，只需保持对Spring/Spring Boot的热度即可，至于Jakarta EE的发展、迭代，就让它“沦落为”汽车的发动机吧，无需关注。

Tips：即使不是Spring框架， 普通开发者（如果你不甘只做普通开发者，就...）也不会回到需要关心Java EE/Jakarta EE的年代，所以dark不必担心

✍总结

虽然Oracle不讲武德的操作，一度让开发者非常的失望和愤怒。但随着Spring的官宣：“带着”Jakarta EE继续前行，Javaer重拾信心，稳步前行。

历史的巨轮，浩浩荡荡的前进。有些是必然的趋势，即使你现在还并不能接受，但这并不妨碍。Java 8再怎么坚挺，终究会迎来其生命的终点，这是不可阻挡的，比较人类需要进步，技术也是。

去Tomcat官网可以看到，它竟提供了应用进行自动代码转换以支持jakarta的工具。或许在不远的将来我们可以看到各种奇yin巧技去搞兼容，又见那乌烟瘴气的一幕。

本专栏上下文

• 【方向盘】版本历史&代码示例之：JAX-RS
• 【方向盘】版本历史&代码示例之：JMX
• 【方向盘】版本历史&代码示例之：JavaMail、JDBC

推荐阅读

• 【方向盘】每人送1G超小容量，“BAT网盘”免费助你做减法
• 【方向盘】蚂蚁金服上市了，我不想努力了
• 【方向盘】因“双减”失业，厉经9面，终获美团外卖L8的Offer

我是方向盘(YourBatman)：前25年不会写Hallo World、早已毕业的大龄程序员。高中时期《梦幻西游》骨灰玩家，网瘾失足、清考、延期毕业、房产中介、保险销售、送外卖...是我不可抹灭的黑标签

• 🎓2013.07 清考、毕业答辩3次未通过、延期毕业
• 🏷2013.08-2014.07 宁夏中介公司卖二手房1年，毕业后第1份工作
• ️️🏷2014.07-2015.05 荆州/武汉，泰康人寿卖保险3月、饿了么送外卖2月，还有炸鸡排、直销等第2345份工作
• 🏷2015.08 开始从事Java开发，闯过外包，呆过大厂！擅长抽象思维，任基础架构团队负责人
• 🏷2021.08 因“双减政策”失业！历经9面，终获美团外卖L8的offer
• 🙅🏻‍♀️Java架构师、Spring开源贡献者、CSDN博客之星年度Top 10、领域建模专家、写作大赛1/2届评委
• 📚高质量代码、规范践行者；DDD领域驱动深度实践；即将出版书籍《Spring奇淫巧技》

• 源代码库地址：https://github.com/yourbatman/tech-column-learning
• CSDN主页：https://blog.csdn.net/f641385712
• 掘金主页：https://juejin.cn/user/430664289367192
• 博客园主页：https://www.cnblogs.com/yourbatman
• 个人博客主页：https://yourbatman.cn
• 个人网盘主页：https://wangpan.yourbatman.cn