Sunday, February 20, 2011

[android-developers] Re: Possible to deserialize java object on Android?

Sun worked hard to make serialization efficient -- not easy since it's
so intensely dependent on reflections, but they succeeded fairly
well. I suspect that Android hasn't invested nearly as much in making
reflections efficient.

On Feb 20, 1:26 am, Bob Kerns <r...@acm.org> wrote:
> Actually, while I don't disagree with the advice Mark gave, he's not correct
> about what Java serialization is designed for, nor is there any issue of
> byte-code compatibility here, because Java serialization does not have
> anything whatsoever to do with byte codes.
>
> The Java serialization protocol is not defined in an architecture-dependent
> way, and is explicitly designed to support transmitting object graphs to
> remote systems, which may be running quite a different version of Java.
>
> It was really designed for RMI, and it's sort of OK for that.
>
> But it has a lot of pitfalls and is hard to use well for complex object
> graphs while managing changes in the code base, and I would seldom recommend
> it
>
> Still, the original scenario is close to its origins, being a form of RMI.
> It does have mechanisms for versioning.
>
> But the description has you sending an entire object graph in both
> directions, and making a change within it. That strikes me as likely to be a
> lot of extra traffic -- why not just send a description of the change?
>
> Also, REST really is an orthogonal question, and a serialized Java object
> could definitely be the payload in a REST architecture, analogously to text,
> XML, or JSON payloads.
>
> I'm not going to believe ANYBODY's statements claiming that serialization is
> slow compared to, say, XML, without documented test results. It could be
> true, but it shouldn't be true. A compact, efficient binary encoding should
> give better performance than a highly duplicative, text-based format. But if
> reflection performs poorly enough, and you don't implement Externalizable to
> do the work without reflection, then perhaps.
>
> But here's why I don't recommend using Java serialization -- it's difficult
> to see what you're doing, and thus hard to debug. It's also hard to test all
> the scenarios, including compatibility with possible future code changes. It
> injects a point of fragility into your system.
>
> It always sounds like a cool trick -- taking this object graph you have been
> working on, and send it off to something remote, or to persist and come back
> to it later. It never works out quite as nicely as it sounds.

--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

No comments:

Post a Comment