前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >【方向盘】认为:开发者已无理由再用Java EE

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

作者头像
YourBatman
发布2022-10-31 11:12:26
6470
发布2022-10-31 11:12:26
举报
文章被收录于专栏:BAT的乌托邦BAT的乌托邦

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

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

Title

Link

所属专栏

【方向盘】-Java EE

源代码

https://github.com/yourbatman/FXP-java-ee

程序员专用网盘公益上线啦,注册送1G超小容量,帮你实践做减法

https://wangpan.yourbatman.cn

Java开发软件包(Mac)

https://wangpan.yourbatman.cn/s/rEH0 提取码:javakit

女娲工程

http://152.136.106.14:8761

版本约定

[Java EE:6、7、8],[Jakarta EE:8、9、9.1]

📚前言

最近通过面试高密度的接触了不少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巧技去搞兼容,又见那乌烟瘴气的一幕。

本专栏上下文

推荐阅读

在这里插入图片描述
在这里插入图片描述

我是方向盘(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奇淫巧技》
在这里插入图片描述
在这里插入图片描述

序号

专栏名称

简介

01

【方向盘】-程序人生

程序人生,人生程序

02

【方向盘】-资讯/新特性

IDEA、JDK、Spring技术栈…新特性

03

【方向盘】-IntelliJ IDEA

熟练使用IDEA就相当拥有物理外挂,助你高效编码

04

【方向盘】-Bean Validation

熟练掌握数据校验,减少90%的垃圾代码

05

【方向盘】-日期时间

帮你解决JDK Date、JSR 310日期/其实 的一切问题

06

【方向盘】-Spring类型转换

Spring类型转换-框架设计的基石

07

【方向盘】-Spring static

static关键字在Spring里的应用

08

【方向盘】-Cors跨域

关于跨域请求问题,本专栏足矣

09

【方向盘】-Jackson

Almost Maybe是最好的Jackson专栏

10

【方向盘】-Spring配置类

专讲@Configuration配置类,你懂的

11

【方向盘】-Spring技术栈

暂无所属小分类的,Spring技术栈大分类

12

【方向盘】-JDK

暂无所属小分类的,JDK技术栈大分类

13

【方向盘】-Servlet

Servlet规范、Web相关内容专题

14

【方向盘】-Java EE

从Java EE到Jakarta EE,30年弹指一挥间

15

【方向盘】-工具/提效

开发工具、软件工具,目标是提效

16

【方向盘】-Spring技术栈新特性

Spring Framework、Spring Boot、Spring Cloud、Spring其它技术

17

【方向盘】-基本功

每个Javaer,都需要有扎实的基本功

99

源代码库

大多数专栏均配有源代码,都在这里

本文参与 腾讯云自媒体分享计划,分享自作者个人站点/博客。
原始发表:2022-07-26,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 📚前言
  • ✍正文
    • 升级到Jakarta EE有哪些转变
      • ✌名称
      • ✌GAV坐标
      • ✌命名空间
    • 命名空间不兼容的具体表现
      • ✌所有服务器需要重新编译
      • ✌企业自身代码修改
      • ✌运维体系的修改
    • 什么叫不用Java EE?
      • Spring与Jakarta EE
      • ✍总结
        • 本专栏上下文
          • 推荐阅读
          相关产品与服务
          容器服务
          腾讯云容器服务(Tencent Kubernetes Engine, TKE)基于原生 kubernetes 提供以容器为核心的、高度可扩展的高性能容器管理服务,覆盖 Serverless、边缘计算、分布式云等多种业务部署场景,业内首创单个集群兼容多种计算节点的容器资源管理模式。同时产品作为云原生 Finops 领先布道者,主导开源项目Crane,全面助力客户实现资源优化、成本控制。
          领券
          问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档