Wire Protocol for Archive Serialization
Use Case: Send an Archive<?> over a network or serialize to disk.
I had a look and wanted to note some thoughts.
At first glance, we think of the process being:
- Export as ZIP
- Write to Stream
- Import from ZIP
This may fine for archive contents, however Archive<?>s have more internal state than simply the payload. Archives have a name, an associated Domain/Configuration/ServiceLoader/ClassLoader etc.
Also we should make the Serialization protocol of the contents more configurable than simply ZIP. Perhaps in CPU-bound environments the user would like to write uncompressed bytes. Or maybe if going over a network they'd like a more compact BZIP.
Simply marking everything as Serializable doesn't really cut it either. The deal with wire compatibility is that it must be consistent between patch and minor releases, and changes to the structure of the implementation classes make the default form brittle. It's easy to keep binary (API) compatibility but fail the serialization contract.
Some questions:
- Do we bother sending along the archive's Configuration? If not, we can assign it ShrinkWrap.getDefaultDomain().getConfiguration() upon deserialization. If so, we need to make the Domain and all other types in the graph Serializable with back-compat protocol as well.
- If we *do* send along the domain, some configurable elements may no longer be available. For instance JVM1's classpath may have user-defined extension types available which are not present on JVM2.
- How do we handle the nestedArchives Map in MemoryMapArchiveBase ? I think we recurse into them in order to write these out.
Other observations:
- We don't need to make ArchivePath Serializable. This is essentially a wrapper around String which provides some convenience, so we should just send the String and make a new ArchivePath from it on the other end.
- I don't much relish the idea of sending along an Archive with Configuration that isn't present in any Domain within the remote (receiving) JVM.
As a general rule, the fewer types we make Serializable, the easier maintenance becomes. The trick is for us to find a consistent way of sending all state over the wire in some contracted form, then reading it back into the proper types.
S,
ALR