[Mono-list] Mono/Java interop - Usage scenarios

[Mathias Hasselmann]

On Tue, 12 Nov 2002, Ben Hutchison wrote:

> I felt the recent discussion on Mono (ie .Net) and Java interoperability
> rapidly became quite low-level. 
> 
> I want to step back for a moment to summarize the usage scenarios,
> because different ones suggest different solutions. Below I use the word
> "foreign" to mean "the other platform"; Java in a .Net context, and .Net
> in a Java context.
> 
> 
> 1. Transform Java bytecode to CIL, or the reverse
> 
> This would allow you to transform your binaries into a form that would
> run on the foreign system. Its more flexible and powerful than
> source-code level transformation, because it handles the many source
> languages that compile to both bytecode formats (C#, VB, Haskell; Java,
> Jpython, AspectJ), and because source code can be compiled then fed into
> such a tool. 
> 
> My understanding is that Java bytecode -> CIL would be much more
> feasible than the reverse. Roughly, CIL has a superset of Java
> capabilities. CIL has delegates (for which Java has no analog [anon-
> classes don't count!]) and the type-polymorphism (ie <templates>)
> planned for .Net future versions is more powerful than that planned for
> future Java.
> 
> IMO the bytecode transformation process would not be particularly
> difficult to implement. MS have done it for their JUMP and Visual J#
> products.
> 
> However, we hit the afore-mentioned obstacle of the Java (or .Net)
> libraries. Most code will be riddled with calls to standard APIs that
> will not exist in the target platform. (Because this is a deep, complex
> and undecided issue, I wont go further here, but refer the reader to
> other posts in the "Mono/Java interop" thread.)
> 
> Note that such a bytecode converter might be used on-the-fly like a JIT
> if it was sufficient fast.
> 
> 1. Transform Java bytecode to CIL, or the reverse

	Far too complex: We'd have to duplicate the huge amount of 
libraries written for Java. Would be kind of useless if the generated code 
doesn't hit Sun's compatibility tests. If I see how far VMs like caffee 
are today... If I see that even huge vendors like Oracle are stick with 
their Java forks on version 1.1.x.... Dunno if this is worth the effort. 
Think such a thing always would be in the state of a useless (since 
incomplete) geek toy.


> 2. Transform Java source code into C# (possibly the reverse)
> If a developer has some Java or C# source that they wish to use in a
> foreign system long-term, they will want to convert the source code to
> maintain it. Having a binary only converter (1) is not sufficient.
> 
> Such a tool would be less flexible than (1), probably operating on
> C#<->Java only. It is a definite second priority IMO to bytecode
> conversion. It may encounter similar difficulties to (1) regarding
> conversion of C# -> Java (lack of delegates, attributes, etc), and
> platform API support, but is otherwise quite feasible. MS have an
> implementation in JUMP.

	Yes, here could be some use for. Specially if people want to 
switch from Java to .NET. As Miguel pointed out having such a tool also 
could help stabilizing Mono since such a tool could offer a way to quickly 
generate huge amounts of code to feed Mono with.

> 3. Call into foreign binaries (eg libraries) locally from within a VM
> process
> 
> Theoretically, I think JNI allows this to be done, but I see many
> practical difficulties, including passing/returning objects types
> between CLR and JVM, and garbage collection between 2 systems, and
> controlling JVM lifecycle (eg shutdown at least).

	Have implemented such a thing over the weekend. It's named JNI#,
available from http://taschenorakel.de/mathias/toys.info. As the name
implies it's built as PInvoke wrapper arround the JNI API. Additionally
I've started to hack some convinience wrappers arround the JNI API.

	As you pointed out: Main problems to work out are two conflicting 
garbage collectors and shutdown of the JVM.



Ciao,
Mathias