Towards better serialization

[forax at univ-mlv.fr]

----- Mail original -----
> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Envoyé: Mardi 11 Juin 2019 23:29:51
> Objet: Re: Towards better serialization

>> About the details,
>> - using factories, constructor and matchers: yes
>> - using annotations @Serializer/@Deserializer + version,
>>    this part is still too magic, no?, an annotation is not better than an empty
>>    interface, it's still not integrated with the language,
>>    @Serializer/@Deserializer should be keywords, and version can be a parameter,
>>    so you can disambiguate versions in code (framework may use annotation on top
>>    of that mechanism to provide a more declarative API).
> 
[..]
> 
> They are not empty; they are parameterized (at least) by version. And
> the version cannot be a runtime parameter to the serializer; the caller
> has no idea of the class-specific current version numbers of the zillion
> classes in an object graph.  They are properties of the class itself, as
> of the time it was compiled.

Being able to pass the version in the serializer allows a new version of the class that uses an instance created from an old version of the stream to be encoded as an old version.

> 
>> - the keyword "open", i think it's not needed, in fact i hope it's not needed,
>> we already have enough visibility keywords in Java. Frameworks can access a JDK
>> API that will provide access to the method  marked with the keywords
>> "serializer" and "deserializer" (also your use of the keyword open is close to
>> the initially proposed use of the keyword module in the JSR 294 which was
>> withdrawn).
> 
> Now THAT would move it over the line where annotations would not be OK,
> because then they would affect the semantics of the class.

now you start to see my point

> 
> There are surely a range of options here, but the one you propose takes
> two orthogonal considerations and couples them -- which is reinventing
> one of the sins of original serialization.  (And, other frameworks
> (e.g., dependency injection, mocking, etc) have similar need for dynamic
> access to members that are not intended as part of the "front door" API
> anyway.)

you want to special mechanism for the serialization, no ?

Otherwise, we already have java.lang.invoke.Lookup.privateLookupIn() and the open keyword on the module/package.
It already encodes the semantics "we believe in encapsulation but sometimes we don't".
Having a finer grain version of "open" goes against what was decided by the JPMS EG in my humble opinion.

Rémi