8359596: Behavior change when both -Xlint:options and -Xlint:-options flags are given #25840

archiecobbs · 2025-06-17T01:57:33Z

My minor contribution to #24746 (which fixed JDK-8354556) accidentally introduced a change in the compiler's behavior when given conflicting lint flags like -Xlint:options -Xlint:-options. This PR restores the original behavior.

Although this might be considered a weird corner case, many build systems add flags in multiple stages and this can easily result in both flags being added, and so the behavior in this scenario needs to stay consistent.

Basically the code was trying to be too clever; when the original logic is restored, the code gets simpler.

Progress

Change must be properly reviewed (1 review required, with at least 1 Reviewer)
Change must not contain extraneous whitespace
Commit message must refer to an issue
Change requires CSR request JDK-8359844 to be approved

Issues

JDK-8359596: Behavior change when both -Xlint:options and -Xlint:-options flags are given (Bug - P2)
JDK-8359844: Behavior change when both -Xlint:options and -Xlint:-options flags are given (CSR)

Reviewers

Uwe Schindler (@uschindler - Author) Review applies to 9e788319
Maurizio Cimadamore (@mcimadamore - Reviewer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/25840/head:pull/25840
$ git checkout pull/25840

Update a local copy of the PR:
$ git checkout pull/25840
$ git pull https://git.openjdk.org/jdk.git pull/25840/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 25840

View PR using the GUI difftool:
$ git pr show -t 25840

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/25840.diff

Using Webrev

Link to Webrev Comment

bridgekeeper · 2025-06-17T01:58:08Z

👋 Welcome back acobbs! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

openjdk · 2025-06-17T01:58:17Z

@archiecobbs This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8359596: Behavior change when both -Xlint:options and -Xlint:-options flags are given

Reviewed-by: mcimadamore, uschindler

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 249 new commits pushed to the master branch:

da7080f: 8359761: JDK 25 RDP1 L10n resource files update
4edf791: 8295851: Do not use ttyLock in BytecodeTracer::trace
12196ba: 8358624: ImmutableDescriptor violates equals/hashCode contract after deserialization
... and 246 more: https://git.openjdk.org/jdk/compare/c793de989facdb532021e1d5ddd01eb0e089b8e6...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

openjdk · 2025-06-17T01:58:52Z

@archiecobbs The following label will be automatically applied to this pull request:

compiler

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

mlbridge · 2025-06-17T14:05:44Z

Webrevs

jddarcy · 2025-06-17T16:27:53Z

/csr needed

openjdk · 2025-06-17T16:29:22Z

@jddarcy has indicated that a compatibility and specification (CSR) request is needed for this pull request.

@archiecobbs please create a CSR request for issue JDK-8359596 with the correct fix version. This pull request cannot be integrated until the CSR request is approved.

The extra checks for "-Xlint:none" are needed now because of JDK-8352612, which changed the behavior of "-Xlint:none" to no longer imply "-nowarn", which allowed the affected warnings to get away with skipping that check.

uschindler · 2025-06-19T10:03:07Z

Adding isDisabled() looks fine to me.

Possibly at a later stage we should centralize all the handling using an EnumSet which is populated only once before the compiler is invoked.

The behaviour should be documented in the javac documentation.

mcimadamore

I generally agree with these changes, but I'm not sure that the code in Lint (which is not shown in this diff as it has not changed) really adheres to the policy described in the JBS issue that "last option should win". What Lint seems to do is to compute an initial set, like follows:

if none is found, start from the empty set
if all is found, start from the "everything" set
if neither is found, start from a "predefined" set which contains some default categories

After that, the initial set is augmented (or reduced) based on the explicit enable/disable options.

I see at least two issues in this logic:

how is the initial set determined if both all and none are specified? The "last win" policy might suggest that we use the last of these to determine the initial set, but the code doesn't do that, and I think it gives precedence to all.
what if the same category is both enabled and disabled? Well, again, the code doesn't really apply a "last win" policy -- instead, for each category, we do this:

// Look for specific overrides
        for (LintCategory lc : LintCategory.values()) {
            if (options.isExplicitlyEnabled(Option.XLINT, lc)) {
                values.add(lc);
            } else if (options.isExplicitlyDisabled(Option.XLINT, lc)) {
                values.remove(lc);
            }
        }

That is, for each category we check if it's enabled -- if so we add it to the set. Otherwise if it's disabled, we remove it from the set. So, if a category is both enabled and disabled, it looks like the code should just treat it as enabled?

So, I'm not sure how this fix (or even the previous code, before we changed any of this) adheres/adhered to the "last win" policy?

mcimadamore · 2025-06-23T10:46:57Z

I generally agree with these changes, but I'm not sure that the code in Lint (which is not shown in this diff as it has not changed) really adheres to the policy described in the JBS issue that "last option should win". What Lint seems to do is to compute an initial set, like follows:
* if `none` is found, start from the empty set

* if `all` is found, start from the "everything" set

* if neither is found, start from a "predefined" set which contains some default categories
After that, the initial set is augmented (or reduced) based on the explicit enable/disable options.

I see at least two issues in this logic:
* how is the initial set determined if both `all` and `none` are specified? The "last win" policy might suggest that we use the last of these to determine the initial set, but the code doesn't do that, and I think it gives precedence to `all`.

* what if the same category is both enabled and disabled? Well, again, the code doesn't really apply a "last win" policy -- instead, for each category, we do this:
// Look for specific overrides
        for (LintCategory lc : LintCategory.values()) {
            if (options.isExplicitlyEnabled(Option.XLINT, lc)) {
                values.add(lc);
            } else if (options.isExplicitlyDisabled(Option.XLINT, lc)) {
                values.remove(lc);
            }
        }
That is, for each category we check if it's enabled -- if so we add it to the set. Otherwise if it's disabled, we remove it from the set. So, if a category is both enabled and disabled, it looks like the code should just treat it as enabled?

So, I'm not sure how this fix (or even the previous code, before we changed any of this) adheres/adhered to the "last win" policy?

Ok, I see that this change only really affects how options behave (and few other lint warnings). After debugging, I can clearly see that my analysis above is correct, and that the way in which the set of enabled lint warnings is computed does NOT conform to a "last win" policy. So, if you compile the code below with -Xlint:unchecked -Xlint:-unchecked:

class Test<X> {
    static void m(Test t) {
        Test<String> ts = t;
    }
}

It does print the lint warning (meaning that Werror would make this fail, even though the last lint command passed disables unchecked warnings).

So, the real fix of this PR is in using isDisabled instead of isExplicitlyDisabled. But I must notice that this carves out a special expection for options and path lint warnings -- whereas every other lint warning will not resolve "conflicts" in the same way.

archiecobbs · 2025-06-23T13:27:42Z

So, the real fix of this PR is in using isDisabled instead of isExplicitlyDisabled. But I must notice that this carves out a special expection for options and path lint warnings -- whereas every other lint warning will not resolve "conflicts" in the same way.

Correct - because that "carve out" was already there in the previous behavior, and the whole point of this patch is to restore that previous behavior.

Some lint warnings simply don't follow the normal enable/disable logic (which you normally get by using Lint.logIfEnabled()) and this is one of them. It would be nice to eliminate these special exceptions over time, but (as revealed by the associated bug) doing so breaks expectations that are built into various folks' build processes. So it's a nice thought but obviously outside of the scope of this PR.

Instead, what I'm trying to do now (in upcoming PR #24584) is simply make these special cases more explicit in the code using new DiagnosticFlag's; see for example this change.

mcimadamore · 2025-06-23T14:15:52Z

Ok, I now see that #24746 did essentially two things:

introduced aliases to lint categories -- this resulted in having a new method Options:;isExplicilyEnabled/Disabled to check all possible aliases for a lint option.
consequently replace calls to options.isSet(Option.XLINT_CUSTOM, lc.option) with options.isExplicitlyEnabled(Option.XLINT, lc)

Part (2) is what created the issue, because by replacing isSet/Unset with isExplicitEnabled/Disabled we ended up changing behavior: the isExplicitEnabled/Disabled methods depend on a new Options::isSet method that takes a default value, and also look into stuff like -Xlint:none/all (which didn't happen before).

So, this PR reverts the behavioral changes, by having isExplicitEnabled/Disabled behave more like isSet/isUnset used to work previously, which seems ok.

I have to admit I don't really get why isExplicitEnabled/Disabled takes an Option parameter -- I see them always invoked with Option.XLINT. Because of that, I'm not even sure they belong much in Options at all -- an instance method on LintCategory which accepts Options would perhaps look simpler for clients?

mcimadamore · 2025-06-23T14:17:14Z

I have to admit I don't really get why isExplicitEnabled/Disabled takes an Option parameter -- I see them always invoked with Option.XLINT. Because of that, I'm not even sure they belong much in Options at all -- an instance method on LintCategory which accepts Options would perhaps look simpler for clients?

Note: the same is true for the new methods isEnabled/isDisabled added in this PR -- they feel Lint-specific methods to me.

archiecobbs · 2025-06-23T18:28:47Z

I have to admit I don't really get why isExplicitEnabled/Disabled takes an Option parameter -- I see them always invoked with Option.XLINT. Because of that, I'm not even sure they belong much in Options at all -- an instance method on LintCategory which accepts Options would perhaps look simpler for clients?

Note: the same is true for the new methods isEnabled/isDisabled added in this PR -- they feel Lint-specific methods to me.

It's to allow for future customization of other lint-related options, in particular -Werror - see #23622.

Maybe that's a little too leading? I can remove it if you prefer.

mcimadamore · 2025-06-23T20:55:13Z

I have to admit I don't really get why isExplicitEnabled/Disabled takes an Option parameter -- I see them always invoked with Option.XLINT. Because of that, I'm not even sure they belong much in Options at all -- an instance method on LintCategory which accepts Options would perhaps look simpler for clients?

Note: the same is true for the new methods isEnabled/isDisabled added in this PR -- they feel Lint-specific methods to me.

It's to allow for future customization of other lint-related options, in particular -Werror - see #23622.

Maybe that's a little too leading? I can remove it if you prefer.

Yeah, I think for now I'd prefer that. I believe each PR should be relatively standalone -- maybe we will go ahead and follow up with the other PR, but I'd prefer to avoid adding more stuff here which is really needed to support that other task.

mcimadamore · 2025-06-24T10:45:32Z

Yeah, I think for now I'd prefer that. I believe each PR should be relatively standalone -- maybe we will go ahead and follow up with the other PR, but I'd prefer to avoid adding more stuff here which is really needed to support that other task.

Especially considering this is a fix that is also targeting 25 (now in rampdown mode), so there's extra motivations for keeping the fix as small as possible.

archiecobbs · 2025-06-24T13:35:45Z

Yeah, I think for now I'd prefer that. I believe each PR should be relatively standalone -- maybe we will go ahead and follow up with the other PR, but I'd prefer to avoid adding more stuff here which is really needed to support that other task.

Especially considering this is a fix that is also targeting 25 (now in rampdown mode), so there's extra motivations for keeping the fix as small as possible.

Good point. Should be fixed in f01f19d.

mcimadamore

Looks good - thanks!

archiecobbs · 2025-06-24T16:18:17Z

Thanks for the review!

archiecobbs · 2025-06-27T18:25:03Z

/integrate

openjdk · 2025-06-27T18:25:27Z

Going to push as commit 3525a40.
Since your change was applied there have been 250 commits pushed to the master branch:

712d866: 8360312: Serviceability Agent tests fail with JFR enabled due to unknown thread type JfrRecorderThread
da7080f: 8359761: JDK 25 RDP1 L10n resource files update
4edf791: 8295851: Do not use ttyLock in BytecodeTracer::trace
... and 247 more: https://git.openjdk.org/jdk/compare/c793de989facdb532021e1d5ddd01eb0e089b8e6...master

Your commit was automatically rebased without conflicts.

openjdk · 2025-06-27T18:25:34Z

@archiecobbs Pushed as commit 3525a40.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

archiecobbs · 2025-06-27T19:38:37Z

/backport jdk25u

openjdk · 2025-06-27T19:39:16Z

@archiecobbs the backport was successfully created on the branch backport-archiecobbs-3525a40f-master in my personal fork of openjdk/jdk25u. To create a pull request with this backport targeting openjdk/jdk25u:master, just click the following link:

➡️ Create pull request

The title of the pull request is automatically filled in correctly and below you find a suggestion for the pull request body:

Hi all,

This pull request contains a backport of commit 3525a40f from the openjdk/jdk repository.

The commit being backported was authored by Archie Cobbs on 27 Jun 2025 and was reviewed by Maurizio Cimadamore and Uwe Schindler.

Thanks!

If you need to update the source branch of the pull then run the following commands in a local clone of your personal fork of openjdk/jdk25u:

$ git fetch https://github.com/openjdk-bots/jdk25u.git backport-archiecobbs-3525a40f-master:backport-archiecobbs-3525a40f-master
$ git checkout backport-archiecobbs-3525a40f-master
# make changes
$ git add paths/to/changed/files
$ git commit --message 'Describe additional changes made'
$ git push https://github.com/openjdk-bots/jdk25u.git backport-archiecobbs-3525a40f-master

⚠️ @archiecobbs You are not yet a collaborator in my fork openjdk-bots/jdk25u. An invite will be sent out and you need to accept it before you can proceed.

Restore behavior when both -Xlint:options and -Xlint:-options are given.

5069bf2

openjdk bot added the compiler [email protected] label Jun 17, 2025

No need for /nodynamiccopyright/ with this test.

8dcea70

archiecobbs marked this pull request as ready for review June 17, 2025 14:00

openjdk bot added the rfr Pull request is ready for review label Jun 17, 2025

openjdk bot added the csr Pull request needs approved CSR before integration label Jun 17, 2025

archiecobbs mentioned this pull request Jun 17, 2025

8349847: Support configuring individual lint categories as errors #23622

Open

4 tasks

Ensure that "-Xlint:none" still works for the affected warnings.

9e78831

The extra checks for "-Xlint:none" are needed now because of JDK-8352612, which changed the behavior of "-Xlint:none" to no longer imply "-nowarn", which allowed the affected warnings to get away with skipping that check.

archiecobbs mentioned this pull request Jun 18, 2025

8348611: Eliminate DeferredLintHandler and emit warnings after attribution #24584

Draft

3 tasks

uschindler approved these changes Jun 19, 2025

View reviewed changes

mcimadamore reviewed Jun 23, 2025

View reviewed changes

Cleanups per review comments.

f01f19d

mcimadamore approved these changes Jun 24, 2025

View reviewed changes

openjdk bot added the ready Pull request is ready to be integrated label Jun 27, 2025

openjdk bot removed the csr Pull request needs approved CSR before integration label Jun 27, 2025

openjdk bot added the integrated Pull request has been integrated label Jun 27, 2025

openjdk bot closed this Jun 27, 2025

openjdk bot removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels Jun 27, 2025

8359596: Behavior change when both -Xlint:options and -Xlint:-options flags are given #25840

8359596: Behavior change when both -Xlint:options and -Xlint:-options flags are given #25840

Conversation

archiecobbs commented Jun 17, 2025 • edited by openjdk bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Progress

Issues

Reviewers

Reviewing

Uh oh!

bridgekeeper bot commented Jun 17, 2025

Uh oh!

openjdk bot commented Jun 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

openjdk bot commented Jun 17, 2025

Uh oh!

mlbridge bot commented Jun 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Webrevs

Uh oh!

jddarcy commented Jun 17, 2025

Uh oh!

openjdk bot commented Jun 17, 2025

Uh oh!

uschindler commented Jun 19, 2025

Uh oh!

mcimadamore left a comment

Choose a reason for hiding this comment

Uh oh!

mcimadamore commented Jun 23, 2025

Uh oh!

archiecobbs commented Jun 23, 2025

Uh oh!

mcimadamore commented Jun 23, 2025

Uh oh!

mcimadamore commented Jun 23, 2025

Uh oh!

archiecobbs commented Jun 23, 2025

Uh oh!

mcimadamore commented Jun 23, 2025

Uh oh!

mcimadamore commented Jun 24, 2025

Uh oh!

archiecobbs commented Jun 24, 2025

Uh oh!

mcimadamore left a comment

Choose a reason for hiding this comment

Uh oh!

archiecobbs commented Jun 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

archiecobbs commented Jun 27, 2025

Uh oh!

openjdk bot commented Jun 27, 2025

Uh oh!

openjdk bot commented Jun 27, 2025

Uh oh!

archiecobbs commented Jun 27, 2025

Uh oh!

openjdk bot commented Jun 27, 2025

Uh oh!

Uh oh!

archiecobbs commented Jun 17, 2025 •

edited by openjdk bot

Loading

openjdk bot commented Jun 17, 2025 •

edited

Loading

mlbridge bot commented Jun 17, 2025 •

edited

Loading

archiecobbs commented Jun 24, 2025 •

edited

Loading