# Wednesday, February 18, 2004
« Jikes 1.19, Bytecode Bug, Serialization ... | Main | Object Model Mapping »

Stuart pointed out the F.A.Q. was out of date, so I updated it a little bit. He also asked:

Speaking of which, I noticed while perusing the FAQ that the JIT compiler is included in IK.VM.NET.dll which means it's required for running even statically-compiled code. For apps that don't use clever classloading tricks, the JIT isn't needed at all when everything's been statically compiled. Would it be possible to separate the JIT out into a different DLL to reduce the necessary dependencies for a statically-compiled Java app?

Sure, the 275K of IK.VM.NET.dll is miniscule compared to the 3Mb of classpath.dll, but it's the principle of the thing ;)

This is definitely something I want to do. In fact, I would also like to have the option to only include parts of the Classpath code when statically compiling a library. So instead of having a dependency on classpath.dll, you'd suck in only the required classes.

Wednesday, February 18, 2004 9:36:11 AM (W. Europe Standard Time, UTC+01:00)  #    Comments [4]
Wednesday, February 18, 2004 12:27:57 PM (W. Europe Standard Time, UTC+01:00)
Is it possible to call ikvmc compiled java from a c# application?


don smith
Wednesday, February 18, 2004 1:03:17 PM (W. Europe Standard Time, UTC+01:00)
Yes! Look at starter.cs [1] (the source of ikvm.exe) for an example. It subclasses and instantiates the GNU Classpath ClassLoader to load the main class and uses Java reflection to execute the main method.

[1] http://cvs.sourceforge.net/viewcvs.py/ikvm/ikvm/ikvm/starter.cs?view=markup
Thursday, February 19, 2004 4:31:09 PM (W. Europe Standard Time, UTC+01:00)
I read somewhere (one of the Mono lists, I think, discussing regular expression compilation to assemblies) that there's no way using System.Reflection.Emit to suck a type out of one dll and emit it into another. That would seem to be a problem for your plan to suck types out of classpath.dll

Potential workarounds: You could compile chunks of classpath from bytecode each time. Or perhaps have a "semi-compiled" version of classpath.dll lying around in a format that you *can* suck types out of without having to recompile them.
Thursday, February 19, 2004 4:46:56 PM (W. Europe Standard Time, UTC+01:00)
That's right. I wasn't planning on sucking the types from classpath.dll, but from the classpath classes (or jar), but I also have to say that this functionality is not likely to appear any time soon. At the moment there is still a lot of higher priority stuff to do.
Comments are closed.