Welcome to the Compatibility & Specification Review (CSR) Group!
The Java platform enjoys both breadth of use and longevity; over two decades after its introduction, it remains one of the most popular programming platforms. A core tenet of the Java platform has been the importance of high-quality specifications, specifications favoring precision, explicitness, and completeness. The Java language, virtual machine, and API specifications are foundational documents for the Java ecosystem. The precision of these specifications, combined with a strong commitment to cross-release compatibility, allows applications and libraries to generally "just work" across releases.
A key component to ensuring and maintaining the quality of the specifications was the "CCC" process, originated at Sun Microsystems, which was dedicated to looking after compatibility and specification concerns, aiming to balance stability with progress to help keep Java vibrant. The role played by the CCC process has now been transferred to the Compatibility & Specification Review (CSR) OpenJDK Group, providing transparency and ensuring wider community input.
The primary role of the CSR Group is to review all changes to the JDK's exported interfaces. The term "interfaces" in this case meaning not only Java programming language interface types, but more generally the protocols between the JDK and users of the JDK. This review typically focuses on specification changes. However, implementation-only changes may also merit review if they have sufficiently large or broadimpact. Secondarily, the CSR is also a resource to provide feedback to engineers working on Java platform APIs. The CSR process fulfills an archival function as well, keeping stand-alone records of API and interface changes.
The general compatibility policy for exported APIs implemented in the JDK is:
- Don't break binary compatibility (as defined in the Java Language Specification) without sufficient cause.
- Avoid introducing source incompatibilities.
- Manage behavioral compatibility changes.
One sufficient cause for breaking binary compatibility is removing a an API deprecated for removal in an earlier release, as described in the enhanced deprecation policy. The different kinds of compatibility can be subtle and are discussed in detail elsewhere. Analogous versions of the policy apply to non-API parts of the platform.
Recent space activity