RFR: 8359493: Refactor how aggregated mandatory warnings are handled in the compiler [v2]

[Maurizio Cimadamore]

On Mon, 23 Jun 2025 18:26:01 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> I'd prefer to address the `DEFAULT_ENABLED` in a separate (and standalone, if possible) PR, to make sure we're really going the right direction about this. My general feeling is that all these properties are ultimately tied to the lint category --- so, once you pick a category, you kind of know whether it's aggregated, or defaultEnabled, or whatever -- modelling this as a flag makes it look as if you can also emit a preview warning w/o the aggregation behavior, which I'm not sure makes sense?
>
>> My general feeling is that all these properties are ultimately tied to the lint category --- so, once you pick a category, you kind of know whether it's aggregated, or defaultEnabled, or whatever -- modelling this as a flag makes it look as if you can also emit a preview warning w/o the aggregation behavior, which I'm not sure makes sense?
> 
> The flags can't always be tied to the category (for example, `compiler.warn.preview.feature.use.classfile` is logged with `MANDATORY` but not `DEFAULT_ENABLED`), but it looks like they could be tied to the specific warning.
> 
> This could use our existing property file comment mechanism.  What do you think about that idea? Example:
> 
> # 0: message segment (feature)
> # lint: preview
> # diag-flags: mandatory, default-enabled, aggregate
> compiler.warn.preview.feature.use=\
>    {0} is a preview feature and may be removed in a future release.
> 
> # 0: file object (classfile), 1: string (expected version)
> # lint: preview
> # diag-flags: mandatory, aggregate
> compiler.warn.preview.feature.use.classfile=\
>    class file for {0} uses preview features of Java SE {1}.
> 
> 
> Then we could eliminate `Log.mandatoryWarning()` too.

I was thinking about capturing flags in the file too (but then hoped we could just ride the category). Doing what you suggest is a possibility -- my only "fear" is that by reflecting the flags in the `compiler.properties` file we'll make the current flag classification look more permanent than what it probably is (e.g. it seems to me there's a lot of ad-hocness to this classification, due to the ad-hoc behavior we're now trying to sort out). Anyway, perhaps worth doing it, even as if an exercise, as it will certainly make asymmetries between various flags pop out more -- then we can ask whether that asymmetry is there for a reason and needs to be supported going forward, or if we can make things a little less ad-hoc.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25810#discussion_r2162525162