river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregg Wonderly <ge...@cox.net>
Subject Re: OSGi
Date Sat, 04 Feb 2017 18:46:49 GMT

> On Feb 4, 2017, at 5:09 AM, Niclas Hedhman <niclas@hedhman.org> wrote:
> 
> see below
> 
> On Sat, Feb 4, 2017 at 6:21 PM, "Michał Kłeczek (XPro Sp. z o. o.)" <
> michal.kleczek@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
Mime
View raw message