-
Notifications
You must be signed in to change notification settings - Fork 175
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
@JsonProperty annoation not respected for booleans in constructor. #52
Comments
@gregschlom thanks for your solution but do you use proguard? Because I do and I encounter a problem with this special annotation while I specified the |
@otomatik no, I do not use proguard. |
Hi, I have kind of similar issue. I have custom generic
and class where it used with
and after serialization |
You really should change behavior or add example on Readme in Caveats because this thread is more than half year old and I just hit this problem. |
I'm looking at this to see if there is a way to resolve it. If not, will document workarounds. |
For reference, this class:
which has part of the values in the constructor (meaning the annotations might go on the parameter instead of the getter), and part of the values in the body (meaning the annotations might go on the field instead of the getter). generates this bytecode (summarized):
|
produces:
So the issue is that the constructor parameters are giving some fields their name This happens because Kotlin places the annotation on the first target in its priority list, and that is different for a constructor parameter than it is for a class member. So a annotation target must be applied to clarify where exactly you want it So this needs to be added to the caveats to make it clear. The only other solution would be for @cowtowncoder to let me replace JsonProperty in Java, with the same written in Kotlin, it would be compatible with the Java version, but would add the Kotlin metadata that allows the targetting of the getter to be higher in precedence than the field. The Java It could also be written in Java, but at compile time would need to add the Kotlin annotation (think that would work, doesn't need any Kotlin metadata, just need the Kotlin version of annotation targetting as well, see the Byte Code)... Roughly something like:
Which generates byte code compatible annotation, but that would act correctly for Kotlin:
|
so @cowtowncoder if you can compile annotations against Kotlin runtime, but as a compile-only dependency, you could add
and then annotations are not required to be present at runtime so SHOULD (yes?) not break anything (I think at one point in Scala it did, but not presently?). I could do a test and check all annotations in jackson annotations library and set the correct list for each, and do tests against them all. The alternative is to allow some way to plug in Kotlin specific annotations for everything that have these, and maybe that is already possible with Annotation Inspector, I haven't checked. Let me know the best way, and I'll check it out. |
I'd have to read this over a few times to make sure, but to be honest, I am not sure this would fly, and although possibly working, sounds quite fragile approach to me. There are couple of practical problems (ideally So... not saying it's not going to happen, but feeling pessimistic at this point. |
@cowtowncoder Is there a way to plugin custom annotations yet still provide the same information? So instead of reading these annotations directly, call something that collects them and returns the data they would be holding, that way you can use custom annotations as long as the module can understand them. Alternatively, but fragile is an alternative build from Kotlin of the same using same packages and have it be drop-in replacement, but one dependency random ordering or dupe classes (Java 9) would break it. |
I can do this already with: |
nope, this isn't called for all cases. close, but no. |
|
One other possibility that might work but be somewhat cumbersome could be to post-process |
Hey I hope my issue is related to this topic After turining on ProGuard it makes something strange thing related with object mapper( other classes those properties haven't
I would like to showyou stacktrace:
|
I am finding that when I use the annotated data class for both deserialization and serialization, that |
I'm not sure if I'm hitting this issue or possibly a different one? When annotating a data class's boolean parameter with Repro: https://bitbucket.org/marshallpierce/jackson-boolean-prop-name-repro/src/master/ |
@marshallpierce yep that is the issue. Try annotating it like I have in my comment, and you'll see it properly serialize/deserialize. The catch is you need to tell Kotlin where to put the @JsonProperty annotation. With the annotation in both places, serialization and deserialization works correctly. |
But why does it change based on whether or not there is an |
It's just how Jackson works. By default, if Jackson sees a property that starts with get or is, it strips that off when serializing. And it expects to deserialize the stripped field name. There's probably a way to configure the ObjectMapper to not do this, but I don't know how. |
What I'm getting at is that having the presence or absence of |
Is there any plan to resolve this in Jackson(if it can be resolved)? Or is the official answer just to use |
It works but I have problem with openapi-generator-maven-plugin that generates only @JsonProperty("isSomething") annotation |
@MaksimRT can you report an issue to that generator code to put the use-site target on it? It appears at this moment to be impossible to defeat Kotlin's choice of how it places annotations on the code it generates for properties. There is a big gap in what it does, from what we need. And no work-around above the programming adding those use-site targets. |
It will be fixed in 2.10.1 version by #256 |
Hello,
The
@JsonProperty
annotation doesn't work as expected for Boolean properties.See example below:
EDIT: It works if we use
@get:JsonProperty()
So in the example above, using
@get:JsonProperty("is_bar")
gives me the correct results.Therefore, maybe close this ticket but improve README by mentioning this?
The text was updated successfully, but these errors were encountered: