This works fine when all classes in a graph are in the same maintenance domain.
But, what about libraries?
Sent from my iPad
> On Jun 23, 2019, at 7:02 AM, Remi Forax <fo...@univ-mlv.fr> wrote:
>
> ----- 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
