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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en