On Tue, 21 Apr 2026 18:07:44 GMT, Archie Cobbs <[email protected]> wrote:
> > Compiler vendors are encouraged to document the strings they support for > > @SuppressWarnings, and to cooperate to ensure that the same strings are > > recognized across multiple compilers. > > The `javac` list is > [here](https://docs.oracle.com/en/java/javase/25/docs/specs/man/javac.html#option-Xlint-custom). > Somewhat obscured but not completely :) Thanks, so it's the same as `javac --help-lint`, right? > > In the past I had looked at some of javac's categories, but just from the > > help text I was unable to infer what exactly was analyzed > > These days the lint category is specified in the same place as the text of > the warning (i.e., in the [properties > file](https://github.com/openjdk/jdk/blob/97ccabb28e7ae81765a84b98ad418e0b7b87a505/src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties#L1958-L1961)). > Look for comments like `lint: module` above each entry. Thanks, I bookmarked the file :) > > When ecj encounters a `@SW` token which it doesn't know of, it reports: > > `Unsupported @SuppressWarnings("foo")`. > > Hmm, depending on how you read it, that could be considered a violation of > ยง9.6.4.5: _A Java compiler must ignore any such string that it does not > recognize._ It's "just another optional warning" (like this entire thread, right?). > > Many warnings aren't even computed if the corresponding option is disabled. > > So we face situations where ecj knows about absence of N but might have > > report M, but M is not analyzed (option disabled). > > FWIW this implementation avoids that scenario, by calculating warnings in a > blob of code if the warning is enabled OR if the warnings is suppressible and > unnecessary suppression detection is enabled. That might be a solution indeed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25167#issuecomment-4290961952
