雅加达poi
在本文中,我们将解释Jakarta EE 8的全部含义。 但是在我们去那里之前,让我们先回顾一下历史。
过去
Java于1996年与当时称为Internet的Netscape收购的Kiva Enterprise Server应用服务器一起发布。 同时,BEA收购WebLogic之后不久,一家名为WebLogic的公司就一直在使用完全不同的API来致力于“应用服务器”的类似概念。
与Sun Microsystems一起,主要基于这两个服务器设计用于广泛通用框架的初始API(JDBC,EJB,Servlet和JSP)。 1999年末,该框架的第一个版本问世:名称有点混乱的J2EE 1.2,由前面提到的Kiva(现在称为iPlanet Application Server(iAS)和WebLogic)实现。
J2EE是(某种程度上)开放的标准,这意味着它可以由其他方许可,然后其他方可以提供它的认证实现。 后来,这些团体甚至可以通过称为JCP的程序加入规范的设计。 Java Community Process,在其整个时期变得越来越开放。
J2EE 1.2对市场产生了很大的影响,很久以前,许多公司推出了与其兼容的产品,包括IBM WebSphere 4,BEA WebLogic 6.1,Oracle 9i AS,Tmax Soft JEUS 3.0,Borland AS 4.5,NEC WebOTX 4.2等。 J2EE在2001年发展到1.3,在2003年发展到1.4,并有19种实现,其中OSS实现是JBoss AS,JOn AS和Apache Geronimo。 值得一提的是,还存在一定数量的J2EE部分实现,例如Tomcat,Jetty,Resin和IronFlare的Orion。
在此期间,我们还进行了几笔较大的收购; 红帽收购了JBoss,Oracle收购了IronFlare和BEA。
尽管实现了许多实现,但J2EE 1.4却遇到了障碍。 一个复杂的墙形式。 在2006年中期,J2EE或多或少以Java EE 5的形式重新启动,该版本着重于开发人员友好性和配置约定。 但是,实现兼容的公司数量减少了,原始实现的数量甚至更少了,基本上由GlassFish,WebSphere,WebLogic,JBoss AS,JOn AS,Geronimo,JEUS和NetWeaver组成。 Java EE 5在2009年末演变为Java EE 6,它引入了许多“现代” API,特别是JAX-RS和CDI,以及期待已久的重新启动JSF(恰当地命名为JSF 2)。
但是,大约在同一时间,Sun被Oracle收购,这极大地改变了Java EE生态系统中的动态。 由于Oracle已经收购了BEA(WebLogic)和IronFlare(Orion),所以它现在还拥有GlassFish,此外,JCP的功率方程式还消除了多余的力量。 随着Apache离开JCP以及Geronimo和JOn AS悄然消失,Java EE市场从本质上减少到了Oracle,IBM和Red Hat这三个主要参与者,再加上规模小得多的Tomitribe,这些遗留了一些东西由Geronimo支持,用于一个名为TomEE的新AS。
还请参见:
与5和6相比,Java EE 7相对于5和6发行版相对较小,最终揭示了现代Java EE平台的含义。 具有可组合拦截器,验证服务和扩展点的核心bean模型。 本来应该用Java EE 8来完成该模型的开发,但是随后事情就大大放慢了速度。 Java EE 8的发布范围大大缩小了,Oracle在2017年末宣布将把Java EE转移到Eclipse Foundation。
现在
转移已经进行了大约两年,其中包括许多步骤:
- 审核和清理现有源代码
- 实际转移的代码,包括问题
- 设置作业以在Eclipse基础架构上构建一切
- 将所有组件的Maven坐标更改为雅加达。*
- 发行Eclipse GlassFish 5.1 ,该版本完全由Eclipse的已移植源构建而成,并通过了现有的Java EE 8 TCK(并正式进行了认证 )
- 设计新的Jakarta和Eclipse规范和认证流程以替代JCP,并获得新的规范许可证
- 传输Java EE TCK源
- 根据新规范许可,从转让的TCK来源构建一系列TCK二进制文件
- 将构成Java EE 8 API的所有项目转换为规范项目,并替换Oracle商标用语或Oracle和Eclipse之间协商解决的其他不再使用新用语的术语
- 向规范项目添加新的范围声明
- 针对更新的API 运行新建的和获得许可的TCK ,针对分阶段的构建运行Jakarta EE 8的认证请求
- 释放暂存的API罐
完成并完成所有工作后,我们将发布一个Jakarta EE 8 API版本,该版本具有与Java EE 8 API相同的签名,但该签名是通过Eclipse Foundation完全构建,许可,测试和认证的及其过程。
在撰写本文时,上述列表中的倒数第二个步骤正在紧锣密鼓地进行中,我们预计很快就会完成工作,该工作应该在2019年8月下旬之前进行。之后,WildFly,Open Liberty和其他公司将很快获得Jakarta EE 8认证。
如上文所述,Jakarta EE 8将为所有众所周知的API带来一组新的名称。 对于这些新名称,我们(决定委员会和提交者)共同决定优先使用小名称,而不是较长的名称,尤其是避免使用晦涩的缩写。 Java EE的长期用户当然习惯于使用JMS,JTA,JCA,JPA,JSF,EJB等缩写,但是对于新手来说,这经常被认为是入门的障碍。 在研究名称时,我们发现它们实际上是不一致的。 即,为什么JMS是“服务”,JTA是“ API”,JCA是“架构”? 几乎总是这些词实际上只是某种填充词,并没有真正带来任何附加值。
还请参见:
为了便于讨论,我们将新名称分为三层:
方法1:一个字
- 雅加达Servlet
- 雅加达面Kong*
- 雅加达WebSocket
- 雅加达并发
- 雅加达拦截机
- 雅加达认证
- 雅加达授权
- 雅加达安全
- 雅加达消息
- 雅加达坚持
- 雅加达楼盘
- 雅加达批次
- 雅加达邮件
- 雅加达连接器
- 雅加达注释
- 雅加达激活
- 雅加达NoSQL
方法2:两个字
- 雅加达Bean验证
- 雅加达表达语言
- 雅加达企业豆
- Jakarta XML绑定
- Jakarta JSON绑定
- 雅加达JSON处理
- 雅加达服务器页面
方法3:三个字或以上
- 雅加达XML Web服务
- 雅加达RESTful Web服务
- 雅加达标准标签库
- 雅加达语境和依赖注入
(*由于时间安排的问题,临时将其称为Java Server Faces,但目的是尽快纠正这一问题)
未来
一个棘手的问题仍然存在,那就是将所有Java API包从javax。*重命名为jakarta。*。 例如, javax.servlet.http.HttpServletRequest将成为jakarta.servlet.http.HttpServletRequest 。
显然,这是一个会影响现有代码的更改,因此应该有一个好的策略。 有很多不同的选择,包括借此机会也将重命名为奇特的程序包(例如javax.security.auth.message)重命名为jakarta.security.auth.message。*,而不是jakarta.authentication,直接匹配(新)规格名称。 正在考虑的其他选项是所谓的“大爆炸”重命名(一次性重命名所有内容)或递增重命名(仅在需要更新该API中的任何内容时重命名整个API)。 仍然需要做出决定,但是从各种民意调查,观点和讨论中,似乎以下是选项的首选组合:
- 大爆炸( 一口气重命名所有API )
- 仅限javax。*至jakarta。*( 不涉及程序包名称的任何其他部分 )
- Jakarta EE 9仅涉及重命名( 没有其他新功能,这将是EE 10的主题 )
另一个未解决的问题是规范文档的传输。 尽管进行了所有工作,但这仍然没有发生,但预计会在合理的时间内发生。 同时,因此,雅加达EE 8的发布没有“真实的”规范文档,而是带有所谓的样板规范文档。 该文档实质上仅包含许可证和范围,而没有其他内容。 当然,API的Javadoc也已成为规范的一部分。
我们都期待着最终拥有转让流程,并开始开发下一代Jakarta EE。 如果遵循上述重命名路径,则将其命名为Jakarta EE 10,或者有时将其称为Jakarta EEX。
JakartaOne LiveStream上将披露此难以捉摸的X版本中可能显示的一些计划,因此,如果您对Jakarta EE的未来感兴趣,请务必参加!
该博客文章最初出现在Eclipse Foundation的August时事通讯中 。
翻译自: https://jaxenter.com/jakarta-ee-8-past-present-future-161990.html
雅加达poi