# Friday, 17 January 2003
Hello Mono

Zoltan Varga wrote on the ikvm-developers list:

   After lots of hacking, I managed to get IKVM to run HelloWorld under mono. This involved lots of changes/bugfixes to IKVM, the mono runtime and the class libs. I intend to submit a big patch to the mono mailing list shortly with the changes.

Great news!

Unrelated to the above, I checked in a bunch of changes and updated the source and binary snapshots. I'll be out of the country for two weeks, so there probably won't be much activity.

Friday, 17 January 2003 22:04:28 (W. Europe Standard Time, UTC+01:00)  #    Comments [1]
# Thursday, 16 January 2003
No Title

Ted Neward wrote:

All this really does, though, is help underscore how fundamentally broken the Java ClassLoader model really is. CLASSPATH is a gross hack and should be deprecated immediately (as in entirely absent from JDK 1.5 and up), and issues like verisoning and JAR-to-JAR dependencies resolved in a more sane and reasonable fashion. Anybody out there in bloggerland willing to go in with me on a new JSR? [The Mountain of Worthless Information]

I couldn't agree more. I've sent him an e-mail offering to help out with the JSR.

Thursday, 16 January 2003 13:09:15 (W. Europe Standard Time, UTC+01:00)  #    Comments [0]
# Saturday, 11 January 2003
custom modifiers and return type custom attributes

Suppose you have the following Managed C++ class:

__gc class Foo {
  void foo(int i) {}
 
void foo(long l) {}
};

How is this compiled? The problem, of course, is that int and long are both signed 32 bit integers. A type cannot have two methods with exactly the same signature. To solve this problem the CLR has custom modifiers (see Partion II Metadata.doc, section 7.1.1). ILDASM shows the above methods as follows:

[...] void  foo(int32 i) [...]
[...] void  foo(int32 modopt([Microsoft.VisualC]Microsoft.VisualC.IsLongModifier) l) [...]

The long parameter is annotated with the optional modifier Microsoft.VisualC.IsLongModifier. Modifiers are part of the signature, so it is legal to have signatures that differ only by modifier.

Now, suppose IKVM.NET is compiling the following Java class:

class Foo {
  Bar foo(Bar o) {}
  Baz foo(Baz o) {}
}

Also suppose that Bar and Baz are not yet available when the class is compiled. For the types that are not available, java.lang.Object is substituted, so now we again have two methods with the same signature. It would have been nice to use a custom modifier to resolve this, but this isn't possible for two reasons:

  1. custom modifiers are not supported by Reflection.Emit (in .NET 1.0 and 1.1)
  2. custom modifiers do not accept any arguments, only a type (it would be possible to generate a type for each modifier, but that would hardly be an elegant solution)

The solution is to use method name mangling. The next problem is that we need a place to store the name of the class that the arguments and return value actually are. The most obvious way to do this is custom attributes. Method arguments (parameters) can be annotated with custom attributes using MethodBuilder.DefineParameter(...). Parameters are indexed starting at one, this (and the ilasm syntax) suggests that zero refers to the return type, unfortunately DefineParameter throws an exception when it is called with zero. This bug also exists in both .NET 1.0 and 1.1. Again the work around is easy, just emit a method attribute and put the real return type class in there.

Saturday, 11 January 2003 12:02:32 (W. Europe Standard Time, UTC+01:00)  #    Comments [3]
# Sunday, 05 January 2003
Why Eclipse

Someone wondered why I chose to try to get Eclipse to run. Three simple reasons:

  • Mark Wielaard posted his success story on the GNU Classpath mailing list.
  • It's a complicated application and that really helps to find bugs.
  • It doesn't require AWT. It will be quite some time before AWT will be done (if ever), so for the time being console (or SWT) applications are all I can use.

Status update: I've been doing a lot of rewriting in the verifier/compiler. I now feel that I finally understand class loading (in particular, what happens when a class is not found). In the verifier and in the compiler, class names are now no longer used, instead references to the TypeWrapper class are used to identify types. This isn't just a performance optimization, but also a requirement because class names aren't necessarily unique (only within a class loader). Still no support for different classes with the same name though, it's getting closer though.

The reason I started this rewriting, is to enable dynamic binding when a class isn't found. The current compiler just inserts a throw NoClassDefFoundError when it encounters a type that couldn't be loaded (and if the verifier needed to load the type, the whole method will just be replaced with code that throws a VerifyError). This is not what the Sun JVM does, it actually retries to load the class everytime the method executes. To simulate this behavior I'm going to emit late bound code in the cases where a class isn't available when the type is compiled. After all this is done, I should be able to run Eclipse without the -Xbootclasspath workaround.

Sunday, 05 January 2003 16:01:01 (W. Europe Standard Time, UTC+01:00)  #    Comments [1]