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