On Mon, 20 Apr 2026 13:58:02 GMT, Archie Cobbs <[email protected]> wrote:
> The unnecessary suppression warning is "just another warning", and you deal
> with it the same way...
>
> To be explicit: let Va and Vb be the source code locations where A and B
> (respectively) complain about unnecessary suppression. Then you add
> `@SuppressWarnings("suppression")` to cover the union Va ∪ Vb. Problem solved
> - in exactly the same way as before.
Yes, Wb would need a `SW("suppression")` in case S it's compiled with A. And Wa
would need a `SW("suppression")` in case S is compiled with B. Effectively this
means having:
`@SuppressWarnings({"serial", "suppression"})`
In a bunch of places (hopefully few).
The ability to use "suppression" itself as a category seems to be an handy
escape hatch. That said, for folks enabling "suppression" in their compilation
units, this *could* mean some adjustments to the code base before they can
fully take advantage of this. Not saying this is a blocker.
> Important detail: The unnecessary suppression warning is never reported for
> suppression itself. So the recursion always stops. It's "just another
> warning".
Yep -- this is a very important detail -- I was about to ask this :-)
> Please let me know if I'm still missing something.
In my view, the design is sound. Some potential compatibility aspects were
identified, and perhaps some of the stuff brought up in this PR should be added
to the CSR (if not done already), so that risk can be assessed more accurately
as part of that process.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/25167#issuecomment-4289198527
PR Comment: https://git.openjdk.org/jdk/pull/25167#issuecomment-4289220852
