<div dir="ltr"><div dir="ltr"><div>Hi Alex,</div><div><br></div></div>On Mon, May 15, 2023 at 1:47 PM Alex Buckley <<a href="mailto:alex.buckley@oracle.com">alex.buckley@oracle.com</a>> wrote:<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">In fact, I would like to see the JEP spend less time rehearsing JLS <br>
modifications </blockquote><div><br></div><div>We are planning to remove all the JLS specification changes - they belong in the CSR instead (this distinction was not clear to me at first).</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">more time exploring how tools, analyzers, linters, etc <br>
will be impacted by ctor bodies that have a prologue. The Risks & <br>
Assumptions section should be pages long.<br></blockquote><div><br></div><div>Can you elaborate on why you think this is needed?</div><div><br></div><div>Of course, it's obviously true that any change to the language is going to affect analyzers, linters, and other such tools. So the question is whether this needs to be explicitly noted.</div><div><br></div><div>I was gauging this based on what I've seen in other JEP's. For example, <a href="https://openjdk.org/jeps/378">JEP 378 Text Blocks</a> includes no such discussion, yet that change has a clear impact on such tools.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
And I will pose another question: are there any tricks, idioms, or <br>
'patterns' that have been necessary in Java code to workaround the <br>
super()-comes-first rule? I would like the Motivation or Description (or <br>
both) to complement the currently rather abstract story (about <br>
superclasses, guarantees, and top-down initialization) with some <br>
straightforward code samples of what developers had to write before and <br>
why it was error-prone and why it hurt maintainability.<br></blockquote><div><br></div><div>This was the goal of the section starting with "the
 current rule causes idioms commonly used within normal methods to be 
either difficult or impossible to use within constructors. Below are a 
few examples." Let me know if you think these examples are unclear.<br></div><div><br></div><div>Thanks,<br></div><div>-Archie</div><div><br></div></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature">Archie L. Cobbs<br></div></div>