[关闭]
@Rays 2018-05-02T18:51:36.000000Z 字数 6211 阅读 1700

Jakarta EE:云原生Java的新平台

语言开发 Java


摘要: 在今年的JAX大会上,Eclipse基金会的执行董事Mike Milinkovich专门介绍了新的Eclipse治理模型和Jakarta EE路线图。新的治理模型基于近期对全球1800多名Java开发人员的调查,将聚焦于提供对微服务、云原生应用开发和加快版本发布周期等特性的支持。最近,Milinkovich就Jakarta EE未来的发展问题接受了InfoQ的专访。

作者: Michael Redlich

正文:

在今年的JAX大会上,Eclipse基金会的执行董事Mike Milinkovich专门介绍了新的Eclipse治理模型和Jakarta EE路线图。新的治理模型基于近期对全球1800多名Java开发人员的调查情况,并将聚焦于提供对微服务、云原生应用开发和加快版本发布周期等特性的支持。

在“Java创新的未来”(The Future of Java Innovation)分会上,Milinkovich首次展示了众所期待的新Jakarta EE图标。该图标将用做新Jakarta EE网站的标识。

Jakarta EE开发人员调查情况给出了三大关键领域:

最近,Milinkovich就Jakarta EE未来的发展问题接受了InfoQ的专访。Milinkovich根据调查结果指出:

上述目标是由社区为我们设立的,我们对此也有很好的共鸣。这些目标的实现,也是我们认为开发人员希望给出的正确场景之一。我们收到的反馈清楚地表明,开发人员与我们在这些目标上是步调一致的。

Milinkovich进而指出:

首先要记住的是,我们正在将Java EE全部迁移到Eclipse基金会,并重命名为Jakarta EE品牌。Java EE将继续存在,为其提供的支持将截至当前的版本级别。而未来的全部工作,都将在Jakarta EE品牌下开展。

Java EE已被“财富”1000强企业在其基础设施中的某处使用,并且全球目前已有数百万的Java EE开发人员。因此,Java EE是一个非常重要的技术平台,它驱动了大部分的企业系统。

Milinkovich回忆了他在去年秋天Oracle将Java EE的所有权转交给Eclipse基金会过程中的经历,并介绍了Jakarta EE的前进道路:

这是一次真正的旅程,最终,我们希望能够形成约40个新项目、具有约300位新的Eclipse项目提交者。Java EE的所有项目上线并在Jakarta EE下重命名,这其中的工作量非常大。

为了实现对Jakarta EE倡议的管治,我们成立了一个Jakarta EE工作组。我们正在建立一种全新的规范流程,用于接管JCP在其中所发挥的角色,这同样也将是一项十分重要的任务。我们还需要做一些工作,找出Jakarta EE品牌的合规程序。目前来看,我们的开局不错。

InfoQ:正如在新闻稿中所述,“该管理Jakarta EE代码库的Eclipse顶级项目承诺将在2018年发布两个版本。” 这些版本是否存在着建议的时间表?

Milinkovich:事实上稍为微妙。我们承诺在今年推出两个版本,用于迁移到Eclipse的技术项目,分别称为Eclipse GlassFish 5.1和5.2。Eclipse GlassFish 5.1将首次由Eclipse基金会交付所有的项目。对于所有项目的上线而言,GlassFish 5.1将成为一个主要的里程碑。考虑到要使用原先的Java EE TCK,该版本将被认证为Java EE 8兼容。一旦发布该版本之后,我们将进而推出5.2版,并称之为Jakarta EE 8兼容。

因此,Jakarta EE规范的首个版本将与Java EE规范保持同一水平,并且目前看来,它们是相同或近乎相同。该过程只是迁移操作中的一部分,我们希望保持尽可能少的自由度。

交付与Jakarta EE 8兼容版本的重要意义,在于这表明我们将启动并运行所有的规范流程,部署到位所有的认证计划和法律协议,进而运行认证程序。

InfoQ:这是否存在一个给定的时间表?

Milinkovich:Eclipse GlassFish 5.1将于今年第三季度末推出,Eclipse GlassFish 5.2将于年底前通过Jakarta EE 8认证。

InfoQ: 我们注意到,最近一轮的项目建议中包括GlassFish。

Milinkovich: 是的,最近一批提案中包括了GlassFish,我们已经接近于完成。其实还有一点也是十分重要,但是对此人们尚未对此过多置评,那这就是开源所有TCK的项目建议。在我看来,一旦所有的TCK开源,这将成为一个非常重要的建议。

InfoQ:Jakarta EE是基于Java EE 8的,我说得没错吧?

