Why we're making Wasm2Kotlin
You may have noticed by the title of this post that we're making something called Wasm2Kotlin. Wasm2Kotlin is a programming tool for converting WebAssembly (Wasm) to Kotlin, specifically for use on the Java Virtual Machine. In most cases, however, this doesn't really make sense, because you could just use Java Native Interface, or something equivalent, which allows Java to interact directly with machine code. In many cases, you must interact with machine code, especially when video games/rendering is involved. One drawback of machine code, however, is that it depends on the device you're running it on.
In the case of something like Android, the devices are more or less standardized, and the differences don't generally interfere with the machine code. This makes it really easy to deal with machine code on Android, so you only have to ship one or two machine code modules.
But not all Java runs on Android. Maybe you have a game you made in Java. In which case, you need to ship a lot more machine code: the machine code that runs on Mac does not run on Windows, and so on. Thankfully, these are often fairly easy to deal with, with someone else having done all the work of making all these versions of the machine code. You still don't want to ship all of these to everyone who downloads the game, so a launcher selects the relevant versions on first run instead.
And in general this is fine, you can more or less just use machine code. But maybe you want to make a modification for a game written in Java. This can present various challenges for using machine code: the use of machine code could enable security exploits, the mod engine could prevent mods from interacting with machine code, or maybe you just aren't allowed to download the device-specific machine code at runtime, and are required to ship all of them instead. And this isn't even taking into account the devices you hadn't considered, which would have a significantly degraded user experience.
Depending on what the machine code does, you don't strictly need it to be machine code. This is where WebAssembly comes in handy, as WebAssembly allows various languages like C, C++, Rust, etc to be converted to a format that isn't machine code, and yet has enough similarities to machine code such that these languages can still work. WebAssembly is also really easy to work with, which is what enabled us to create Wasm2Kotlin.
All Wasm2Kotlin does is enable running Wasm on the Java Virtual Machine. It does this in a fairly indirect way, but the end result is the same: you get to run Wasm on the Java Virtual Machine. Specifically, Wasm2Kotlin exists in the hopes that the Java Virtual Machine can apply its runtime optimizations to the WebAssembly code, ideally making it run as fast as machine code. This has never been measured to work, however. There are other ways to run WebAssembly on the Java Virtual Machine, but they might not necessarily be able to benefit from those runtime optimizations.
It is important to note that, regardless of what you pick to run WebAssembly on the Java Virtual Machine, using WebAssembly can make it so you don't need to ship machine code, in particular you don't need to ship multiple variants of machine code, for different devices. And while this isn't generally worthwhile, in the case of game modifications it may well be.
In other words, we made Wasm2Kotlin for Minecraft modding, and it likely has no other use outside of this.