Thanks guys for the feedback. > BTW, P4 is a better priority for this useful addition, P5 is pretty much ignored or trivial and not worth it.
I've updated to P4. I've been erring on the side of caution when assigning priority to nice-to-have JBS issues which I create :-) I'll go ahead and create the PR in the next day or two, as well. Take care, Daniel On Thu, Jan 8, 2026 at 11:33 PM Joseph D. Darcy <[email protected]> wrote: > From the CSR FAQ > (https://wiki.openjdk.org/spaces/csr/pages/32342047/CSR+FAQs): > > > Q: If my change needs a CSR review and a code review, which should I > > do first? > > A: To take a common case of a Java API change, there is some overlap > > between the factors considered in a general code review and the > > factors considered by the CSR when reviewing the specification and > > compatibility impact. (CSR members often participate in code reviews > > in addition to their reviews in CSR roles.) An engineer may choose to > > run the CSR process and code review in parallel, but feedback from > > either channel may be received which requires updates to the proposal > > in the other channel. If an engineer chooses to sequence code review > > and CSR review, to minimize latency the process expected to provide > > more feedback should be run first. > > > HTH, > > -Joe > > On 1/8/2026 1:19 PM, Roger Riggs wrote: > > Hi Daniel, > > > > CSR's get few reviewers than PR's. > > > > A broader review in the PR can improve the prose and get comments on > > additional use cases. > > For myself, I do them in parallel, putting the initial CSR in proposed > > state to get early feedback from the CSR review. > > Comments on the PR accumulate and are addressed in the PR and when > > that settles down, update the PR and finalize. > > > > In the CSR, the Compatibility Risk description highlights a typical > > more serious risk, that of superseding an existing method in an > > implementation and possibly changing or being in conflict with its > > semantics. As a protected method, its potential to be in conflict with > > existing implementations is reduced somewhat. > > > > The diff in the CSR should focus on the specification change, not the > > implementation changes unless they affect visible behavior. > > (Generally, avoid irrelevant information in the CSR). > > > > BTW, P4 is a better priority for this useful addition, P5 is pretty > > much ignored or trivial and not worth it. > > > > Thanks for the followup, Roger > > > > > > On 1/7/26 4:07 PM, Daniel Gredler wrote: > >> Hi Roger, > >> > >> I've created the CSR here: https://bugs.openjdk.org/browse/JDK-8374739 > >> > >> Alan also provided some feedback on the original issue here: > >> https://bugs.openjdk.org/browse/JDK-8374610 > >> > >> I was going to wait to create the PR until the CSR has been approved, > >> if that's OK? > >> > >> Take care, > >> > >> Daniel > >> > >> > >
