Pros and cons for using ObjectInputStream/ObjectOutputStream to implement network “packets” in Java?

Question

I'm working on a simple client/server application that uses sockets for all the communications. Communications are packet-based and the concept of packets is implemented using a set of classes and ObjectInputStream/ObjectOutputStream wrapper for socket streams.

Wondering if this approach has any disadvantages when compared to either fully text-based protocol (like IRC) or "very binary" stuff where I explicitly work with bytes.

Let's ignore the traffic problems here ("qwerty" vs. "qwerty" + 1KB of metadata) and only consider reliability and maintainability.

What do you think?

Answer 1

Personally I've found the binary serialization built into Java to be immensely painful. It's ludicrously easy to end up with version incompatibilities even when you haven't changed anything you expect to cause problems.

That's not an issue if:

• You can guarantee your clients/servers will all be running exactly the same version of your code.
• You never need to read any data that was written by a previous version.

Maybe that's your situation - but personally I prefer a serialization format which allows me to be more flexible with versioning. Now that doesn't require it to be either binary or text of course. You could use JSON, Protocol Buffers, Thrift or any number of other options. Each will have separate pros and cons - but each is likely to be designed with simpler version compatibility in mind than Java.

Now the upside of Java serialization is that while you're in the situation where everything works (your entire tree is serializable) you can just serialize it with no other changes - you don't need to model your data separately, as you do with some serialization frameworks. Unfortunately, as soon as you want to use a class which isn't serializable somewhere in your tree, you're back into pain...

As for the choice between text and binary forms - the pros and cons are reasonably obvious. Text is bigger, but it's easier to diagnose what's going on just by looking at network traces. You need to make sure you use the same encoding on both sides, of course.

Oh, and of course if you ever want to communicate with a non-Java client/server, you'll have a hard time if you've used Java's native serialization :)

Answer 2

It.s a pain to maintain backwards comparability with serialized objects, and non java clients can't talk to your service. Serialized objects are not great with respect to serialized size as well.

I would use something like protocol buffers instead.