New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Incremental compilation of java modules is broken with Gradle 7.6 #23067
Labels
a:regression
This used to work
affects-version:7.6
in:java-plugins
java-library, java, java-base, java-platform, java-test-fixtures
in:modular-java
Milestone
Comments
ljacomet
added
in:modular-java
a:regression
This used to work
in:java-plugins
java-library, java, java-base, java-platform, java-test-fixtures
and removed
a:bug
to-triage
labels
Dec 9, 2022
Reproducing the expected behaviour with Gradle 7.5.1 can be done as follows:
|
Moved to 8.0RC1, since we have to finish 8 in next weeks. But we will backport the fix to 7.6.1. |
This was referenced Dec 19, 2022
Note: If the fix still causes some issues for you, you can use in the future Gradle 8 (and in the future Gradle 7.6.1):
that should make incremental compilation behavior the same as with Gradle 7.5. |
This was referenced Jan 5, 2023
Closed
bot-gradle
added a commit
that referenced
this issue
Jan 20, 2023
…lation after a failure Changing compile output folder to a temporary folder for incremental compilation after failure causes some issues with modules (#23067) and with annotation processors (#23066). But to restore outputs we can just do (not necessarly in the given order): 1. restore stale classes and resources that were deleted 2. remove all newly generated classes and resources 3. restore any overwritten classes (this happens in practice rarely, and only on the incremental compilation, e.g. if we have `B.java` with `class B` and we don't change that file and we create `B1.java` with `class B`). We already do 1) in the current implementation, for 2) we can use Compiler API data we generate for incremental annotation processors and for "source to class name" mapping. For step 3) I implemented a [CompilationClassBackupService.java](https://github.com/gradle/gradle/pull/23226/files#diff-21d9cec673f39ed2a74d60de1b8862dd6fa18e6eea1769209e8ec9fb47b53919) that is injected in the Compiler API and backups any `.class` file during compilation. Backup is done just for "normal compilation". Annotation processors are very limited so this is not needed. They are limited in a way that If two types generate one class/resource, the annotation processor can only be aggregating, for which we always regenerate class/resources and reprocess all types with aggregating annotation. Since we track types also for Groovy compilation, the same method for restoring outputs works well also with Groovy and Groovy/Java joint compilation. --- Todo: - [x] When #23119 gets merged to master, revert changes done in [GradleStandardJavaFileManager](https://github.com/gradle/gradle/blob/5d8adb4002742924f7327db670eb8f2fffff9414/subprojects/language-java/src/main/java/org/gradle/api/internal/tasks/compile/reflect/GradleStandardJavaFileManager.java#L100-L111). Co-authored-by: Anže Sodja <asodja@gradle.com>
ijuma
pushed a commit
to apache/kafka
that referenced
this issue
Feb 24, 2023
Details: * gradle upgrade: 7.6 -> 8.0.1 * spotbugs plugin upgrade: 5.0.9 -> 5.0.13 * tweaked the mechanics for `-release`/`-source`/`-target` to workaround idiosyncrasies in Gradle 8.0.1 and newer Scala 2.13 versions. * streams-scala `test` task no longer triggers the `spotless` task since a newer version is required for Gradle 8 support, but the newer version requires Java 11. Note: relates to #5479 Gradle upgrade highlights: * "Scala Incremental Compilation for Multi-Module projects broken in 7.x": gradle/gradle#20101 * "Incremental compilation of java modules is broken with Gradle 7.6": gradle/gradle#23067 Full release notes: https://docs.gradle.org/8.0/release-notes.html Reviewers: Ismael Juma <ismael@juma.me.uk>
elasticsearchmachine
pushed a commit
to elastic/elasticsearch
that referenced
this issue
Feb 24, 2023
This updates the gradle wrapper to 7.6.1. This patch release contains a fix for incremental compilation of java modules we have raised against gradle 7.6 see gradle/gradle#23067
breskeby
added a commit
to elastic/elasticsearch
that referenced
this issue
Feb 25, 2023
This updates the gradle wrapper to 7.6.1. This patch release contains a fix for incremental compilation of java modules we have raised against gradle 7.6 see gradle/gradle#23067
breskeby
added a commit
to elastic/elasticsearch
that referenced
this issue
Feb 27, 2023
This updates the gradle wrapper to 7.6.1. This patch release contains a fix for incremental compilation of java modules we have raised against gradle 7.6 see gradle/gradle#23067
saarikabhasi
pushed a commit
to saarikabhasi/elasticsearch
that referenced
this issue
Apr 10, 2023
…ic#94122) This updates the gradle wrapper to 7.6.1. This patch release contains a fix for incremental compilation of java modules we have raised against gradle 7.6 see gradle/gradle#23067
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
a:regression
This used to work
affects-version:7.6
in:java-plugins
java-library, java, java-base, java-platform, java-test-fixtures
in:modular-java
After updating our elasticsearch build to Gradle 7.6 we are seeing weird compilation issues when using incremental compilation.
The only two workarounds are
Expected Behavior
It should not be required to run the clean task for correct java module compilation
Current Behavior
When changing the sources slightly we see java module related error messages during
compileJava
likeContext
We seen this when updating the elasticsearch build to from 7.5.1 to Gradle 7.6
Steps to Reproduce
Your Environment
Build scan URL: https://gradle.com/s/amjv2v4a4qmym
The text was updated successfully, but these errors were encountered: