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
