Review request 8002212 - adding read/writeObject to additional SerialXXX classes (original) (raw)

Remi Forax forax at univ-mlv.fr
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 here.

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

cheers, Rémi

More information about the core-libs-dev mailing list