Draft Spec for Second Preview of Flexible Constructor Bodies (JEP 482)

[Archie Cobbs]

On Mon, Jun 10, 2024 at 12:10 PM Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> I’m saying that the model put forward by the spec is (a) not very
> intuitive (despite what you seem to claim) and (b) not a very useful
> generalization.
>

I agree with you that it's totally debatable what is most "intuitive" and
"useful" because those are opiniony words. So I don't have an ironclad
counter-argument.

I also agree that your complicated example is (a) unrealistic and (b)
demonstrates that the compiler still has bugs in this area.

The strongest argument I have for preserving the current behavior is that
the overall Java/JDK project has been traditionally very careful to
preserve backward compatibility. Changing the compiler so that code in the
world that has compiled successfully since Java 8 no longer compiles is not
something to be taken lightly.

In fact the compiler itself has a few examples, e.g., TypeEnter.java line
301 - the constructor TypeEnter.ImportsPhase() invokes super(..., new
TypeEnter.HierarchyPhase()) which wouldn't be possible if early
construction contexts were treated as static (i.e., no access to enclosing
instances).

There may be some better, less draconian restriction than "treated as
static" but I'm not sure it would be appreciably more intuitive than what
we've currently got, though I'm curious to hear your ideas. To put it
another way, I think things only get non-intuitive with the current
proposal for contrived examples.

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-spec-experts/attachments/20240610/c379621c/attachment.htm>