bytecodealliance
TeaVM bindings for resource types are un-implemented
the lib.rs in teavm-java seems to have a number of todo! macros currently, which prevent bindings being generated for any .wit files containing resource types.
I think that teavm-java is not being actively maintained. Loop in @dicej for clarification.
@Mossaka is correct that it's no longer being actively maintained; it was an experiment that never really took off. I think we should probably remove it unless someone wants to volunteer to maintain it going forward.
TeaVM is a really cool project, but it's not necessarily the best solution for transpiling general-purpose Java code to Wasm given that the class library is extremely limited compared to OpenJDK's library, which means most third-party libraries won't work. Other projects, such as Bytecoder and GraalVM's native image compiler might be better suited to the task, although the latter is a long shot given that Oracle appears to have zero interest in Wasm.
I'm personally not super invested in TeaVM in particular. Just compiling JVM applications to WASM, so Bytecoder definitely looks promising.
I wouldn't mind helping with some of the work to add that as a new target, but I'll probably need to learn a lot more about the WASM Component Model ABI before I'd be very helpful.
@dicej @Sintrastes Bytecoder's class library emulation looks even more limited. FYI, that original TeaVM project supports WASI target, except that there's no support for wit bindings.
@dicej @Sintrastes Bytecoder's class library emulation looks even more limited. FYI, that original TeaVM project supports WASI target, except that there's no support for wit bindings.
@konsoletyper Can you elaborate on how Bytecoder's class library is more limited? I haven't done anything with it myself, so I honestly don't know, but the "Backed by OpenJDK 20 as JRE classlib" item listed in the high level goals section of the readme led me to expect broader compatibility.
@dicej according to what I saw, they just take bytecode from the underlying JDK and replace some of the classes with their own implementations. Not sure their implementation is complete and fits any other underlying JDK than 20. With some classes it may work, for some it may lack necessary re-imlpementation. Their test coverage is quite limited, they rely on their own tests, not running JDK tests. So for anything beyond class library emulation that comes with Bytecoder, there no guarantee that some particular Java API would work. Not even sure they have support for WASI.
BTW, GraalVM currently does not support WebAssembly target, they doing quite opposite thing: running WebAssembly within JVM. I heard though that they have plans to support WebAssembly as a target.
@konsoletyper thanks for clarifying WRT Bytecoder.
BTW, GraalVM currently does not support WebAssembly target, they doing quite opposite thing: running WebAssembly within JVM. I heard though that they have plans to support WebAssembly as a target.
Right. This issue contains a proposal to support a Wasm target, but Oracle appears to be entirely unmotivated despite strong interest from the community, so I don't have high hopes for it.
Good news: GraalVM is finally getting a Wasm backend for its Native Image feature: https://2025.wasm.io/sessions/the-future-of-write-once-run-anywhere-from-java-to-webassembly/.
TeaVM was removed in https://github.com/bytecodealliance/wit-bindgen/pull/1202 so I'm going to close this
