# Thursday, 21 November 2002
ikvmc

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.

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

Updated the binaries and source snaphots.

Thursday, 21 November 2002 12:53:45 (W. Europe Standard Time, UTC+01:00)  #    Comments [0]
# 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]