Partial serialization/deserialization

[mkarg]

There are cases when deserialization is getting complex. For example, if the value of one property decides about how to proceed with other attributes, as it could happen with polymorphic hierarchies:

{
  "kind": "com.my.ClassName",
  "foo": "x",
  "bar": "y"
}

In this example, the class name is not found in a surrounding wrapper, but directly in the same object's kind propery (e. g. Kubernetes API does this style). Currently such a deserializer needs to handle not only "kind" using JSON-P, but also foo and bar. That's not nice. It would be better if the deserializer could simply do this:

Class c = parseKind(parser); // uses JSON-P to turn "kind" into "Class"
Object o = c.newInstance();
deserializationContext.deserialize(o, parser); // has no return type but writes into "o" from "here" until END_OBJECT

This simply will deserialize into the existing object "o" from the parser's current position. It is working just like the existing deserialize(Class, JsonParser) but does not create an new instance nor returning it, and it does not expect an opening bracket {.

On the serialization side, it would be great to have an analog solution, e. g. SerializationContext.serialize(T object, JsonGenerator generator, boolean omitStartingBracket) which works like the existing variant, but just does not write the starting bracket in case 'false' is provided.

[rmannibucau]

Hi, isn't it the same as https://github.com/eclipse-ee4j/jsonb-api/issues/147 ?

[mkarg]

@rmannibucau No, it is not. #147 talks about the request for solving the particular problem of polymorphic (de)serialization. #182 is a proposed solution for a general API for partial (de)serialization. This is not limited to polymorphic scenarios, and it does not solve it but just enables it.

[rmannibucau]

@mkarg if you check out the linked impl it is the same, (de)serializers are the API covering that exact need.

[mkarg]

@rmannibucau There is a huge difference between both issues. #147 only targets in solving the high-level API needed to declare polymorphism, so the JSON-B implementation can solve it "under the hood" (without a need of the calling application to care about how partial (de)serialization is performed by the JSON-B implementation. #182 does not strive to solve polymorphism "under the hood", but just provides an API that the application programmer can call to solve any case of partial (de)serialization himself (on behalf of the calling application), even if it is polymorphism or not.

[rmannibucau]

@mkarg technically it is the same and we must not have 2 solutions for the same issue IMHO: enriching a "natural" (de)serialization with other metadata. The context - (de)serializer solves that, the only issue it has is that it uses parser and not reader or jsonobject as a base so it can't be reused so if your attributes are not sorted then you are broken - and you will if you are not java-java.

Now JSON-B.next will likely have a from/toJsonValue (or JsonStructure, this part is undefined, yasson only handles structures, johnzon handles values). So in your (de)serializer you can create/read a JsonObject and then bind it to as much models as you want.

At the end you should already have all you need and in a (java) natural way to do the mapping so I'm really not sure what you miss and why a new (conflicting/concurrent) API would help to solve that issue.

The only thing I can see is: deserialize(Type, JsonValue) addition which would avoid to inject the jsonb instance in the deserializer but it is not a blocker not something hard to do IMHO. But I'm starting to think that it would be saner to just enable to inject Jsonb directly or a new parent class just having the value<->pojo mapping for this kind of case.

Does it make sense?

[mkarg]

@rmannibucau +1 for what you write about JSON-B.next, but in fact, the discussion in #147 is still open: It is just labelled as "Maybe JSON-B.next". So whethere we need the separate issue or not is dependend of the outcome of that "Maybe" discussion. There is no guarantee that the outcome will definitively be what you describe above. So unless #182 is actually implemented, we cannot know if #182 is included or not. Hence I would keep #182 open until that day comes.

[rmannibucau]

Makes sense to me.

Anyone knows if we have a "dependency" flag to be able to track it efficiently?

[mkarg]

Off-Topic: It's a pity that Github does not have sub-issues, so we could span all of these serialization topics under one common umbrella issue.