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

[Maurizio Cimadamore]

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>