Serialization of java.time.* classes doesn't work out of the box about one-nio HOT 5 CLOSED

The fix has been integrated

from one-nio.

Hi @genuss. Yes, java.time.* serialization is a known problem which I plan to fix.

Unfortunately, implementing writeReplace/readResolve in a generic way is not as trivial as one may think. Resolving inner references within an object graph may be problematic, since the referenced object doesn't yet exist before the full graph is deserialized and readResolve is called.

SKIP_READ_OBJECT option for all java.time.* classes or for the whole java.time package at once is a viable solution. However, this will result in a bigger overhead for some objects comparing to standard Java serialization. E.g. LocalDateTime will take extra 16 bytes for LocalDate and LocalTime headers. This is not a big problem though.

Another option I consider is a white-list support for writeReplace/readResolve (e.g. enable them for the known "good" classes). Finally, there is always a last resort solution to add a custom serializer for java.time* classes. If you have other ideas, please let me know.

from one-nio.

Well my first thought was to implement custom serializers for needed classes. This method has downsides because it's too much hand work and it's not easy to support in long-term.
Enabling SKIP_READ_OBJECT was my second thought and it looks like good solution for most cases. If we combine custom serializers idea with this one, we won't get the size overhead.

Could clarify why generic way is not that trivial? From my point of view Serializer is generated at serialization phase not at deserialization on which we have all needed information about class and fields of serialized instance.

from one-nio.

I mean, runtime object graph may have the same object serialized multiple times. Furthermore, an object may refer to itself either directly or through a chain of references. This needs to be deserialized correctly. DeserializeStream.context solves this problem, but it does not work for serialization proxy.

from one-nio.

Thank you, I see now what you mean. Looks like there is no obvious solution, but I will try to dig in.
At least SKIP_READ_OBJECT is a reasonable workaround for now.

from one-nio.