Proposal: Warnings for unnecessary warning suppression

[Archie Cobbs]

Hi Jon,

Thanks for the comments.

On Sat, Nov 9, 2024 at 5:29 PM Jonathan Gibbons <jjg3 at pobox.com> wrote:

> 1. The set of strings that are valid for @SuppressWarnings is undefined
> and open-ended. Yes, the JDK compiler `javac` defines a set of strings but
> there is no guarantee that code will only be compiled by `javac` and that
> there are no other strings in use. Some IDEs may also use the
> @SuppressWarnings mechanism.
>
Thanks - I should have made that point clear. This new functionality would
be limited to the actual warnings implemented by javac.

In other words, there must be a corresponding LintCategory enum value;
string values in @SuppressWarnings annotations that don't correspond to
actual javac warnings would be completely ignored/unaffected by this.

> JLS also says 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. so we should
> document this in such a way that other tools are encouraged to support the
> same string with the same semantics.
>
Yep, thanks. A basic Google search didn't reveal any examples of other
compilers having a similar option for the @SuppressWarnings annotation. If
you know of any, we should certainly try to be consistent.

> 3. I note that the JDK `javadoc` tool supports variations on
> `@SuppressWarnings("doclint"), corresponding to the `-Xdoclint` option
> supported by both `javac` and `javadoc`, although there has been informal
> discussions on dropping support from `javac`.  See here:
> https://docs.oracle.com/en/java/javase/23/docs/specs/man/javadoc.html#doclint
>
I've run across a few of these. For now they're being treated just like any
other unknown value - i.e., being ignored.

A reasonable future task would be to implement the analogous functionality
for Javadoc warnings but I haven't investigated that.

In any case it seems clear that this should be done as part of the javadoc
tool, not javac. The two "worlds" (i.e., javac vs. javadoc) should be
handled separately for this kind of analysis. In other words, I wouldn't
want my javac compiler warning me about unnecessary doclint:foo
suppressions, or vice-versa.

Thanks,
-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20241110/6b7c7c1a/attachment.htm>