JAVA 学习随笔 ： JDK Enhancement Process JEP process

Earlier this year, Oracle published the JDK Enhancement Proposal and roadmap process. The purpose of this is to allow OpenJDK committers to submit ideas and extensions to improve the OpenJDK ecosystem.

The purposes of the JEPs is described in JEP 1: JDK Enhancement Proposal and Roadmap Process. They define an enhancement to be something with a non-trivial change (i.e. more than two weeks worth of effort, a significant change to the JDK, or in high demand by developers and/or customers). As with the Python Enhancement Proposals and the Scala Improvement Process lists, the purpose is to define on a feature basis what enhancements or changes are needed. As with Python, the JEP 0 is a meta index of the enhancement proposals posted, and at the time of writing lists 127 JEPs (as well as two meta-JEPs, the JEP 1: Enhancement Proposal and Roadmap Process and JEP 2: JEP Template.

The process document explicitly notes that JEPS do not supplant the Java Community Process; since the JCP is the governing body for the standard Java SE APIs and related interfaces. Whilst many of the currently posted JEPs do align with the Java SE APIs, some are VM specific, such as the highly anticipated JEP 122: Remove the Permanent Generation.

JEPs transition through various states:

Draft: Work in progress with open discussions
Posted: Entered into the JEP archive
Submitted: Declared to be ready for evaluation
Active: Approved for publication
Candidate: Accepted for inclusion in the OpenJDK roadmap
Funded: Judged by a group/area lead to be fully funded
Completed: Finished and delivered
Withdrawn: Taken out of circulation (perhaps for future re-inclusion)
Rejected: Not worth pursuing now or in the future
Terminal states above are shown with underlines; this includes the completed and rejected states. Whilst withdrawn may be considered a terminal state, there is the possibility that it will be resurrected in the future. Some JEPs, like JEP0 and JEP1, are intended to be permanently in the active state rather than transitioning to a terminal one.

One of the key differences between the JEPs and the JSRs is the level of formality involved in contributing to, or viewing, the states. The JCP has a quite rigid process model that must be followed; but the JEP is a lighter-weight way of throwing ideas and having an identifier which can be used to synchronise ideas, comments, and other processes. On the other hand, JEPs also talk about funding; whether there has been resources committed to the project or not, and which organisation is on the hook for delivery. All of the JEPs to date (101-126) are sponsored by Oracle, although JEP 104: Annotations on Java Types is co-sponsored with the University of Washington, where co-author Michael Ernst is a professor of computer science. Type checkers are one of Michael Ernst‘s research fields, and the proposed JEP 104 is the result of experiments in type checkers as published in ICSE‘11.

Whilst the majority of the JEPs are in the posted state, three are in the submitted state at the time of writing. This includes JEP 104 as well as JEP 118: Access to Parameter Names at Runtime and JEP 119: javax.lang.model implementation backed by core reflection. These are proposals that are in the “Ready for evaluation” phase, rather than just being in a work in progress state. (They still have to go through the candidate and funded status before they will be developed for real, however.)

Whilst the JEP view shows what might be happening, the view of the list doesn‘t show a summary view of the states of the process. Also, whether a JEP is funded or not seems like an internal implementation decision rather than any standards process; but as Oracle is trying to gain more commercial partners with OpenJDK (such as IBM) it may have been something which they felt was necessary.

去年年初，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认为这是必须的。