Loosening requirements for super() invocation

Archie Cobbs archie.cobbs at gmail.com
Sat Jan 28 16:03:26 UTC 2023


On Fri, Jan 27, 2023 at 8:19 PM John Rose <john.r.rose at oracle.com> wrote:

> On 26 Jan 2023, at 11:19, Maurizio Cimadamore wrote:
>
> On 26/01/2023 18:16, Archie Cobbs wrote:
>
> Yes, but for this to happen the subclass would have to be in effect
> intentionally subverting the superclass constructor.
>
> In other words, a problem like you describe can't suddenly just start
> happening "by accident" just because this new feature exists...
>
> 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.
>
> 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.
>
> Just to be clear:
>
> Early assignment to a *super* field is never possible
>

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

JVMS §4.10.2.4:

> Before that method invokes another instance initialization method of
> myClass or its direct superclass on this, the only operation the method
> can perform on this is assigning fields *declared within myClass*.
>

So that whole discussion about writing to superclass fields prior to
super() is moot.

I must be missing your point here Maurizio… There is
> some corner case you are concerned with but I can’t see
> where the danger is.
>

Yes... and now me too :)

-Archie

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


More information about the amber-dev mailing list