Page History

...

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. A CSR can be created from a bug, enhancement or subtask. A CSR cannot  be created from a JEP issue. An implementation issue associated with a JEP should be used for create a CSR covering the technical changes of the JEP.

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:

...