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

[Maurizio Cimadamore]

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

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

Also, are there mandatory warnings for which there's no aggregation?

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

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