Adolfo Ochagavía (Feb 06 2026 at 18:56): Adolfo Ochagavía (Feb 06 2026 at 18:56):I'm blown away by wasm components and want to use them in the JVM, but the wasm runtimes available there don't support components. This situation is similar to Node.js and browsers, where I've successfully used jco transpile to work around the issue. That set me thinking: it should be possible to enhance jco transpile and have it generate Kotlin code instead of Javascript. Has anyone ever looked into more targets than only JS? Are there any caveats to be aware of? I have an early prototype that looks promising, but I wanted to check here if there are any unknown unknowns lurking around the corner.
Adolfo Ochagavía (Feb 06 2026 at 19:01):For additional context, I'm not interested in running components that rely on WASI interfaces, just "wasm core". I'm hoping that would reduce the implementation surface considerably.
Pat Hickey (Feb 06 2026 at 19:12):In general the approach that jco uses, which is to take a wasm component and decompose it into 1. a set of wasm modules, and 2. glue code that implements a component runtime specific to that component by instantiating those modules, is a great architecture which we encourage folks to pursue if they arent able to use a native component runtime on their platform yet
Pat Hickey (Feb 06 2026 at 19:13):jco is architected this way, and i recall someone did something similar for python but i dont have a link to it handy. in general its easiest in languages that have eval, since then it can be "ordinary" library code, but theres no reason to not use it as a "macro" pass in languages without eval.
Pat Hickey (Feb 06 2026 at 19:15):I'm enthusiastic about you taking that approach to a kotlin component runtime, using whatever core wasm runtime you like. Its quite possible that buildign such a thing would crib a whole lot of code from jco, which is probably the best implementation of the rough architecture described. But I don't think it would actually be an advantage to either your project or to jco to have both languages supported inside the same tool. My advice is to fork jco and hack it into exactly what you need
Adolfo Ochagavía (Feb 06 2026 at 21:39):That's great to hear, thanks a lot! I was indeed thinking of a fork, or even a reimplementation (I'm keen on using Rust, because of the language and because they have good libraries for wasm-related stuff). We'll see how it goes...
Pat Hickey (Feb 07 2026 at 01:19):AFAIK, the core of jco that knows how to parse/decompose a component is written in Rust - its wasm-tools + wasmtime-environ
Pat Hickey (Feb 07 2026 at 01:20):(its been many years since ive been in that code so its possible something has changed, but i doubt it - the algorithm in wasmtime-environ has, afaik, never been replicated elsewhere)
Victor Adossi (Feb 07 2026 at 06:21):Hey @Adolfo Ochagavía a bit late but I think that what I can add is that you should take a look at the following repos/codebases:
wasm-tools component unbundle (i.e. the first step of decomposing a component into modules that are easier to run for runtimes that don't yet support the ComponentModel)wasmparser technically unnecesary, but obviously you'll want to be able to create scaffolding around the WIT and sections included in the component. A lot of the work Jco does is essentially iterating the structure of the Wasm and dealing with various sections and generating code, as I'm sure you've seen.wit-bindgen-core is actually not a requirement but it's a big part of jco transpile -- by providing essentially a visitor to abi::call, you can do generation for various distinct instructions (some pseudo instructions/more representing areas of execution).Glad you're keen on using Rust, because much of the tooling is written in Rust :)
A rewrite of Jco is great place to start, sorry for any weird code you see! We're always happy to take pull requests or contributions and would be delighted if you took some notes on hard to understand bits/ways the codebase could be simpler.
Christof Petig (Feb 07 2026 at 07:37):There is some chance that https://github.com/pulseengine/meld might work (create multi memory modules from components)
Ralph (Feb 09 2026 at 16:41):you might also want to chat with @Zalim Bashorov (Kotlin_, JetBrains) about your JVM/Kotlin thing....
Adolfo Ochagavía (Feb 10 2026 at 14:56):Thanks a lot for the great ideas! I'll keep you posted ;)
Last updated: Feb 24 2026 at 04:36 UTC