Different serialization strategies for different formats?

[Brian Goetz]

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 <forax at univ-mlv.fr> wrote:
> 
> ----- Mail original -----
>> De: "Brian Goetz" <brian.goetz at oracle.com>
>> À: "Tagir Valeev" <amaembo at gmail.com>
>> Cc: "amber-spec-experts" <amber-spec-experts at 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