java standard serialization order

Question

I want to know in which order the attributes of the following example class would be serialized:

public class Example implements Serializable {

   private static final long serialVersionUID = 8845294179690379902L;

   public int score;
   public String name;
   public Date eventDate;
}

EDIT:

Why i wanna know this:

I got a serialized string in a file for a class of mine which has no implementation for readObject() or writeObject(). now that implementation changed ( some properties are gone ) and i want to write a readObject() method that handles the old serialized class.

There i would just read this property but wouldnt save it to the created object.

This is basically just for legacy i use a database now but need to support the old serialized files.

to write this readObject() i need the order of properties that in the stream.

Lockridge

Off-topic: Why do you want to know that?! Its not that you'd open the file and try to manually comprehend it and see the order for yourself(though you won't be able to understand the gibberish there). – Jessy

i added the why to my question! – Lockridge

@Konstantin Possible case of the XY problem :-) – Kidnap

guess youre right with that. ^^ I´m open to alternatives. Although im curios how the standard serialization proceeds so im staying with my original question. – Lockridge

Is this a one-off effort to read the old files or do you need to be able to support both new and old serialized objects going forward? In the former case, you could reconstruct your old class (ensuring the serialVersionUID matches) and extract the necessary data, before re-serializing in a "transport" class you can safely read from later. – Kidnap

there clients who stored data through this serialisation and i need to enable them to access this data. Storing via serializable is off the table but restoring from this old serialized files is necessary. – Lockridge

Possibly relevant: javaworld.com/community/node/2915 – Kidnap

let us continue this discussion in chat – Kidnap

I think you can use Serialization proxy, read the full object in Proxy and write your actual object as you want : #897445 – Contrapuntist

Answer 1

Based on a brief reading of the spec.

• The fields are written in the order of the field descriptors the class descriptor

• The field descriptors are in "canonical order" which is defined as follows:

  "The descriptors for primitive typed fields are written first sorted by field name followed by descriptors for the object typed fields sorted by field name. The names are sorted using String.compareTo."

---

_{(I suspect that the bit about the canonical order should not matter. The actual order of the fields in the serialization should be recoverable from the actual order of the field descriptors in the class descriptor in the same serialization. I suspect that the reason a canonical order is specified is that it affects the computed serialization id. But I could easily be wrong about this :-) )}

---

Reference:

• Java Object Serialization Specification - Section 4.3 and Section 6.4.1 (the comment on the "nowrclass" production)

Endocrinology

Answer 2

With regards to your original problem, some testing would suggest that if you've maintained your serialVersionUID and haven't removed fields containing values you need, you can probably just deserialize your old objects without error.

Any fields you no longer have will be ignored. Any new fields will be initialised to default values (e.g. null, or 0 etc.).

Bear in mind, this approach might violate constraints you've placed upon your class. For example, it may not be legal (in your eyes) to have null values in your fields.

Final warning: this is based on some testing of mine and research on the Internet. I haven't yet encountered any hard proof that this is guaranteed to work in all situations, nor that it is guaranteed to continue to work in the future. Tread carefully.

Kidnap

Answer 3

It doesn't matter. Fields are serialized along with their names. Changing the order doesn't affect serialization compatibility, as long as the serialVersionUID is the same. There are a lot of other things that don't mater either. See the Versioning chapter in the Object Serialization Specification.

Brakpan

Changing the order is not mentioned as in the compatible changes nor in the incompatible changes (April 2016). That's why this is a useful answer. – Lookin