[Mono-list] Mono/Java interop?

[Norbert Harrer]

Thanks, Ben, that was a great summary. Although...

BH> The ability to make remote calls using object types between the two
BH> systems. A brief search of the web shows several companies developing
BH> this type of tech; eg www.jnbridge.com.

BH> The first challenge here is to find a suitable common wire protocol. At
BH> present, there is SOAP (Web Services), but it is weak in both
BH> performance and sematics.

Right. SOAP is not meant for this kind of things. I read on
www.jnbridge.com that they do communication between .NET and Java via
HTTP/SOAP *OR* a proprietary binary protocol. Not mentioning though
what kind of binary protocol they've cooked there.


BH> (c) Complex pass-by-value objects which likely as not have no
BH> representation in the other framework; imagine sending eg a
BH> javax.swing.JButton to .Net (remember it cant instatiate it directly as
BH> .Net doesn't understand the Java class definition). How is .Net going to
BH> handle this piece of data?

Hmmm. I don't think so. All Java objects would be instantiated on the
java side of the bridge. On the .Net side I'd always see only a
references to the java objects. The .Net side would have a
wrapper/proxy object for the javax.swing.JButton object.

There are basically only a few things you can do with an object.
1: call one of it's member methods/properties.
2: pass it along with a method call of another object.
3: reference it from another object

ad 1:
If a member method of the wrapper is invoked on the .net side, it
would forward the method call through the bridge and the method of the
real java object would be called.

ad 2: (only talking about passing by value here)
2.a) passing from .net to java: The wrapper's ID would be passed, and the
real java object would be used on the java side.

2.b) passing from java to .net: A new instance would be created on the
java side. It's ID would be passed to the .net side of the bridge with
instantiation of a new wrapper object counterpart.

ad 3:
A .net object would reference to the wrapper object.
A java object would reference to the real java object itself.

With wrapper ID, I mean some sort of token that can be stored in the
wrapper object, which can be used to identify/reference it's real java
object counter part on the java side.

Maybe I am missing something here. But the beauty of a bridge would be
that I'd never need to pass an object through the bridge by value.
Only basic data types would be passed by value. And since those basic
data types are also objects in .Net (I hope in java too), we wouldn't
even need to pass them by value either. (instantiating a java string
object, would always stay a java string object. On the .net side you
use it's wrapper counterpart).

If we could build a symmetric bridge that would work both ways, we
could even pass .net objects to the java side of the bridge. Working
the same way, the java side would never really have the object by
value, just the reference to it (contained in a java wrapper object
this time).

Norbert