[Mono-list] Mono/Java interop?

[Ben Hutchison]

> -----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.
They are also IDE builder tools the save out and reload configured GUIs
in serial form.

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)

> 
> > While I don't think there's a *general* solution for (c), it can be
> > imporved by building a mapping for a wide variety of common 
> Class-Type
> > pairs. 
> 
> 	I only see the need of recreating the interfaces of the 
> referenced 
> objects by using reflection mechanisms. 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.

> > Since this is a .Net focused list, I guess there is greater 
> interest in
> > making Java work with .Net than the other way round. 
> 
> 	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.

 Something I doubt is the assumption you could have Java 
> objects in .Net apps without being able to create .Net 
> objects in Java 
> apps....
> 
>  > Therefore,
> > obtaining or producing some specification of the Remoting binary
> > protocol seems a critical early step. This may mean 
> reverse-engineering
> > it from the shared source CLI.
> 
> 	I strongly double Rotor's license allows this. The the 
> statement about 
> this on http://go-mono.com/.

If a person posts an accurate spec of binary remoting protocol on the
web, which mono becomes compatible with, what are MS going to do? Sue
the person that wrote the spec? Its like Samba or MS Word all over
again; you cant prevent reverse engineering of a widely used protocol
forever.

> 
> > Alternately, I think Daniel Morgans idea of a CORBA channel 
> has merit;
> > Java already has excellent support for CORBA, and this sidesteps the
> > need to develop wire protocol code.
> 
> 	I don't see CORBA just as an alternative. In my opinion 
> providing CORBA 
> support in Mono would be the most valuable solution:
> 
> 	a) CORBA support has some value per se (crossplatform,
>             accepted standard, ...).
>          b) Java already has good CORBA support, so we only 
> would have to
>             build the other end of the bridge.
> 	c) Having CORBA support in Mono would speedup Bonobo integration
>             of Mono and therefore would improve GNOME integration of
>             Mono.
> 
> 	The main question to work out about this: Does the OMG 
> have defined 
> CORBA bindings für CIL already? Or does Microsoft have 
> defined some? Or 
> is there at least a working group in the OMG working on this issue?

A question re: CORBA strategy (basically it’s the same issue as I
discussed under bridging): 

How do I call methods that take object parameters whose types don't
exist in the callers world? 

Eg A .Net client calling
java.security.Certificate.verify(java.security.PublicKey)?

Regards
Ben