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

[Peter Levart]

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