JDK Enhancement Process简介

去年年初，Oracle发布了JDK增强提案与路线图进程，目的在于鼓励OpenJDK提交者贡献点子和扩展以改进OpenJDK生态圈。

JEP的目的在JEP 1: JDK Enhancement Proposal and Roadmap Process中得到了说明。他们将增强定义为较重大的变化（比如说需要两周以上的工作量、JDK的重要变化或是为开发者/用户所强烈要求的）。类似于Python Enhancement Proposals与Scala Improvement Process，提案的目的在于根据某个特性来定义所需的增强或是修改。与Python一样，JEP 0是个增强提案的列表索引，在本文撰写之际，它里面一共列出了127个JEPs（还有两个元JEPs， 分别是JEP 1: Enhancement Proposal and Roadmap Process与JEP 2: JEP Template）。

进程文档明确指出JEPs并不会取代Java Community Process；因为JCP是标准Java SE APIs与相关接口的管理部门。虽然目前发布的很多JEPs都对应于Java SE APIs，但还有一些是特定于VM的，比如说万众期待的JEP 122: Remove the Permanent Generation。

JEPs会经历各种状态转换，如下所示：

• 草案：开放讨论
• 张贴：进入JEP归档
• 提交：开始评估
• 活动：批准公开发布
• 候选：获准进入OpenJDK路线图
• 资助：由小组/区域领导判断给予全力资助
• 完成：完成与交付
• 撤回：退出（或许未来还会重新加入进来）
• 拒绝：现在或将来不值得继续

上面带下划线的是最终状态，包括完成与拒绝状态。虽然撤销也可以看作是一种最终状态，但未来还有可能重新加入进来。某些JEPs，如JEP0与JEP1，会永远处于活动状态，并不会转换到最终状态。

JEPs与JSRs之间的一个主要差别在于对状态投入和检查的正式程度。JCP具有相当严格的进程模型，必须要严格遵守才行；但JEP则更加轻量级，可以抛出想法并为其设定一个标识符，标识符用于同步想法、评论和其他进程。另一方面，JEPs也会涉及到资助问题；是否有资源能够投入到项目中，哪个组织负责交付。到目前为止，所有JEPs（101——126）都由Oracle资助，但JEP 104: Annotations on Java Types是与华盛顿大学联合资助的，其合作者Michael Ernst是计算机科学教授。类型检查器是Michael Ernst研究的一个领域，他曾在ICSE'11上发表过一篇关于类型检查器的论文，JEP 104提案就来自于对该类型检查器的试验结果。

虽然大多数JEPs都处于张贴状态，但在本文撰写之际已经有3个处于提交状态了。这包括JEP 104、JEP 118: Access to Parameter Names at Runtime与JEP 119: javax.lang.model implementation backed by core reflection。这些提案已经处于“准备评估”阶段了（但在实际开发前，他们还需要经历候选与资助阶段）。

虽然JEP视图列出了各种提案，但列表视图却并没有概要显示出进程状态。此外，某个JEP是否会得到资助是个内部实现决策问题，并没有什么标准可言；但Oracle正在努力争取OpenJDK更多商业上的伙伴（比如IBM），Oracle认为这是必须的。

查看英文原文：JDK Enhancement Process