> On Feb 4, 2017, at 5:09 AM, Niclas Hedhman <nic...@hedhman.org> wrote: > > see below > > On Sat, Feb 4, 2017 at 6:21 PM, "Michał Kłeczek (XPro Sp. z o. o.)" < > michal.klec...@xpro.biz> wrote: >> In the end all of the arguments against Java Object Serialization boil > down to: >> "It is easy to use but if not used carefully it will bite you - so it is > too easy to use" > > Well, kind of... > If you ever need to deserialize a serialVersionUid=1 with a codebase where > it is now serialVersionUid != 1, I wouldn't call it "easy to use" anymore. > Back in the days when I used this stuff heavily, I ended up never change > serialVersionUid. If I needed to refactor it enough to loose compatibility, > I would create a new class and make an adapter.
And this is one of the patterns that you had to learn. I often never change serialVersionUid beyond 1 as you suggest here. Instead, I use an internal, private version number in a class field to help me know how to evolve the data. For each version, I know which “data” will not be initialized. I can have a plan for a version 10 object to know how to initialize data introduced in version 4, 7 and 8 which will be null references or otherwise unusable. The readObject() can initialize, manufacture or otherwise evolve that object correctly. Gregg