Milinkovich: 我们必须根据品牌并基于规范,仔细考虑那些开源相关的事情。Jakarta EE和Java EE一样,是一个依附于认证过程的品牌。因此,在声明WebSphere已通过Java EE 8认证之前,它必须通过Java EE 8测试。

类似的事情同样适用于Jakarta EE。但需要了解的重要一点是,这不仅仅是从Eclipse基金会交付开源代码。 而且也是为了支持那些在Jakarta EE品牌下的专有的和开源的独立实现。

并没有任何供应商给出正式的通知。但就目前而言,我希望并期待有一天WebLogic发布将被命名为Jakarta EE,并被认证为Jakarta EE 8兼容。对于WebSphere、JBoss、TomEE等,同样也是如此。

InfoQ: Java EE、Jakarta EE和EE4J等命名容易让人产生混淆。您能向我们的读者解释一下其间的差异吗?

Milinkovich:Java EE是当前定义Java EE的一组规范。Java EE是在JCP流程下完成的,并且为了达到当前的版本级别,还将继续在市场上运行数年。因此,Java EE基本上已被置于“仅维护”模式。对于一位Java EE客户,其软件供应商将在未来几年中继续提供支持。

Jakarta EE将成为这一持续推进的技术平台的名称。该技术的未来版本及其规格将以Jakarta EE的名称和品牌发布。我们将要建立一种类似的流程,用于验证一个产品是否兼容Jakarta EE。为此,产品必须要通过一系列的测试。这些测试的出发点与Java EE相同,因为它们是由Oracle提供给Eclipse基金会的验证过程的组成部分。

EE4J仅仅是Eclipse基金会的一个顶级项目名称,大部分Jakarta EE项目运行于其中。通常情况下,我们很可能永远不会在引用项目时以EE4J为名称。未来,人们将称自己是一位Jakarta EE开发人员。EE4J仅是一些组织工件,用于表示如何在Eclipse基金会上运行项目。

Glassfish、Jersey、Grizzly、JAX-RS等技术的所有参考实现,都位于EE4J顶级项目之下。但是EE4J并非一个品牌,而仅仅是一个顶级项目的名称。导致这种混乱的原因在于我们尚未选定品牌的名称。所以,人们在一开始将其称为EE4J,因为这是人们手头唯一的命名。

很不幸,这种混淆持续存在。这是不可避免的。希望随着时间的推移,我们将不再听到EE4J。

InfoQ:Oracle是否将会继续持有Java EE品牌?

Milinkovich:Java EE和Java将仍然是Oracle持有的商标。如果你打算将某个项目以Java EE命名,那么就必须要与Oracle商谈如何使用该名称。你可能已经看得了一些持有争议性观点的文章,它们对Oracle持批评态度,因为Oracle并未将Java EE命名转交给Eclipse基金会。

我想要指出两点。第一,争议是永远不会发生的。人们从一开始就十分清楚,Java是Oracle的一个重要品牌,Oracle将会继续拥有Java的品牌。如果你了解大公司和商标法的内容,你就会明白这是事情总是这样的。

第二,事实上,我们将这次重命名看作是一件非常积极的事情,也是这项技术的一个绝佳机会。在许多开发人员的头脑中,Java EE总是意味着十数年前在内部部署的应用服务器。通过将该技术重命名为Jakarta EE,我们有机会去改变这项技术能力在开发人员的思想中的印象。所以,我非常高兴能做这次重命名。我认为,这对我们而言是重塑这项技术的一个契机,可使该项技术在开发人员头脑中重新定位,因而将具有更积极的前景。

InfoQ: 这么说,聚焦于云原生特性绝对是一个好的出发点?

Milinkovich:确切地说,我预计随着技术的重点置于云原生和微服务上,很快还将会出现响应式。我们将尽快将这些重要的技术趋势加入到Jakarta中。这是一件十分新奇有趣的事情,因此我希望也确信,它们终将获得通过。并且从今年现在开始,会出现一些愿意尝试Jakarta EE的开发人员。

也许这些开发人员永远都不会考虑去尝试Java EE的某个新版本,因为在他们的印象中,Java EE并不会有助于问题的解决。所以我认为,对于Jakarta社区和技术而言,重命名是一个很好的契机。

InfoQ: 鉴于Java EE 8处于“仅维护”模式,Oracle是否将不会进一步发展Java EE?

Milinkovich:是的。不会再有Java EE 9了。

InfoQ:很多应用不能运行在Java SE 9上,例如Payara、GlassFish、OpenLiberty等。但这已经发生了一些变化。例如,Data Geekery jOOQ的支持项目已模块化,Speedment去年启动了向Java 9的迁移过程。Jakarta EE最终是否会支持Java 9?

