Use wasm-pack to create a wasm package for JAVA

Hi there!
I am trying to use wasm-pack to create a wasm file which shall be included in JAVA via e.g. https://chicory.dev/
Is there someone who has experience with this? Which target do you use for building, or is there another tool at all which I should be using?
Greetings and thank you,
Christian

wasm-pack (and wasm-bindgen) are for producing WebAssembly and JavaScript code that will run in a browser or other JS+Wasm engine. If you do not have any JS environment you should not use wasm-pack; instead just use cargo build --target wasm32-....

As to exactly which target to pick:

  • If you want use Chicory's support for WASI, use wasm32-wasip1. This is the only option that allows you to use std functionality like std::time::Instant::now().
  • Otherwise, wasm32v1-none is the most basic place to start.
  • However, some libraries may have poor cfg setups that will only work with wasm32-unknown-unknown. You can use this target if you have to, but it is weirdly defined and should be avoided when possible.

Hmm...

Chicory, a JVM native WebAssembly runtime

Having scanned that web page I still can't see what this is.

Is it a WASM run time that is running on the JVM (Written in Java I guess). Is it a JVM compiled to WASM allowing Java to run on the JVM on the WASM runtime.

Or is it a WASM run time that runs in parallel with a JVM more like WASM runs alongside a JS engine. Presumably allowing any language compiled to Java byte code to interoperate with any language compiled to WASM?

Heck what does "native" mean? If you are running on top of the JVM or unto of a WASM engine that is not any kind of native in my book.

Thank you for your feedback! :slight_smile:
I also reallized that wasm-bindgen is not intended for my usecase and started to play around with wit-bindgen. The approach using the separate .wit file looks very interesting.
@kpreid thanks for pointing out the WASI support of chicory, this looks very promising.

As far as I understand, it's a WASM runtime that is running on JVM. But yes, I guess "native" is a flexible term depending on the point of view.