On 5/17/16 1:09 PM, Peter Levart wrote:
I don't think it's possible to have a single form for all new serializable
objects in java.util. The java.util package isn't as cohesive as java.time.
There's a bunch of random stuff in it. Consider the non-serializable things
currently in java.util:
*SummaryStatistics, Optional, Formatter, ResourceBundle,
Scanner, ServiceLoader, StringJoiner, Timer
If any of these were to be made serializable, I don't think it would make
sense for it to share the serialized form with CollSer.
They would not share the form. The java.time.Ser does not specify serialized
form by itself (short of a single byte stream prefix that selects the
sub-format/implementaion typically hosted in the implementation classes
themselves). java.time.Ser is just an adapter that allows for
Externalizable-like functionality of implementations but not requiring them to
implement a public no-arg constructor that constructs uninitialized instances.
So all above mentioned classes could simply share a single java.util.Ser
serialization proxy however different they are.
OK, I guess I overstated this by saying that I didn't think it was possible. Of
course it's possible, given sufficient hacking.
But a unified "java.util.Ser" proxy for everything in java.util would have the
objects share the same serialized form in that they'd share the serialized
object header, serial version UID, class descriptor, and fields (if any).
Clearly the responsibility for handling actual instance data would be delegated
back to the classes themselves.
I just don't think there's any advantage to doing this for unrelated classes.
Indeed, it's a disadvantage to couple together the serial forms of classes that
are otherwise unrelated.
s'marks
