<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<font size="4"><font face="monospace">This is a first stab, but I
think this may be the extent of the spec changes for this JEP:<br>
<br>
<blockquote type="cite">8.8.7 Constructor Body<br>
The first statement of a constructor body may be an explicit
invocation of another<br>
constructor of the same class or of the direct superclass
(§8.8.7.1).<br>
</blockquote>
<br>
A constructor body _may contain_ an explicit invocation...<br>
<br>
<blockquote type="cite">ConstructorBody:<br>
{ [ExplicitConstructorInvocation] [BlockStatements] }<br>
</blockquote>
<br>
ConstructorBody:<br>
{ [BlockStatements] [ExplicitConstructorInvocation]
[BlockStatements] }<br>
<br>
<blockquote type="cite">It is a compile-time error for a
constructor to directly or indirectly invoke itself<br>
through a series of one or more explicit constructor
invocations involving this.<br>
If a constructor body does not begin with an explicit
constructor invocation and<br>
</blockquote>
<br>
does not contain an explicit constructor invocation<br>
<br>
<blockquote type="cite">the constructor being declared is not
part of the primordial class Object, then<br>
the constructor body implicitly begins with a superclass
constructor invocation<br>
"super();", an invocation of the constructor of its direct
superclass that takes no<br>
arguments.<br>
Except for the possibility of explicit constructor
invocations, and the prohibition<br>
on explicitly returning a value (§14.17), the body of a
constructor is like the body<br>
of a method (§8.4.7).<br>
A return statement (§14.17) may be used in the body of a
constructor if it does<br>
not include an expression.</blockquote>
<br>
If a constructor body contains an explicit constructor
invocation, the BlockStatements preceding the explicit
constructor invocation are called the _prologue_ of the
constructor body, and the BlockStatements following the explicit
constructor invocation are called the _main body_ of the
constructor. A return statement may be used in the main body of
a constructor if it does not include an expression. It is a
compile-time error if a return statement appears in the prologue
of the constructor body. <br>
<br>
<blockquote type="cite">8.8.7.1 Explicit Constructor Invocations</blockquote>
<blockquote type="cite">An explicit constructor invocation
statement introduces a static context (§8.1.3),<br>
</blockquote>
which includes the prologue of the constructor and the explicit
constructor invocation statement, <br>
<blockquote type="cite">which limits the use of constructs that
refer to the current object. Notably, the<br>
keywords this and super are prohibited in a static context
(§15.8.3, §15.11.2),<br>
as are unqualified references to instance variables, instance
methods, and type<br>
parameters of lexically enclosing declarations (§6.5.5.1,
§6.5.6.1, §15.12.3).</blockquote>
<br>
Additionally, as you point out, there are some corresponding
changes in 12.5. Your list is a good start, I'd amplify as: <br>
<br>
</font></font><font size="4"><font face="monospace">
<blockquote type="cite">
<ol>
<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>
</ol>
</blockquote>
</font></font><font size="4"><font face="monospace"><br>
If this constructor contains an explicit constructor invocation,
then execute the BlockStatements of the prologue of the
constructor body. If execution of any statement completes
abruptly, then execution of the constructor completes abruptly
for the same reason. <br>
<br>
<br>
<br>
</font></font>
<div class="moz-cite-prefix">On 1/28/2023 11:03 AM, Archie Cobbs
wrote:<br>
</div>
<blockquote type="cite" cite="mid:CANSoFxs-nzYGoM2XwXOjwMrLX=j23szSSC-7xJXcHSbbguFdTQ@mail.gmail.com">
<div dir="ltr">
<div dir="ltr">On Fri, Jan 27, 2023 at 8:19 PM John Rose <<a href="mailto:john.r.rose@oracle.com" moz-do-not-send="true" class="moz-txt-link-freetext">john.r.rose@oracle.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>
<div style="font-family:sans-serif">
<div style="white-space:normal">
<p dir="auto">On 26 Jan 2023, at 11:19, Maurizio
Cimadamore wrote:</p>
</div>
<div style="white-space:normal">
<blockquote style="margin:0px 0px
5px;padding-left:5px;border-left:2px solid
rgb(119,119,119);color:rgb(119,119,119)">
<p dir="auto">On 26/01/2023 18:16, Archie Cobbs
wrote:</p>
<blockquote style="margin:0px 0px
5px;padding-left:5px;border-left:2px solid
rgb(153,153,153);color:rgb(153,153,153)">
<p dir="auto">Yes, but for this to happen the
subclass would have to be in effect
intentionally subverting the superclass
constructor.</p>
<p dir="auto">In other words, a problem like you
describe can't suddenly just start happening "by
accident" just because this new feature
exists...</p>
</blockquote>
<p dir="auto">Well, you could have a subclass (in
some client jar) which "subverts" as you say, some
superclass in a library. Perhaps the library was
not prepared for that kind of behavior, and now
there's a new bug.</p>
<p dir="auto">IMHO, we should try to stay well clear
of that can of worms. It's not like we have to
open it now either - the other things you propose
are 100% non-controversial.</p>
</blockquote>
</div>
<div style="white-space:normal">
<p dir="auto">Just to be clear:</p>
<p dir="auto">Early assignment to a <i>super</i>
field is never possible</p>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
Ah, you are correct. I was missing this nuance and incorrectly
thinking it was allowed to write to *any* field in the object
prior to super().</div>
<div class="gmail_quote"><br>
</div>
<div class="gmail_quote">JVMS §<a href="https://urldefense.com/v3/__http://4.10.2.4__;!!ACWV5N9M2RV99hQ!PVfZ2aP1yhsmDre2rqLZwvzdU2KqHPHxwcf19bfGgyqPIZCOpSjLpImKZbP3917Y2zJtbWyCr5rKOTzGy6Ammew$" moz-do-not-send="true">4.10.2.4</a>:</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="gmail_quote">Before that method invokes another
instance initialization method of <code class="gmail-literal">myClass</code> or its direct
superclass on <code class="gmail-literal">this</code>, the
only operation the method can perform on <code class="gmail-literal">this</code> is assigning fields <b>declared
within <code class="gmail-literal">myClass</code></b>. </div>
</blockquote>
<div class="gmail_quote"><br>
</div>
<div class="gmail_quote">So that whole discussion about writing
to superclass fields prior to super() is moot.</div>
<div class="gmail_quote"><br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="gmail_quote">I must be missing your point here
Maurizio… There is<br>
some corner case you are concerned with but I can’t see<br>
where the danger is.</div>
</blockquote>
<div class="gmail_quote"><br>
</div>
<div class="gmail_quote">Yes... and now me too :)<br>
</div>
<div class="gmail_quote"><br>
</div>
<div class="gmail_quote">-Archie<br clear="all">
</div>
<br>
-- <br>
<div dir="ltr" class="gmail_signature">Archie L. Cobbs<br>
</div>
</div>
</blockquote>
<br>
</body>
</html>