开发者已无理由再用Java EE

三叶草

正文

Oracle的一顿猛如虎操作，让开发者彻底失去了Java

对于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坐标：

javax

javaee-api

8.0.1

Jakarta EE的GAV坐标：

jakarta.platform

jakarta.jakartaee-api

8.0.0

解释一下，也许你从未导入过甚至都没见过这两个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规范：

• Jakarta Servlet
• Jakarta Standard Tag Library(JSTL)
• Jakarta WebSocket
• 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，最重磅的变化莫过于这两个
基于Java 17。话外音：不再支持Java 8、Java 11
基于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巧技去搞兼容，又见那乌烟瘴气的一幕。