gpt4 book ai didi

【方向盘】认为:开发者已无理由再用Java EE

转载 作者:qq735679552 更新时间:2022-09-27 22:32:09 31 4
gpt4 key购买 nike

CFSDN坚持开源创造价值,我们致力于搭建一个资源共享平台,让每一个IT人在这里找到属于你的精彩世界.

这篇CFSDN的博客文章【方向盘】认为:开发者已无理由再用Java EE由作者收集整理,如果你对这篇文章有兴趣,记得点赞哟.

【方向盘】认为:开发者已无理由再用Java EE

正文

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

【方向盘】认为:开发者已无理由再用Java 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坐标:

  1. javax
  2. javaee-api
  3. 8.0.1

Jakarta EE的GAV坐标:

  1. jakarta.platform
  2. jakarta.jakartaee-api
  3. 8.0.0

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

【方向盘】认为:开发者已无理由再用Java EE

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

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

【方向盘】认为:开发者已无理由再用Java EE

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

命名空间

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

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

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

所有服务器需要重新编译

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

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

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

【方向盘】认为:开发者已无理由再用Java EE

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应用服务器,响应速度还是非常快的:

【方向盘】认为:开发者已无理由再用Java EE

简而言之,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编程会更高效.

【方向盘】认为:开发者已无理由再用Java EE

估摸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巧技去搞兼容,又见那乌烟瘴气的一幕.

原文链接:https://mp.weixin.qq.com/s/bWVTBRwERXV2adzL00LT-A 。

最后此篇关于【方向盘】认为:开发者已无理由再用Java EE的文章就讲到这里了,如果你想了解更多关于【方向盘】认为:开发者已无理由再用Java EE的内容请搜索CFSDN的文章或继续浏览相关文章,希望大家以后支持我的博客! 。

31 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com