# Wednesday, 20 November 2002
map.xml

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, 20 November 2002 09:49:12 (W. Europe Standard Time, UTC+01:00)  #    Comments [3]
# Wednesday, 13 November 2002
F.A.Q.

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, 13 November 2002 10:42:17 (W. Europe Standard Time, UTC+01:00)  #    Comments [6]
# Sunday, 03 November 2002
Conference

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, 03 November 2002 18:52:13 (W. Europe Standard Time, UTC+01:00)  #    Comments [3]
# Friday, 01 November 2002
GetHashCode & reflection

What is the output of the following code fragment?

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

.NET 1.0 says:

193410979
23
193410979

.NET 1.1 beta says:

193410979
193410979
193410979

Mono 0.13 says:

101574
1554225471
1554225471

Mono 0.16 says:

101574
33369132
101574

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, 01 November 2002 14:41:12 (W. Europe Standard Time, UTC+01:00)  #    Comments [5]
Dependencies

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, 01 November 2002 11:01:07 (W. Europe Standard Time, UTC+01:00)  #    Comments [0]
# Tuesday, 29 October 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, 29 October 2002 17:03:28 (W. Europe Standard Time, UTC+01:00)  #    Comments [3]
# Friday, 25 October 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, 25 October 2002 16:55:13 (W. Europe Daylight Time, UTC+02:00)  #    Comments [0]
# Tuesday, 22 October 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, 22 October 2002 20:58:29 (W. Europe Daylight Time, UTC+02:00)  #    Comments [0]
# Thursday, 17 October 2002
No Title

More James...

I changed the class loader to use only one dynamic assembly and tried to run James again. It still doesn't run:

Phoenix 4.0a4

Application file://C:/james/apps/james.sar uses a deprecated packaging format.
There was an uncaught exception:
---------------------------------------------------------
--- Message ---
Unable to create BlockInfo as are unable to locate resource "org/apache/james/James.xinfo".
--- Stack Trace ---
org.apache.avalon.phoenix.interfaces.DeploymentException: Unable to create BlockInfo as are unable to locate resource "org/apache/james/James.xinfo".
        at org.apache...DefaultDeployer.deploy
        at org.apache...DefaultEmbeddor.deployFile
        at org.apache...DefaultEmbeddor.deployFile
        at org.apache...DefaultEmbeddor.deployFiles
        at org.apache...DefaultEmbeddor.deployDefaultApplications
        at org.apache...DefaultEmbeddor.execute
        at org.apache...frontends.CLIMain.run
        at org.apache...frontends.CLIMain.execute
        at org.apache...frontends.CLIMain.main
        at java.lang.reflect.Method.invoke
        at org.apache...launcher.Main.startup
        at org.apache...launcher.Main.main
Caused by: org.apache....assembler.AssemblyException: Unable to create BlockInfo as are unable to locate resource "org/apache/james/James.xinfo".
        at org.apache....assembler.Assembler.getBlockInfo
        at org.apache....assembler.Assembler.buildBlock
        at org.apache....assembler.Assembler.buildBlocks
        at org.apache....assembler.Assembler.assembleSar
        ... 12 more
---------------------------------------------------------
The log file may contain further details of error.
Please check the configuration files and restart Phoenix.
If the problem persists, contact the Avalon project.  See
http://jakarta.apache.org/avalon for more information.
Shutting down Phoenix.

(I editted the stack trace a little so that it doesn't mess up the formatting of the page too much).

I have no idea what this means and I don't feel like debugging this. May be I'll revisit James in a while when I've implemented more stuff and have better debugging support.

 

Thursday, 17 October 2002 17:44:55 (W. Europe Daylight Time, UTC+02:00)  #    Comments [5]
# Monday, 14 October 2002
No Title

Back again...

Friday I tried to get James (a mail server) to run under IKVM. First thing I ran into was the lack of support for extensions. That turned out to be easy to add. The next problem wasn't so easy to get around. I started getting TypeLoadExceptions. The only way this can happen is if there is a bug in IKVM or in the .NET runtime, because if a Java class cannot be found IKVM should throw a ClassNotFoundException or a NoClassDefError.

After much debugging I managed to isolate the problem as a bug the .NET runtime. Here is a small C# reproduction.

The problem was triggered by the new extension class loader, which creates a second dynamic assembly to emit the dynamically generated .NET types in. It turns out that references from one dynamic assembly to another dynamic assembly sometimes do not result in an AppDomain.TypeResolve event. The trigger for this is that the type being referenced was first defined inside another TypeResolve event.

Monday, 14 October 2002 10:48:52 (W. Europe Daylight Time, UTC+02:00)  #    Comments [3]