Loosening requirements for super() invocation

[Archie Cobbs]

On Wed, Jan 25, 2023 at 8:05 PM John Rose <john.r.rose at oracle.com> wrote:

> I’m pretty sure either tactic could be made to work in the JLS. I’m a
> little more hopeful than Brian that DA/DU bits would do the job well, but
> sometimes a sledgehammer is better than a samurai sword. What I’m wondering
> now is, if we use the sledgehammer technique, what is the total “diff
> weight” of the spec.?
>

That's a question I'd like to better understand as well.

Brian pointed out the commonality between code and spec - both are going to
require some refactoring when a change is made... i.e., we can't just add a
footnote that says, "Oh and one more thing: everything we just said is true
except that code prior to super() ..."

So the question is mostly about how much refactoring will be required, as
the refactoring is likely to be most of the "diff weight".

It's still an open question in my mind but also I need to do more study.
Brian has a definite opinion here and he's probably right but I want to
confirm that for myself...


> I have an unrelated suggestion (which makes sense with either tactic). The
> existing DA/DU rules for blank finals are (I think) easy to adapt to allow
> blank finals initializations to be hoisted above super-init. So far so
> good. For non-finals (*mutable* non-static fields), may I suggest that,
> if you were to allow initializations to them above super-init, that you
> formulate the restrictions on their treatment to align them with blank
> finals. Something like this:
>
>    -
>
>    Before super-init, any *local* field, *without an initializer*
>    (whether final or not) is put into the DU state. (Today it is blank finals
>    only.)
>    -
>
>    Before super-init, no local fields may be read, and only DU fields may
>    be written. (The JVM is slightly more lenient; we don’t care.)
>    -
>
>    Assignments to any field in a DU state put it into the DA state.
>    (After that any further access must occur after super-init.)
>
> So if I understand what you're getting at, you're saying "Prior to
super(), if you assign a value to a non-final field, we're going to treat
it as if the field were actually final".

But I don't understand what that buys us compared to just leaving the rules
for non-final fields alone (I'm sure I'm missing something).

So what if you can assign them more than once? No harm there. And
developers may scratch their heads if this code:

public class Foo {

    private int ival;

    public Foo(float fval) {
        this.ival = (int)fval;
        if (!Float.isFinite(fval))
            this.ival = -1;
        super();
    }
}

generates an error like this:

Foo.java:8 error: variable ival may have already been assigned
            this.ival = -1;
                ^

>
>    - Before super-init, the names this.f and f, where f means this.f, are
>    treated identically, and there is no other expression which can be used to
>    assign to f. (This is true for finals after super-init as well.)
>
> Yes, something limited like this would be needed. We already have the same
limitation when assigning final fields - as you describe in JDK-8193904
<https://bugs.openjdk.org/browse/JDK-8193904>.


> This leads me to one more observation: Blank finals can be observed in
> their uninitialized state during a super-init call. This is a hole in the
> otherwise strong fence around final variables, and it sometimes causes bad
> bugs. It will make the fence around finals stronger if we allow them to be
> initialized before the super-init call. That is, if users take the chance
> of initializing their blank finals before the super-init call, then there
> is a very strong proof that no such blank final will ever be observed in
> its uninitialized state. To me that’s an indication that we should put this
> feature in the 80% rather than the 20%.
>

I totally agree... you said it much better than me.

-Archie

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