Bump org.checkerframework:checker-qual from 4.2.3 to 4.3.0 in /value in the dependencies group across 1 directory

[dependabot]

Bumps the dependencies group with 1 update in the /value directory: org.checkerframework:checker-qual.

Updates org.checkerframework:checker-qual from 4.2.3 to 4.3.0

Release notes

Sourced from org.checkerframework:checker-qual's releases.

Checker Framework 4.3.0

Version 4.3.0 (2026-10-01)

User-visible changes

The new Modifiability Checker warns when a program might throw UnsupportedOperationException at run time because it calls a mutating method on a collection that does not support the method.

The new wpi2.sh script does whole-program inference, but requires buildfile edits.

Purity Checker:

• Renamed message keys purity.not.deterministic.X, purity.not.sideeffectfree.X, and purity.not.deterministic.not.sideeffectfree.X to purity.X.
• -AcheckPurityAnnotations issues warnings that it missed previously.

The Checker Framework runs under JDK 27 -- that is, it runs on a version 27 JVM.

The Checker Framework runs noticeably faster, due to performance tuning.

The HTML version of the manual has a new look. In addition to the single-page version, there is a multi-page version.

Changes for type system implementers

JavaParserUtil: moved DEFAULT_LANGUAGE_LEVEL, parseCompilationUnit(), parseStubUnit(), and parseExpression() into new class StaticJavaParserUtil.

Renamed AnnotatedTypes.innerMostType() to innermostComponentType().

Removed the unused method WholeProgramInferenceScenesStorage.updateAnnotationSetInScene().

Methods that used to return (or accept) an IPair now use a record with meaningful component names.

Closed issues

#294, #1170, #1184, #1256, #1440, #1444, #1669, #2090, #2172, #2429, #2448, #2561, #2637, #2704, #2722, #2770, #2896, #2995, #3015, #3025, #3027, #3146, #3281, #3624, #4690, #4708, #4754, #5064, #5201, #6038, #6716, #6741, #6748, #6756, #6768, #6832, #6881, #7023, #7049, #7064, #7311, #7683, #8053, #8054, #8055, #8167, #8168, #8169, #8238, #8261, #8284.

Changelog

Sourced from org.checkerframework:checker-qual's changelog.

Version 4.3.0 (2026-10-01)

User-visible changes

The new Modifiability Checker warns when a program might throw UnsupportedOperationException at run time because it calls a mutating method on a collection that does not support the method.

The new wpi2.sh script does whole-program inference, but requires buildfile edits.

Purity Checker:

• Renamed message keys purity.not.deterministic.X, purity.not.sideeffectfree.X, and purity.not.deterministic.not.sideeffectfree.X to purity.X.
• -AcheckPurityAnnotations issues warnings that it missed previously.

The Checker Framework runs under JDK 27 -- that is, it runs on a version 27 JVM.

The Checker Framework runs noticeably faster, due to performance tuning.

The HTML version of the manual has a new look. In addition to the single-page version, there is a multi-page version.

Changes for type system implementers

JavaParserUtil: moved DEFAULT_LANGUAGE_LEVEL, parseCompilationUnit(), parseStubUnit(), and parseExpression() into new class StaticJavaParserUtil.

Renamed AnnotatedTypes.innerMostType() to innermostComponentType().

Removed the unused method WholeProgramInferenceScenesStorage.updateAnnotationSetInScene().

Methods that used to return (or accept) an IPair now use a record with meaningful component names.

Closed issues

#294, #1170, #1184, #1256, #1440, #1444, #1669, #2090, #2172, #2429, #2448, #2561, #2637, #2704, #2722, #2770, #2896, #2995, #3015, #3025, #3027, #3146, #3281, #3624, #4690, #4708, #4754, #5064, #5201, #6038, #6716, #6741, #6748, #6756, #6768, #6832, #6881, #7023, #7049, #7064, #7311, #7683, #8053, #8054, #8055, #8167, #8168, #8169, #8238, #8261, #8284.

