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.
I wonder how the performance of this would compare to using XML serialization on each side? Any guesses?