Loosening requirements for super() invocation

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Sat Jan 28 21:49:01 UTC 2023


On 28/01/2023 02:19, John Rose wrote:
> 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.

My point was not about "danger" but about "complex programming model", 
and "return on complexity". Allowing initialization of local fields 
before super() call would at the very least cause observable behavior 
changes in all the instance initializers of the class (there was such an 
example in the previous version of the JEP I believe).

So my point was: why do we need to go there? That is not (anymore) about 
allowing programs which were rejected for obtuse reasons. This starts 
going down a path of messing with initialization order (e.g. moving a 
field initializer, even if local, across the "super" call is _not_ a 
compatible change).

It maybe failure of imagination - but aside from pathological cases 
(like classes whose initialization lets `this` escape - which I think we 
all agree are on the bad side of the spectrum) I can't think of why you 
would want to do that. The fact that the JVM allows it, and that it does 
so in a sound fashion (which is what I'd expect the JVM to do) is 
irrelevant in my consideration.

To put it more clearly - it is quite clear as to why one might want to:

* do validation on constructor parameter before a super call
* pass constructor parameter twice
* do some complex initialization which requires control flow

These are things that add a net improvement on language expressiveness, 
and do that with a very simple rule: you cannot spell `this` before the 
super() call, which is easy to remember, and close to what users would 
expect.

To add the next bit, the model is: you cannot spell `this` except if 
it's an initializer of a field. But wait, not any field, it has to be a 
"local" field (this names is, btw, not great, as in Java I only know 
about "local variables") - so that concept also comes with the ride. Of 
course these concepts aren't hard to teach, but I think before we go 
there we should have better arguments of _why_ we need to, as the 
examples I've seen so far seem a bit on the thin side. And, doing the 
points above doesn't prevent us from doing more later, if needed.

Cheers
Maurizio



More information about the amber-dev mailing list