Commits

• a850bea new release 4.3.0
• 2df7db6 Fix the module in links to Collections Javadoc
• c714cde Fix broken links in the lwarp-generated manuals (#8312)
• 1014d08 Add the Modifiability Checker (#8234)
• 3c6e930 Don't bound a fresh capture type variable by unresolved inference variables (...
• cd86e5d Prep for the release.
• 0195f64 Check a constructor's purity against its class's instance initializers (#8113)
• 93d6023 Add test cases for issues that are already fixed (#8303)
• 9e0f606 Add test cases for issues that are already fixed (#8302)
• 8a1a3aa Don't let an inference bound that ignores annotations override one that (#8285)
• Additional commits viewable in compare view

[cpovirk]

The failures in this and #2159 appear to have come from the new version of Maven included in an incremental upgrade to the ubuntu-24.04 image:

• before: 20260927.320.1 (software)
• after: 20261004.327.1 (software)

I'm not yet sure whether the issue is the Maven version per se or something about a version of a plugin used. (I kind of thought that Maven's default was to pull the newest compatible version of a plugin, but I was never clear on that. If so, then the problem is presumably the Maven version itself or perhaps some shared dependency that that version provides?)

[cpovirk]

If I'm reading the output correctly, I'm seeing Surefire 3.6.0 for both versions of Maven: before, after.

[cpovirk]

(Hmm, I do see a Surefire version change in Auto-Common: before 3.5.4, after 3.6.0. So maybe Maven versions do have default versions specified for their plugins, and any drift that I remember over time has been from upgrades to the versions of Maven in GitHub CI and our internal environments? But I'm hoping that that's irrelevant to the failure we're seeing, which is in AutoFactory.)

[cpovirk]

It would be premature to point to apache/maven#13347 / apache/maven#13390, but I do notice that we use profiles to set some modules-related flags, perhaps related to the missing JDK internals? But that shouldn't be an issue for a build that is using Java 8.

Ah, Gemini is now pursuing a similar theory but with Compile-Testing, which pulls in lib/tools.jar through a profile!

[cpovirk]

I posted on one of the Maven issues. However, Gemini thinks that the problem for Auto/Compile-Testing is an intentional behavior change:

Because disabling <file> profile activation in dependency POMs (withoutFileActivation) was intentional security hardening in Maven 3.10.0 (unlike the externalActivationContext property side effects reported in #13347 and #13390), Maven 3.10.1+ / 4.x will almost certainly keep <file> activation disabled for dependency POMs. So:

• Having <profile><id>tools-jar</id><activation><jdk>1.8</jdk></activation> directly in factory/pom.xml and value/processor/pom.xml — and switching compile-testing upstream from <file> to <jdk>1.8</jdk> / <jdk>(,9)</jdk> — is needed permanently even after 3.10.0: Model interpolation does not take property activated profiles into account apache/maven#13347 and Maven 3.10.0 activates dependency POM profiles using the POM’s own properties apache/maven#13390 are fixed.

Gemini's (additional?) suggested change to AutoFactory of adding its own system dependency for tools.jar sounded questionable to me, since the need for tools.jar should be exclusive to tests (which use Compile-Testing)—but which the Maven model doesn't permit, since the system and test scopes are not orthogonal to Maven. I was concerned about impact downstream. Given that, Gemini changed course to additionalClasspathElement. That sounded better, but it sounded like the even better fix would be one in Compile-Testing itself: While Compile-Testing appears to build and test fine with Maven 3.10.0, it sounds like its profile's reliance on file presence is the problem, so a profile triggered by Java version would work better.

So I am going to try to fix this in Compile-Testing, release that, and pull in the new version here.

[cpovirk]

@dependabot rebase

[dependabot]

This pull request was built based on a group rule. Closing it will not ignore any of these versions in future pull requests.

To ignore these dependencies, configure ignore rules in dependabot.yml