Java - .Net object interchange, not web-based

Question

I have a client-server system implemented in C#, and the client and server exchange .Net objects via serialization / deserialization and communicating via TCP/IP. This runs on a

Answer 1

You can also try wox (https://github.com/codelion/wox), it is a cross platform serialization library for Java and C# based on XML.

Answer 2

SO user "default locale" should get the honor for this, but he/she has only answered via a comment. So just to make it very clear what my choice was I'll answer my own question.

I've decided to go with Google Protocol Buffers, which in my opinion has much better support for moving objects back and forth between Java and .Net than JSON. Because I have a lot of experience with C#, and a lot of existing C#-defined classes, I've selected Marc Gravell's protobuf-net program for the .Net end, and Google's own support for the Android end (no - see edit). This implies that I'm defining the objects in C#, not in .proto files - protobuf-net generates the .proto files from which I then generate the Java code.

Incidentally, as the transport mechanism I'm using a little-known program called naga on the Android end. http://code.google.com/p/naga/ Naga seems to work fine, and is well-documented and has sample programs, and should be better known in my opinion.

EDIT:

OK, I've got it working now to my satisfaction. Here's what I'm using:

Google Protocol buffers as the interchange format: https://developers.google.com/protocol-buffers/

Marc Gravell's protobuf-net at the C# end: http://code.google.com/p/protobuf-net/

A program called called protostuff at the Java end: http://code.google.com/p/protostuff/

(I prefer protostuff to the official Google Java implementation of protocol buffers due to Google's implementation being based on the Java objects being immutable.)

Actually, I'm not using pure protocol buffers as the interchange format - I prefix the data with the name of the (outermost) class being transmitted. This makes the data self-identifying for deserializing at the other end.

Answer 3

I would suggest either JSON or XML (which is based on a .xsd file) because these are independent of their respective implementations (instead of something like an ObjectOutputStream in java).

The problem of having this format between the two components (client and server) is that they need to be at the same version. My best practice is to have one underlying definition of the format (i use xml with an xsd file which specifies how the xml has to look like), then use jaxb to generated java classes. That way you can (un)marshal from/to xml in the java part.

I am very sure a similar thing exists in the world of .NET.

JSON is smaller than xml in size, i find xml to be more readable.