On Sun, 19 Apr 2026 20:30:32 GMT, Chen Liang <[email protected]> wrote:
>> Archie Cobbs has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains 143 commits: >> >> - Merge branch 'master' into JDK-8344159 to fix conflicts. >> - Merge branch 'master' into JDK-8344159. >> - Merge branch 'master' into JDK-8344159 to fix conflicts. >> - Merge branch 'master' into JDK-8344159 to fix conflicts. >> - Update copyrights to 2026. >> - Merge branch 'master' into JDK-8344159 >> - Merge branch 'master' into JDK-8344159 >> - Merge branch 'master' into JDK-8344159 >> - Suppress new unnecessary suppresion warnings created by recent commits. >> - Merge branch 'master' into JDK-8344159 >> - ... and 133 more: https://git.openjdk.org/jdk/compare/d71f070c...86889534 > > I still share the concerns with Jon and Maurizio on the mailing list, that > this may interfere with other Java Language compiler implementations. I think > we might get a different flag than -Xlint to enable this to alleviate that > issue? Not sure. > > Anyways we definitely need a unit test to ensure this is not emitting > warnings for values not recognized by javac. But that said, if we are not > recognizing these values, some users might not want those suppressions too > (assuming, say, they aren't using any IDE). So I still think this check may > be better done by a third party or so instead of a part of javac. Hi @liach, thanks for taking a look. > I still share the concerns with Jon and Maurizio on the mailing list, that > this may interfere with other Java Language compiler implementations. Hmm, I was not aware that there were outstanding questions about this feature. But obviously if so they need to be addressed first. There has been some good discussion in the past year, and I thought there was general agreement. My apologies if I missed any sticking points. Can you elaborate on the outstanding issues? I'm not clear on what "interfere with other compilers" means. I don't know if this helps any, but... this feature really is "just another warning": it lives in a lint category, that lint category can optionally be suppressed, and as with any other warning, some compilers might implement it while others might not. As for the new lint category, other compilers that don't recognize it will ignore it, just as javac will ignore any lint categories that it doesn't recognize. Put another way, this feature is just as orthogonal with respect to lint categories as any other part of the compiler. > Anyways we definitely need a unit test to ensure this is not emitting > warnings for values not recognized by javac. Good idea - I've added one in e16ef3bce55. FWIW this behavior is specified as part of the CSR. > But that said, if we are not recognizing these values, some users might not > want those suppressions too (assuming, say, they aren't using any IDE). So I > still think this check may be better done by a third party or so instead of a > part of javac. I'm sorry but I'm not understanding what you mean by that. Can you give a concrete example? Thanks. > Why should we recognize this as a value in `SuppressWarnings`? I think this > increases complexity and provides little value. There are good reasons for doing this, for example, allowing compilation by different versions of the compiler. See the CSR for a discussion. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25167#issuecomment-4276842884 PR Review Comment: https://git.openjdk.org/jdk/pull/25167#discussion_r3107525532
