JDK是一个不断变化的环境。 一些工具正在离开，其他工具正在到来，而幸运的工具则活着讲述着这个故事。

首先传来的消息 ，我们正在告别的Java EE和CORBA组件，那么很明显，JDK 11代表的不仅仅是对Java EE模块的路的尽头 -这也是为JavaFX在路的尽头-种，因为它现在可以作为独立的模块使用，并且与JDK分离。 仅仅几个月后，我们发现狩猎季节还没有结束，最新的受害者是Nashorn JavaScript Engine ，该引擎最初并入JDK 8 [并于2014年3月发布]。

我们在采访系列的第二部分中谈到了这种“Spring大扫除”，但是现在该讨论一下关门和关门的时候了。 您能猜出我们在谈论什么技术吗？

认识有影响力的人

Markus Eisele（ @myfear ）是Lightbend的开发者倡导总监和Java冠军。

Guillaume Laforge（ @ glaforge ）是Google Cloud Platform的开发倡导者，Apache Software Foundation的Apache Groovy PMC主席和Java Champion。

Lukas Eder（ @ lukaseder ）是Data Geekery GmbH的创始人兼研发主管，该公司是jOOQ背后的公司和Java冠军。

Josh Long（ @ starbuxman ）是Pivotal的Spring Developer Advocate。 他是5本书和3本畅销视频培训的作者。 他还是Java冠军。

Eberhard Wolff（ @ ewolff ）是INNOQ的研究员和软件架构师。

Martin Thompson（ @ mjpt777 ）是一名顾问，培训师和教练，专门设计高性能和低延迟的系统。 他还是Java冠军。

昆汀·亚当（Quentin Adam）（ @ waxzce ）是Clever Cloud的首席执行官。

Markus Eisele：很难将Nashorn与GraalVM进行比较。 首先，该缩写下有许多项目。 它是用于HotSpot的新JIT编译器，也是新的多语言虚拟机。 我个人认为这是重新思考Java和其他语言的编译器设计的机会。 通常，用Java重新创建更好的Java编译器具有很多优点。

另一方面，Nashorn被设计为JVM上JavaScript引擎。 我没有看到很多构建在上面的生产系统，对我来说，它一直是对Java 8引入的新invokedynamic调用站点的非常独特而完整的测试。

我的期望是，与运行在HotSpot之上的任何东西相比，GraalVM在运行JavaScript代码时将提供更好的结果。 可以肯定的是，社区有机会接管它，但我不确定是否值得。

我很悲伤地看到了GPL许可证，这使得它不可能由Apache基金会项目中使用，例如格拉尔去。

Guillaume Laforge： Nashorn和GraalVM是完全不同的两件事。 前者实际上是一种嵌入式语言，而后者是一种新的Java VM。

如前所述，对于Nashorn的替代产品，已经存在可以轻松添加到Java项目中的可变替代语言，例如Apache Groovy编程语言。

但是GraalVM绝对是一个有趣的项目，因为它承诺了简单的多语言集成故事。 但是，我对构建本机映像的功能更感兴趣，该功能使应用程序可以更快地启动，占用更少的磁盘和内存空间。

但是，我很遗憾看到Graal带有GPL许可证，例如，这使得Apache Foundation项目无法使用它。 我希望Oracle将许可证更改为Apache许可证之类的东西，以便更广泛地使用。

Lukas Eder：我绝对认为Nashorn和类似的引擎不属于JDK。 我不认为它们是独立的第三方项目（无论是由Oracle还是其他供应商提供）。

面对现实吧。 JAXB已添加到JDK，然后再次删除。 Rhino已添加到JDK，然后再次删除。 JavaDB / Derby已添加到JDK，并将再次删除。 JavaFX已添加到JDK，并将再次删除。 纳斯霍恩…

我认为JDK不应包含任何此类“第三方”工具。 而且人们不应该依赖那些工具作为JDK的一部分。

还请参见： Nashorn JavaScript Engine不推荐使用：“这可能再次增加Rhino的重要性”

