10 December 2004
Java Serialization and .NET - There Really *is* a Santa Claus
Ah, yup, it works.
You can take a single class (SomeType.java), marked with ISerializable, and then compile it twice - once with javac.exe, and once with vjc.exe. Serialize from Java and you can de-serialize from J#. and vice versa. It works in both directions.
If you do this, the .NET app is not limited to just J#. .NET is truly a multi-language platform, so a .NET app can define a type in J#, then use it from within VB or C# or whatever. If I de-serialize an instance of the J#-defined type, I can use that instance in code written in any .NET language. Cho!
For those who don't believe, I have a sample that demonstrates it. It's a WinForms app and a Java console app. The Java console app acts as a "server" or "producer" , and the WinForms app acts as a "client" or "consumer." They communicate using MQSeries. The client enqueues a message on a queue, which acts as a request to the producer for N messages. The producer de-queues the request, and then loops N times, each time instantiating a type, using Java serialization to serialize the instance as a byte array into an MQ Message, enqueuing the message onto the queue. The client then de-queues the response messages, de-serializing using J#'s serialization support, and getting a full-fidelity copy of the instance. In about 3 seconds on my machine, the single-threaded client can dequeue and de-serialize about 1000 instances of the TestMessage type I defined.
Get the sample
I wonder how the performance of this would compare to using XML serialization on each side? Any guesses?
Comment Notification
If you would like to receive an email when updates are made to this post, please register here
Subscribe to this post's comments using
Comment Policy: No HTML allowed. URIs and line breaks are converted automatically. Your e–mail address will not show up on any public page.