Maybe a bug, or bad usage from my part: Resource loading fails for runtime loaded IKVM assemblies

[maxpiva]

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?

[wasabii]

I don't think VFS resolution should fail in this case. So I'd like to dig into why that is happening.

Can you explain how you're doing this? Precompiling the JAR into a DLL, then loading it using .NET strategies, AppDomain or AssemblyLoadContext or? Or are you just creating a ClassLoader and loading a JAR file like you would do in Java?

[maxpiva]

Runtime Resource Resolution Issue with IKVM Plugins

Scenario

• The main application ships with a base set of precompiled IKVM JAR classes (the ikvm directory is present under bin).

• At startup, the application downloads the IKVM runtime and tools.

• It then downloads a JAR-based plugin.

• The plugin JAR is compiled at runtime into a DLL, referencing the precompiled base JAR classes.

The resulting artifacts are stored in a plugin folder:

plugin/
plugin.jar
plugin.dll

Runtime Behavior

• The plugin host creates a new AssemblyLoadContext and loads the generated DLL, the host has strong dispose.
• Invoking managed methods from the plugin works correctly.

However:

• When the plugin code attempts to load any embedded resource via the Java ClassLoader (e.g., getResource*()), resource resolution fails.

Failure Details

• The issue appears inside IKVM.RuntimeAssemblyClassLoader.

• The stack trace shows a FileNotFoundException pointing to a path like:

\ikvm\win-x64\assembly<SOMEHEX>\plugin.jar

So RuntimeAssemblyClassLoader is attempting to resolve resources from a JAR located in that directory, but that JAR was never placed there in the first place.

Workaround

I was able to bypass the problem by implementing a custom Java ClassLoader that loads resources directly, instead, and adding the hook in the java bytecode.

Question / Suggestion

This might be useful information for IKVM’s resource resolution logic, or it’s possible I’m missing a required step in the runtime plugin flow.

Does RuntimeAssemblyClassLoader assume the original jar is always present on disk, even when the assembly is loaded dynamically?

[wasabii]

So just so you understand, this is very weird. If you want to load a JAR at runtime, you generally just load a JAR at runtime as you would in Java. You create a URLClassLoader and load it. You do not need to download the tools or precompile anything. It's just regular Java code.

That said, IKVM compiled static assemblies do not need the orignal JAR. The VFS exists to make a 'fake path' that the Java code can use that ultimately is redirected to .NET embedded resources.

Which should work fine. BUt the fact that you're manualy running the tools at runtime, I'd suspect you just aren't passing the correct options.

[maxpiva]

So just so you understand, this is very weird. If you want to load a JAR at runtime, you generally just load a JAR at runtime as you would in Java. You create a URLClassLoader and load it. You do not need to download the tools or precompile anything. It's just regular Java code.

😶‍🌫️

That said, IKVM compiled static assemblies do not need the orignal JAR. The VFS exists to make a 'fake path' that the Java code can use that ultimately is redirected to .NET embedded resources.

Which should work fine. BUt the fact that you're manualy running the tools at runtime, I'd suspect you just aren't passing the correct options.

Two questions come up:

Load / Unload Support

In my case, I need to be able to load and unload plugins at runtime, including multiple versions of the same plugin.

On the .NET side, I’ve been using AssemblyLoadContext specifically because it allows unloading by disposing the context.

Is there an equivalent approach on the JVM side with URLClassLoader?
In other words, can URLClassLoader be reliably unloaded so different plugin versions can be loaded dynamically, or is unloading not realistically supported in that model?

Replicating MSBuild / IKVMC Behavior

If I want to fully emulate what MSBuild does when building, is there documentation or a reference for the default compiler parameters it passes to ikvmc?

I noticed that DLLs generated manually with ikvmc differ from those produced via the MSBuild integration, and I haven’t been able to reproduce the exact same output or settings.

[wasabii]

On the .NET side, I’ve been using AssemblyLoadContext specifically because it allows unloading by disposing the context.

