Loosening requirements for super() invocation

[Archie Cobbs]

Hi Maurizio,

Thanks very much for taking time to review.

On Thu, Jan 26, 2023 at 8:55 AM Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> 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).
>

Yes... I also thought maybe we should combine those two examples into one.
You've confirmed the hunch so I'll make that change.

what if the class initialized a protected field in the superclass before
> the superclass constructor is called?
>

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.

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...

Anyway, here's a breakdown of what happens if a subclass writes to a
superclass field prior to super():

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).

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.

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).

If the superclass constructor overwrites the value, the field gets its new
value, as expected.

If the superclass constructor doesn't overwrite the value, the field
retains the value written by the subclass, as expected.

So in a nutshell, it behaves as one would expect: either the superclass
constructor overwrites the value, or it doesn't. Life goes on.

(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.)

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.

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.
>

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.

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?

Thanks,
-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20230126/91b69641/attachment.htm>