Loosening requirements for super() invocation

John Rose john.r.rose at oracle.com
Sat Jan 28 02:19:45 UTC 2023


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,
nor is any access other than *writing* a *local* field.
No instance method calls to the uninitialized “this”,
and no instance field reads of any kind from it, and
no instance field writes to fields defined non-locally.

Before the super-constructor call, the object cannot
assume that super-class invariants have been set up,
so no API point of the super-class can be touched,
except to call a constructor.

So the JVM doesn’t permit non-local early accesses (early
meaning “before super constructor call”) because that
would allow subclasses to inject actions into superclass
state before the superclass initialization sequence.
And that could, indeed, subvert invariants intended by
the superclass author.

But if a superclass sticks its nose into the business of
a subclass, by down-casting, or by calling an overridden
virtual from its constructor, then we must hope that the
subclass has set things up so that the superclass sees
something consistent.  Archie’s proposals generally
give subclass authors more freedom to set things up
nicely before the super-constructor is called.

That doesn’t lead to any increased subversion, only
better control by the subclass of its proper concerns,
by which I mean local concerns, in the same source file.

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.

— John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20230127/04694fd5/attachment-0001.htm>


More information about the amber-dev mailing list