Handling wrapped collections without intermediate objects

[mglunafh]

Hi, recently I had to deal with the JSON objects which treated lists in a special way:

{
  "name": "George",
  "surname": "Smith",
  "nicknames": {
    "Nickname": [ "Al-Dente", "Roundhead", "Whiskers" ]
  },
  "kids": {
    "Child": [
      {"name":  "Kate", "birthday": "2015-01-01"},
      {"name": "Lucy", "birthday": "2018-08-08"}
    ]
  },
  "cars": {
    "Car": [
      { "id": "12323456", "brand": "Toyota" },
      {"id":  "12314243512245", "Brand": "Hyundai"}
    ]
  }
}

Properties representing collections had an additional indirection level:

• "nicknames"->"Nickname"->[....] ,
• "kids" -> "Child"-> [...] ,
• "cars" -> "Car -> [...]

After poking around a bit I decided to settle with intermediate objects in my Java model representation as well:

class Person {
    String name;
    String surname;
    Nicknames nicknames;   
    Kids kids;        

    static class Nicknames {
        @JsonProperty("Nickname")
        List<String> nicknames;
    }

    static class Kids {
        @JsonProperty("Child")
        List<Child> kids;
    }

    static class Child {
        String name;
        String birthday;
    }
}

However, my question is: how to manage to represent such JSON i.e. implement serialization-deserialization having a model with the collection properties directly in it?

class NicePersonModel {
    String name;
    String surname;
    List<String> nicknames;
    List<Child> kids;

    static class Child {
        String name;
        String birthday;
    }
}

1. Some custom annotation @WrappedCollection(inner = "Inner", outer = "outer") at first glance would look sexy, but I have no idea how to even start tackling the implementation so I would definitely ask some guidace on it :)
2. @JsonUnwrapped handles only deserialization part, unfortunately;
3. @JsonRootName could only be used on top of classes, but in my case I have lots of generic lists.

[cowtowncoder]

I wish developers did not add such useless, pointless wrapping. :)

Other than that I have tried to limit amount of structural changes Jackson does to sort of minimum... because doing those is fundamentally difficult (or impossible) in incremental/streaming way.

But I guess addition of a new @JsonWrapper (or @JsonWrapped to be compatible with existing @JsonUnwrapped?) annotation for supporting such intermediate level -- and not just for Collections, for what that's worth -- might make sense. I don't think I have time to work on that but maybe you or someone else could.
Basically I think it'd add a simple serializer/deserializer that would be much delegating ser/deser (StdDelegatingSerializer, StdDelegatingDeserializer), but would "wrap" (on serialization) and "unwrap" (on deserialization) one single-property JSON Object to handle structural mismatch.

Doing this should actually be quite a bit simpler than implementation of @JsonUnwrapped, I think.
I think there is already an issue for this feature...

[mglunafh]

Thanks for the explanations, I tried to follow your instructions, that's what I've got so far in the serialization department:

1. WrapperList annotation which can be placed on fields and methods for now
2. WrapperIntrospector class which overrides findSerializer method and essentially substitutes any possible serializer for WrapperList-annotated properties with a custom-made WrapperSerializer
3. Aforementioned WrapperSerializer which also implements ContextualSerializer interface

With this set of classes I managed to successfully introduce wrappers into the JSON representation, so big hoorays; however, I've also had some questions regarding it:

1. I guess overriding JacksonAnnotationIntrospector.findSerializer() was kind of selfish for the cases when a class or property has @JsonSerialize or JsonRawValue and can have some unintended consequences
2. Should my WrapperSerializer take a generic type parameter provided that it's somewhat hard to reliably determine the type of a delegating serializer? spent some time choosing among <T>, <?>, <Object>, Class<T> in various places;
3. I am curious about the implementation of WrapperSerializer.createContextual() method: is it possible to drop some checks in my case? Could BeanProperty parameter be null? Could property.getAnnotation(WrappedList.class) return null? Should I drop some jackson equivalents of IllegalStateException in these cases?
4. I managed to get things done without BeanSerializerModifier, was that because it's not that suitable for my problem?

Again, thank you very much the insights, looking forward to tackle the remaining deserialization part!

[cowtowncoder]

Great progress, congratulations!

Some notes:

1. Yes, findSerializer() override will probably not work for some use cases (@JsonSerialize will by-pass call I think)
2. Ideally, yes, JavaType should be taken and used, not Class<> (as it can be type-erased)... if available
3. Yes. BeanProperty may be null for various reasons, including serializers for "root values" (main Object passed to writeValue() is not referenced by a property)
4. BeanSerializerModifier would unfortunately not work here, since it does not get context information. Although... I think it could be part of solution, but would require use of ContextualSerializer callback to get context info on wrapper annotation. Its use would actually support @JsonSerialize(using = ...) cases, unlike AnnotationIntrospector.findSerializer()

[mglunafh]

I finally managed to take some time and finish the work on the deserialization part of the solution.

1. I overrode findDeserializer(Annotated a) in WrapperIntrospector class
2. I implemented WrapperDeserializer class. What I haven't figured out is how to utilize a delegating deserializer in a streaming fashion like it was in serializer: a) start reading object, b) read its inner wrapper property, c) then i guess call delegating deserializer and obtain result, d) finish reading object (?) e) return result. So for now I circumvented it by reading a whole object tree, which is not ideal in a general case scenario if I understand the process correctly, and deserializing the required part of it; apparently there was no need to capture a delegating deserializer in this solution.

Thus, my questions regarding the deserialization part are: would it be beneficial to use a delegating deserializer, and in case it is how to use it correctly?

Thanks in advance!

[cowtowncoder]

Yes, deserializers are ideally delegated too; each deserializer only reading part of content it is to handle, delegating to ones it needs (which are handled to them for "well-known" structured types like Collections, Maps and arrays). So the parent deserializer should read content up to the first token that delegated-to deserializer need, call deserializer (and get its result value); all deserializers should be called with JsonParser pointing to token they are to consume, and should continue until last token they consume (and no further).
And for structured types, delegating content within.

Does this make more sense? I am not quite sure what else to tell, except maybe look at existing implementation like, say, src/main/java/com/fasterxml/jackson/databind/deser/std/CollectionDeserializer.java.

[mglunafh]

It does make sense, thank you very much for the explanations; I'll take a closer look at the existing implementations.