[SUGGESTION]: Better internal working pipeline

[redplcs]

My suggestion is inspired by Kotlin for Forge mod

I think we should add specialized mod that will handle CIL compilation of .NET binaries into machine code and link API (e.g. Neo-Forge or Minecraft) with specialized mod loader via injecting machine code into JVM output.

Modder creates simple class-library .NET 9 project, imports CSharpBridge package, imports specialized mod loader wrapper package to work with (e.g. CSharpBridge.ModLoaders.NeoForge) and writes the code. The end user must import custom .jar mod that will load .NET binary and inject mod loaders wrapper methods into mod loaders itself. Basically scan .NET assembly for specified mod loader wrapper package.

For example, I want to write mod for Forge

I have to create simple class-library for .NET 9. I have to import CSharpBridge.ModLoaders.Forge to make mod for forge. This package must also have implicit reference to CSharpBridge.Minecraft package.

After importing specialized mod loader wrapper, I'm writing code like it was made for original Forge. To archive this, mod loader wrapper must have similar APIs to original Forge library.

The end user who's want to play with my mod must import intermediate mod dependency that will handles with .NET binaries.

Internally intermediate mod must handle .NET compilation (It takes .NET binaries with CIL code, compiles it via crossgen2, inject .NET machine code via JNI into mod loader methods).

Note that compilation must be happen on end-user, because we can't just compile into machine code on compilation stage, because we will get the platform-specific code. It will much harder to distribute those binaries for modders

Let's call this intermediate mod: .NET for %mod-loader-name-here%

[kiseiju04]

Interesting idea, if I understand this would be easier to use the .NET mod ad dependency in the .NET environment. How would you implement the .NET compilation and the JNI?

[redplcs]

How would you implement the .NET compilation and the JNI?

Honestly, there is plenty of ways how to archive it. You can wrap Modloader into COM, invoke native code from JNI, use shared resources like RPC, SOAP, maybe Kafka, RabbitMQ e.t.c. We need find the solution that will be high-performance and does not rely on .NET's VM (nor Mono, nor CLR). I'm not a big expert of Java and might be wrong somewhere, so treat what I'm saying with scepticism

Developers expect to be able to call native ModLoader APIs and receive calls, or react to events, from the Minecraft APIs using code written in one of the .NET managed languages. I was searching for already existing bridges and I found one that should be working out of the box: .NET for Android, or more specifically (Java.Interop). It's allows to interact with Java through JNI with fully nesting hierarchy compatibility. It's developed by Microsoft and uses inside of Xamarin.Android and MAUI, and also design to be runned outside of Android scope:

However, it is designed to be fully independent of Android and should be usable by other Java implementations

What we need is to (somehow) use this technology to generate Modloaders API into C# wrapper library.

I found a few articles that might be useful:
https://learn.microsoft.com/en-us/dotnet/maui/android/internals/java-interop?view=net-maui-9.0
https://learn.microsoft.com/en-us/dotnet/android/binding-libs/binding-java-libs/binding-java-library
https://learn.microsoft.com/en-us/previous-versions/xamarin/android/platform/binding-java-library/
https://github.com/dotnet/java-interop/wiki/Understanding-the-Binding-Pipeline
https://learn.microsoft.com/en-us/dotnet/android/building-apps/build-process?toc=%2Fdotnet%2Fmaui%2Ftoc.json&bc=%2Fdotnet%2Fmaui%2Fbreadcrumb%2Ftoc.json&view=net-maui-9.0

I think we don't even need to write modloader API wrapper library. The Java.Interop already provides code generation from Java into CIL. What we need to think is how to utilize MCW for invoking modloader/minecraft APIs and ACW for invoking managed code, but we still need to write bridge library on java to load managed assemblies from minecraft itself

[redplcs]

So basically we need to write jar mod that will load CLR and proxy calls from mod loader into managed assembly representation. Java.Interop will help us to build proxy libraries from Java