# Tuesday, August 1, 2006
« JaCIL | Main | New Snapshot »
.NET Generic Types

Recently I changed the way .NET generic types are handled by IKVM. The previous scheme was based on a naive mangling of the .NET Type.FullName property, but that turned out to be problematic for various reasons. The first obvious reason was that type names often were way too long for comfort. For example:

Type t = typeof(System.Collections.Generic.List<string>);

With IKVM 0.28 this prints out:

System.Collections.Generic.List`1[[System.String, mscorlib, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089]]
cli.System.Collections.Generic.List$$00601$$005B$$005B System$$002EString$$002C$$0020mscorlib$$002C$$0020 Version$$003D2$$002E0$$002E0$$002E0$$002C$$0020 Culture$$003Dneutral$$002C$$0020 PublicKeyToken$$003Db77a5c561934e089$$005D$$005D

(I manually inserted some spaces to make the HTML wrap.)

This obviously isn't very practical, but there is also a deeper problem. This literal translation of the name misses the fact that class loading in .NET is fundamentally different from class loading in Java. Which means that it is easy to go from Type to class name, but given a class name it is much harder to construct the corresponding type, especially if on or more of the type parameters are Java types (or remapped types).

In the next release the class name will be:


Not only more readable, but it also correctly reflects the fact that System.String is known as java.lang.String on the Java side.

I also changed the way these names are resolved to be more inline with the way Java works. The name is now parsed by the class loader that first tries to load the class which then in turn loads the component classes and constructs the generic type from that. This means that the following code will now work (if you can somehow convince your Java compiler to compile it):

import cli.System.Collections.Generic.*;

class Test
  public static void main(String[] args)
    List$$00601_$$$_LTest_$$$$_ list = new List$$00601_$$$_LTest_$$$$_();
    list.Add(new Test());

With the previous scheme there was no way to refer to the Test class in the generic class name, but now the correct class loader is used so you can refer to Java classes as well. That leaves only one question, what does list.getClass().getClassLoader() return? Well, for the time being I've decided to automatically construct a class loader that delegates to the defining class loaders of the classes used to construct the generic type, this ensures (as long as no types with the same names are used) that all types used in the definition of the generic type instance can be loaded by its class loader. It isn't actually clear to me that this is required, but at least for the time being it is, because some of the reflection code relies on this fact.

Finally, as a reminder, all this stuff is still experimental and, frankly, not intended to be practical. The main reason this support exists is to make the life of reflection/ikvmstub easier, otherwise the runtime would have to have all sorts of complicated support to deal with field types and method parameter/return types that take generic type instantiations.

Tuesday, August 1, 2006 3:11:32 PM (W. Europe Daylight Time, UTC+02:00)  #    Comments [0]
Home page

I apologize for the lameness of this, but the comment spam was driving me nuts. In order to be able to post a comment, you need to answer a simple question. Hopefully this question is easy enough not to annoy serious commenters, but hard enough to keep the spammers away.

Anti-Spam Question: What method on java.lang.System returns an object's original hashcode (i.e. the one that would be returned by java.lang.Object.hashCode() if it wasn't overridden)? (case is significant)

Comment (HTML not allowed)  

Live Comment Preview