Java 9幕后花絮：新功能从何而来？

JCP

找出Java幕后发生的事情，以及新功能如何实现

在上一篇文章中，我们介绍了即将发布的Java 9版本的新功能和尚待解决的功能，并简要提到了将新功能添加到下一个版本之前要经历的过程。由于此过程几乎影响了所有Java开发人员，但大多数人对此知之甚少，因此本文将重点介绍内部人员对Java的看法（以及如何建议您一直想要的新功能）。我们认为了解新功能如何生活的最佳方法是询问负责将其实现的人。

我们与2位Java执行委员会成员Gil Tene和Werner Keil以及伦敦Java社区成员Richard Warburton进行了交谈，并向他们询问了Java的新功能以及他们希望将来看到什么样的新功能。这篇文章将涵盖面试的第一部分。

但是在执行此操作之前，以下是参与创建新功能并对其进行投票的主要参与者：

组 –在广泛的主题或特定代码体系方面具有共同利益的个人和组织。安全，网络，Swing和HotSpot是一些示例。

项目 –产生大量代码，文档或其他努力的工作。必须由至少一个团体赞助。最近的示例是Lambda项目，Jigsaw项目和Sumatra项目。

JDK增强建议 （ JEP ）–允许在需要进一步探索时在JCP之前或与之并行地非正式地推广新规范。与JSR不同，它可能还包含没有规范级可见性的功能（例如，新的垃圾收集器或JIT实现）。接受的JEP成为JDK路线图的一部分，并分配一个版本号。

Java Specification Request （ JSR ）–该功能的实际规范在此阶段发生，可以通过组/项目，JEP或来自单个JCP（Java Community Process）成员来进行。通常会为每个Java版本打开一个伞式JSR（也称为平台JSR），Java 9尚未实现。社区的每个成员也可以提出新的Java规范请求。

新功能如何进入Java？

Warburton： “真正的答案是有人想要该功能。该人可以是大型供应商的内部工程师或项目经理，也可以是社区的外部成员。无论哪种方式，都需要满足严格的标准：

严重的用户需求：它必须是对整个社区的共识。示例：Java SE 8添加了lambdas-这项功能已经争论了很多年，并且已经被人们要求。
经过试验和测试：标准必须持续很长时间，并且修改已经建立的标准是非常困难且昂贵的过程。结果是JCP（Java社区流程）并不是最前沿。一旦技术为企业所采用，它就成为了一个去处。
并非每个供应商都独有：标准必须适合所有供应商。例如：弱/软/幻像引用与垃圾收集器交互，因此以一种试图最小化它们对GC设计的限制的方式指定了它们。

“一旦确定您的功能是一个好主意，就需要开始标准化过程。这涉及到提出一个JSR（Java规范请求），它是更改Java的基本单元。 JSR需要多次投票。首先，批准在此主题上启动JSR是一个好主意。每当进行公共审核时，都要反复进行迭代，以确保JSR朝着正确的方向前进。最终是时候批准标准了。

Tene： “ Java长期以来一直在进行仔细和有意的增强。在历史上，仍然使Java比几乎所有其他编程语言和环境更成功的事情之一是，它在避免Swift采用“最新的有趣事物”方面取得了相对的成功，以及它作为平台的相对一致性。在整个平台（Java SE，EE等）整个平台上都是如此，但在Java SE平台（我将大部分精力集中在Java SE平台上）中，可能最清楚地遵循了这一点。集合，NIO，泛型，平台优化的并发实用程序，MethodHandles，以及最新的Lambda表达式和流库支持都是很好的示例，这些功能随着时间的流逝而被添加并被广泛采用，显示了它们对平台的真正价值及其重要性。不只是短暂的时尚。”

“ JCP（Java社区流程）负责通过JSR捕获新功能。成功的独立JSR可以标准化一组特定功能或行为的语义。但是，当功能成为平台JSR的必需部分并由此成为Java SE或Java EE平台的组成部分时，通常会证明该功能的最终成功和采用。自从创建OpenJDK以来，我们已经看到Java SE的许多早期功能工作都从在JSR中开发到在JEP中开发（JDK增强建议）。它们最终仍然像以前一样经过规范和完成，并且也成为Platform JSR的一部分，但是我们看到了更多的开放开发，以及更多的试验（不一定要成为JSR）。”

Keil： “ 3个竞争的JSON库，一个用于Java EE，另一个Oracle专有与Java ME 8捆绑在一起，而另一个针对Java SE 9的基于JEP的独立方法可能是最好的例子之一，这可能会出错并且与用户的使用相反。开发人员的需求或为Java设置一个标准的目标。另一个可能是Java SE 8（JavaFX + JSR 310）引入的重叠和很大程度上不兼容的日期/时间API，而“ java.util”下以前存在另外两个库。 Java架构师提供了输入和建议，但是从日期/时间API的角度来看，只有他们或其他人（包括一些执行委员会成员）指出的最糟糕的问题得以解决，而其他问题则被消除了。”

您能否分享您在Java社区流程中的个人经历？

Keil： “前一段时间，我本人和共同规范负责人Antoine Sabot-Durand提出了一种JSR，用于基于标准化CDI的社交媒体连接器，以及类似的基于JSON，REST或OAuth等安全标准的类似API。 JSR被8：5的绝大多数拒绝。鉴于Seam Social和Red Hat的整个Seam生态系统都被新项目取代，就像整个JBoss服务器在那个时候获得了一个新的名称和品牌（WildFly）一样，由此产生的开源项目Agorava很自然地替代了Seam我们为JSR 357提出的社交和许多想法。”