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.

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.

"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.

"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

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.

Milestone! I just managed to JIT the entire transitive closure of classes required to run Hello World (304 classes).

It doesn't run yet, because I don't have the required classpath native methods yet and the resulting exe (708KB) contains tons of verification errors, but this is definitely an exciting step.

I had to make a few minor changes to the classpath source:

removed java/lang/CharSequence interface from java/lang/String and added workarounds to make it compile after this

removed equals() and hashCode() from java/util/Collection

removed equals() from java/util/Comparator

The equals() and hashCode() methods in interfaces don't really do anything, but at the moment I cannot handle them. It would be trivial to add code to handle them, but I don't want to hardcode that kind of stuff, all method remapping should be based on the XML file that defines the remappings.

I've been trying to get "Hello World" working with the classpath library. I implemented tons of bytecodes, fixed bugs and enhanced the method (and now field) remapping functionality. Still not there yet. I just ran into the problem that the constructors for java.lang.Throwable and System.Exception aren't the same, so for classes derived from java.lang.Throwable I will need to rewrite the call to the superclass constructor, to supply the proper arguments.

Yesterday, I wrote a partial bytecode verifier to track the types on the stack and in the locals, and based on this, today, I wrote a new bytecode compiler that, instead of decompiling the bytecode into an AST and then recompiling that (as I did previously) just converts individual bytecode instructions. This is a much better approach, as I will now be able to handle all sorts of weird code constructs not typically generated by Java compilers. Of course, it'll also be easier to handle the bytecode that is produced by the Java compilers.