什么是 Jakarta EE

Jakarta EE并不是新技术,他的前身就是大家熟悉的Java EE,老一辈的程序员可能还记得J2EE,是的,他们都是同一个东西,至于为什么会改来改去,这里面就有很多故事了。

1998年12月,SUN公司发布了JDK1.2,开始使用Java 2 这一名称,第二年Sun公司联合IBM、Oracle、BEA等大型企业应用系统开发商共同制订了一个基于Java组件技术的企业应用系统开发规范,名字很自然就取为Java 2 Platform Enterprise Edition简称J2EE,后面的事情大家也知道,JDK版本升的很快,J2EE名称如果跟着Java版本走必然会给开发人员造成困惑不利于该技术的推广,终于在2006年,SUN公司在发布Java 5后正式将J2EE改名为Java EE(Java Platform, Enterprise Edition),很多早期j2ee开发者虽然现在用的是最新的java ee标准但他们还是认为自己在用j2ee,当然,只是名称的改变并没有给开发者带来什么麻烦,相比之下下面这个就是要命。

2009年,Oracle宣布收购SUN,Java相关技术自然归Oracle所有,在2017年,Oracle 宣布开源 Java EE 并将项目移交给 Eclipse 基金会,但Oracle移交的很不痛快,提了很多要求,其中就包括不能再使用Java EE这个名称,虽然有点无理但Eclipse基金会还是接受了这个要求并且改名为Jakarta EE,经历了从j2ee到java ee的改名再经历一次似乎也无所谓,但要命的是Oracle要求Jakarta EE不能修改javax命名空间,这个就意味着java ee移交后代码就此封版,如果想修改代码,不好意思,请另起炉灶,所以,Oracle你移交的意义在哪?

那么从Java EE到Jakarta EE会给企业带来什么影响?下面我们一起分析。

名称的转变

这个对企业影响不大,对开发者影响也不大,你可以愉快用着Jakarta EE最新标准的同时跟同事说java ee发布新版本了。

命名空间的转变

如果你是用Maven进行开发,那么Java EE的依赖是这么定义的

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

我们可以看到groupId是javax,并且源码的结构如下:

.
└── javax
    ├── annotation
    ├── batch
    ├── decorator
    ├── ejb
    ├── el
    ├── enterprise
    ├── faces
    ├── inject
    ├── interceptor
    ├── jms
    ├── json
    ├── mail
    ├── management
    ├── persistence
    ├── resource
    ├── security
    ├── servlet
    ├── transaction
    ├── validation
    ├── websocket
    ├── ws
    └── xml

所有的源码都定义在javax.*这个路径下,根据Oracle的要求Jakarta EE不能修改javax命名空间,那么Jakarta EE只能将代码中javax修改为jakarta,因此最新版本Jakarta Maven描述是长这样的:

<dependency>
    <groupId>jakarta.platform</groupId>
    <artifactId>jakarta.jakartaee-api</artifactId>
    <version>9.0.0-RC2</version>
    <scope>provided</scope>
</dependency>

源码目录:

.
└── jakarta
    ├── activation
    ├── annotation
    ├── batch
    ├── decorator
    ├── ejb
    ├── el
    ├── enterprise
    ├── faces
    ├── inject
    ├── interceptor
    ├── jms
    ├── json
    ├── jws
    ├── mail
    ├── persistence
    ├── resource
    ├── security
    ├── servlet
    ├── transaction
    ├── validation
    ├── websocket
    ├── ws
    └── xml

可以看到除了顶层包名称不一样下面的定义都一样,那么包路径更改会有什么影响?影响非常大。

  • 所有java ee应用服务器比如Weblogic,GlassFish等如果要支持最新版本的jakarta ee就必须修改源码重新编译,并且如果支持了jakarta ee就无法支持java ee,也就是无法向前兼容,Tomcat虽然只是Servlet容器但是Servlet本身就是Java EE的一部分,因此也逃不过修改的命运。据说Tomcat可以对应用进行自动代码转换以支持jakarta,因此在不远的将来我们可以看到各种奇技淫巧去兼容jakarta,是不是想起了被IE支配的恐惧。
  • 企业如果需要用到jakarta ee最新特性必须修改现有代码,修改并不复杂,就是把代码中import javax.*替换为import jakarta.*,修改完重新编译打包部署,似乎很简单,事实上没那么简单。
  • 对企业来说,保持应用服务器处于最新版本是必须的,因为新版本可能修复了老版本的漏洞,并且性能上也可能有一定的提升,但如果升级应用服务器的同时也要修改源码代码就很大,修改的成本,带来的风险并不是所有企业都能接受的。
  • 假设修改了一个应用,那么就需要部署到新版本应用服务器上,由于新服务器不兼容老应用因此需要运维两套应用服务器,运维成本提高,两套应用服务器也可能涉及license问题,不知道各厂商要怎么解决这个问题。

总之企业面临两难的境地,要么升级改系统源码,要么保持不变不升级,要么部分升级运维两套应用服务器,刀刀都要命。

未来

在如今各种诸如spring boot框架的包装下,在应用层面已经找不到Java EE的影子了,这些框架完全有能力抛弃jakarta自己实现,对于这些框架来说,跟随jakarta的意义似乎不大。对于企业来说,拥抱spring boot已经大势所趋,Java EE又搞出这么一件事,只会更加坚定企业转型的决心。对于开发者来说,Java EE已经是古董级的技术,Spring Boot不香吗,有什么理由去用jakarta EE。Oracle似乎也是看到了Java EE行将就木就索性移交出去,还能换取Eclipse基金会的董事会席位,但我还是看不懂Oracle对Java EE致命的这一刀目的何在,weblogic和中间件也是Oracle重要的两块业务,这两块业务都依赖Java EE,这么做只会两败俱伤。

Trackback

no comment untill now

Add your comment now