Project Jigsaw: Serialization Notes
In module mode the VM makes classes visible to each other based on module definitions. This creates a challenge when deserializing since the code doing the deserialization may not have visibility to the types that it needs to reconstitute.
More specifically, the default behavior of ObjectInputStream's resolveClass method is to walk the thread stack to find a method whose declaring class is a "user-defined class loader". When running in module mode, the approximate equivalent would be to walk the thread stack looking for a class loader for a non-platform class although there is no guarantee that types defined by that module class loader will have visibility of the types that need to be reconstituted.
Another significant issue to consider is that the serialization protocol does not include information on class loaders or modules in the serialization stream.
For static, single-version module resolution, the class descriptor in the serialization protocol may be enough to determine the containing module, and hence the defining module class loader, when deserializing. On the other hand, when applications are hosted by a container, and there is potential for simultaneous multiple versions, then this may not be sufficient.
The Object Serialization Stream Protocol (and the supporting API in java.io) allows class descriptors to be annotated with custom data. At least for exploratory purposes, this can be used to encode module or class loader information into the stream. Such experiments would help to determine if it will be necessary to revise the protocol to support modules.
