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: 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 CSR group have more than one releases of "double triple" bug fixing activity, authoring more than 100 changes and reviewing more than 100 changes by others. 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 "OpenJDK Developers' Guide, Version 0.777".
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:
- Changes to public and exported APIs in java.* and javax.* packages.
- Changes to public and exported APIs in jdk.*packages.
- New language updates to the Java Programming Language
- New structures in the Java Virtual Machine Specification
- Adding or removing a command in $JDK/bin
- Adding, removing, or changing a command line option; for details about evolving HotSpot command line options see Hotspot Command-line Flags: Kinds, Lifecycle and the CSR Process
- Using or defining an environment variable
- Using or defining a new file format or wire format
Changing or defining a new system or security property; be default, as of JDK 12 system properties should be documented using the @systemProperty javadoc tag.
Interfaces that are experimental or for diagnostic purposes do not need to go through CSR process, but the CSR process may be employed if feedback from the CSR reviewers is desired.