RFR: 8294461: wrong effectively final determination by javac [v2]

Joe Darcy darcy at openjdk.org
Tue Nov 1 02:27:32 UTC 2022


On Mon, 31 Oct 2022 19:00:32 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> There shouldn't be any spec change implied by this change. From my understanding, the compiler was not following the spec, which says that the variable `i` in the example is not effectively final. This change makes the compiler follow the spec and generate a "local variables referenced from a lambda expression must be final or effectively final" error.
> 
> Regarding release notes, I'll let someone else who has more familiarity with the release process comment on that.

Adding some additional context, there CSR reviews both specification changes and behavioral changes considered to have sufficiently high compatibility impact.

This change renders code that previously (if erroneously) compiled into a compilation error, which is a source compatibility concern. (Changing code that compiles into code that doesn't compile is considered a more serious change than the reverse.)

Offhand, I don't know how often such coding patterns may appear in practice; we should some internal tooling which can help gauge that. A modification that may be suggested is only doing the updated check for source level 20 and higher.

HTH

-------------

PR: https://git.openjdk.org/jdk/pull/10856


More information about the compiler-dev mailing list