It worked in v1.9.1, just upgrading to v1.9.2 broke the compilation, gives this error:
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':app:kaptDebugUnitTestKotlin'.
> A failure occurred while executing org.jetbrains.kotlin.gradle.internal.KaptExecution
> java.lang.reflect.InvocationTargetException (no error message)
This is the class located in test folder:
@JsonClass(generateAdapter = true)
data class DataFloatDouble(
@Json(name = "float_value")
val floatValue: Float,
@Json(name = "double_value")
val doubleValue: Double
)
and it fails also when it is global.
In app/build.gradle this has to be:
kaptTest "com.squareup.moshi:moshi-kotlin-codegen:1.9.2"
otherwise the adapter isn't generated.
Here's the part of stack trace where moshi appears:
Caused by: java.lang.StackOverflowError
at kotlin.reflect.jvm.internal.pcollections.IntTree.get(IntTree.java:93)
at kotlin.reflect.jvm.internal.pcollections.IntTree.get(IntTree.java:91)
at kotlin.reflect.jvm.internal.pcollections.IntTree.get(IntTree.java:91)
at kotlin.reflect.jvm.internal.pcollections.IntTreePMap.get(IntTreePMap.java:42)
at kotlin.reflect.jvm.internal.pcollections.HashPMap.getEntries(HashPMap.java:85)
at kotlin.reflect.jvm.internal.pcollections.HashPMap.get(HashPMap.java:51)
at kotlin.reflect.jvm.internal.KClassCacheKt.getOrCreateKotlinClass(kClassCache.kt:32)
at kotlin.reflect.jvm.internal.ReflectionFactoryImpl.getOrCreateKotlinClass(ReflectionFactoryImpl.java:50)
at kotlin.jvm.internal.Reflection.getOrCreateKotlinClass(Reflection.java:54)
at com.squareup.moshi.kotlin.codegen.api.KotlintypesKt.stripTypeVarVariance(kotlintypes.kt:155)
at com.squareup.moshi.kotlin.codegen.api.KotlintypesKt$stripTypeVarVariance$1$1$1.invoke(kotlintypes.kt:144)
at com.squareup.moshi.kotlin.codegen.api.KotlintypesKt$stripTypeVarVariance$1$1$1.invoke(kotlintypes.kt)
at com.squareup.moshi.kotlin.codegen.api.KotlintypesKt.mapTypes(kotlintypes.kt:110)
at com.squareup.moshi.kotlin.codegen.api.KotlintypesKt.mapTypes(kotlintypes.kt:115)
at com.squareup.moshi.kotlin.codegen.api.KotlintypesKt$stripTypeVarVariance$1.invoke(kotlintypes.kt:150)
at com.squareup.moshi.kotlin.codegen.api.KotlintypesKt$stripTypeVarVariance$1.invoke(kotlintypes.kt)
at com.squareup.moshi.kotlin.codegen.api.KotlintypesKt.mapTypes(kotlintypes.kt:110)
at com.squareup.moshi.kotlin.codegen.api.KotlintypesKt.stripTypeVarVariance(kotlintypes.kt:155)
...
This looks like a bug in the kotlin stdlib, please file on kotlin鈥檚 issue tracker
I didn't change the version of Kotlin Stdlib, I only changed the version of moshi-kotlin-codegen that caused the compilation to break. The stack trace shows that the code in com.squareup.moshi.kotlin.codegen.api calls itself in an endless loop leading to StackOverflowError. I only pasted very small piece of the whole stack trace that repeats, have a look at these 2 enclosing lines (that's the repeated line so it didn't make sense to paste more):
at com.squareup.moshi.kotlin.codegen.api.KotlintypesKt.stripTypeVarVariance(kotlintypes.kt:155)
and what's between them.
I think you drew your conclusions too quickly by just looking at the top of the stack trace.
If you'd like I can try it with different versions of Kotlin Stdlib (I'm on version org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.3.61), I can provide more information. As long as I want to use com.squareup.moshi.kotlin.codegen.api in my unit tests, it means I have to stay on the older version where it still builds.
@ZacSweers Can you please stop promoting silence? https://github.com/ZacSweers/CatchUp/issues/193 These are the only threads that come up in google and it's not very professional.
I recently added a moshi dependency to a project when merging code from 2 different projects. When I compile from Android Studio it works fine but from the terminal it fails with this exception.
Tried the below variances and it ended up working with gradle 5.6.4 & Java 8. Had to delete ~/.gradle, project .gradle, and clean build. I've been having so many issues with gradle 6.3 I'm gonna just try to stick to stable gradle & java for a while..
Kotlin 1.3.72
Gradle 6.3 and 5.6.4
Java 8, 13, & 11
Hi.
https://github.com/ZacSweers/CatchUp/issues/193 is unrelated to this issue. It was originally a kapt caching issue on an older version of kotlin + warnings about moshi not being incremental. The caching issue was fixed in Kotlin 1.3.70, and Moshi has supported incremental annotation processing since its 1.9.0 release.
For _this_ issue, let's try to break it down and be as detailed as possible.
I didn't change the version of Kotlin Stdlib, I only changed the version of moshi-kotlin-codegen
That doesn't rule out an issue with the stdlib or kotlin-reflect, Moshi hits different APIs between releases. This code path _is_ new between 1.9.1 and 1.9.2, as it was added in 1.9.2 to fix a type variance issue: https://github.com/square/moshi/pull/1010.
After a quick bit of investigation and futzing the line numbers to what they would have been in the 1.9.2 release (i.e. not current master), this specific issue originates from this line: https://github.com/square/moshi/blob/0c85eae34af00ecbee46beaa5b25fb4af00fb9f2/kotlin/codegen/src/main/java/com/squareup/moshi/kotlin/codegen/api/kotlintypes.kt#L147
The stacktrace here shows an attempt to look up a KClass
at kotlin.reflect.jvm.internal.KClassCacheKt.getOrCreateKotlinClass(kClassCache.kt:32)
at kotlin.reflect.jvm.internal.ReflectionFactoryImpl.getOrCreateKotlinClass(ReflectionFactoryImpl.java:50)
at kotlin.jvm.internal.Reflection.getOrCreateKotlinClass(Reflection.java:54)
Which would suggest it's specifically originating from this call:
it.mapTypes(TypeVariableName::stripTypeVarVariance)
when it tries to look up the corresponding KClass<TypeVariableName>. Just a guess though, as this is a kotlinc intrinsic. There's no actual code here or in KotlinPoet directly calling kotlin.jvm.internal.Reflection.getOrCreateKotlinClass(Reflection.java:54) in source.
TypeVariableName::stripTypeVarVariance is totally legal Kotlin code. The stacktrace from that point onward falls into an infinite loop somewhere in Kotlin's reflection code
Caused by: java.lang.StackOverflowError
at kotlin.reflect.jvm.internal.pcollections.IntTree.get(IntTree.java:93)
at kotlin.reflect.jvm.internal.pcollections.IntTree.get(IntTree.java:91)
at kotlin.reflect.jvm.internal.pcollections.IntTree.get(IntTree.java:91)
at kotlin.reflect.jvm.internal.pcollections.IntTreePMap.get(IntTreePMap.java:42)
at kotlin.reflect.jvm.internal.pcollections.HashPMap.getEntries(HashPMap.java:85)
at kotlin.reflect.jvm.internal.pcollections.HashPMap.get(HashPMap.java:51)
So, as mentioned - this is an issue on the Kotlin side. Moshi and KotlinPoet are using standard APIs here and it's entirely possible the combination of this and OP's codebase causes it to hit some sort of weird edge case!
If a bug's filed, that would allow the Kotlin maintainers over at Jetbrain to chime in. We can also look at trying to work around it (such as using a lambda rather than a reference there, etc), and folks are welcome to PR that if they can verify it works around the issue for them. That would be good context to link in a filed issue on Youtrack as well for both the Jetbrains folks and any other users that hit a similar StackOverflow error in their own projects.
This problem got fixed with Moshi v1.11.0 so I suppose it was related to
https://github.com/square/moshi/blob/master/CHANGELOG.md#version-1110
Fix: Don't crash with a
StackOverflowErrordecoding backward-referencing type variables in Kotlin. This caused problems for parameterized types likeMyInterface<E : Enum<E>>
I don't see how that would be related as that fix was in code gen and your issue was in kotlin reflect
Kotlin reflect? Nope, the title of this issue starts with "moshi-kotlin-codegen ..." :) That's a "code gen", right?
The comments above were stacktraces from kotlin reflect code so I think this issue is getting some wires crossed. In any case, good to hear your issue is resolved and we can conclude this thread 馃憤
I got the same problem with the same error, the class I wanted the adapter to be generated for had a delegated property, i got it fixed by removing the delegation.
Most helpful comment
I didn't change the version of Kotlin Stdlib, I only changed the version of moshi-kotlin-codegen that caused the compilation to break. The stack trace shows that the code in
com.squareup.moshi.kotlin.codegen.apicalls itself in an endless loop leading toStackOverflowError. I only pasted very small piece of the whole stack trace that repeats, have a look at these 2 enclosing lines (that's the repeated line so it didn't make sense to paste more):and what's between them.
I think you drew your conclusions too quickly by just looking at the top of the stack trace.
If you'd like I can try it with different versions of Kotlin Stdlib (I'm on version
org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.3.61), I can provide more information. As long as I want to usecom.squareup.moshi.kotlin.codegen.apiin my unit tests, it means I have to stay on the older version where it still builds.