Current Behavior
We are observing cache misses in tasks like JavaCompile due to input classpath differences for the same dependency. Using the build scan comparison, the difference points to a classpath input discrepancy where specific dependencies are reported as having different contents:
Initially, we compared both JARs from different environments (CI/LOCAL) using various methods (IDE, diff, cmp), and the results consistently indicated that the files are identical. However, we are still able to reproduce this behavior even when the dependency resides in the same Gradle user home:
If we track the fingerprint of dependencies with classpath differences, such as com.squareup.okhttp3:okhttp:4.12.0, during the build by enabling org.gradle.caching.debug=true, we notice a difference in the fingerprinting:
| Work Unit |
Input |
Type |
First Build |
Second Build |
| BuildToolsApiClasspathEntrySnapshotTransform |
inputArtifact |
CLASSPATH |
92801 |
92801 |
| JavaCompile |
classpath |
COMPILE_CLASSPATH |
92801 |
5a62b |
Expected Behavior
No classpath differences for the same dependency
Context (optional)
This issue is being investigated after observing similar behavior among different users. We are providing a reproducible repository in the following section, but we have identified certain conditions necessary to reproduce the issue:
- The issue appears when one of the dependencies used in the Java compile classpath has already been downloaded from another "scope" in the project, such as through init scripts.
- The issue occurs only in projects that contain both Java and Kotlin.
Self-contained Reproducer Project
- Clone https://github.com/cdsap/ReproducerClasspathDifference
- In a clean Gradle user home cache, execute:
./gradlew clean :tasks --init-script gradle/init.gradle.kt
- Remove the project's
.gradle folder and terminate Gradle/Kotlin processes: jps | grep -E "GradleDaemon|KotlinCompileDaemon" | awk '{print $1}' | xargs -r kill
Execute ./gradlew clean :lib:assemble
- Remove the Gradle user home cache
- Remove the project's
.gradle folder and terminate Gradle Kotlin processe
- Execute
./gradlew clean :lib:assemble
- Compare
:lib:assemble scans
Gradle version
8.12
Build scan URL (optional)
https://ge.solutions-team.gradle.com/s/ambfo5kmqrxd2 and https://ge.solutions-team.gradle.com/s/nrraf4seirqrc
Your Environment (optional)
No response
Current Behavior
We are observing cache misses in tasks like
JavaCompiledue to input classpath differences for the same dependency. Using the build scan comparison, the difference points to a classpath input discrepancy where specific dependencies are reported as having different contents:Initially, we compared both JARs from different environments (CI/LOCAL) using various methods (IDE, diff, cmp), and the results consistently indicated that the files are identical. However, we are still able to reproduce this behavior even when the dependency resides in the same Gradle user home:
If we track the fingerprint of dependencies with classpath differences, such as
com.squareup.okhttp3:okhttp:4.12.0, during the build by enablingorg.gradle.caching.debug=true, we notice a difference in the fingerprinting:Expected Behavior
No classpath differences for the same dependency
Context (optional)
This issue is being investigated after observing similar behavior among different users. We are providing a reproducible repository in the following section, but we have identified certain conditions necessary to reproduce the issue:
Self-contained Reproducer Project
./gradlew clean :tasks --init-script gradle/init.gradle.kt.gradlefolder and terminate Gradle/Kotlin processes:jps | grep -E "GradleDaemon|KotlinCompileDaemon" | awk '{print $1}' | xargs -r killExecute ./gradlew clean :lib:assemble.gradlefolder and terminate Gradle Kotlin processe./gradlew clean :lib:assemble:lib:assemblescansGradle version
8.12
Build scan URL (optional)
https://ge.solutions-team.gradle.com/s/ambfo5kmqrxd2 and https://ge.solutions-team.gradle.com/s/nrraf4seirqrc
Your Environment (optional)
No response