# Friday, November 22, 2002

I tried to get Eclipse to run. This led to an interesting series of events:

  • I found that I didn't set the ProtectionDomain of a Class instance. Fixed.
  • I found that FileOutputStream in append mode didn't work. Fixed.
  • I found that Eclipse requires a 1.3.0 VM, but doesn't give any feedback whatsoever if the version isn't good enough. Workaround: ikvm -Djava.version=1.3.0
  • The bytecode compiler didn't implement migrating uninitialized object references into and out of try-blocks. Fixed.
  • The version of java.io.File.listFiles() that I used couldn't deal with the native method returning null. Fixed by getting the latest version from CVS.
  • Classpath's java.net.URL has bug where it doesn't try its own pool of protocol handlers, if a factory is installed, but the factory refuses a particular protocol. In order to fix this, I first had to update my Classpath code, to get the most recent URL code (it changed quite a bit, but the bug is still there).
  • After I got the latest version of Classpath from CVS, jikes would hang when compiling (it later turned out that jikes wasn't hanging, but that it was actually nAnt, but at that moment I suspected jikes).
  • I downloaded a new version of jikes, 1.18 (the version I was using was 1.15), generally tried as sorts of stupid things (including accidentally deleting my whole Classpath tree).
  • Not exactly sure why, but this whole exercize caused a number of bugs to appear when compiling classpath.dll. Here are some examples:
  • When this code is compiled by jikes 1.15:
    class Outer {
        private static class Inner {
            private Inner() {}
        public static void main(String[] args) {
           new Inner() { };
    First of all, I don't why this is legal. IMO since the constructor of Inner is private, you shouldn't be able to instantiate in Outer, but Sun's 1.4 compiler compiles it, and so does jikes. However, jikes 1.15 actually emits code that calls the private constructor from the constructor of the anonymous class. This is clearly incorrect (and it is fixed in 1.18), but it took me a while before I had figured out what was going on. BTW, the "correct" compilation is to inject a synthetic constructor in Inner that accepts a reference to the Outer class (and has package accessibility).
  • jikes doesn't generate Miranda methods. Take the following class, for example:
    abstract class Foo implements Runnable {
        Foo() {
    This compiles (and is legal). When javac compiles this code, it inserts an public abstract void run() method into Foo, this method is called a Miranda method. Older VMs (probably in the 1.0 time frame) didn't think the class was valid without this method. Jikes doesn't do this and IK.VM.NET couldn't handle that. Fixed.
  • Access check for fields had a bug. java.awt.Component directly accesses the id field of several events, this is legal because in the java.awt.AWTEvent class the id field is declared protected (which also implies package accessibility). However, jikes 1.18 decided that the reference to the field should not be compiled as a reference to java.awt.AWTEvent.id, but to (e.g.) java.awt.event.ComponentEvent.id, perfectly legal, because the field is inherited, but the compiler incorrectly did the package accessibility check on the class name in the reference, instead of on the class name where the field is actually declared. Fixed.

At the moment I'm stuck on an exception that the .NET framework throws (when I'm compiling classpath.dll with ikvmc):

System.TypeLoadException: Method getBounds2D in type java.awt.Rectangle from assembly getBounds2D does not have an implementation.
   at System.Reflection.Emit.TypeBuilder.TermCreateClass(TypeToken handle, Module module)
   at System.Reflection.Emit.TypeBuilder.CreateType()

I have no idea why this happens. Interestingly enough, it doesn't happen when I compile with jikes 1.15.

Friday, November 22, 2002 3:45:26 PM (W. Europe Standard Time, UTC+01:00)  #    Comments [0]
# Thursday, November 21, 2002

Inspired by Stuart's comment to yesterday's post, I decided to clean up ikvmc a little to make it possible to compile executables.

Other changes:

  • it's now possible to specify an IL implementation of a native method in map.xml. At the moment this is used only for System.identityHashCode() to solve this issue.
  • map.xml is now parsed using the XmlSerializer (see yesterday's post on why this is not a good idea)
  • implemented a work-around for the stack overflow that occurred when the compiler couldn't find java.lang.ClassNotFoundException
  • ikvm now supports -classpath switch (thanks dIon)

I've only compiled a simple Hello World type executable with ikvmc and here are some things to look out for:

  • all classes (or jars) that are referenced by the application must be specified (except for the Classpath classes)
  • a reference (-reference:<path>) to the classpath.dll must be specified
  • when compiling an executable the class containing the main method must be specified
  • code that expects to be loaded by the system classloader will probably not work. Statically compiled code will be loaded by the bootstrap (aka null) classloader.

    ikvmc -out:hello.exe -reference:bin/classpath.dll -main:Hello Hello.class

Updated the binaries and source snaphots.

Thursday, November 21, 2002 12:53:45 PM (W. Europe Standard Time, UTC+01:00)  #    Comments [0]
# Wednesday, November 20, 2002

I wasn't happy with the handling of map.xml, so I rewrote the code that deals with it to use XmlSerialization. Cool stuff, but it turns out to be totally unsuitable for this purpose. I only need to parse the xml file once (at startup of the VM), and the XmlSerializer generates a C# file (and compiles it) to do the parsing. This is great if you have to parse lots of files (that adhere to the same schema), but it is very wasteful (i.e. slow) if you only need to parse a single file.

After a lot of thinking, I came to the conclusion that I should statically generate an assembly from the map.xml file. In other words, compile it.

Other thoughts: I'm still trying to find ways to make implementing the classpath "native" methods easier (and more efficient, by getting rid of reflection) and I'm contemplating the following idea: Turning classpath.dll, ik.vm.net.dll & the new compiled map.xml into a multi module assembly. This solves two problems: 1) The native methods implementations no longer have to be public, 2) native methods can be statically compiled against the non-native (i.e. compiled Java) code. Downside: more icky circular dependencies and it won't be possible anymore to run without a precompiled classpath.dll

Wednesday, November 20, 2002 9:49:12 AM (W. Europe Standard Time, UTC+01:00)  #    Comments [3]
# Wednesday, November 13, 2002

I wrote a small F.A.Q. that hopefully answers most questions people have without them having to go read through the entire history of the project.

It lives here.

Wednesday, November 13, 2002 10:42:17 AM (W. Europe Standard Time, UTC+01:00)  #    Comments [6]
# Sunday, November 3, 2002

Yesterday I arrived in Keystone, Colorado for the Colorado Software Summit, a most excellent Java & XML conference.

I hope to get some hacking done this week, but if I don't it'll be because I'm having too much fun at the conference ;-)

Sunday, November 3, 2002 6:52:13 PM (W. Europe Standard Time, UTC+01:00)  #    Comments [3]
# Friday, November 1, 2002
GetHashCode & reflection

What is the output of the following code fragment?

  object o = "foo";
  Console.WriteLine(typeof(object).GetMethod("GetHashCode").Invoke(o, null));
  Console.WriteLine(typeof(string).GetMethod("GetHashCode").Invoke(o, null));

.NET 1.0 says:


.NET 1.1 beta says:


Mono 0.13 says:


Mono 0.16 says:


Note: the actual numbers are irrelevant, it matters if they match up or not.

.NET 1.1 is correct, the others aren't. The funny thing is, I just realised that IK.VM.NET currently depends (for its System.identityHashCode implementation) on the broken behavior.

.NET 1.0 only behaves this way for methods in String, for other types reflective method invocation works the same as a virtual method call.

In Mono 0.16 all reflective method invocations appear to be non-virtual.

Friday, November 1, 2002 2:41:12 PM (W. Europe Standard Time, UTC+01:00)  #    Comments [5]

Thanks to Zoltan Varga for trying to compile IK.VM.NET on Mono. He pointed out some problems:

  • I used the undocument C# __arglist keyword in my multianewarray helper method, but since Mono's C# compiler doesn't support that and it isn't part of the standard, I reworked that to get rid of the __arglist construct.
  • zlib.dll is a part managed part unmanaged dll, and thus it will not run on Mono. I removed the zlib.dll dependency and I've changed ikvmc and netexp to use java.util.zip.* from classpath.dll.

This change has introduced a circular dependency: ikvmc is used to generate classpath.dll, but it also depends on it.

Other changes:

  • started on NAnt build files, to support building the project outside of Visual Studio .NET, and (in the future) hopefully without platform dependencies.
  • All Classpath's native methods are now (at least partially) implemented, except for java.nio.*

Updated the binaries and source snaphots.

Friday, November 1, 2002 11:01:07 AM (W. Europe Standard Time, UTC+01:00)  #    Comments [0]
# Tuesday, October 29, 2002
java.lang.Thread issues

I worked on java.lang.Thread and ran into two issues. In .NET it is not possible to:

  • obtain the interrupted status of a thread (other than the current thread)
  • test for Monitor ownership

I worked around the interrupted status issue by always returning false when you query a thread other than the current thread :-( and to test for Monitor ownership I do a Monitor.Wait on the object, with a timeout of 0. That works, but it isn't safe, because Wait temporarily releases the Monitor (if we do own it), and that could cause a deadlock :-(

Tuesday, October 29, 2002 5:03:28 PM (W. Europe Standard Time, UTC+01:00)  #    Comments [3]
# Friday, October 25, 2002
James works (sort of)

James now works. Where works is defined as: accepts incoming e-mail via SMTP and allows me to read that e-mail through POP3.

I made some major changes to support reflection, still not completely done yet, but most reflection based code should work now. Also implemented support for Serialization.

Updated the binaries and source snaphots.

Friday, October 25, 2002 4:55:13 PM (W. Europe Daylight Time, UTC+02:00)  #    Comments [0]
# Tuesday, October 22, 2002
No Title

Yet more James...

I managed to get James to start up! I had to implement a whole chunk of reflection stuff that I hadn't yet implemented. It still isn't anywhere near finished, but it is starting to look a lot better. The architecture is starting to shape up. One of these days I'm going to draw some pictures and write up something about the IKVM architecture, if I can find the time.

Thanks to Mark Wielaard for debugging the resources issue (see previous item).

Tuesday, October 22, 2002 8:58:29 PM (W. Europe Daylight Time, UTC+02:00)  #    Comments [0]