<div dir="ltr"><div dir="ltr"><div>Hi Maurizio,</div><div><br></div><div>Thanks very much for taking time to review.<br></div><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jan 26, 2023 at 8:55 AM Maurizio Cimadamore <<a href="mailto:maurizio.cimadamore@oracle.com">maurizio.cimadamore@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">
<div>One example that I didn't get was the NullPointer vs. IAE - to me
this seems another case where you want to validate the parameter
before passing it to the superclass constructor - e.g. the same as
the very first example. For this reason, this example seems weak
to me - and the JEP would probably be better off with it omitted
(unless I missed some more subtle point, which is possible).
</div></blockquote><div><br></div><div>Yes... I also thought maybe we should combine those two examples into one. You've confirmed the hunch so I'll make that change.<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"><div> what if the class
initialized a protected field in the superclass before the
superclass constructor is called?</div></blockquote><div><br></div><div>That possibility may seem "weird" because it's a new possibility for the first time in 25+ years, but I'd argue that with a little analysis it turns out it doesn't actually lead to any problematic or surprising outcome.<br></div><div><div><br></div><div>One could also argue that the language already allows much
weirder things, like 'this' escapes where a subclass can observe a
supposedly final field with the wrong value...<br></div><div><br></div></div><div>Anyway, here's a breakdown of what happens if a subclass writes to a superclass field prior to super():<br></div><div><br></div><div>If the superclass field is final, assignment is not allowed - you get the usual "cannot assign a value to final variable x" (no change here).</div><div><br></div><div><div>Otherwise, before super() is invoked, the field may not be
read, and invocation of
superclass methods are disallowed, so the field's value can have no
effect on anything.</div><div><br></div><div>When super() is invoked, either the superclass constructor overwrites the value or it doesn't (if it reads the value, then presumably that's intentional).<br></div><div><br></div><div>If the superclass constructor overwrites the value, the field gets its new value, as expected.<br></div><div><br></div><div>If the superclass constructor doesn't overwrite the value, the field retains the value written by the subclass, as expected.</div></div><div><br></div><div>So in a nutshell, it behaves as one would expect: either the superclass constructor overwrites the value, or it doesn't. Life goes on.</div><div><br></div><div>(And if you don't like subclass constructors writing to your fields prior to super(), you can make them private or final, or just overwrite them in your constructor.)</div><div><br></div><div>So yes this scenario is new and different, but I don't think it's fair to say it's problematic. It's just new.<br></div><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>My feeling is that it would be better to start simple(r), and, at
least for the time being, not to give instance field initializers
any special treatment.</div></blockquote><div><br></div><div>Certainly agree it would be simpler... but it would be at the cost of eliminating the only tool we'll likely ever have for dealing with a superclass 'this' escape, which is one of the primary motivations behind this change.</div><div><br></div><div>But back to the crux... if what you're saying is that you're worried about the uncertainty around initializing fields prior to super(), does the earlier breakdown showing that it's harmless (so to speak) help any?</div><div><br></div><div>Thanks,<br></div><div>-Archie<br></div><div> </div></div>-- <br><div dir="ltr" class="gmail_signature">Archie L. Cobbs<br></div></div>