Hi Stuart,
On 05/17/2016 09:03 PM, Stuart Marks wrote:
On 5/17/16 3:43 AM, Chris Hegarty wrote:
The JSR 310 Serialization framework is a little more involved, as you
know.
I wonder if it is worth following that pattern more closely here?
That way
java.util.Ser could be a generic proxy for all new Serializable types
in the
java.util package, and not just the immutable collections. The 310
pattern
also results in a reasonable place to document the serial form.
The proposed java.util.CollSer follows the java.time.Ser pattern in
that they're both common serialization proxies for several different
implementation classes. I'm not sure exactly what you have in mind by
suggesting that the pattern be followed "more closely" though.
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.
But there's a different problem I see with java.time.Ser as is. Namely,
how does it provide for serialization format to evolve over time.
Suppose, hypothetically, that java.time.Duration would like to have
picosecond precision in JDK 16. How would you change the serialization
format/implementation that it would be backwards and forwards compatible?
Having different values in the serialization format "tagged" with field
names provides for that functionality. So in that respect,
java.util.CollSer is more evolvable than java.time.Ser.
Regards, Peter
