[lworld] RFR: 8342575: [lworld] Compiler should reject volatile fields in value classes

[John R Rose]

On Thu, 7 Nov 2024 21:16:21 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> programs like:
> 
> 
> value class V {
>     volatile int f = 1;
> }
> 
> 
> should be rejected by javac as instance fields of value classes are implicitly final and according to the `JLS 23`, `8.3.1.4 volatile Fields`:
> 
> It is a compile-time error if a final variable is also declared volatile

Just checking: This logic applies only to non-static fields, right?  When we discuss such things we typically omit specifying whether we are talking about static fields, non-static fields, or both kinds, and that can sometimes lead us to make mistakes in our thinking.

Under the principle of preserving independence of language features, it should be possible for a value class to have a non-final or a volatile fields, **if** it is a static field.

(An impulse to restrict static fields of value classes might well be the designer's siren song of "I never liked those and this is my chance to show them who's boss!")

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

PR Comment: https://git.openjdk.org/valhalla/pull/1297#issuecomment-2463322413