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

[Maurizio Cimadamore]

On Mon, 23 Jun 2025 21:00:52 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>>> 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.

Re. default-enabled, I suspect this is used for preview language feature warnings -- e.g. warnings to be issued when (a) preview features have been enabled and (b) the use of a preview language feature has been detected. As JEP 12 says, while it's ok to use suppressible warnings for preview APIs, it is not ok to use suppressible warnings for language features. So, I believe what JEP 12 says is not "default-enabled", but really "always-enabled", or "unsuppressible". (unfortunately the JEP text does some confusion as it uses the term `lint` warning to refer to the unsuppressible warning, when in reality, in javac, the term `lint` is used for warnings that *can* be suppressed).

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

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