Towards better serialization

[Remi Forax]

Hi Brian,
I agree with the motivation and the requirements.

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

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());
    }


Rémi

PS: "This mistake is understandable in historical context, since at the time the industry believed that distributed objects were going to save us from complexity."
This is still true today, the industry believed that distributed systems aka microservices will save us all.

----- Mail original -----
> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "amber-dev" <amber-dev at openjdk.java.net>
> Envoyé: Mardi 11 Juin 2019 21:21:19
> Objet: Towards better serialization

> I've posted a document at:
> 
> http://cr.openjdk.java.net/~briangoetz/amber/serialization.html
> <http://cr.openjdk.java.net/~briangoetz/amber/serialization.html>
> 
> on an exploration we've been doing to address some of the shortcomings
> of Java serialization, building on other tools that have been (or will
> be) added to the platform. Rather than attempt to add band-aids on
> existing serialization, it addresses the risks of serialization at their
> root.  It is somewhat of a shift -- it cannot represent all object
> graphs, and it makes some additional work for the author -- but it
> brings object serialization into the light, where it needs to be in
> order to be safer.  This is an early draft; questions, and constructive
> feedback on the approach, are welcome.