Page History

...

Q: What is the CSR?
A: The CSR is a review body for changes being made in JDK releases. The letters "CSR" stand for "compatibility and specification review"; therefore the CSR focuses on reviewing specifications (as opposed to implementations) with an emphasis on long-term compatibility impact. Besides compatibly review, review of a specification includes but is not limited to abiding by naming conventions, clear description of semantics, appropriate use of language features, and so on. The compatibility review is not strictly limited to specifications; some implementation-only changes with compatibility impact merit CSR review as well.

Q: How do I create a CSR ?
A: Do not directly create a CSR from the Create Menu. JIRA will let you do this right up until the moment you try to save it and find your typing was in vain.

Instead you should go to the target bug, select "More", and from the drop down menu select "Create CSR". This is required to properly associate the CSR with the main bug, just as is done for backports.

Q: Who are the CSR group members?
A: The current membership of the CSR group is listed in the OpenJDK census. The members of the CSR are experienced in JDK development and have deep knowledge of one or more areas of the platform. Multiple members of the initial CSR group have more than one release of "double triple" bug fixing activity, authoring more than 100 changes and reviewing more than 100 changes by others during a pre-rapid cadence feature release. Updating the membership of the CSR group will follow the OpenJDK group procedures.

Q: What kinds of compatibly does the CSR look after?
A: The CSR looks after source, binary, and behavioral compatibility. Binary compatibility is the ability of existing binaries to link. Source compatibility concerns whether or not existing code still compiles and if it still compiles, if it compiles into an equivalent binary. Behavioral compatibility involves operational equivalence; with "the same" inputs, does a program behave "the same way" before and after a change. More detailed and nuanced discussion of these compatibility concerns can be found in the Kinds of Compatibility page.

Q: What sort of changes require CSR review?
A: Any change to a JDK interface meant to be used outside of the JDK itself requires CSR review. In this context "interface" isn't limited to the Java programing language definition of an interface, but encompasses the broader concept of a protocol between the JDK and users of the JDK. Examples of interfaces by this definition include:

...

Q: I found a case where the specification and implementation disagree; how is this resolved?
A: The proper resolution depends on the nature of the discrepancy. However, if it is technically reasonable for either the specification to be changed to match the implementation or for the implementation to be changed to match the specification, the preference is to change the specification to match the implementation. This preference better preserves behavioral compatibility for users of the API in question. Note this is only a preference and at times it is unreasonable to allow erroneous behavior of the implementation, once recognized, to persist.Q: How do I create a CSR ?
A: Do not directly create a CSR from the Create Menu. JIRA will let you do this right up until the moment you try to save it and find your typing was in vain.
Instead you should go to the target bug, select "More", and from the drop down menu select "Create CSR". This is required to properly associate the CSR with the main bug, just as is done for backports.

Q: How should I get CSR review for multiple release trains?
A: Say you want to get an interface change into JDK N and later decide the change is also desirable and appropriate for the JDK (N-1) update release and that update release is using the CSR process. First a CSR should be created from the main bug targeted at JDK N. Afterward, if a backport of the main bug covering JDK (N-1) does not already exist, a backport of the main bug covering JDK (N-1) should be created. Then, a CSR can be created from that backport. The CSR for the backport should explicitly state how the interface change for the backport relates to the interface change for the main release: either the interface change is the same or, if it differs, what the difference is.

...