<div dir="ltr"><div dir="ltr">On Fri, Jan 27, 2023 at 2:52 PM Archie Cobbs <<a href="mailto:archie.cobbs@gmail.com">archie.cobbs@gmail.com</a>> wrote:</div><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"><div dir="ltr">JEP is <a href="https://bugs.openjdk.org/browse/JDK-8300786" target="_blank">updated</a>. Not surprisingly, it has gotten a good bit simpler.</div></blockquote><div><br></div><div>FYI, I've added this additional detail:</div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><p>(4) Replace the steps for constructor processing in §12.5 with the following:</p><ol><li>Assign the arguments for the constructor to newly created parameter variables for this constructor invocation.</li><li>If this constructor contains an explicit constructor invocation (§8.8.7.1), then execute the preceding <code class="gmail-prettyprint">BlockStatements</code>, if any.</li><li>If this constructor contains an explicit constructor invocation (§8.8.7.1) of another constructor in the same class (using <code class="gmail-prettyprint">this</code>),
then evaluate the arguments and process that constructor invocation
recursively using these same six steps. If that constructor invocation
completes abruptly, then this procedure completes abruptly for the same
reason; otherwise, continue with step 6.</li><li>This constructor does not contain an explicit constructor invocation of another constructor in the same class (using <code class="gmail-prettyprint">this</code>). If this constructor is for a class other than <code class="gmail-prettyprint">Object</code>, then this constructor contains an explicit or implicit invocation of a superclass constructor (using <code class="gmail-prettyprint">super</code>).
Evaluate the arguments and process that superclass constructor
invocation recursively using these same six steps. If that constructor
invocation completes abruptly, then this procedure completes abruptly
for the same reason. Otherwise, continue with step 5.</li><li>Execute the instance initializers and instance variable initializers
for this class, assigning the values of instance variable initializers
to the corresponding instance variables, in the left-to-right order in
which they appear textually in the source code for the class. If
execution of any of these initializers results in an exception, then no
further initializers are processed and this procedure completes abruptly
with that same exception. Otherwise, continue with step 6.</li><li>Execute the rest of the body of this constructor. If that execution
completes abruptly, then this procedure completes abruptly for the same
reason. Otherwise, this procedure completes normally.</li></ol></blockquote>
</div><div> The new step added is Step #2. Note that this means field initializers (and initialization blocks) execute after <span style="font-family:monospace">super()</span> returns, which is the same as before but more interesting now that <span style="font-family:monospace">super()</span> is no longer required to be first.<br></div><div><div><br></div><div>Currently, there is an illusion of initializers executing at the "beginning" of
the constructor. But in actuality, they have always actually executed after <span style="font-family:monospace">super()</span> returns. Changing this wouldn't be backward compatible, and really there's no other option - they couldn't (for example) execute at the start of the constructor, because initializers are allowed to reference 'this' and assume the superclass is initialized.</div><br></div><div>You can observe the current behavioral nuance if you're willing to e.g. (ab)use static fields:</div><div><br></div><div style="margin-left:40px"><span style="font-family:monospace">$ cat InitOrder1.java<br></span></div><div style="margin-left:40px"><span style="font-family:monospace">public class InitOrder1 {<br><br> public static class Class1 {<br> public Class1() {<br> Class2.nextIndex++; // bad form here!<br> }<br> }<br><br> public static class Class2 extends Class1 {<br> static int nextIndex = 1;<br> final int index = nextIndex;<br> }<br><br> public static void main(String[] args) {<br> System.out.println(new Class2().index);<br> }<br>}</span></div><div style="margin-left:40px"><span style="font-family:monospace">$ javac InitOrder1.java && java InitOrder1<br>2</span><br></div><div><br></div><div>The changed JLS would open the window a little wider for oddities like this, to include the "static context" statements in a constructor prior to invoking <span style="font-family:monospace">super()</span>. You still would have to jump through a static field or other tricks to observe the nuance though.<br></div><div><br></div><div>Here's such an example:</div><div style="margin-left:40px"><span style="font-family:monospace"><br></span></div><div style="margin-left:40px"><span style="font-family:monospace">$ cat InitOrder2.java public class InitOrder2 {<br><br> public static class Class1 {<br> static int nextIndex = 1;<br> final int index = nextIndex;<br> public Class1() {<br> nextIndex++;<br> super();<br> }<br> }<br><br> public static void main(String[] args) {<br> System.out.println(new Class1().index);<br> }<br>}<br>$ javac InitOrder2.java && java InitOrder2</span></div><div style="margin-left:40px"><span style="font-family:monospace">2</span></div></div><div><div><br></div><div>I think this falls into that category of things where the JLS has more
detail in it than the corresponding programmer's mental model - and
that's OK (see other discussion around switch patterns, instanceof, and
primitive types). I don't think it's likely for a developer to be doing anything that would allow their mental model to be violated in this way, but of course it is possible if they try hard enough.</div><div><br></div><div>-Archie<br></div><div><br></div></div>-- <br><div dir="ltr" class="gmail_signature">Archie L. Cobbs<br></div></div>