Re: java serialization alternative

On Sun, Mar 30, 2008 at 1:03 AM, Attila Szegedi <[email protected]> wrote:
>  Right - the real pain (which your blog entry doesn't show) is when
>  both classes are actually two versions of the same class, so you must
>  ensure you have both .class files available somewhere, have them
>  loaded through different class loaders, and then persuade the
>  ObjectInputStream to deserialize to the right class (as it's
>  notoriously ignorant of thread context class loader...). PITA indeed.

The blog entry does address that. If you want to use the old classes
as is, you have to keep the class files around, you have to load them
in a separate classloader, and you have to somehow test them, but this
would be difficult (the same test code touching two different
instances of the same class loaded by different class loaders?!).

In the blog entry, I recommend copying the old code into the test
directory under a different name. My serialization utility enables you
to serialize it under the fake name and deserialize it under the real
name, and vice versa. It's hacky but much easier than the alternative,
IMO.

>  > If you use a tool like Thrift, you can check two definitions for
>  > compatibility statically, so for example, you could add a submit check
>  > to your source control system or test suite to detect incompatible
>  > changes.
>
>  Nice - thanks for the pointer. I wonder how easy is it to extract this
>  functionality from Thrift, as otherwise it seems to be geared toward
>  RPC, and I'm more on the async messaging side of architecture...

I assume you could just use the IDL functionality on its own, but I
haven't used Thrift before. I've used a few similar proprietary
frameworks though.

Bob

===================================
This list is hosted by DevelopMentor®  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com