找出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提出的社交和许多想法。”

社交媒体API执行委员会投票结果

Tene： “作为JCP执行委员会的一部分，我不得不考虑批准新的JSR。 在不止一个案例中，我投票拒绝了我认为不属于平台的JSR（并主张其他人也这样做），但是大多数自然适合Java生态系统的JSR的门槛并不高。只要JSR负责人签署就可以完成所涉及的详细工作和流程。

Warburton： “我对日期和时间库有所帮助。 我认为这使我对需要完善功能或方法签名的每个单元的详细程度有了更多的了解。 人们花费大量时间尽最大努力使这些API正确无误。”

翻译自: https://www.javacodegeeks.com/2014/10/java-9-behind-the-scenes-where-do-new-features-come-from.html