Towards better serialization

[Brian Goetz]

> 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.)

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.

> - 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.

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.)

Having something that means both "use me for serialization" and "throw 
the usual accessibility rules out the window" is not a primitive.  These 
are separate things, that want separate markings.

> And nitpicking, can we agree that in a pattern the parameters act more as return values than as parameters, so instead of writing
>      public pattern serializeMe(String serverName) {
>          serverName = conn.getName();
>      }
> I prefer
>      public pattern (String serverName) serializeMe {
>          return (conn.getName());
>      }

OMG, are you seriously going to bikeshed the syntax of a *different 
feature* here?  Really?  Really?

(And no, we cannot agree that.)