Class loading is a complicated subject in Java, and IKVM11 makes it more so. In Java each class is expected to have an associated class loader by which it can resolve additional classes or resources at runtime. And each class loader has a clear hierarchy of parent class loaders by which it can dispatch requests. This is quite unlike .NET which has a more tangled runtime dependency model.

Within the IKVM11 dynamic model, the traditional Java class loader design is respected. Thus you can create instances of URLClassLoader and others, parent them to each other, and expect it to work. Existing Java code should work without changes when loaded dynamically.

Static compilation is a different matter. When static compiling your Java code to a .NET assembly all that remains at runtime is the .NET assembly. There is no Class Loader that caused that code to launch. It's just assemblies present in the AppDomain or AssemblyLoadContext. However, Java code needs to still be able to examine .NET types at runtime and find a java.lang.ClassLoader associated with the java.lang.Class types you are accessing. To accomplish this we introduce ikvm.runtime.AssemblyClassLoader.

ikvm.runtime.AssemblyClassLoader serves as the fake class loader type assigned as the class loader of .NET types visible to Java. Each .NET assembly is given a unique AssemblyClassLoader instance. These class loaders however do not have a parent. Instead, they implement class and resource lookups using a delegation model, forwarding the request to the other assemblies referenced by the starting assembly. This takes the .NET assembly reference information and ensures that if one assembly depends on another assembly the seconds resources are accessible to the first.

The short story of this is that when Java code is compiled statically into .NET assemblies, it no longer falls into the same class loader hierarchy as Java code loaded dynamically. At runtime, for this statically compiled code, there are no class paths and no class path order to be concerned about, etc. As long as the assemblies properly reference their dependencies they have access to resources of those dependencies.

Class paths and class path order however remain important during static compilation itself.