• Home
    • View
    • Login
    This page
    • Normal
    • Export PDF
    • Export Word
    • Attachments
    • Page Information

    Loading...
  1. Dashboard
  2. Compatibility & Specification Review
  3. Main

Page History

Versions Compared

Old Version 15

changes.mady.by.user Joe Darcy

Saved on Jun 16, 2020

compared with

New Version Current

changes.mady.by.user Joe Darcy

Saved on Jun 01, 2022

  • Previous Change: Difference between versions 14 and 15
  • View Page History

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Make assignee/reviewer state changes more explicit

Welcome to the Compatibility & Specification Review (CSR) Group!

The Compatibility & Specification Review (CSR) Group is empowered to review interface changes proposed within active JDK Release Projects. CSR group discussions are conducted on its mailing list.

A dashboard of active CSR requests is maintained in JBS, the JDK bug system.

Anchor
CSR Background
CSR Background
CSR Background and Overview

The Java platform enjoys both breadth of use and longevity; over two and a half 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 broad behavioral compatibility impact. 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.

CSR Workflows

In the simplest one-phase workflow, a CSR request is first drafted by the assignee (and other engineers working on the request). After being reviewed by at least one engineer familiar with that technology area, the request is Finalized by the assignee. After being Finalized, the CSR reviews the request and if there are no problems or shortcomings with the request it will be Approved by the CSR lead.

In the two-phase workflow, after the initial CSR proposal is drafted, it is moved by the assignee to the Proposed state to gather an initial round of feedback. Once the proposal is mature enough to advance, the CSR lead moves it to the intermediate Provisional state. Possibly after additional refinement and additional reviewers, the proposal is Finalized by the assignee to request the second phase of CSR review.

If problems are identified during CSR review that are serious enough to prevent the request from advancing toward approval, the CSR request can be moved to the Pended state by CSR reviewers. After the concerns are addressed by the assignee, the request can then resume either the two-phase or one-phase process.

Anchor
JDK Compatibility Policy
JDK Compatibility Policy
General JDK Compatibility Policy

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.

Kinds of Compatibility

FAQs

Resources

  • Members
  • Mailing list
    • csr-discuss
    • csr-discuss Archives

Recent space activity

Recently Updated
typespage, comment, blogpost
max5
hideHeadingtrue
themesocial

Space contributors

Contributors
modelist
scopedescendants
limit5
showLastTimetrue
orderupdate


Overview
Content Tools
ThemeBuilder

Terms of Use • License: GPLv2 • Privacy • Trademarks • Contact Us

Powered by a free Atlassian Confluence Open Source Project License granted to https://www.atlassian.com/software/views/opensource-community-additional-license-offer. Evaluate Confluence today.

  • Adaptavist ThemeBuilder Powered by Atlassian Confluence 7.13.8
  • Adaptavist ThemeBuilder printed.by.atlassian.confluence
  • Report a bug
  • Atlassian News
Atlassian
Adaptavist ThemeBuilder EngineAtlassian Confluence
{"serverDuration": 177, "requestCorrelationId": "a94ca4122848d803"}