乔什·朗（Josh Long）：我认为纳斯霍恩（Nashorn）应该让社区保持生机，但我不知道这样会怎样。 无论如何，JavaScript都是最丰富的语言之一，但即使在Oracle的带领下，Nashorn仍然没有蓬勃发展。 开发语言很困难，并且取决于专业技能。 这不是公地的工作。 很少有人会像JRuby的Charles Nutter那样热心和才华横溢的人们为热爱这项工作而工作。

Graal是令人兴奋的地平线！ 我正在尝试，他们正在突飞猛进。 我特别喜欢同一平台和本机图像生成器下的语言互操作。

如果Nashorn足够重要，它将保持活力。

Eberhard Wolff：淘汰Nashorn的JDK增强建议实际上询问了有多少开发人员正在使用Nashorn。 因此，似乎他们有理由相信Nashorn毕竟不那么受欢迎。 但是，如果事实证明纳索恩实际上很受欢迎，他们愿意改变自己的理由。 我还不清楚为什么JavaScript实现应该成为JDK的一部分。 还有其他脚本语言可以作为第三方库使用，对于JavaScript也应该适用。 因此，我想如果Nashorn足够重要，它将保持活力。

我认为GraalVM是目前Java领域最重要的创新。 从一开始，Java就一直使用字节码。 如果需要，甚至可以更改此基本原理。 这种创新和灵活性而又不牺牲太多的向后兼容性，是Java在如此长的时间之后仍然有用的原因。

Martin Thompson：我在服务器端并没有太多参与JavaScript。

昆汀·亚当（Quentin Adam）： JDK中的模块是一件好事，将核心与非必需的东西分开很重要。 考虑到Java生态系统内部JavaScript语言，其愿景是将其用作脚本语言。 但是今天，该角色比Apache Groovy更为重要，并且当前在JVM之上使用JavaScript并不需要将其嵌入平台的核心。

作为一个技术项目，Nashorn是一款非常出色的软件，我非常喜欢它，甚至在几年前我甚至构建了服务器端JavaScript应用程序服务器并在其之上构建工具。 但是，随着时间的流逝，只有人们每天都需要时，它才能得到维护。

它可以使延迟对于Java应用程序来说不是问题吗？

Markus Eisele：一种有趣的方法。 Azul已经有很长一段时间收集大量堆垃圾了。 红帽有雪兰多。 随着ZGC进入OpenJDK，它将为需要此功能且无法在正常堆大小内工作的方案提供替代方案。

我的感觉是，从中获利的利基用例很少。 尤其是在微服务架构中，一切都与超快速的启动时间和较小的占用空间有关。 低延迟部分肯定会满足这些要求。

在Fosdem演示中 ，有些野外数字很有希望。

还请参见： ZGC：使Java成为更广泛的应用程序更有吸引力的平台

Guillaume Laforge：对于寿命短的应用程序（例如应该快速启动并仅持续几秒钟的小型微服务），我认为这是一个可喜的变化。

Java一直以来都有抱怨，因为它的启动时间很慢，而且某些GC周期会造成一些暂停，因此这肯定会有所帮助。

当然，不应将它用于长时间运行的应用程序，否则您将很快遇到内存问题。

多年来，有很多用例可用于此GC。

乔什·朗（Josh Long）：什么不是爱？ 多年来，有很多用例可用于此GC。 大数据和在线交易系统浮现在脑海。 我们已经看到了有趣的发展，例如用于各种数据网格技术的堆外内存以及Azul的Java虚拟机在支持大堆方面的出色工作，这也许可以从ZGC中受益。

卢卡斯·埃德（Lukas Eder）：我从事的行业不多，所以我无法发表评论。

埃伯哈德·沃尔夫（Eberhard Wolff）：也许。 这无疑是一个重大转变，并且可能会消除Java的一个重大问题。 但是，垃圾回收非常棘手，通常必须在生产中进行调整。 因此，我宁愿等到我们对ZGC在生产中的实际工作方式和缺点有更多的了解。

Martin Thompson：垃圾回收是许多Java应用程序的主要问题，但是许多Java开发人员并未意识到这一点。 在分布式系统中，与实际的网络故障相比，网络分区更可能是由GC事件引起的。 我已经看到Azul Zing成功地用于消除垃圾收集问题，从而使设计能够以显着的分配速率处理大型内存空间而没有问题。

