[Mono-list] Mono/Java interop?

[Mathias Hasselmann]

On Thu, 7 Nov 2002, Ben Hutchison wrote:

> > -----Original Message-----
> > From: Mathias Hasselmann [mailto:mathias.hasselmann@gmx.de] 
> > > (c) Complex pass-by-value objects which likely as not have no
> > > representation in the other framework; imagine sending eg a
> > > javax.swing.JButton to .Net (remember it cant instatiate it 
> > directly as
> > > .Net doesn't understand the Java class definition). How is 
> > .Net going to
> > > handle this piece of data?
> > 
> > 	Bad example: Why would you like to transport something 
> > complex like a 
> > JButton by value? 
> 
> Actually serializing Java GUIs is done, though its not common. I can be
> used to deploy user-interfaces over a network; the GUI is serialized up,
> sent to the client, and instatiated there and presented to the user.

	Hey, that sounds fancy. Always considered serialization as an 
evil way to create binary files. Never considered this useful usage...

> Method invokation on this object per 
> > reference would 
> > be natural and works like perfectly...
> 
> Per reference natural on a Jbutton? Granted, it could definitely be
> useful for a .Net app to create a Java UI, and manipulate its elements
> directly, by reference. But I have some concerns with manipulating
> arbitrary Java or .Net objects by (remote) reference ... 
> 
> 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..." ;-)

> > From my understanding of the .NET technology it should be possible to
> > teach C# late binding if this is possible for VB.Net already...
> > 
> Late binding is certainly possible in C# using Reflection.

That's what I'd think...

> > 	At least for Java on Windows it should be easy to 
> > integrate .Net 
> > objects into Java applications: .NET objects on windows automatically 
> > are COM objects. Java on Windows is capable to instanciate COM 
> > objects...
> 
> 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

"The Microsoft Java VM supports two native method interfaces. At the low 
level, it provides an efficient Raw Native Interface (RNI). The RNI offers 
a high degree of source-level backward compatibility with the JDK's native 
method interface, although it has one major difference. Instead of relying 
on conservative garbage collection, the native code must use RNI functions 
to interact explicitly with the garbage collector.

At a higher level, Microsoft's Java/COM interface offers a language- 
independent standard binary interface to the Java VM. Java code can use a 
COM object as if it were a Java object. A Java class can also be exposed 
to the rest of the system as a COM class."

	Well, but I have to admit: I did not follow this path yet.
 
> 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.


Ciao,
Mathias