RFR(s): 8133977 add specification for serial form of immutable collections
Chris Hegarty
chris.hegarty at oracle.com
Tue May 17 10:43:02 UTC 2016
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
More information about the core-libs-dev
mailing list