Per-task skipCheckerFramework option doesn't work

[tmarback]

Hello!

I am trying to set up an additional build of the project's main sources before actually compiling with the Checker Framework enabled, so that the class files can be used with the @StaticallyExecutable annotation. Naturally, this task can't be run with Checker enabled, so I figured I could use the per-task exclusion setting that is listed on the instructions:

val preCompile = tasks.register<JavaCompile>("preCompile") {
    description = "Pre-compiles classes to use in static verification"

    classpath = sourceSets["main"].compileClasspath
    source = sourceSets["main"].java
    destinationDirectory = preCompiledClasses

    checkerFramework {
        skipCheckerFramework = true // Should disable Checker on this task
    }
}

However, what I'm finding is that the skipCheckerFramework setting at the task level has no effect at all, no matter which way I use it. Note that doing it exactly as the README says doesn't work either:

tasks.withType<JavaCompile>().configureEach {
    if (name.equals("preCompile")) {
        checkerFramework {
            skipCheckerFramework = true
        }
    }
}

In the end I had to tack on a Test at the end of the task name just so that it would get skipped by the excludeTests setting.

Am I using the setting wrong, or is there a specific setup needed for it to work?

(Using Gradle 8.8, checkerframework-gradle-plugin 0.6.42)

[kelloggm]

Hi, sorry you're having trouble! I've tried to reproduce this problem on a small sample project to debug it, and I haven't been able to do so - the Checker Framework is being disabled per-task as expected. You can look at my reproduction setup here: https://github.com/kelloggm/sample-gradle-project/tree/issue281. I assume that there must be something else particular to your setup that's causing the problem. Do you have any idea what it might be (I don't, unfortunately)?

Reproduction steps:

Running ./gradlew clean compileJava shows that the Checker Framework is running on (and warning about) regular compilation:

➜  sample-gradle-project git:(issue281) ✗ ./gradlew clean compileJava

> Configure project :
No explicit dependency on the Checker Framework found, using default version 3.45.0

> Task :compileJava FAILED
/Users/mjk76/jsr308/sample-gradle-project/src/main/java/sample/gradle/project/App.java:16: error: [return] incompatible types in return.
        return null;
               ^
  type of expression: null (NullType)
  method return type: @Initialized @NonNull Object
1 error

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':compileJava'.
> Compilation failed; see the compiler error output for details.

* Try:
> Run with --info option to get more log output.
> Run with --scan to get full insights.

BUILD FAILED in 982ms
3 actionable tasks: 3 executed

By contrast, running the preCompile task via ./gradlew clean preCompile succeeds cleanly:

➜  sample-gradle-project git:(issue281) ✗ ./gradlew clean preCompile

> Configure project :
No explicit dependency on the Checker Framework found, using default version 3.45.0

BUILD SUCCESSFUL in 375ms
2 actionable tasks: 2 executed

And, this produces the expected .class files in build/preCompiled:

➜  sample-gradle-project git:(issue281) ✗ find build/preCompiled
build/preCompiled
build/preCompiled/sample
build/preCompiled/sample/gradle
build/preCompiled/sample/gradle/project
build/preCompiled/sample/gradle/project/Pojo.class
build/preCompiled/sample/gradle/project/App.class

[tmarback]

Hm, it is certainly odd that it isn't working for me, then! Aside from generally having more configuration going on (none of which should be affecting this plugin) and the different DSL, the only real differences that jump to mind is the different toolchain version (21 vs 17), and that I'm applying the Checker plugin in a conventions plugin (via buildSrc) rather than directly on the build script - though it would be odd for either of them to only be affecting this piece of the configuration in particular.

I'll try moving the configuration around some more to see if I can't figure out what conditions cause it to break.