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