I think we do not support this quite correctly in IKVM. You might be running into one of those reasons. We could probably support this better.

Is there an equivalent approach on the JVM side with URLClassLoader?

It literally is URLClassLoader. Java has had dynamic loading and unloading since version 1.0. It is what a ClassLoader does. It loads classes. You unload the class loader and the classes go away eventually.

If I want to fully emulate what MSBuild does when building, is there documentation or a reference for the default compiler parameters it passes to ikvmc?

No. You'd have to read the MSBuild scripts. That said, we also rely very heavily on MSBuild itself to deliver the full compile closure. That is, all the reference assemblies from the specific target TFM. If you want to invoke ikvmc at runtime, you'll need the full SDK that you're targeting packaged along with the project itself.

[maxpiva]

Thanks :), was able to run it with URLClassLoader instead.
Nevertheless I have a recurrent on hardened tests.
0xC0000602: A fail fast exception occurred. Exception handlers will not be invoked and the process will be terminated immediately.

After trying different things, the issue got solved by a Copilot Hint:

Error: The process hit a CoreCLR FailFast (0xC0000602), terminating immediately without invoking managed exception handlers.
Why you’re getting it: Your ExtensionBridge.Test.exe_260126_124107.dmp runs on .NET 10.0.2 (net10.0) while it loads IKVM runtime libraries built for net8.0 and native jvm.dll/JNA components. This mixed runtime setup is unstable: the IKVM/Android.Compat stack spins Java threads and native poll loops, while the managed main thread is blocked awaiting an async operation. A version/ABI incompatibility in the runtime or native bridge triggers Environment.FailFast or an internal CoreCLR failfast path, causing the crash in coreclr.dll.
Root cause: Incompatible target frameworks and native IKVM/JNA components (net10 host with net8 IKVM artifacts) leading to a fatal runtime initialization/interop failure.
Possible fix:
•	Align target frameworks and packages:
•	Retarget the test project to net8.0 and use IKVM/Android.Compat packages for net8.0, or
•	Upgrade IKVM/Android.Compat to versions that explicitly support net10.0 and remove runtimes\win\lib\net8.0 binaries from your output.
•	Ensure native IKVM jvm.dll/JNA binaries match the managed runtime version and architecture.
•	Start Java/IKVM initialization off the main thread and add health checks before awaiting, logging initialization errors instead of letting them failfast.

After retargeting everything to net 8.0, and rebuild Android.Compat.jar in net 8.0.
the issue seems to be gone. I think the runtimes are not available yet on .net 10, and .net 8 are used, and that is the issue.

[wasabii]

I have no idea what any of this means. Android?

[maxpiva]

No worries, the Android compatibility layer is Java-based (a JAR) anyway.

The important part is that the issue disappears when targeting .NET 8, and the Copilot suggestion resolved it.

At the moment, when you reference the IKVM NuGet package in a .NET 10.0 project, it ends up pulling in .NET 8.0 runtime components, it seems.

[wasabii]

I'm pretty sure AI is making stuff up all around. IKVM does not "pull in .NET 8 Runtime components".

[maxpiva]

I pulled that out 😄

IDK, but targeting .NET 8 does resolve the issue. It might be something on my side, since I’m still using a prebuilt version of that layer from another project, instead of referencing the JAR directly. Because of the CIL issue mentioned in the PR. Nevertheless, that project was also .NET 10.

Next time, I’ll switch to feeding the compatibility layer directly in JAR form rather than as a DLL and then rerun full end-to-end tests on both .NET 10 and .NET 8 to confirm the behavior.

[wasabii]

What is this Android stuff?

[maxpiva]

it's an Android compatibility layer created in java and kotlin, that permits Suwayomi a Java based server, to run native android-based libraries. https://github.com/Suwayomi/Suwayomi-Server/tree/master/AndroidCompat, and I'm just doing poc:
android on java on ikvm on net. So yes, I'm runing android code on .net ;)

[wasabii]

Oh, that's interesting.

Should run fine on .NET 10 though. It would be interesting to actually figure out the issue there.