When using IKVMReference, is it possible to create the same environment as when using Launcher.Run?

[kdaek21]

There are cases where exceptions such as ClassNotFoundException occur even though they are included in the Compile options and compiled together, so I checked and tested various things.

When using Java code compiled with IKVMReference in C# code, it was confirmed that when loading a class using ClassLoader's loadClass in Java code, the class is not found and ClassNotFoundException or NoClassDefFoundError occurs. (If you use the class in a general way or Class.forName, the class is found without a problem.)

When creating a main method in Java code and running it using Launcher.Run, it works fine. It seems that Launcher.Run also adds the assembly specified to the class loader.

Therefore, is there a way to add the assembly to the class loader like Launcher.Run does?

• If you add a jar containing the class to be found to java.class.path as a property and place the jar file in the same path, the class will be found in that jar and run normally.

[wasabii]

The Java class loader hierarchy and .NET assemblies are very differnet things. So it's important to understand how IKVM fabricates a class loader hierarchy given .NET classes in .NET assemblies.

Each .NET assembly is exposed to Java code in it's own ClassLoader. It's own isolated one. This is because multiple
.NET assemblies can have types with the same name, where as this isn't really a possibility in Java. In Java there is one classpath, and the first matching class name in that path is it.

This fictional class loader is called the AssemblyClassLoader. So, when accessing a .NET type from Java-land, you will see that each corresponding Class will have a reference to it's assemblies ClassLoader: clazz.getClassLoader(), for a .NET type, will return a ClassLoader specific to the assembly that originated that type.

There is a form of parenting here as well. Typically Java class loaders form a single rooted hierarchy, with the application or bootstrap class loader at the top, and everything else a child of it. This isn't how AssemblyClassLoader works. AssemblyClassLoader is tied to a single assembly, and there is no such thing as a "parent assembly", only assembly references. That is, one assembly can reference another assembly. Or they can reference each other. There's no clear hierarchy. But AssemblyClassLoader does provide a sort of delegation to assemblies which are referenced from the current assembly.

So, imagine you have three assemblies, AssemblyA depends on AssemblyB which depends on AssemblyC. If you do findResource or findClass on AssemblyA, you will be able to see types or resources in B and C. But, if you do it on B, it will only show C. And C can only show C.

So, it very much depends on which class loader you are using to try to discover another class or resource.

IKVM.Runtime.Launcher is different: there are no relevant .NET assemblies. IKVM.Runtime.Launcher loads JAR or CLASS files, just like java.exe does. There are no fake class loaders for assemblies because none of the user code is an assembly to begin with.

[kdaek21]

After searching around, I found that 'ikvm.runtime.Startup.addBootClassPathAssembly(..)' is provided, and after applying ikvm.runtime.Startup.addBootClassPathAssembly(typeof([Java class built as Assembly]).Assembly); and running it, I confirmed that the 'Java class built as Assembly' entered in addBootClassPathAssembly was also added to the top-level classloader, and that the class used by loading it through ClassLoader in the Java code in the statically built assembly was also found and operated normally.