----- Mail original ----- > De: "Brian Goetz" <brian.go...@oracle.com> > À: "Remi Forax" <fo...@univ-mlv.fr> > Cc: "amber-spec-experts" <amber-spec-experts@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
