# Saturday, 13 July 2002
No Title

Stuart commented on the previous item: ...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?

The way I plan to go about this, is to create a tool that generates jar files from .NET assemblies. The jar will contain all the public classes & interfaces from the .NET assembly, and all the methods will appear to be native. Standard Java compilers can then be used to compile against .NET code. The IK.VM will be aware of these special classes (they will contain an attribute to specify the fully qualified .NET type name) and reroute all access to these wrappers to the real .NET types. I haven't built any of this, but I don't expect any problems.

Saturday, 13 July 2002 10:31:48 (W. Europe Daylight Time, UTC+02:00)  #    Comments [1]
# Wednesday, 10 July 2002
No Title

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.

Wednesday, 10 July 2002 18:18:28 (W. Europe Daylight Time, UTC+02:00)  #    Comments [1]
# Monday, 08 July 2002
No Title

Many changes:

  • Added exception remapping support for some exceptions (NullReferenceException, IndexOutOfRangeException, InvalidCastException & TypeInitializationException)
  • Changed Throwable.printStackTrace() to print out stack traces in Java format
  • Partial support for retaining stack traces when exception is rethrown
  • java.lang.StringBuffer is now remapped to System.Text.StringBuilder
  • Rewrote file IO in classpath because it was buggy
  • Started on an ahead-of-time compiler that also emits debugging information (based on the debugging info in the Java classes)

Yesterday, I ran into a bug in MC++ when unboxing.

I've updated the snapshot and since I've made some changes to classpath, I've now put my modified version of that online as well.

Monday, 08 July 2002 12:28:53 (W. Europe Daylight Time, UTC+02:00)  #    Comments [0]
# Thursday, 04 July 2002
No Title

Updated the snapshot. Many fixes to the verifier and compiler and I also implemented a few more "native" methods. My company's database server product now works (at least partially), which is a pretty exciting step. It uses JNI to do its file I/O (because it runs on JDK 1.1), so it runs a little slower than under JDK 1.1, but hopefully that will improve once I've optimized the JNI method calling implementation.

Thursday, 04 July 2002 15:45:24 (W. Europe Daylight Time, UTC+02:00)  #    Comments [0]
# Tuesday, 02 July 2002
Benchmark

Just for fun, I tried to run a FFT program from the IBM Ninja (Numerically Intensive Java) package. After implementing a few more native methods, it ran, but to my surprise it ran about as fast as under JDK 1.4 (with Sun's Hotspot VM). Not bad for totally unoptimized code ;-)

The cfft.java source that I ran can be viewed here, the resulting executable (in a zip) can be found here and I've updated the project snapshot. For the array package, follow the Ninja link.

Tuesday, 02 July 2002 12:28:37 (W. Europe Daylight Time, UTC+02:00)  #    Comments [0]
J# released

Yesterday, Microsoft released J#. When I first looked at it yesterday, I was happy to find that they fixed the huge flaw that existed in beta 2. In the final version they have made java.lang.Object and java.lang.String aliases for System.Object and System.String. So they no longer require a "VerifierFix" to convert System.Object references to java.lang.Object references. Even so, they've decided to remove the AllowPartiallyUntrustedCallers attribute from the J# runtime libraries.

Unfortunately, the rest of the story isn't so positive. In only an hour of trying to compile my Java code, I already encountered three bugs in the compiler and one in the runtime. So I remain very sceptical about the quality of this product.

Tuesday, 02 July 2002 11:34:38 (W. Europe Daylight Time, UTC+02:00)  #    Comments [1]
# Friday, 28 June 2002
Status Update

"Hello, world!" is now fully verifiable. I haven't got all the corner cases of jsr support worked out, but the most important chunk of work in handling try {} catch {} blocks is now done. Next task is to translate the CLR exceptions (System.NullReferenceException, System.IndexOutOfRangeException, and may be others) into the corresponding Java exceptions.

Friday, 28 June 2002 16:03:39 (W. Europe Daylight Time, UTC+02:00)  #    Comments [0]
# Thursday, 27 June 2002
Status Update

"Hello, world!" now runs without first having to process the entire transitive closure of classes. It turns out that there is (what I feel) a bug in ModuleBuilder.GetType(string). It can be used to construct array types for types that have not yet been finished, but whenever you do that, it does fire the AppDomain.TypeResolveEvent, which caused me to finish the type (which wouldn't work because it was already in the process of being finished). Fortunately, it's easy to workaround, by setting a flag to ignore the TypeResolveEvent while inside ModuleBuilder.GetType().

Running "Hello, world!" takes slightly less than 2 seconds. So startup performance could be better ;-)

Thursday, 27 June 2002 14:33:14 (W. Europe Daylight Time, UTC+02:00)  #    Comments [0]
Naming

I removed the << from the title of the blog, because of Radio's problems with them.

Thursday, 27 June 2002 13:24:12 (W. Europe Daylight Time, UTC+02:00)  #    Comments [1]
Hello, world!

It's running! Those who have ever implemented a JVM know that running "Hello, World!" requires a very large percentage of the VM to be up and running, so I'm very happy to have reached this point.

If anyone wants to see the results for themselves, a zip file containing the executable and two dlls is available here.

The full project is available here.

There are still many things todo (in no particular order):

  • Implement jumping into and out of try blocks (run peverify on hello.exe to see what I mean ;-))
  • A few missing bytecodes need to be implemented
  • CLR exceptions need to be mapped to Java exceptions
  • Exceptions should retain their stacktraces even though they are thrown again
  • Many classpath native methods have to be implemented
  • Many JNI methods need to be implemented
  • Figure out how to deal with final fields (CLR initonly is not the same as Java's final. In Java a class is allowed to change a final field (although most JITs don't support that))
  • Figure out a way to make sure that generated types are finished in the proper order, to avoid deadlock. This is a major problem now, if I don't save the dynamic assembly before starting to execute the main method, the loading of classes deadlocks.
  • Many things I haven't even discovered yet ;-)
Thursday, 27 June 2002 12:39:22 (W. Europe Daylight Time, UTC+02:00)  #    Comments [2]