JDK-8350514 : Refactor MandatoryWarningHandler to support dynamic verbosity
  • Type: Sub-task
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 25
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2025-02-21
  • Updated: 2025-07-22
  • Resolved: 2025-07-03
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 26
26 b06Fixed
Related Reports
Relates :  
Description
 This is split off as a sub-task of JDK-8224228, which seeks to add @SuppressWarnings support for lexical features.

The `MandatoryWarningHandler` is used by the `preview`, `deprecation`, `removal`, and `unchecked` mandatory warnings. The constructor takes a boolean `verbose` flag which is documented to "Specify whether or not detailed messages about individual instances should be given, or whether an aggregate message should be generated at the end of the compilation."

The problem is that this flag doesn't really make sense for warnings that are suppressible via `@SuppressWarnings`: for such warnings, what we actually want to do is trigger the aggregate message at the end of compilation if and only if there were any warnings that were not suppressed by `@SuppressWarnings` but _were_ suppressed because the corresponding lint category was not enabled, either because it wasn't enabled by default, or due to an explicit `-Xlint:-foo' flag.

Currently, we get that same net result, because `preview` is not suppressible via `@SuppressWarnings`, and for the other three categories there is logic around the calls to `MandatoryWarningHandler.report()` to ensure the right thing happens.

It would be simpler and more straightforward for the users of `MandatoryWarningHandler` to just pass along the currently applicable `Lint` instance and let `MandatoryWarningHandler` figure out what to log, if anything, and also keep track of whether to generate the aggregate message the end of the compilation.
Comments
Changeset: 25ed36f3 Branch: master Author: Archie Cobbs <acobbs@openjdk.org> Date: 2025-07-03 18:13:07 +0000 URL: https://git.openjdk.org/jdk/commit/25ed36f3ef1fe1d6914689c762910f104775f48c
03-07-2025

A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/25810 Date: 2025-06-13 21:25:54 +0000
13-06-2025

Reopening, as this will get fixed as a side-effect of fixing JDK-8359493.
13-06-2025

this one will be made obsolete by fix for JDK-8348611
29-05-2025

A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/23730 Date: 2025-02-21 20:42:10 +0000
21-02-2025