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?