Proposal: Warnings for unnecessary warning suppression

[Archie Cobbs]

Hi Maurizio,

Thanks for your input.

On Fri, May 9, 2025 at 9:31 AM Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> IMHO, this is a problem present with the addition of every new lint
> warning. It's not specific to this one. Of course, some new lint warning
> operate on brand new language features, so the potential to compromise
> existing compilaton units is low. But I'd expect that warnings such as
> "serial" would have ran into similar corner cases (e.g. previously ok code
> started to report new warnings, and to fail with Werror).
>
> So I think this seems ok, and not enough to cause a tweak to the treatment
> of lint:all.
>
That sounds good to me, but Joe Darcy had some reservations (see CSR). So
we would need to decide how to proceed.

Maybe the thing to do is just to ensure that it gets introduced early in
the cycle so we can get some experience with it...?

> I'll add here that a more robust fix for Werror issues is to enable
> developers to be more specific in the warnings they'd like to promote to
> errors (as discussed in the past). I'll CC Kevin who has always been a fan
> of this feature ;-)
>
Good news: that PR is already in place  :)
https://github.com/openjdk/jdk/pull/23622

> Also complicating things, there are two different ways to suppress
> warnings, @SuppressWarnings("foo") and -Xlint:-foo and for similar
> "corner case" reasons they need to be configurable separately.
>
> IMHO, the main value of this new lint warning is to detect the use of
> `@SuppressWarnings` that are redundant. Sure there's the command-line
> flavor as well, but that renders any source code analysis dependent on the
> flags passed to javac. In other words, detecting redundant
> `@SuppressWarnings` has a more "timeless" nature that does not apply to
> detecting redundant command-line suppressions. The former tells you
> something about _your code_, in a way that is independent from which flags
> you use to compile it. Which is why I think we should only worry about that.
>
I think that's a reasonable way to start - that is, we just add the
category for "suppression" now and worry later about possibly adding
"supression-option".

Joe - any thoughts?

-Archie

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