Unexpected serialization of "internal" properties

[enerdgumen]

A property with "internal" visibility is serialized with the unexpected "$backend" suffix, i.e.:

open class Identifiable {
    internal var identity: Long? = null
}

is serialized as:

{"identity$backend": null}

[enerdgumen]

Similarly, if you want ignore such properties, you must include the "$backend" suffix in the property name:

@JsonIgnoreProperties("identity\$backend")

[apatrida]

The Kotlin module is not involved in property selection, and the Java code doesn't know about internal properties. @cowtowncoder is there a way for a module to imply JsonIgnore for some properties?

[cowtowncoder]

@apatrida Nothing specific comes to mind, although perhaps overriding methods in AnnotationIntrospector could work. Specifically findNameForDeserialization and findNameForSerialization could block auto-inclusion by returning null if internal modifier is detected (or, if not, perhaps there is naming convention to use).
This would have the benefit of being overridable by explicit annotations, should user actually want to include.
Or, perhaps overriding hasIgnoreMarker() to return true with similar logic.

[apatrida]

Ok, I can take a look at it, but likely i would want this to be a feature switch, because I'm not sure if internal should always mean 'exclude' .... does package local in Java get excluded @cowtowncoder ?

[cowtowncoder]

@apatrida Package local inclusion depends on both per-accessor minimum levels (only public getters and fields are auto-discovered; but all levels of setters), and association by naming (meaning that public getter/setter can "pull in" similarly named non-public field).

So while non-public fields are not auto-discovered, by default, they may be included if there is matching public accessors, for purpose of setting value.

[MikeRippon]

(Note for other people that struggle to find this on google :))
@JsonIgnore also does not work with internal properties for this same reason. A workaround is to declare property as public.

[jrgonzalezg]

To define the serialized name for the internal property to something else you can use @field:JsonProperty("name") so the annotation is applied to the field overriding the name$module default. Also @field:JsonIgnore probably works for ignoring it.

[jrgonzalezg]

For more information: https://kotlinlang.org/docs/reference/annotations.html#annotation-use-site-targets

[jillesvangurp]

@jrgonzalezg also ran into this. Your suggestion nearly works except I had to use @get:JsonIgnore to make it stop serializing my internal property. I'm guessing jackson looks explicitly at the getters rather than the field itself.

[jrgonzalezg]

I wrote previous comment without being in front of a computer, so didn't check the details.

There is no single solution cause it depends on actual usage and on the class and the targets generated. For immutable data classes for instance I am using now both @get:JsonProperty and @param:JsonProperty for each field. @get applies to the getter and it is used when the class needs to be serialized to retrieve the value of the field and the name to use on the written json. And @param annotation applies to the data class constructor parameter and it is used on deserialization to pass the deserialized field value on that position when creating an instance of the data class. That leads to consistent bidirectional serialization working for immutable data classes.

But for other custom classes you may need to specify something else like a @set and there may be cases (or other libraries) were you may need @field or where @field or @param are not possible cause those targets are not available, so there is no single recipe.

[apatrida]

The workaround from @jrgonzalezg is the only option currently.

[apatrida]

Now that I wrote that, it would be possible to un-mangle names like this if needed. Maybe, I would have to think about it and the patterns. It would be fragile because we would be coding to internal naming conventions that could change with ABI versions in the future.

[apatrida]

For example, now the generated naming is:

{"identity$jackson_module_kotlin":null}

[korda]

I recently run into this problem and it turned out that someone has removed some lines of code that I didn't even remember why I have written, but apparently this helps with some problems we had with Koltlin and Jackson and indeed it "fixes" this issue too.

This is objectMapper configuration we use that "fixes" this issue (that is, no more annoying suffixes for your data classes):

			objectMapper.setVisibility(ObjectMapper().getSerializationConfig().getDefaultVisibilityChecker()
				.withFieldVisibility(JsonAutoDetect.Visibility.ANY)
				.withGetterVisibility(JsonAutoDetect.Visibility.NONE)
				.withIsGetterVisibility(JsonAutoDetect.Visibility.NONE)
				.withSetterVisibility(JsonAutoDetect.Visibility.NONE)
				.withCreatorVisibility(JsonAutoDetect.Visibility.NONE)
			)

(obv, it has bigger effect than that and it may break some other stuff since it affects how properties are handled)

[cowtowncoder]

@Spikhalskiy here's an older issue that I had forgotten about that'd be good to tackle. Not sure if improvements into name-mangling configurability would help Kotlin module automatically remove this odd suffix.

[k163377]

Memo :
This problem is caused by the getter name of the internal property generated by Kotlin being different from how it looks on Kotlin.

internal class A {
    internal var number: Int? = null
}

// decompiled
public final class A {
   @Nullable
   private Integer number;

   @Nullable
   public final Integer getNumber$jackson_module_kotlin() {
      return this.number;
   }

   public final void setNumber$jackson_module_kotlin(@Nullable Integer var1) {
      this.number = var1;
   }
}

It could be fixed by modifying KNAI.findImplicitPropertyName and truncating after the $.
However, this method will cause the same problem as #434.

Personally, I would solve this problem by implementing #630.

[k163377]

The issue of property names in the serialization result differing from the definition in Kotlin will be addressed in #630.
This issue be closed as a duplicate.