小白科普:Java EE vs J2EE vs Jakarta EE

Java · tyson · 2019-01-11 · 0 次阅读

文章来源: http://zhuanlan.51cto.com/art/201901/590328.htm, 本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。

1. 引言

听说过 Java EE 吗?那关于 Java 2 EE 、J2EE 或者现在的 Jakarta EE,你又是否有所耳闻呢?实际上,这些各异的术语描述的都是相同的东西:由 Java SE 扩展出的一系列企业规范。

在本篇短文中,我们将讲述 Java EE 的发展史。

2. 历史

在 Java 的第一个版本中,Java 企业扩展还只是核心 JDK 的一部分(译者注:核心 JDK 通常指 Java SE) 。然而到了 1999 年,Java 企业扩展已经被剥离出 Java SE,成为了 Java 2 的一部分,这也意味着 J2EE,或者说Java 2 平台企业版(Java 2 Platform Enterprise Edition)的诞生。J2EE 这个称呼一直维持到2006年。

2006 年发布的 Java 5,J2EE 被重命名为 Java EE,或者说 Java 平台企业版(Java Platform Enterprise Edition)。这次改名后的称呼一直延续到 了 2017 年的 9 月。那年发生了一件重大的事,Oracle 决定将 Java EE 捐赠给 Eclipse 基金会(但 Java仍然属于 Oracle)。

3. 转变原因

事实上,因为 Oracle 拥有 “Java” 商标权。按照法律要求,Eclipse 基金会需要对 Java EE 进行更名。

经过社区的投票选择,Java EE 被更名为 Jakarta EE。从某种意义上来说,Java EE 依然叫 JEE。(译者注: 将 Java EE 首字母缩写也可简称为 JEE)。

小白科普:Java EE vs J2EE vs Jakarta EE

不过这仍然是个正在进行的故事,还未完全尘埃落定。

举个例子,虽然 Oracle 开源了 Java 源代码,但却并未开源所有的文档。关于这个问题,因为涉及到一些法律事宜,导致开源一些文档(例如与 JMS、EJB相关的)非常棘手,至今仍有许多争议。

现在还无法得知新的 Eclipse 基金会文档是否能够参考原文档。

同样令人奇怪的是 Eclipse 基金会不能使用 javax 的命名空间来创建新的 Java 包,但是可以在现有包的下面创建新的类和子类。

转变阶段也意味着对 Jakarta EE 添加规范的新流程。为了更好地理解这一点,让我们快速看一下 Oracle 添加规范的流程以及 Eclipse 基金会相应做出的改变。

4.未来

在过去,为了将一个特性添加进 “EE”(译者注:原文作者为了避免 Jakarta EE 历史名字的混杂性,使用“EE”来代指全部的版本,下同),我们需要 3 样东西 :规范、参考实现与测试。社区里的任何人都可以提交这 3 样东西,之后执行委员会将会决定何时将它们整合进 Java 语言中。

为了更好地理解添加规范的旧流程,让我们进一步了解 JSRs、Glassfish 和 TCK是什么 ,以及它们是如何整合新特性的。

我们也将一睹在未来可以预期的事。

4.1 JCP 以及现在的 EFSP

在过去,产生EE 新特性的流程被称为 JCP(Java Community Process)。

