The JDK Enhancement-Proposal (JEP) process is “for collecting, reviewing, sorting, and recording the results of proposals for enhancements to the JDK and for related efforts, such as process and infrastructure improvements.” JEP 0 is the “JEP Index” of “all JDK Enhancement Proposals, known as JEPs.” This post provides a brief overview of current JDK Enhancement Proposals and discusses the surprisingly mysterious disappearance of two JEPs (JEP 187 and JEP 145).
JDK Enhancement Proposal Overview
The JEPs in the JEP Index with single-digit numbers are “Process” type JEPs and are currently:
The JEPs in the JEP Index with two-digit numbers are “Informational” type JEPs are are currently:
The remainder of the listed JEPs (with three-digit numbers) in the JEP Index are “Feature” type JEPs and currently range in number from JEP-101 (“Generalized Target-Type Inference”) through JEP 418 (“Internet-Address Resolution SPI”) (new candidate JEP as of this month [September 2021]).
Finally, there are some JEPs that do not yet have JEP numbers and which are shown in the under the heading “Draft and submitted JEPs” The JEPs in this state do not yet have their own JEP numbers, but instead are listed with a number in the JDK Bug System (JBS).
Originally, a JEP could exist in one of several different “JEP 1 Process States“:
The explanation of evolved potential JEP states is described in “JEP draft: JEP 2.0, draft 2.” This document has a “Workflow” section that states that the “revised JEP Process has the following states and transitions for Feature and Infrastructure JEPs” and shows a useful graphic of these workflows. This document also describes the states of a Feature JEP:
- Proposed to Target
- Proposed to Drop
Neither these documented states for Feature JEPs nor the additional text that describes these state transitions describes a JEP with a JEP number (rather than a JBS number) being completely removed and this is what makes the disappearance of JEP 187 (“Serialization 2.0”) and JEP 145 (“Cache Compiled Code”) unexpected.
The Disappearance of JEP 187 (“Serialization 2.0”)
JEP 187 is not listed in the JEP Index, but we have the following evidence that it did exist at one time:
- Original message on OpenJDK core-libs-dev mailing list (14 January 2014)
- Internet Archive Wayback Machine
- Mercurial Changesets
It’s surprisingly difficult to find any explanation for what happened to JEP 187. Unlike fellow serialization-related JEP 154 (“Remove Serialization”) which has been moved to status “Closed / Withdrawn”, JEP 187 appears to have been removed completely rather than being present with a “Closed / Withdrawn” status or “Closed / Rejected” status. Adding to the suspicious circumstances surrounding JEP 187, two requests on OpenJDK mailing lists regarding the state of this JEP (14 December 2014 on core-libs-dev and 6 September 2021 on jdk-dev) have so far gone unanswered.
The reasons for the complete disappearance of JEP 187 can be insuated from reading the “exploratory document” titled “Towards Better Serialization” (June 2019). I also previously touched on this in my post “JDK 11: Beginning of the End for Java Serialization?“
The Disapperance of JEP 145 (“Cache Compiled Code”)
Like JEP 187, JEP-145 is not listed in the JEP Index, but there is evidence that it did exist at one time:
- Original message on OpenJDK hotspot-dev mailing list (28 February 2012)
- 28 February 2012 Tweet
- Internet Archive Wayback Machine
- Mercurial Source
- OpenJDK / jep / jeps changeset 54:a16daa94ba0f (28 February 2012)
Also similarly to JEP 187, it is surprisingly difficult to find explanations for the removal of JEP 145. There is a StackOverflow question about its fate, but the responses are mostly speculative (but possible).
It seems that both JEP 187 (“Serialization 2.0”) and JEP 145 (“Cache Compiled Code”) have both been rendered obsolete by changing developments, but it is surprising that they’ve vanished completely from the JEP Index rather than being left intact with a closed or withdrawn state.