文Oracle的猛操作，让开发者彻底失去了JavaEE。而Eclipse基金会则自己创业，启动了JakartaEE项目。对于JakartaEE，从其官网https://jakarta.ee可以看出，Eclipse基金会在接手后发布了三个版本：JakartaEE8：2019年9月发布，是交接后发布的第一个版本。特点总结如下：①：内容与2017年8月发布的JavaEE8完全一致，无功能修改②：更改了GAV坐标，如旧的javax.servlet:javax.servlet-api:4.01更改为jakarta.servlet:jakarta.servlet-api:4.02。这是本次版本升级的主要目的。首先反转GAV坐标③：命名空间依然是javax，也就是说完全兼容JavaEE8。JakartaEE9：2020年11月发布，这次是阻塞式升级。特点总结如下：①：GAV与JakartaEE8相同②：没有javax命名空间，而是全新的jakarta命名空间。例如：javax.servlet.Servlet改为jakarta.servlet.Servlet③：所有EE技术的主版本号都增加1例如：Servlet4.01升级到Servlet5.0.0，告知开发者其向后不兼容JakartaEE9.1：2021年5月发布，添加了JDK11运行时支持。特点总结如下：①：没有新增API，与JakartaEE9保持一致②：基线版本（最低编译版本）仍然是JDK8，但增加了JDK11的运行环境③：版本号相关技术基本保持不变（只有少数小版本号+1）一般来说，如果要升级到JakartaEE9+版本，麻烦还是比较大的。作为开发者，我们应该怎么做？本文将分析这给开发者带来的变化，并论证作者为什么得出开发者没有理由再使用JavaEE的结论。升级到JakartaEE有哪些变化当然这里指的是升级到JakartaEE9+版本。由于这是一个阻塞升级，因此评估哪些更改很重要。名称旧名称：JavaEE；新名称：雅加达EE。除了对品牌的影响（毕竟是新品牌），对公司的影响不大，对开发者的影响基本可以忽略不计。GAV坐标这里以Maven的GAV坐标为例。JavaEE8的GAV坐标：javaxjavaee-api8.0.1JakartaEE的GAV坐标：jakarta.platformjakarta.jakartaee-api8.0.0解释一下，也许你从来没有导入过，甚至没有看过这两个APIs，是JavaEE/JakartaEE技术的集大成者：一个API包含所有EE技术，如servlet、ejb、el、validation等。我对它比较陌生，因为在大多数真实的使用场景中，开发者不会在一个项目中使用所有这些技术，而是按需导入独立的API。从截图中可以看出，JakartaEE8的命名空间依然是javax.*，但如前所述，如果只停留在JakartaEE8，那么岁月静好，岁月静好。但是，一旦您升级到JakartaEE9+版本，它就是这样的：顶级命名空间发生了变化！这就是接下来要发生的事情。命名空间如果说这两个变化对企业和开发者的影响可以忽略不计，那么命名空间不兼容的影响将是巨大的，甚至是致命的。这无异于锅底抽薪。顶层包名不同，所有模块完全受影响。命名空间不兼容的具体表现自古以来，不乏因不兼容而最终夭折的技术。作为标准的Java企业级技术，此次将迎来如此大的分块升级。会有哪些具体表现？什么？我们可以从以下几个角度一窥所有需要重新编译的服务器。有许多类型的JavaEE服务器。由于命名空间的变化，所有服务器都需要重新编译和发布。如：Eclipse的GlassFish：已经适配。作为官方推荐的服务器，总是最先适配RedHat的WildFly:Adapted。截止日期前，预览版已经适配了Oracle的WebLogic的新命名空间：未适配。IBM的WebSphere：未改编。下图列出了截止日期前已经适配JakartaEE9新命名空间的服务器（JakartaEE8旧命名空间的服务器数量要多得多，证明很多服务器厂商还没有行动）：Tips:你没看错，带有汉字的标识是一家成立于2002年的中国公司：中创软件商业中间件有限公司Tomcat？？？好吧，Tomcat不是JavaEE容器，而只是一个Servlet容器（Web容器）而已，所以它不能出现在这个列表中。但ApacheTomcat实现了四种JakartaEE规范：JakartaServletJakartaStandardTagLibrary(JSTL)JakartaWebSocketJakartaAuthenticationApacheTomcat是世界上使用最广泛的Web应用服务器（超过60%的市场），其响应速度仍然是非常快：简而言之，Tomcat从10.x版本开始就全面拥抱了jakarta.*命名空间，9.x及以下版本用于维护对javax.*命名空间的支持。修改企业自己的项目代码，需要将importjavax.*替换为importjakarta.*。改装并不复杂。它看起来很简单，但事实并非如此。大中型企业项目和服务成百上千，你还觉得简单吗？有些代码承载着巨大的流量，根本不能错过。风险是企业必须花费更多人力去规避的事情。对于企业应用，运维系统的修改一般都保持定期升级应用服务器的习惯。但由于新服务器与旧应用不兼容的问题，可能需要两套来部署系统，运维成本成倍增加。另外，如果使用两套服务器，我是否需要向服务提供商支付双倍的费用？这也是一个问题~以上至少列出了企业想要升级到新版JakartaEE需要面对的三大问题。“破解”，你觉得还有升级的必要吗？不使用JavaEE是什么意思？作为一名Java开发人员，我一定听说过JavaEE这个词，但大多数人会回答说他们从未使用过它。我并不惊讶，因为你大概率用过Spring/SpringBoot。如果说用SpringBoot就等同于用JavaEE，我觉得太牵强了，就像不能说每个开车的司机都用过内燃机，玩过轮胎一样。如今，在SpringBoot等框架的封装下，应用层已经看不到JavaEE的踪迹。所以，这位“年轻”的面试官说自己从来没有用过JavaEE也就不足为奇了。毕竟Spring已经成为中国互联网公司的实际开发标准，并且还在不断蚕食JavaEE的市场份额。拥抱SpringBoot开发是大势所趋。对于新一代的开发者来说，JavaEE已经是古董级别的技术了。随着Spring技术栈的流行，没有理由再使用JavaEE/JakartaEE技术了。面向Spring的编程会更有效率。估计Oracle也看出情况不对，干脆把JavaEE拱手让给了EclipseFoundation的董事会。为什么不这样做呢？但是，停止使用javax命名空间太不合理了。德国，这件事引起了很多开发商的反感。但是，谁买得起？毕竟最会发律师函的还是Oracle！Spring和JakartaEE有什么关系Spring和JakartaEE？这个问题有点难回答。可以说两者是竞争关系，或者说Spring是基于JakartaEE构建的；可以说JakartaEE是企业级开发的官方标准，也可以说Spring是企业级开发的实际标准。两者这么多年形影不离，所以新的JakartaEE要想得到更多的覆盖，看Spring对它的支持程度，才能快速普及是非常重要的。2021年9月1日，一年一度的SpringOne大会线上召开。Spring项目负责人Pivotal发布了SpringFramework6.0和SpringBoot3.0的RaodMap。最重要的变化是这两个都是基于Java17的。画外音：不再支持Java8，Java11是基于JakartaEE9的。画外音：不再支持JavaEE，不再支持javax命名空间.以Spring目前的影响力和能力，我认为它完全有能力在没有JakartaEE的情况下自立门户，玩转。但Spring一直秉持着不重新发明轮子的理念，在社区中成长反哺社区，共同维护更美好的生态环境。这难道不是Java开发者最大的“责任”吗？对于开发者来说，只需要保持对Spring/SpringBoot的热情即可。至于JakartaEE的开发迭代，任其“还原”到汽车的引擎上，不去理会。Tips：即使不是Spring框架，普通开发者（如果你不愿意做普通开发者，就...）也不会回到需要关心JavaEE/JakartaEE的时代，所以暗黑不用愁总结虽然Oracle不谈武功德的操作一度让开发者非常失望和愤怒。但随着Spring官宣：“带”JakartaEE前行，Javaer重拾信心，稳步前行。历史的巨轮正浩浩荡荡向前。有些是必然的趋势，即使你现在接受不了，也不妨碍。不管Java8再强大，它终究会迎来生命的终结。这是不可阻挡的。与人类相比，技术需要改进。去Tomcat的官网可以看到居然提供了应用程序自动代码转换的工具来支持jakarta。或许在不久的将来，我们可以看到各种奇葩的兼容性，再次看到雾霾的场景。
