Re: java serialization alternative

On Sun, Mar 30, 2008 at 5:17 PM, Jeff Kesselman
<[email protected]> wrote:
>  There are plenty of things that can be re-written without losing data.
>  See "serialization compatible changes."

You can make much more significant changes than those while
maintaining compatibility. See putFields() and readFields(). Like I
said, the problems with serialization are detecting incompatible
changes, no static foundation upon which to build tools, testing
compatibility, and it breaks down when you try to perform non trivial
refactorings: class renames, breaking one class down into a couple,
etc. You're effectively stuck with your original design so long as you
have data generated by that design.

>  Beyond that, as i mentioned
>  before, I'm already looking at  ways to build a  merge-type tool.

I'll look forward to your writing that, but I'm skeptical that the
result will be as user friendly and robust as other approaches.

>  The fact of the matter is I need transparent POJO data management for my
>  client base and I know of no other way to achieve that.

I'm not expert by JRuby might be an option. If you don't need static
type safety in your flattenning, perhaps you don't need it in the rest
of your code?

>  At the end of the day there are always advantages and limits to every
>  tchhnique.  A good craftsman does not so fall in love with his hammer he
>  forgets how to turn a screw, or vice versa.

I'm not sure what you're trying to say here. There definitely aren't
always advantages to every technique. Are you trying to sell me on
serialization? I've used it extensively on multiple projects over the
years.

>  And if he hist himself  in the thumb with the hammer a few times, he
>  asks "what am i doing wrong with this tool."  He doesn't throw it away.

Sure, blame the flawed design on the user. :-)

Bob

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

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