Review request 8002212 - adding read/writeObject to additional SerialXXX classes

Remi Forax forax at
Sat Nov 3 15:14:52 UTC 2012

On 11/03/2012 01:46 AM, Lance Andersen - Oracle wrote:
> Hi Remi,

>> In SerialDataLink, do you really need readObject/writeObject given
>> that you call the default implementations.
> I thought about that but had decided to add them for consistency

The serialization implementation needs to create metadata associated 
with readObject/writeObject,
so if we can avoid to implement them, we reduce the runtime memory 
footprint a little.
I would prefer to have a comment saying that default serialization is Ok 

>> in SerialJavaObject, in equals, you should declare a local variable like in SerialDataLink.equals,
>> even if the local varialble is used once, it's more readable.
> OK
>> Also like in SerialArray.equals, you can do a return directly instead of if(...) return true.
>> in clone(), you can use the diamond syntax,
>> sjo.chain = new Vector<>(chain);
> Yeah, long story, but I forgot to reset to diamond syntax (will tell you over a beer sometime :-) )

sure, now or you have to visit Paris or I have to go to NY :)

>> in setWarning(), you can use the diamond syntax as the original source does.
>> and in readObject, you can use the diamond syntax too.
> OK
>> In readObject, you forget to throw an exception if there are some static fields
>> in getClass().getFields() as the constructor does
>> (this code can be moved in a private static method).
> I thought about that, but figured since it was already through that check when the object was created, I did not think it required repeating in the readObject method

A serialization stream can be forged to encode a SerialJavaObject that 
references an object that have a static field without creating a 
SerialJavaObject in memory.

>> Also, you should add a comment that because you call getClass() on obj,
>> there is an implicit null check.
> Would it be better to put an null check in explicitly?

As you prefer :)


> Thank you again, will send an update webrev over the weekend
> Best
> Lance


More information about the core-libs-dev mailing list