Towards better serialization
forax at univ-mlv.fr
forax at univ-mlv.fr
Tue Jun 11 22:47:36 UTC 2019
----- 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
> 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
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.
More information about the amber-spec-experts