----- Mail original -----
> De: "Brian Goetz" <brian.go...@oracle.com>
> À: "Tagir Valeev" <amae...@gmail.com>
> Cc: "amber-spec-experts" <amber-spec-experts@openjdk.java.net>
> Envoyé: Jeudi 20 Juin 2019 15:43:46
> Objet: Re: Different serialization strategies for different formats?
> Yes, a similar question came up in an internal discussion as well.
>
>> Consider we have a Color class which represents a color in RGB format:
>>
>> class Color { private final int rgb; }
>>
>> The most obvious and efficient way to serialize/deserialize its state is to
>> extract this int field:
>>
>> It's great for binary serialization. However if I serialize to JSON I would
>> not
>> like to see `color: 16711680`. JSON or XML are intended to be at least
>> partially human-readable. So probably I want to see `color: red` or at least
>> `color: #FF0000`. Well no problem, we can alternatively serialize as string:
>
> Good example. There’s no problem in the model with multiple serializers, but
> it
> raises the question: how would a client select which form? Suppose instead of
> (or in addition to) the version property on the annotation, we had some other
> selectors. Suppose for sake of argument that Color has the following
> serializers:
>
> @Serializer(selector = “binary”)
> public pattern Color(int colorValue) { … }
>
> @Serializer(selector = “text”)
> public pattern Color(int r, int g, int b) { … }
>
> These tags are selected by the author of Color at development time. But the
> ultimate user of serialization is someone in some other maintenance domain,
> asking to serialize a whole graph that has colors in it. Without some sort of
> global agreement on the taxonomy of selectors, a given graph might have many
> classes which reflect the text/binary distinction (just one possible
> distinction) in a dozen different ways. And the tex/tbinary distinction might
> not be the only distinction one wants to reflect; one could imagine varying
> degrees of detail preservation, for example.
>
> So I like the idea of treating the set of serializers as something that can be
> queried over by a serialization library — the question is — what is the
> structure of these queries, such that would-be queriers don’t have to “join”
> 100 different “tables” each with their own schema style?
I don't think we should specify a query scheme, it seems more future proof to
only provide a way to expose all serializers (resp deserializer) and let the
serialization library provides their own annotations / do the selection on top
of what we expose.
so the JDK will only provide @Serializer/@Deserializer and an hypothetical JSON
library will provide @JsonFormat to indicate a supplementary way of selection
@Serializer @JsonFormat(selector = “binary”)
public pattern Color(int colorValue) { … }
@Serializer @JsonFormat(selector = “text”)
public pattern Color(int r, int g, int b) { … }
Rémi
