I changed the Java to native code transition from my own MC++ marshaling to use the calli instruction. The code is much more elegant now, not to mention much faster. My database app now performs on a par with JDK 1.1. Not bad at all.
Also, I implemented support for interfaces that "override" java.lang.Object methods and I remapped java.lang.Comparable to System.IComparable. Both of these features use the same underlying mechanism, i.e. the ability to provide explicit interface implementations that redirect to virtual methods with a different name.
My interest in this project has always been from the perspective of making Java a full-fledged .NET language. From that perspective, as I see it, the tricky challenges are (1) what you've already done - running the Java code inside .NET; (2) making the Java compiler aware of .NET classes somehow, so that Java code can call .NET methods natively, and (3) making .NET aware of the Java classes, so that .NET code can call the Java stuff. It seems to me that (1) is all-but-solved already by your work and (3) is just a matter of running your program in ahead-of-time mode and putting the resulting binaries into the GAC (or whatever .NET's equivalent of $CLASSPATH is).
That leaves #2, which seems hard to me. At the very least, it seems like it would require changes to the Java language compiler to interpret (at least metadata from) .NET classes and allow for those to be in the CLASSPATH at compilation time. Is that something you're interested in pursuing as part of IKVM, or do you regard it as a separate problem?
Powered by: newtelligence dasBlog 2.3.12105.0
© Copyright 2021, Jeroen Frijters
E-mail
E-mail