# Wednesday, 18 February 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, 18 February 2004 09:36:11 (W. Europe Standard Time, UTC+01:00)  #    Comments [4]
Wednesday, 18 February 2004 12:27:57 (W. Europe Standard Time, UTC+01:00)
Is it possible to call ikvmc compiled java from a c# application?


don smith
Wednesday, 18 February 2004 13:03:17 (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, 19 February 2004 16:31:09 (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, 19 February 2004 16:46:56 (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.
Home page

I apologize for the lameness of this, but the comment spam was driving me nuts. In order to be able to post a comment, you need to answer a simple question. Hopefully this question is easy enough not to annoy serious commenters, but hard enough to keep the spammers away.

Anti-Spam Question: What method on java.lang.System returns an object's original hashcode (i.e. the one that would be returned by java.lang.Object.hashCode() if it wasn't overridden)? (case is significant)

Comment (HTML not allowed)  

Live Comment Preview