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

Archie Cobbs acobbs at openjdk.org
Mon Jun 23 18:28:29 UTC 2025


On Mon, 23 Jun 2025 16:09:04 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, 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, 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.

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

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


More information about the compiler-dev mailing list