Incompatible with kotlinx-metadata 0.6.0 #3701
Comments
|
They are looking to stabilize this library fwiw, and these API changes are a part of that effort. From the kotlin-lang Slack message:
|
|
Yup - We are aware of the breaking changes, I'm working on updating xprocessing which then will help Dagger (and Room) avoid the incompatibility. Thanks! |
|
xprocessing was updated in Dagger (44b876d) fixing this issue. |
|
Hello, Caused by: java.lang.NoSuchMethodError: 'kotlinx.metadata.jvm.KotlinClassMetadata kotlinx.metadata.jvm.KotlinClassMetadata$Companion.read(kotlinx.metadata.jvm.KotlinClassHeader)' I am using Android Studio: Android Studio Flamingo | 2022.2.1 Am i missing something? Full stack trace Thanks |
|
It's fixed on the main branch but not yet released |
|
Thanks for the quick response. Do you have any idea when it will be in release? Or do we have another(snapshot) build where the fix is present? |
|
There are snapshots available and detailed on the dagger docs site or README. I don't know when it's going to be released, I don't work on dagger. It's generally considered poor taste to ask in OSS projects for release ETAs. |
|
@witmitchell this should now be fixed in Dagger 2.46 |
|
Version 2.46 does not fix this problem |
|
Still facing this problem; issue is not fixed in v2.46 release. |
|
same bug with v2.46 |
|
I upgraded today and getting this error on v2.46 |
|
Same bug on v2.46 |
|
For those who are still experiencing the problem, are you also using Room? If so which version? Can you also confirm that the stacktrace contains |
|
That's right, Room is present in the stacktrace. This is with most recent stable Room release 2.5.1, and the error appears only after updating Dagger to 2.46 Caused by: com.sun.tools.javac.processing.AnnotationProcessingError: java.lang.NoSuchMethodError: 'kotlinx.metadata.jvm.KotlinClassMetadata kotlinx.metadata.jvm.KotlinClassMetadata$Companion.read(kotlin.Metadata)'
at jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment.callProcessor(JavacProcessingEnvironment.java:1035)
at jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment.discoverAndRunProcs(JavacProcessingEnvironment.java:939)
at jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.run(JavacProcessingEnvironment.java:1267)
at jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessing(JavacProcessingEnvironment.java:1382)
at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:1234)
... 33 more
Caused by: java.lang.NoSuchMethodError: 'kotlinx.metadata.jvm.KotlinClassMetadata kotlinx.metadata.jvm.KotlinClassMetadata$Companion.read(kotlin.Metadata)'
at dagger.spi.shaded.androidx.room.compiler.processing.javac.kotlin.KmClassContainer$Companion.createFor(KotlinClassMetadataUtils.kt:161)
at dagger.spi.shaded.androidx.room.compiler.processing.javac.JavacTypeElement$kotlinMetadata$2.invoke(JavacTypeElement.kt:57)
at dagger.spi.shaded.androidx.room.compiler.processing.javac.JavacTypeElement$kotlinMetadata$2.invoke(JavacTypeElement.kt:56)
at kotlin.SynchronizedLazyImpl.getValue(LazyJVM.kt:74)
at dagger.spi.shaded.androidx.room.compiler.processing.javac.JavacTypeElement.getKotlinMetadata(JavacTypeElement.kt:56)
at dagger.spi.shaded.androidx.room.compiler.processing.javac.JavacMethodElement$kotlinMetadata$2.invoke(JavacMethodElement.kt:75)
at dagger.spi.shaded.androidx.room.compiler.processing.javac.JavacMethodElement$kotlinMetadata$2.invoke(JavacMethodElement.kt:74)
at kotlin.SynchronizedLazyImpl.getValue(LazyJVM.kt:74)
at dagger.spi.shaded.androidx.room.compiler.processing.javac.JavacMethodElement.getKotlinMetadata(JavacMethodElement.kt:74)
at dagger.spi.shaded.androidx.room.compiler.processing.javac.JavacMethodElement.isSuspendFunction(JavacMethodElement.kt:117)
at dagger.spi.shaded.androidx.room.compiler.processing.javac.JavacMethodElement$returnType$2.invoke(JavacMethodElement.kt:89)
at dagger.spi.shaded.androidx.room.compiler.processing.javac.JavacMethodElement$returnType$2.invoke(JavacMethodElement.kt:86)
at kotlin.SynchronizedLazyImpl.getValue(LazyJVM.kt:74)
at dagger.spi.shaded.androidx.room.compiler.processing.javac.JavacMethodElement.getReturnType(JavacMethodElement.kt:86)
at dagger.spi.shaded.androidx.room.compiler.processing.javac.JavacMethodElement.getReturnType(JavacMethodElement.kt:34)
at dagger.spi.shaded.androidx.room.compiler.processing.javac.JavacAnnotationValue.<init>(JavacAnnotationValue.kt:38)
at dagger.spi.shaded.androidx.room.compiler.processing.compat.XConverters.toXProcessing(XConverters.kt:150)
at dagger.internal.codegen.base.DaggerSuperficialValidation.lambda$getDefaultValues$6(DaggerSuperficialValidation.java:408)
at dagger.internal.codegen.base.DaggerSuperficialValidation.getDefaultValues(DaggerSuperficialValidation.java:409)
at dagger.internal.codegen.base.DaggerSuperficialValidation.validateAnnotation(DaggerSuperficialValidation.java:395)
at dagger.internal.codegen.base.DaggerSuperficialValidation.validateAnnotations(DaggerSuperficialValidation.java:389)
at dagger.internal.codegen.base.DaggerSuperficialValidation.validateAnnotationsOf(DaggerSuperficialValidation.java:208)
at dagger.internal.codegen.base.DaggerSuperficialValidation.validateElement(DaggerSuperficialValidation.java:263)
at dagger.internal.codegen.processingstep.SuperficialValidator.validationExceptionsUncached(SuperficialValidator.java:58)
at dagger.internal.codegen.processingstep.SuperficialValidator.throwIfNearestEnclosingTypeNotValid(SuperficialValidator.java:47)
at dagger.internal.codegen.processingstep.TypeCheckingProcessingStep.lambda$process$0(TypeCheckingProcessingStep.java:80)
at com.google.common.collect.SingletonImmutableBiMap.forEach(SingletonImmutableBiMap.java:68)
at dagger.internal.codegen.processingstep.TypeCheckingProcessingStep.process(TypeCheckingProcessingStep.java:70)
at dagger.internal.codegen.processingstep.TypeCheckingProcessingStep.process(TypeCheckingProcessingStep.java:48)
at dagger.spi.shaded.androidx.room.compiler.processing.XProcessingStep.process(XProcessingStep.kt:59)
at dagger.spi.shaded.androidx.room.compiler.processing.CommonProcessorDelegate.processRound(XBasicAnnotationProcessor.kt:125)
at dagger.spi.shaded.androidx.room.compiler.processing.javac.JavacBasicAnnotationProcessor.process(JavacBasicAnnotationProcessor.kt:71)
at org.jetbrains.kotlin.kapt3.base.incremental.IncrementalProcessor.process(incrementalProcessors.kt:90)
at org.jetbrains.kotlin.kapt3.base.ProcessorWrapper.process(annotationProcessing.kt:197)
at jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment.callProcessor(JavacProcessingEnvironment.java:1023)
... 37 more |
|
Same issue, not using room. But room is mentioned in the stacktrace: |
|
Its as if something is pinning Can you try forcing the usage of 0.6.0 by explicitly declaring it in your dependencies, for example It would also be good to check the projects dependency tree to verify the right Lastly if there is a repro project we can try, that would be amazing, since our Gradle integration projects in https://github.com/google/dagger/tree/master/javatests/artifacts didn't reproduce this. |
|
We see a slightly different issue when forcing metadata 0.6.0 It does appear to finish the build successfully, but the above warnings are new and seem concerning |
|
Bare bones repro app (if you downgrade the dagger dependency to 2.45 it works): |
|
@ZacSweers: The warning is coming from here when a metadata for a synthetic class is found. It is probably harmless but I can see the warning being annoying... Even though these classes rarely show up in the AST they can appear in Kotlin, see this comment for example: #2379 (comment). I think this is a bit of a regression, Dagger used to error out when a synthetic class metadata was found, that was later fixed (relaxing the check) but recently Dagger switched to using xprocessing for metadata and that logic had a warning, hence its back in warning form. @almeric Thank you sooo much for the repro. I am a bit baffled as to what is going on but I was able to pin-point the issue to Kotlin's new-ish The project will build and right kotlinx-metadata-jvm will be in the classpath. Alternative, upgrading the toolchain version to 18 (only tried that version) also worked for me, so there is some classpath shenanigans occurring when configuring Kotlin's JDK via the For others who are using Room 2.5.1 with Dagger / Hilt 2.46 then the issue is that Dagger / Hilt upgrades kotlinx-metadata-jvm to a version incompatible with Room 2.5.1 and instead Room 2.6.0-alpha01 or higher needs to be used. |
|
Great find @danysantiago! Thanks a bunch for the detailed analysis! |
|
Thanks @danysantiago the: For others who are using Room 2.5.1 with Dagger / Hilt 2.46 then the issue is that Dagger / Hilt upgrades kotlinx-metadata-jvm to a version incompatible with Room 2.5.1 and instead Room 2.6.0-alpha01 or higher needs to be used. fixed it for me. |
This was referenced May 4, 2023
|
Upgrade room to alpha is not a solution for me and not fix this, declaring impl of metadata no work, downgrade hilt or invalidate cache, no work, only a rollback from agp 8 to 7 and kotlin to 1.8.10 makes the app compile |
|
2.46 not fixed the issue, please reopen the ticket |
|
I'm still having this same error with:
If I remove |
|
We'll revisit this, we are going to probably shade / jarjar kotlinx-metadata-jvm while Jetbrains stabilizes the APIs and it would avoid issues with other libraries using it since its a transitive dependency for Dagger / Hilt. |
copybara-service bot
pushed a commit
that referenced
this issue
May 9, 2023
RELNOTES=Fixes #3701: Shade kotlinx metadata in Dagger's artifacts. PiperOrigin-RevId: 530726420
copybara-service bot
pushed a commit
that referenced
this issue
May 10, 2023
This CL also removes an extra version of auto-common that we jarjared and shaded into the Hilt compiler artifacts. In particular, since Hilt's compiler artifacts depend transitively on the dagger-spi artifact, we can shade our auto-common references to use the version of auto-common shaded into dagger-spi instead of creating another version of the shaded classes in the hilt compiler artifacts. I've also updated the `gen_maven_artifact` macro to exclude are shaded dependencies from the `artifact_target_maven_deps` since that list is supposed to mimic our pom file dependencies. RELNOTES=Fixes #3701: Shade kotlinx metadata in Dagger's artifacts. PiperOrigin-RevId: 530726420
copybara-service bot
pushed a commit
that referenced
this issue
May 10, 2023
This CL also removes an extra version of auto-common that we jarjared and shaded into the Hilt compiler artifacts. In particular, since Hilt's compiler artifacts depend transitively on the dagger-spi artifact, we can shade our auto-common references to use the version of auto-common shaded into dagger-spi instead of creating another version of the shaded classes in the hilt compiler artifacts. I've also updated the `gen_maven_artifact` macro to exclude are shaded dependencies from the `artifact_target_maven_deps` since that list is supposed to mimic our pom file dependencies. RELNOTES=Fixes #3701: Shade kotlinx metadata in Dagger's artifacts. PiperOrigin-RevId: 530726420
copybara-service bot
pushed a commit
that referenced
this issue
May 10, 2023
This CL also removes an extra version of auto-common that we jarjared and shaded into the Hilt compiler artifacts. In particular, since Hilt's compiler artifacts depend transitively on the dagger-spi artifact, we can shade our auto-common references to use the version of auto-common shaded into dagger-spi instead of creating another version of the shaded classes in the hilt compiler artifacts. I've also updated the `gen_maven_artifact` macro to exclude are shaded dependencies from the `artifact_target_maven_deps` since that list is supposed to mimic our pom file dependencies. RELNOTES=Fixes #3701: Shade kotlinx metadata in Dagger's artifacts. PiperOrigin-RevId: 530726420
copybara-service bot
pushed a commit
that referenced
this issue
May 10, 2023
This CL also removes an extra version of auto-common that we jarjared and shaded into the Hilt compiler artifacts. In particular, since Hilt's compiler artifacts depend transitively on the dagger-spi artifact, we can shade our auto-common references to use the version of auto-common shaded into dagger-spi instead of creating another version of the shaded classes in the hilt compiler artifacts. I've also updated the `gen_maven_artifact` macro to exclude are shaded dependencies from the `artifact_target_maven_deps` since that list is supposed to mimic our pom file dependencies. RELNOTES=Fixes #3701: Shade kotlinx metadata in Dagger's artifacts. PiperOrigin-RevId: 530726420
copybara-service bot
pushed a commit
that referenced
this issue
May 10, 2023
This CL also removes an extra version of auto-common that we jarjared and shaded into the Hilt compiler artifacts. In particular, since Hilt's compiler artifacts depend transitively on the dagger-spi artifact, we can shade our auto-common references to use the version of auto-common shaded into dagger-spi instead of creating another version of the shaded classes in the hilt compiler artifacts. I've also updated the `gen_maven_artifact` macro to exclude are shaded dependencies from the `artifact_target_maven_deps` since that list is supposed to mimic our pom file dependencies. RELNOTES=Fixes #3701: Shade kotlinx metadata in Dagger's artifacts. PiperOrigin-RevId: 530726420
copybara-service bot
pushed a commit
that referenced
this issue
May 10, 2023
This CL also removes an extra version of auto-common that we jarjared and shaded into the Hilt compiler artifacts. In particular, since Hilt's compiler artifacts depend transitively on the dagger-spi artifact, we can shade our auto-common references to use the version of auto-common shaded into dagger-spi instead of creating another version of the shaded classes in the hilt compiler artifacts. I've also updated the `gen_maven_artifact` macro to exclude are shaded dependencies from the `artifact_target_maven_deps` since that list is supposed to mimic our pom file dependencies. RELNOTES=Fixes #3701: Shade kotlinx metadata in Dagger's artifacts. PiperOrigin-RevId: 530726420
copybara-service bot
pushed a commit
that referenced
this issue
May 10, 2023
This CL also removes an extra version of auto-common that we jarjared and shaded into the Hilt compiler artifacts. In particular, since Hilt's compiler artifacts depend transitively on the dagger-spi artifact, we can shade our auto-common references to use the version of auto-common shaded into dagger-spi instead of creating another version of the shaded classes in the hilt compiler artifacts. I've also updated the `gen_maven_artifact` macro to exclude are shaded dependencies from the `artifact_target_maven_deps` since that list is supposed to mimic our pom file dependencies. RELNOTES=Fixes #3701: Shade kotlinx metadata in Dagger's artifacts. PiperOrigin-RevId: 530726420
|
What is the solution or this? I have tried the suggestions mentioned above but nothing worked. Please can you suggest the right solution for this? |
|
@Bhuvanaarkala07 we have shaded the dependency within Dagger, which should solve this issue, but it's currently only available in the snapshot. I plan to do an official release (v2.46.1) later today. |
|
@bcorso - Is the release done today? |
|
No, it will be available in https://github.com/google/dagger/releases once it's done. |
|
@Bhuvanaarkala07 Okay, it should be released now https://github.com/google/dagger/releases/tag/dagger-2.46.1. Let us know if you're still running into issues. |
|
@bcorso - Still Iam facing same issue, after updating the dagger version to latest. These are the versions I am using, |
|
Hmm, I've checked the class files for Dagger 2.46.1 and they look like they're correctly pointing to the shaded deps now. @Bhuvanaarkala07, can you post the exact error message you are seeing? My guess is that it may be from a different library other than Dagger, e.g. Room is also shading the kotlinx-jvm dependency for the same reason so you may need to update that as well. |
Thanks, that fixed the issue for me. |
|
If you are using Hilt, update it to 2.46.1 and it will work. |
mateuszkwiecinski
added a commit
to mateuszkwiecinski/lottie-android
that referenced
this issue
May 20, 2023
mateuszkwiecinski
added a commit
to mateuszkwiecinski/lottie-android
that referenced
this issue
May 20, 2023
mateuszkwiecinski
added a commit
to mateuszkwiecinski/lottie-android
that referenced
this issue
May 20, 2023
mateuszkwiecinski
added a commit
to mateuszkwiecinski/lottie-android
that referenced
this issue
May 20, 2023
mateuszkwiecinski
added a commit
to mateuszkwiecinski/lottie-android
that referenced
this issue
May 20, 2023
mateuszkwiecinski
added a commit
to mateuszkwiecinski/lottie-android
that referenced
this issue
Jun 13, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
kotlinx metadata 0.6.0 was released yesterday with a number of breaking API changes. It looks like Dagger doesn't currently shade this dependency, so this update breaks dagger/xprocessing internally when it runs.
Repro: ZacSweers/CatchUp#402 (run
./gradlew :app:assembleDebug --stacktrace)The text was updated successfully, but these errors were encountered: