[Mono-list] Mono/Java interop?

[Ben Hutchison]

> -----Original Message-----
> From: Mathias Hasselmann [mailto:mathias.hasselmann@gmx.de] 

> On Thu, 7 Nov 2002, Ben Hutchison wrote:
> > Java's remote conventions are that if an object is passed 
> by reference
> > remotely, it should implement java.rmi.Remote interface. If 
> it does not,
> > and is Serializable (like JButton), then it should be 
> assume to support
> > pass-by-value. 
> > 
> > Why does it matter? Pass-by-value parameters are *copies* of the
> > orignal, and so changes made to them will not apply to the original.
> > There are applications which depend upon the 
> presence/absence of this
> > behavior, and will break otherwise. (Side note: same reason why in
> > distributed J2EE environment, you cannot "optimize away" 
> calls between
> > EJB components, even when hosted on the same machine; it breaks
> > semantics)
> 
> 	Uh-ha... Java design patterns aka. "How to work arround Java's 
> bugs..." ;-)

I think that's very unfair, else I don't understand what you think is a
"bug"?

The remote / local distinction is present in all object-based languages
that I know of, including C++, .Net and Java, and can be said to be
"designed into" them. It's a consequence of the fact that in-process,
objects are passed by reference. This isnt feasible across a network, so
RPC mechanisms introduce some means of distinguishing remote refs from
pass-by-value data.

> > How? I have never heard of such capability in standard Java 
> from Sun,
> > and I know Java well. AFAIK, you either need to talk the DCOM socket
> > protocol, or use native code, and both of these require 3rd party
> > (typically commercial) libraries.
> 
> 	I'm just citing parts of the Sun's JDK docs:
> 
>http://java.sun.com/j2se/1.4.1/docs/guide/jni/spec/intro.doc.html#16442
>	Well, but I have to admit: I did not follow this path yet.

Evidently. The passage you quote is from a discussion of RNI &
*Microsoft's* (extinct) JVM, and describes why Sun choose *not* to go
down that route. 
 
> A question re: CORBA strategy (basically it's the same issue as I
> discussed under bridging): 
>
>	See my other post: Dropped the CORBA strategy right now. Putting
a 
>PInvoke wrapper arround jni.h and friends right now.

I wouldn't jump on any solution too quickly myself. Or write off Corba.
Integrating the two major programming systems of this decade is not a
task to be taken on lightly, not will it be done overnight, IMO.

But a bit of experimentation and prototyping is certainly useful!

Regards
Ben