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