Persistence¶
Problems¶
- Java serialization doesn't guaranty that a file can be reread when a class has changed
- File are in binary mode -< they cannot be reread
- A field change
- A method signature change
However, it does not change if the contents of a method is modified => it doesn't guaranty the behavior of the class.
Objectives¶
- User must be able to reread project file during time
- Detect potential changement even if the project can be read
Some Solutions¶
Use of class serialverionsuid field¶
- It improves robustness for simple changes but doesn't support field modifications
The serialVersionUID should be changed when :.
- a field is added or renamed or removed.
- the type of a field is changed
- the name of the package or the class is changed
However, serialVersionUID should not be changed when
- the scope of a field is changed (private, protected, public).
- the fields ore reordered.
- a method is added, rename, pr removed.
- modify a static fields.
What's happen if the serialversionuid is not changed ?
- If a field is removed : not error
- if a field is added : it is
null - if the type of a field is changed : we get a
java.lang.ClassCastException - If a class is renamed : we get a
java.lang.ClassNotFoundException
Use of java.bean.xmlencode¶
- Only usable with java bean standard
XML library¶
Advantages
- These method are robust against class changes (method signature modification, new field or removed field)
- XML format is human readable. It can be used for external processing or reutilisation
Drawbacks
- XML is verbose, file are huge
- File doesn't crash if method or fields have change -> it can leads to inconsistency
Discussion
- XML solution are attractive but must be associated with a mechanism to detect inconsistency
How to Detect inconsistency change¶
- Record SVN version id => all class should declare a SVN revision
- Record the list of class fields
file size comparison¶
- binary : 459 kb
- xml (xstream) : 6.8 Mb
- xml.gz (xstream) : 235kb