RFR: 8362885: A more formal way to mark javac's Flags that belong to a specific Symbol type only

[Jan Lahoda]

On Thu, 24 Jul 2025 15:25:33 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> This looks like a really nice improvement for maintainability.
> 
> **?** Would it make more sense (and/or be simpler?) to move the conflict-checking logic into `FlagsGenerator`?
> 
> It somehow seems odd to have a tool which can knowingly generate an invalid `FlagsEnum.java` file... and then defer the check for that until later, maybe, in a unit test... when we could just make the build fail instead.
> 

Done.

> **?** Is it worth adding some simple runtime check for correct `FlagTarget` usage?
> 
> For example (just brainstorming):
> 
>     * For each `FlagTarget` have `FlagsGenerator` output e.g. `public static final long METHOD_FLAGS = 0x0301930420520017L;`
> 
>     * At appropriate location(s) in the code, add `Assert.check(this.flags_field & ~METHOD_FLAGS) == 0);`

I've added the checks. It may be useful, but it is somewhat limited, as it cannot detect the most dangerous case where the flag with overloaded meaning is set incorrectly.

> 
> 
> (Of course even better would be to check this at compile time using stronger typing (e.g., by replacing `long flags_field` with some `EnumSet`, etc.) but that's probably way beyond this first step.)

There were several experiments, in the past and currently ongoing, but it is difficult to do something that is safer and does not cost too much on performance/memory consumption. Value classes may or may not help.

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

PR Comment: https://git.openjdk.org/jdk/pull/26452#issuecomment-3117882238