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

[Stephen Colebourne]

I've just checked, and yes the 310 Ser class is more involved (and
more efficient) as it implements Externalizable. (Externalizable saves
bytes over Serializable, by taking full control of the output IIRC).

While criticisms of the 310 design are welcome, it was carefully
crafted to be a generally useful package-based pattern for
serialization. Following exactly that pattern here would seem
desirable if possible. ie. a single Ser class for all new serialized
forms in java.util, starting with immutable collections.

Stephen


On 17 May 2016 at 11:43, Chris Hegarty <chris.hegarty at oracle.com> wrote:
>
> On 17 May 2016, at 09:55, Stephen Colebourne <scolebourne at joda.org> wrote:
>
>> CollSer should not be public, especially not just for serialization
>> reasons.
>
> Right, and I see no reason to refer to it by name in the javadoc, the
> link should be sufficient.
>
>> Stuart, I disagree with using an int for the flags, it should be a byte. If
>> you need future expansion you can use 0xff to indicate it with the parser
>> reacting accordingly. That is the strategy for JSR 310
>
> 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.
>
> -Chris.
>
>> Stephen
>> On 17 May 2016 8:29 a.m., "Peter Levart" <peter.levart at gmail.com> wrote:
>>
>> Hi Stuart,
>>
>>
>>
>> On 05/17/2016 12:48 AM, Stuart Marks wrote:
>>
>>> Hi all,
>>>
>>> Please review this changeset that adds specifications of the serialized
>>> forms (really, a single serialization proxy class) for the immutable
>>> collections implementation. There are no code changes in this changeset,
>>> just documentation.
>>>
>>> It's somewhat odd, but the class doc for the serialization proxy isn't
>>> actually included in the serialized-form.html output. I had to jigger
>>> around the method doc for readResolve() to include some general information
>>> about the class.
>>>
>>> I also added links manually from the List, Map, and Set interfaces to the
>>> serialized form and vice-versa. I'm not aware of another way for a private
>>> class to link to its (proxied) serialized form.
>>>
>>> I was able to coerce specdiff into giving a diff of serialized-form.html.
>>> It's not very convenient, though; like serialized-form.html, the html diff
>>> is one big file. The only difference is the addition of java.util.CollSer.
>>>
>>> Webrev:
>>>
>>>    http://cr.openjdk.java.net/~smarks/reviews/8133977/webrev.0/
>>>
>>> API specdiff:
>>>
>>>
>>>
>>> http://cr.openjdk.java.net/~smarks/reviews/8133977/specdiff.0/api.specdiff/overview-summary.html
>>>
>>> serialized-form.html diff:
>>>
>>>
>>>
>>> http://cr.openjdk.java.net/~smarks/reviews/8133977/specdiff.0/serial.specdiff/specdiff-summary.html
>>>
>>> Thanks,
>>>
>>> s'marks
>>>
>>
>> Perhaps java.util.CollSer could be promoted to be a public class. It does,
>> after all, specify the API (serialization form == API). I don't see a point
>> in hiding it and then jiggering around the method doc for readResolve()...
>> You could just restrict its use by keeping the constructor(s)
>> package-private...
>>
>> What do you think?
>>
>> Regards, Peter
>