Milinkovich: 我认为从某种程度上看,完全可以说Jakarta将支持Java 9。但很明显,Java EE的整个生态系统尚未实现代码的模块化,进而可以使用Jigsaw,所以仍有许多工作需要推进。

Java生态系统作为一个整体,必须要随时关注平台和语言的最新发展。我相信对Java 9的支持终将实现,但我并不清楚这将于何时发生,以及将在哪个发行版本中实现。它必须成为一个合理的优先事项,并且还有很多重要的事情需要完成。

InfoQ:当然,相比起实现Java 9支持,当前的事项要更为优先。

Milinkovich:部分原因在于对技术的采纳。如果我们翻看一下调查结果,就会发现与Java 8的采纳情况相比,采纳Java 9(当前是新发布的Java 10)的比例微乎其微。因此,我认为在Java 8的支持过期后,将在几年内看到更多的迁移。

目前,要让人们所具有的代码可完全适用于Jigsaw和模块化,还需要做大量的工作。所以,对Java 9的支持只是暂时搁置,直到迫不得已时才会启动。

同时,我认为压力主要在于移植那些基于Java构建的工具和框架。一旦客户和企业开始迁移基础架构中的各项零零碎碎,从IDE到日志记录,这种将整个Java生态系统迁移到模块化无疑是一项艰巨的任务。

InfoQ:在JDK 11中去除了Java EE和CORBA模块(即JEP-310)。这是否会对Jakarta EE产生某种影响?

Milinkovich:Java EE正在移交Eclipse基金会的过程中,其中将确保在SE和EE间给出绝对清晰的分离。部分泄漏到SE中的JTA规范,同样也被拒之门外。所以,这只是一些背景清理工作,与其它所有的工作是并行发生。

InfoQ: JDK已经采用新的“六个月发布”周期。Jakarta EE是否也有必要采用同样的发布周期?

Milinkovich:目前我们还不知道。依我个人的观点,这并不反映社区中任何技术牵头者的观点,就是Jakarta EE完全没有必要对Java SE亦步亦趋,去每隔六个月就推出一个新发布。

在我看来,创新的速度和节奏,取决于我们需要采取什么措施去实现云本地和微服务,去实现响应式。我认为在这些创新中,只有相对较少的一部分是与Java SE平台中的全新功能密切相关的。就此而言,我们会给出一个对我们自身有意义的发布节奏,因为企业迁移到新版本Java发展的速度,肯定要滞后于Java的发布速度。

目前,我尚未看到将Jakarta EE的发布节奏挂钩到六个月周期以与Java SE亦步亦趋这一做法的可取之处,尽管我们可能终将看到。我可以构想每六个月交付一次这样的场景,但这并不一定意味着我们每隔六个月就要推出一个新版本的Java。

如果企业和云计算框架都没有必要每隔六个月就转向最新最好的Java版本,那么我认为Jakarta EE也完全没有任何必要这样做。就像我曾说的那样,这是完全是我的个人观点。也许大家会看到,那些实际运作这些项目的技术人员会持完全不同的观点。

InfoQ:Eclipse基金会是否与云原生计算基金会(CNCF)具有一定的工作联系?

Milinkovich:公平起见,可以说是我们希望与CNCF建立工作联系。我们正在与CNCF就我们在构建物联网中使用的一些技术上建立工作关系。我们的目标是确保Jakarta EE能以平台形式,尽可能强壮地运行在Kubernetes和Docker生态系统上。这样,我们就可以与CNCF开展合作,共同讨论双方的需求。

我认为这对我们双方而言都是一个很好的机会。很明显,Kubernetes在工业界具有很好的发展势头,因为Kubernets不仅为人们提供了将工作负载从云到云服务提供商转移出来的能力,而且也提供了从本地云基础设施转移到公共云基础设施的能力。Kubernets为人们提供了很大的部署灵活性。

与此同时,Java是企业中最重要的语言平台。因此我认为,这两种技术的紧密结合程度,不仅有助于双方为企业采纳云计算提供帮助,而且还充分地利用了数百万开发人员的技能,并帮助他们将自身的技能推向该新技术领域。

InfoQ:这是否意味着Eclipse基金会和CNCF需要以成员方式相互参与到对方的组织中?

Milinkovich:我们可能会那样做,但我们和CNCF都并非以收费服务(Pay-to-play)模式运行的基金会。这不是我们要做的事情。但我认为,这给出一种很好的姿态,使得我们双方都可以公开表明,我们正开展合作,并具有很好的合作基础。

相关资源

查看英文原文: Cloud Native Java Has A New Home: Jakarta EE

添加新批注
在作者公开此批注前,只有你和作者可见。
回复批注