[Mono-list] Mono/Java interop?

[Ben Hutchison]

> -----Original Message-----
> From: Miguel de Icaza [mailto:miguel@ximian.com] 
> Sent: 07 November 2002 18:57
> To: Ben Hutchison
> Cc: Mono List
> Subject: RE: [Mono-list] Mono/Java interop?
> 
> 
> hello!
> 
> > Although similar, I don't think the two libraries are close 
> enough to
> > perform this mapping successfully. I think such an approach 
> will provide
> > shallow interoperability that initally looks good, but 
> worsens the more
> > complexity you introduce. My personal feeling is that 
> cross-compilation
> > (like http://www.go-mono.com/java.html) doesn't add as much value as
> > "bridging"...
> 
> I think you should handle specially a few classes, and the rest would
> come from an existing class library like GNU Classpath.
> 
> > (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?
> 
> It is a problem for a full bridge, but not for a common subset.  For
> example, take the .NET Common Type System (CTS): it defines a 
> subset of
> the features available to languages (and it is for example a subset of
> C#, not every C# feature can be exposed to the CTS).
> 
> Trying to solve the very complex problem of a perfect mapping is the
> path to oblivion, you want to make a compromise, and go for a subset. 
> CORBA for instance defines a nice subset that maps to a 
> number of modern
> languages. 

Ok, Im starting to come around to this viewpoint. 

The large part of the Java libraries are written in pure Java (whether
they be Suns, GNU, IBMs, etc). These rest upon a few key classes (eg
Thread, Class, Runtime, SocketImpl) which use native code to access the
underlying OS functionality (similar to Mono).

If a mapping from these "foundation classes" onto the .Net equivalents
(which there almost invariably are) can be developed...

1.  A Java bytecode converter can "fix" Java method invocations on
foundation classes according to the mapping as it converts. If it
encounters a non-foundation method, it treats it as a normal compile
dependency and converts the referenced class too. If it hits a
non-foundation native method, it can throw an exception - bad luck!

2.  A remote bridge can make excellent use of the converted classes. Any
Java class that has been converted or is a foundation class can be used
as pass-by-value parameter, and remote refs/proxies to remote Java
objects can be downcast to ported/foundation Java interfaces.

I think this could (almost) really work.... I guess a next step on this
mapping idea is to study some parts of the foundation API, looking for
any aspects of the two libraries that are intractably different.

And on that note, I will allude to the one that bothers me most - which
Im going to write up in another post - the totally different way that
.Net and Java handle class/assembly loading, and the interaction with
AppDomains.

Regards
Ben