On Mon, 20 Apr 2026 10:17:12 GMT, Maurizio Cimadamore <[email protected]> wrote:
>> 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. > >> I'm sorry but I'm not understanding what you mean by that. Can you give a >> concrete example? > > I think there are two potential issues here: > > 1. a SW includes a warning not handled by javac (but handled by another > compiler, or IDE). Is the suppression then marked as redundant when compiling > with javac? > 2. a SW category `Foo` includes N warnings in javac, but N + M warnings in > some other compiler/IDE. Say that none of the N javac warnings is detected -- > we will then proceed to claim this SW has redundant suppressions. But in some > other IDE/compiler this might not actually be the case. > > Now, (1) is simpler to handle than (2) -- after all, we know which warnings > javac can handle and which it cannot -- so we might only restrict redundant > suppressions to the very categories handled by javac. Which, I think, it's > what > https://github.com/openjdk/jdk/commit/e16ef3bce55444e6c85fe788b248ba2f1bfe0e4c > does. > > There's no such logic for (2) though. So, in a way, this PR assumes that SW > category definition is sort of fixed, and that other tools follow the same > classification as what's done in javac. I'm not 100% sure this is always the > case, but perhaps this is an area that @stephan-herrmann could help us assess? Hi @mcimadamore, Thanks for the clear & concrete examples. > I think there are two potential issues here: > > 1. a SW includes a warning not handled by javac (but handled by another > compiler, or IDE). Is the suppression then marked as redundant when compiling > with javac? Suppression warnings are only emitted for lint categories recognized by javac (i.e., `LintCategory.get()` would return non-empty). It has always worked this way - and if it didn't, I completely agree that would cause problems. > 2. a SW category `Foo` includes N warnings in javac, but N + M warnings in > some other compiler/IDE. Say that none of the N javac warnings is detected -- > we will then proceed to claim this SW has redundant suppressions. But in some > other IDE/compiler this might not actually be the case. Great point - I think this is the primary scenario that people seem to be worried about. Just to restate for clarity... apologies for the verbosity, just trying to be precise here. Let's say we have some source code S, and there are two compilers A and B, both supporting some lint category `foo`, but when we compile S with A, warnings are generated at one set of source code locations Wa, while when we compile S with B, warnings are generated at a different set of source code locations Wb. In general, Wa ≠ Wb and neither one is a subset of the other. To provide a concrete example: consider `serial` warnings. There are lots and lots of them, and different compilers probably generate differ warnings for all the different scenarios. With a serialization-heavy application it's likely that Wa ≠ Wb. The question everyone is worried about: What if you want S to compile warning-free under both A and B? Answer: you have to position `@SuppressWarnings("serial")` annotations over the union Wa ∪ Wb. This would be true for any other lint category where that happens, and it's always been this way (and this is why the JLS requires compilers to ignore unrecognized categories). Now you ask: OK but then if either/both compiler supports `suppression` warnings, then won't you then be stuck? Because the `@SuppressWarnings("serial")` annotations in Wb∖Wa will be reported as unnecessary by A, and the ones in Wa∖Wb will be reported as unnecessary by B? The point I'm trying to get across here is that **the situation with `suppression` is no different than the original situation with `serial`**. 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. Important detail: The unnecessary suppression warning is never reported for `suppression` itself. So the recursion always stops. It's "just another warning". Please let me know if I'm still missing something. Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25167#issuecomment-4281398839
