When a Java JAR is compiled into a DLL and loaded at runtime (plugin scenario), any attempt to load resources via getResource() fails.

Observed behavior

If everything is compiled and loaded together, resource resolution works correctly.
In that case, it seems a Virtual File System appears to point back to the original jar.

However, when the Java-compiled DLL is loaded dynamically at runtime, resource loading breaks because the VFS tries to resolve resources from a jar file that does not exists in the ikvm\win-x64\assembly\ directory.

Root cause

The issue seems to originate in RuntimeAssemblyClassLoader, which reference a non-existent jar-backed VFS when the assembly is loaded dynamically.

Suggestion

Would it be possible for RuntimeAssemblyClassLoader to fall back to ikvmres: when VFS resolution fails?

My understanding is that ikvmres: will be able to resolve the resource? correct?

For example:

If the VFS lookup fails,

then automatically attempt to resolve the resource from the embedded DLL jar resources (ikvmres:).

Possible approaches

Add a fallback mechanism inside RuntimeAssemblyClassLoader

Or introduce an additional ClassLoader that redirects resource lookups to ikvmres:

I attempted to subclass the existing Java class loaders in ikvm.runtime, but they are final, so creating a custom loader is not straightforward.

Any suggestions how to accomplish this?