还请参见： ZGC加入聚会：针对JDK 11的JEP 333

ZGC有潜力成为Zing的不错替代品，但Zing Linux内核内存模块的性能将受到限制。 GC是一个看到良好进展的空间。 Java 10通过消除单线程完整GC的瓶颈消除了G1的主要问题之一，现在使用了并行算法，希望线程检查点可以提高写屏障成本。 我们还看到来自Red Hat和Epsilon No-Op垃圾收集器的Shenandoah的竞争越来越激烈，这提供了比较GC实施方案的基准。

它可以彻底解决延迟问题吗？ 不，但这是向前迈出的一大步。

Quentin Adam： ZGC是一款令人印象深刻的软件，给我留下了深刻的印象。 这将帮助JVM扩展许多繁重的工作负载，并继续统治大数据市场。 它可以彻底解决延迟问题吗？ 不，但这是向前迈出的一大步。 但是，由于没有完美的工具可以满足从修理洗衣机到建造木房子的所有需求，因此计算机科学可以使用多种工具来解决我们面临的问题。

有时，垃圾收集器是一个问题，由于GC总是会引入延迟，因此您需要使用一些非托管语言，例如Rust或C。由于Java平台已经具有广泛的使用前景，因此ZGC的兴趣在于随着需求的增长和硬件的进步，性能也随之提高。

下周，我们将讨论Java影响者希望在JDK 12中看到的功能，以及无服务器在Java未来中的作用。

如果您想与Java推动者和摇动者见面，请于10月在伦敦加入我们。

JDK 11的17个功能

为了刷新您的记忆，JDK 11包含以下功能 ：

引入nests ，这是一种与Java编程语言中嵌套类型的现有概念一致的访问控制上下文。 嵌套允许类在逻辑上属于同一代码实体，但被编译为不同的类文件，可以访问彼此的私有成员，而无需编译器插入可访问性增强的桥接方法。

309：

扩展Java类文件格式以支持新的常量池形式CONSTANT_Dynamic 。 加载CONSTANT_Dynamic会将创建委托委派给bootstrap方法，就像将调用动态调用站点链接到bootstrap方法一样。

315：

改进现有的字符串和数组内部函数，并在AArch64处理器上为java.lang.Math sin，cos和log函数实现新的内部函数。

318：

开发一个可以处理内存分配但不实现任何实际内存回收机制的GC。 一旦可用的Java堆耗尽，JVM将关闭。

320：

从Java SE平台和JDK中删除Java EE和CORBA模块。 这些模块在Java SE 9中已弃用，声明要在将来的版本中删除它们。

321：

通过JEP 110标准化JDK 9中引入的，在JDK 10中更新的已孵化的 HTTP客户端API。

323：

在声明隐式类型的lambda表达式的形式参数时，允许使用var 。

324：

如RFC 7748中所述，使用Curve25519和Curve448实现密钥协议。

327：

升级现有平台API以支持Unicode标准 10.0版 。

328：

提供低开销的数据收集框架，用于对Java应用程序和HotSpot JVM进行故障排除。

329：

实现RFC 7539中指定的ChaCha20和ChaCha20-Poly1305密码。 ChaCha20是一种相对较新的流密码，可以代替较旧的，不安全的RC4流密码。

330：

增强Java启动器以运行作为Java源代码的单个文件提供的程序，包括通过“ shebang”文件和相关技术从脚本内部使用该程序。

331：

通过JVMTI提供一种低开销的Java堆分配采样方法。

332：

实现传输层安全性（TLS）协议的1.3版。

333：

Z垃圾收集器（也称为ZGC）是可伸缩的低延迟垃圾收集器。

335：

弃用Nashorn JavaScript脚本引擎和API，以及jjs工具，以在将来的发行版中删除它们。

336：

在java.util.jar弃用pack200和unpack200工具以及Pack200 API。

翻译自: https://jaxenter.com/java-influencers-series-4-148837.html