-
Notifications
You must be signed in to change notification settings - Fork 757
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
Document Kotlin types shouldn’t subclass Java types and vice-versa #372
Comments
Yikes. Nope, that looks broken! |
|
Actually declaring the use-site target explicitly solves the problem: open class Parent(@property:Json(name = "xyz") var abc: String = "") but it's verbose. Maybe a Kotlin-specific version of |
The Kotlin adapter looks for the annotation on all properties (that's why The problem in this issue is that it doesn't look at the superclass's constructor parameters. |
That's correct, but it complicates the implementation, as you have to search in a lot of places to collect the annotations, while it really only makes sense to have properties annotated with @Target(AnnotationTarget.PROPERTY)
annotation class KJson(val name: String) then there would be no need to look into constructor params (haven't verified if it indeed works this way). Right now you can annotate params that don't have corresponding properties: class Foo(@Json(name = "bar") foo: String) which has no effect (or does it?), so would be great to disallow it completely to avoid confusion. |
(aside: If the parameter doesn't have a corresponding property, the factory will throw an IllegalArgumentException when trying to create an adapter.) Ah, I see what you mean. That's cool, even if more API surface area (and a bigger transition for folks migrating off Java). sorry, I went off the original issue topic. |
Good discussion! Can Moshi simultaneously be the best JSON library for Java and for Kotlin? Or does it have to pick one? |
I've thought about writing a separate toy object mapper for Kotlin. Since Kotlin's type system is like a superset of Java's, it's tough for a Java API for types to understand Kotlin callers' types. :/ |
I'm experiencing a similar issue on a specific Java/Kotlin edge case ( I have a Java model:
And an extending Kotlin model:
I'm trying to deserialize a very simple JSON object:
But it fails with the following exception:
I can't use |
@marcosalis having a Kotlin type extending a Java type or vice-versa is something we’re not expecting. Your best bet is to manually write |
Fair enough @swankjesse, thank you for your reply! |
We should document that we don’t support Kotlin subtypes of Java types and vice-versa. |
Yes. And, the original post also shows a broken behavior for Kotlin subclasses of Kotlin types. |
Added to the README. |
I'm annotating a field in a Kotlin class (using
moshi-kotlin
) with@Json(name = "xyz")
and serializing produces the expected result, but when I try to serialize a subclass the annotation from the parent class is not applied.Example:
...results in:
expected result:
Is this the intended behavior?
The text was updated successfully, but these errors were encountered: