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.
Now, for new *collection* classes that might be added to java.util, sure. I can
imagine adding new collections, immutable or mutable, and they could use CollSer
as their serialized form. Those could be accommodated easily by adding new
values for the "kind" bits of the flags field. What other changes would need to
be made to CollSer to prepare for that?
s'marks
