Hi,
This topic has been discussed already. Current version of the spec is clear about polymorphism: “Deserialization into polymorphic types is not supported by default mapping. [JSB-3.8-1]”. The spec is almost finished and I am strongly against going back and changing some basic things now.
On the other hand I understand that this use case exists. There is a possible workaround to it using adapters. Sorry if there are any mistakes, I am writing code without checking.
We can create a generic wrapper to any type holding its type info like this:
class TypedWrapper<T> {
String type;
T obj;
}
We can create a generic adapter which converts type to wrapper and vice versa. I am not putting a full implementation here, I hope that the idea is clear:
class TypedAdapter implements JsonbAdapter<T, TypedWrapper<T>> {
TypedWrapper adaptToJson(T obj) {
TypedWrapper<T> t = new TypedWrapper<T>();
t.type = obj.getClass().getName();
t.obj = obj;
return t;
}
T adaptFromJson(TypedWrapper<T> t) {
// Use reflection API to create an instance of object based on t.type field value
}
}
Now lets imagine that we have the following classes:
class Animal {
}
class Dog extends Animal {
}
class Cat extends Animal {
}
class Foo {
Animal animal;
}
To properly handle serialization/deserialization of Foo we just need to create an adapter which extends TypedAdapter from above and annotate animal field:
class AnimalAdapter extends TypedAdapter<Animal, TypedWrapper<Animal>> {
}
class Foo {
@JsonbTypeAdapter(AnimalAdapter.class)
Animal animal;
}
We can include TypedWrapper and TypedAdapter in reference implementation.
Thanks,
Dmitry
> On 21 Mar 2016, at 19:31, Eugen Cepoi <cepoi.eugen_at_gmail.com <mailto:cepoi.eugen_at_gmail.com>> wrote:
>
> Not sure if it should or not be part of jsonb. Though it is very likely people will want that feature. On the other side, it is a good way to have different impls distinguish them self by providing such advanced features (I mean as part of the impl and not at all present in the spec). In that case I would find it fine to have people configure directly the impl api.
>
> When we think polymorphism, at first it seems enough to handle it only for json objects, but it can also happen for other types, esp. ones that are serialized as literals. Then where do you store the type? Same for json arrays. This is just one aspect of the introduced complexity when one wants to handle polymorphism. The produced json starts getting more and more ugly.
>
> Then comes the moment when you want to change the name of the serialized property or the format you use.
>
> In some other situations (depending on how it has been implemented) you might want to have access to a dom structure that holds the properties so you can extract from them what is related to the type and then "convert" that structure to the target type. This happens if you allow the type property to appear in any order.
>
> There are many other things that one could want for polymorphic support which would make all that even more complex.
>
>
> In genson I first handled it only for what gets serialized as a json object and imposed that the type property must appear first in the json (so we don't need to read the full structure before knowing the target type). Then recently I added support for all types (literal and array) by wrapping them in a json object (yeah not very nice, but has the merit of being relatively simple).
>
>
>
> 2016-03-21 2:22 GMT-07:00 Sebastian Daschner <java_at_sebastian-daschner.de <mailto:java_at_sebastian-daschner.de>>:
> Hi guys,
>
> The idea was that this "javaType" (name is subject to change) wouldn't be included in all cases. Default behaviour should be to serialize as small / easy as possible. Only if the type information is needed to determine the actual type, an @JsonbTypeInfo annotation could be added to the corresponding type. Configuring a "forceTypeInfo" boolean for the programmatic JSONB config could be possible though.
>
> @Przemyslaw:
> Even if you solely use DTOs for serialization (I won't agree that that's a must for all situations) you can still have situations with subclasses and more complex hierarchies -- we had that case in several projects, also when using transfer objects to map the domain objects. "Flattening" the type hierarchies as workaround is not always desired.
>
> But the longer I think about your approach that enums could be used to derive the type information (like JPA, yes) the more I like this idea as it would be more generic (more difficult / more effort to configure, but easier to apply to different technologies). We should investigate further (with some examples) what approach could be the best fit for JSONB.
>
> But I highly recommend that some functionality to determine polymorphic types should be included in the spec.
>
>
> @Romain:
> The spec should in fact require the impl to check for "suitable" types then, i.e. only types to which the actual property type can be assigned to should be allowed, etc.
>
> I like your idea to add a "Wrapper" to unwrap instances but let JSONB still do the (de-)serialization. This could be helpful for more control how the containing type (the List in my example) should be instanciated. But it doesn't fully solve the polymorphism example in all cases, as the implementation of the actual type (Customer or VipCustomer) can still not determined from the nested JSON objects if there is no such thing as a JSON meta type information.
>
>
> Cheers,
> Sebastian
> On 03/21/2016 08:32 AM, Przemyslaw Bielicki wrote:
>> Hi,
>>
>> I'm not a fan of the original idea (and it's an euphemism). Remember that JSONB is used to serialize/deserialize DTOs, not domain objects. You should have an additional adapter layer to convert DTOs into application's business model/domain objects and back.
>> Polymorphism is broken (yeah, it's another topic and more philosophic) and I would discourage its application in DTO layer. If you have to, you can use an enum to mark what's the target class (check JPA for additional inspirations). "//javaType": "x.y.z" is really bad idea IMO - what if you use the same JSON to communicate with applications developed in .net, python, php, c++ at the same time? (yes, it happens). Would you define a type for each platform?
>>
>> If you use DTOs in business layer, you're doing something wrong :)
>>
>> @Romain, your idea looks interesting, can you show and example or deserialization process where polymorphism is involved?
>>
>> Cheers,
>> Przemyslaw
>>
>> On Sun, Mar 20, 2016 at 10:52 PM, Romain Manni-Bucau < <mailto:rmannibucau_at_tomitribe.com>rmannibucau_at_tomitribe.com <mailto:rmannibucau_at_tomitribe.com>> wrote:
>> Hi guys
>>
>> Why not allowing adapters to wrap and unwrap instances but keep serializer mecanism. For serialization no issue but for deserialization we need to switch the deserialized type and then post process the instance - or do it automatically with an Unwrappable interface?
>>
>> Overall idea for this particular use case would be:
>>
>> X ----TypedWrapper(X)----> JSON
>> JSON----TypedWrapper.class----> TypedWrapped ----unwrap----> X
>>
>> Parts in arrows are adapter/jsonb integration.
>> An alternative is to provide to adapters the stream and jsonp instances to do it themself with probably a mapper reference to re(de)serialise an object directly.
>>
>> Wdyt?
>> ---------- Message transféré ----------
>> De : "Romain Manni-Bucau" <rmannibucau_at_tomitribe.com <mailto:rmannibucau_at_tomitribe.com>>
>> Date : 19 mars 2016 21:49
>> Objet : Re: [jsonb-spec users] Java polymorphism support
>> À : <users_at_jsonb-spec.java.net <mailto:users_at_jsonb-spec.java.net>>
>> Cc :
>>
>> Hi Sebastian
>>
>> I am not fan of that - Mark knows ;) - and in particular now I'm sure we shouldnt do it: the 0-day vulnerability is still there and you open the door to the same issue or a complicated config adding this feature in something as generic as jsonb.
>> Le 19 mars 2016 21:28, "Sebastian Daschner" <java_at_sebastian-daschner.de <mailto:java_at_sebastian-daschner.de>> a écrit :
>> Hi experts,
>>
>> I don't know whether this has been discussed in the mailing list before
>> but a needed functionality would be to specify the Java type of
>> properties in the serialized JSON.
>>
>> As JSON doesn't standardize comments or other "attributes" (like XML
>> does) a "magic property" could be added.
>>
>> Please see the proposal (explored by Mark Struberg, Reinhard Sandtner
>> and myself) on my blog:
>> https://blog.sebastian-daschner.com/entries/json_mapping_polymorphism_support <https://blog.sebastian-daschner.com/entries/json_mapping_polymorphism_support>
>>
>> WDYT?
>>
>>
>> Cheers,
>> Sebastian
>>
>>
>
>