Hello!
Nice reading, thanks!
What about inheritance? Could factory method deserializer declared in the
class X produce an object of type Y which is a subclass of X? In this case
where serializer pattern should be declared? In Y or in X? Assuming that
serialized stream contains the class name Y, then probably both serializer
and deserializer should be searched by serialization framework in the Y.
However probably Y is a private implementation detail and we don't like to
expose it and we already have some factory method in the X which can
produce Y and we like to use it for the serialization.
More concrete example: immutable lists created via List.of(...). There are
at least two implementations inside and, I think, it's desired not to
expose their count and structure. E.g. future Java version might have more
or less imlementations. How the serializer and deserializer would look like
for these objects?
Another question: is it expected that static checks will be applied for
annotated methods/patterns? I expect the following:
- Deserialization annotation is applied only to constructor or to static
factory method which return type is the same as the containing class. If
the class is parameterized like Map<K, V>, then static factory method
should be parameterized in the same way like static <KK, VV> Map<KK, VV>
createMap(...) (or such restriction is redundant?). Parameterized
constructor is not allowed (or it is?)
- Serialization annotation is applied only to patterns. Probably could be
applied to getter-like no-arg method if object is serialized to single
simpler value like File::toString could be used to serialize File.
- No two members of the same class could have the same annotation with the
same version number
- If class contains both serializer and deserializer with the same version
number, their parameter count and types should match.
What about singleton objects or objects without state in general? Seems no
problem with deserialization (e.g. class Singleton { @Deserializer public
static Singleton getInstance() {...} }). But how to declare the serializer?
Is it expected to have patterns which deconstruct the object to zero
components?
Will java.lang.String have a serializer (toCharArray?) and a deserializer
(String(char[])) or it's considered to be basic enough and all
serialization frameworks should handle it as a primitive?
With best regards,
Tagir Valeev.
On Wed, Jun 12, 2019 at 2:21 AM Brian Goetz <brian.go...@oracle.com> wrote:
> 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.
> Comments welcome!
>
