Skip to content
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

Issue #356 Demangling kotlin getter #383

Merged
merged 7 commits into from
Dec 1, 2020
Merged

Conversation

dinomite
Copy link
Member

@dinomite dinomite commented Oct 13, 2020

Fixes issue found in #356, serialization of inline classes, using @elektro-wolle's contribution.

@dinomite dinomite marked this pull request as ready for review October 13, 2020 19:57
@dinomite dinomite mentioned this pull request Oct 13, 2020
@dinomite
Copy link
Member Author

@cowtowncoder Are there performance considerations around this or tests I should run in that respect?

@dinomite dinomite added 2.12 bug cla-needed PR looks good (although may also require code review), but CLA needed from submitter labels Oct 13, 2020
* resolve the name of the property, if not given otherwise.
*/
override fun findNameForSerialization(annotated: Annotated?): PropertyName? {
if (annotated is AnnotatedMethod) {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Might want to add:

a.declaringClass.methods.any { it.name == "box-impl" }

to ensure that this is an inline class. Or declaredMethods. I always forget which is which.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, I don't see any methods with box-impl. The documentation on name mangling doesn't mention that name, but an earlier KEEP does. Do we need another unit test to show this behavior?

@cowtowncoder
Copy link
Member

One problem with this approach: findNameForSerialization() should ONLY be used if there is explicit annotation (like @JsonProperty) as it will force name -- so override here could prevent use of explicit annotations.

This could be resolved by instead overriding findImplicitPropertyName() which is intended for name mangling of "implicit" name (one derived from accessors).

But it might be even better to use 2.12 introduced AccessorNamingStrategy, added via:

FasterXML/jackson-databind#2800

as this would open up much more efficient handling of all aspects of naming for a class -- a strategy instance is created (via .Provider) for given AnnotatedClass and can do pre-processing for a set of names (or at least hold on to a preference).

But perhaps the simplest way for now would be overriding findImplicitPropertyName(), and maybe considering bigger rewrite for 2.13.

@dinomite
Copy link
Member Author

@cowtowncoder Moved the checking to findImplicitPropertyName() and filed an issue for using AccessorNamingStrategy in the future (slated for 2.13.0 right now…hopefully I'll have enough knowledge to do it at that point).

@dinomite
Copy link
Member Author

@elektro-wolle Would you sign the CLA for Jackson and email a scan/photo of the result to info at fasterxml dot com?

https://github.com/FasterXML/jackson/blob/master/contributor-agreement.pdf

@dinomite dinomite added this to the 2.12.0 milestone Oct 20, 2020
@cowtowncoder
Copy link
Member

@dinomite That sounds like a good approach to me.

@elektro-wolle
Copy link
Contributor

@dinomite

@elektro-wolle Would you sign the CLA for Jackson and email a scan/photo of the result to info at fasterxml dot com?

https://github.com/FasterXML/jackson/blob/master/contributor-agreement.pdf

Unfortunately, your gmail settings rejects the mail from my mailserver to your mail-address: rejected due to spam classification. The owner of the group can choose to enable message moderation instead of bouncing these emails. More information can be found here: https://support.google.com/a/answer/168383.

@dinomite
Copy link
Member Author

dinomite commented Oct 21, 2020

Hmm, maybe there is something @cowtowncoder, but you can also just send it to me (drew@[my github username].net) and I'll get it on to Tatu.

@efenderbosch
Copy link

Looks like this didn't make it in to 2.12? Just tried updating our Kotlin 1.4 branch to 2.12 and the getters are still mangled.

@dinomite
Copy link
Member Author

dinomite commented Dec 1, 2020

@efenderbosch Yes, I still need a CLA from @elektro-wolle

@dinomite dinomite modified the milestones: 2.12.0, 2.12.1 Dec 1, 2020
@elektro-wolle
Copy link
Contributor

@dinomite I've just resent the CLA to your address.

@dinomite
Copy link
Member Author

dinomite commented Dec 1, 2020

Got the CLA and forwarded to Tatu. I'll get this merged today.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug cla-needed PR looks good (although may also require code review), but CLA needed from submitter
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants