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

[Stuart Marks]

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