Loosening requirements for super() invocation

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Thu Jan 26 17:00:15 UTC 2023


On 26/01/2023 16:12, Archie Cobbs wrote:
> 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.
Thanks
>
>     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.
>
I agree that the behavior you propose is not problematic per se.

But, as I mentioned, it brings up can of worms. For instance, now a 
superclass constructor could see its field with a non-zero value. Which 
could definitively be surprising. After all, there might be code in the 
wild assuming that an int field that has not been assigned yet has value 
zero - whether writing code like that is good or bad, it's a separate 
question. My point here is that here you cross a fine line between  
"let's make the language more expressive" and "this change might have 
some compatibility impact".

As I said, my general feeling is that it's not worth going there to "fix 
escaping this" - because... developers should strive to write code where 
this doesn't escape in the first place (and hopefully the Lint warning 
you recently added will help with that).

Maurizio

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


More information about the amber-dev mailing list