Draft Spec for Second Preview of Flexible Constructor Bodies (JEP 482)
Maurizio Cimadamore
maurizio.cimadamore at oracle.com
Tue Jun 11 16:36:49 UTC 2024
On 11/06/2024 16:57, Archie Cobbs wrote:
> 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 (!)
I think you are comparing apples and oranges. The issue you mention was
backed out as part of this:
https://bugs.openjdk.org/browse/JDK-8299416
Which has a very long discussion, mentioning the need of supporting JLS
text:
https://bugs.openjdk.org/browse/JDK-8299861
In other words, as sometimes happens, following JLS to the letter can
reveal other cases where perhaps JLS was underspecified, and in those
cases it's ok (even desirable) to take a step back to see what needs to
be aligned with what.
Maurizio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-spec-experts/attachments/20240611/c782756f/attachment.htm>
More information about the amber-spec-experts
mailing list