----- 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). > > While you know that I reject about 99% of the proposed uses of > annotations as "that's not what annotations are for", this one really > does fit the bill. Because, what these annotations do is _capture > design intent_ that these members are intended, by the author, to be > usable by serialization frameworks for certain activities. But it does > not affect their accessibility, or semantics, or the generated > bytecode. The language has (almost) no interest in these annotations; > they are a side-channel signal between a class and a serialization > framework (and not just Java serialization) that these members are > suitable and intended for a certain purpose. (Yes, the compiler may > wish to do additional type checking, like checking that the arguments > lists for the serializer and deserializer are compatible, and issue > diagnostics accordingly, but that's also within the rules for > annotations, like @Override.) The main difference between @Override, @FunctionalInterface and @Serializer/@Deserializer is that the formers are a form of documentation, the code still work if you remove them, it's not true with the two annotations you are proposing. Those annotations add a new contract at the language level, so they should be keywords and not annotations. Rémi
