Stream: wasmtime

Topic: Java Component Model Support

Ashanti Mutinta (Aug 21 2024 at 17:51):

So far I have only found teavm-wasi which hasnt been updated in 2 years . I was wondering if they are any other alternative modes for support for the java component model ? I guess maybe a lot of people are waiting for the GC standard? Link here https://github.com/fermyon/teavm-wasi

Joel Dice (Aug 21 2024 at 18:01):

This recent discussion might be helpful.

The TL;DR is that TeaVM uses its own class library, which is quite limited compared to e.g. OpenJDK's class library, and that means most non-trivial Maven packages aren't compatible with it. An ideal solution would reuse OpenJDK's class library; Bytecoder might be an option, and GraalVM native image support for Wasm could also be an option if it ever happens. Oracle seems to have no interest in Wasm, though, so the latter seems unlikely.

Ashanti Mutinta (Aug 27 2024 at 17:27):

Joel Dice said:

This recent discussion might be helpful.

The TL;DR is that TeaVM uses its own class library, which is quite limited compared to e.g. OpenJDK's class library, and that means most non-trivial Maven packages aren't compatible with it. An ideal solution would reuse OpenJDK's class library; Bytecoder might be an option, and GraalVM native image support for Wasm could also be an option if it ever happens. Oracle seems to have no interest in Wasm, though, so the latter seems unlikely.

Thought I replied to this but thank you for the response! I read through the discussion and it looks like bytecoder might be even more limited. I guess my vague question would be how "usable" is the current teavm-wasi? Is it enough to create reactors with the current wasi standards? I only ask cause I don't think it has been updated in a while

Joel Dice (Aug 27 2024 at 17:33):

I guess my vague question would be how "usable" is the current teavm-wasi? Is it enough to create reactors with the current wasi standards? I only ask cause I don't think it has been updated in a while

It hasn't been updated to support WIT resource types yet, so it can't be used to target WASIp2. I don't think it would be terribly difficult to update it to support resource types (and anything else that's missing), but someone would need to volunteer to do the work. I'd be happy to provide guidance, if needed. Also, the C# generator has full resource support, so that could be useful as a reference.

Pat Hickey (Aug 27 2024 at 17:33):

The best answer I can come up with, without expertise, is that CI runs cargo test for each language in the matrix including teavm-java currently, and that the following runtime tests exist:

[pat@Pats-MBP:tests/runtime]% find . | grep java
./smoke/wit_worlds_SmokeImpl.java
./records/wit_worlds_RecordsImpl.java
./records/wit_exports_test_records_TestImpl.java
./variants/wit_exports_test_variants_TestImpl.java
./variants/wit_worlds_VariantsImpl.java
./numbers/wit_exports_test_numbers_TestImpl.java
./numbers/wit_worlds_NumbersImpl.java
./lists/wit_worlds_ListsImpl.java
./lists/wit_exports_test_lists_TestImpl.java

Pat Hickey (Aug 27 2024 at 17:33):

which, as joel just pointed out, doesnt include anything involving resources.

Joel Dice (Aug 27 2024 at 17:37):

I should also point out that my TeaVM-WASI fork has fallen way behind the upstream TeaVM project, and Alexey (the upstream maintainer) has since implemented his own WASI support. So if you're serious about using TeaVM on WASI going forward, you might want to switch the wit-bindgen generator to use the upstream project instead of my fork. Not sure how much work that would be, but I'm guessing not trivial.

Last updated: Oct 23 2024 at 20:03 UTC