RFR(s): 8133977 add specification for serial form of immutable collections

[Stuart Marks]

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