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

Archie Cobbs archie.cobbs at gmail.com
Tue Jun 11 15:57:42 UTC 2024


On Tue, Jun 11, 2024 at 10:35 AM Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> I think so. At times we have made other source incompatible changes (esp.
> in the context of type inference in Java 8) with the goal of putting the
> language on a firmer ground.
>
> So far the evidence is that this code idiom is basically non-existent in
> the wild, and there's workarounds. So that, alone, wouldn't constitute a
> great argument IMHO.
>
OK - we can have different predictions on how it might play out.

My guess is colored by previous experience. For example, my fix for
JDK-8294461 ("wrong effectively final determination by javac") got reverted
because of backward incompatibility in compiler behavior, and this change
in behavior was arguably even more obscure in terms of "code in the wild"
affected and it was certainly more justified from a spec point of view
because it wasn't changing the spec, it was fixing the compiler to
correctly follow the spec (!)

> My point is that we'd probably want the two examples above to align, which
> probably means going with the rules in JEP 482 (or some alternate rules
> which achieve the same effects).
>
I agree.

-Archie

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


More information about the amber-spec-experts mailing list