Java SE 现在仍然采用 JCP。但是由于 EE 的所有权已经从 Oracle 移交至 Eclipse 基金会,EE 已经有了新的流程,这个流程是Eclipse 开发流程(https://www.eclipse.org/projects/dev_process)的扩展,与 Java SE 的流程互不干扰,我们称之为 EFSP(Eclipse Foundation Specification Process)。

尽管 JCP 与 EFSP 之间有一些大的差异,但大都围绕着“透明、公开、集体负责和供应商中立”这几条准则展开。例如,EFSP 的组织者设想的合作工作团体是供应商中立的,认证流程是自助服务的,组织的运作与管理是精英化的。

4.2 JSRs

在 JCP 中,为 EE 添加新特性的第一步是创建一个 JSR(Java Specification Request)。JSR 有点类似于一个 EE 特性的接口。JCP 执行委员会会核准一个完整的 JSR,然后相应的 JSR 贡献者会编写代码,使其在社区内生效。

JSR-339 或者 JAX-RS 对于阐述上面的流程是一个好例子。JAX-RS 最初于 2011 年提出,在2012年被 JCP 批准,最终在 2013 年得以发布。

虽然在讨论规范时,社区可以随时加入进来,但时间表明,一个实现优先( implementation-first)的方式更利于创建能被广泛接受的特性与 API。所谓的实现优先,类似于JSR 310中的 java.time 和 Joda Time这个例子(译者注:JDK 1.8 之前 Java 关于时间的 API 很不如人意,使用广泛的是 Joda-Tme)。

因此,EFSP(Eclipse Foundation Specification Process)在其设定的目标中阐述了这个观点:“EFSP 将基于是否先进行了动手实验和编码,来判断其是否值得添加进规范中。

4.3 GlassFish

此外,JSR 作为 JCP 的一部分,需要一个参考实现。这有点类似于实现接口的类。对于那些想要创建自己的规范实现的群体,比如说兼容库的开发人员或者其他组织,参考实现都可以给予帮助。

对于 Java EE 特性,JCP 使用 Glassfish 作为参考实现。

虽然 Glassfish 的中心化简化了实现者的探索过程,但是这种中心化也要求更多的管理,并且倾向于偏袒某个供应商。

因此,EFSP 不要求参考实现,而只要求兼容的实现。简而言之,这种微妙的变化使得类似 Glassfish 之类的中心体系结构内的实现,不会被基金会无缘由地首选。

4.4 TCK

最后,JCP 要求 EE 特性需通过 TCK(Technology Compatibility Kit)的测试。

TCK 是一组验证特定 EE JSR 的测试。简而言之,为了遵循 Java EE,应用 服务器 需要实现所有 JSR, 并通过特定 TCK 上的所有测试。

与前述类似,Oracle虽然开源了TCK和EE jsr的源代码(译者注:但并没有开源相应的文档)。当然,未来所有的文档和 TCK 都将是开源的。

5. 总结

这些年来,Java EE 无疑前进了许多。很高兴看到它继续变化与变好。

前方之路充满坎坷,希望 Java 的转变能够平滑些。

作者 | Rodrigo Graciano

https://www.baeldung.com/java-enterprise-evolution

小白科普:Java EE vs J2EE vs Jakarta EE

【本文为51CTO专栏作者“刘欣”的原创稿件,转载请通过作者微信公众号coderising获取授权】

戳这里,看该作者更多好文

以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网

码农书籍
程序员的自我修养:链接、装载与库

程序员的自我修养:链接、装载与库

俞甲子、石凡、潘爱民 / 电子工业出版社 / 2009-4 / 65.00

这本书主要介绍系统软件的运行机制和原理,涉及在Windows和Linux两个系统平台上,一个应用程序在编译、链接和运行时刻所发生的各种事项,包括:代码指令是如何保存的,库文件如何与应用程序代码静态链接,应用程序如何被装载到内存中并开始运行,动态链接如何实现,C/C++运行库的工作原理,以及操作系统提供的系统服务是如何被调用的。每个技术专题都配备了大量图、表和代码实例,力求将复杂的机制以简洁的形式表达出来。本书最后还提供了一个小巧且跨平台的C/C++运行库MiniCRT,综合展示了与运行库相关的各种技术。对装载、链接和库进行了深入浅出的剖析,并且辅以大量的例子和图表,可以作为计算机软件专业和其他相关专业大学本科高年级学生深入学习系统软件的参考书。同时,还可作为各行业从事软件开发的工程师、研究人员以及其他对系统软件实现机制和技术感兴趣者的自学教材。

JSON 在线解析
JSON 在线解析

在线 JSON 格式化工具

随机密码生成器
随机密码生成器

多种字符组合密码

HEX HSV 转换工具
HEX HSV 转换工具

HEX HSV 互换工具