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.