[Mono-list] Mono/Java interop?

[Ben Hutchison]

> -----Original Message-----
> From: mono-list-admin@ximian.com 
> [mailto:mono-list-admin@ximian.com] On Behalf Of Norbert Harrer
> Sent: 07 November 2002 17:57
> 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.

[removed mechanics of passing/using proxies across bridge, which I
basically agree with]

> 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).

Norbert,

I see several challenges for your scheme. (please refer to my later post
"Mono/Java interop - Usage scenarios" for more context) 

1. Java and .Net types are not unified and thus still incompatible; have
you actually achieved "interoperability"? 

Eg imagine I wish to use a Java formatting library to format a String I
have in .Net. The formatted Java String I have can never be used in my
CLR in place of a .Net string, because they are distinct types. Imagine
the following C# code, using your wrapper system.

java.lang.String s = new String("abc);
java.lang.String formatted = java.formatter.MyFormatter.format(s);

//this line will blow up, because java.lang.String != string
TextField.setText(formatted);


Do you see the problem? You cannot have substatial interoperability
without some shared understanding; that is, some degree of unification
of the type systems. Otherwise you have parallel worlds, which can only
exchange information via primitives, and that's primitive ;)

2. Performance using proxies for all objects passed across the bridge
will be extremely poor in the remote bridging scenario. Every access to
the objects fields will involve a remote call! Not such a problem for
in-process bridging, however.

Regards
Ben