dazraf (Sep 29 2021 at 18:18): dazraf (Sep 29 2021 at 18:18):Hello,
I'm a newbie to wasmtime. Have several decades of experience with several languages and runtimes, general distributed systems design, as well as fairly in-depth experience with blockchain & DLT development. I've been looking at WASM as a means of developing cross-ledger contracts - my aim is to execute wasm based contracts on a variety of platforms and runtimes, including the JVM. Have tried a few wasm compilers and execution platform - notably wasmer and now wasmtime. I really like wasmtime :-) However, I noted the lack of JVM support. I've started writing one. Is this something that would be use? Does anyone else already know of such a project? I will happily terminate my efforts on mine, and contribute to that project instead. Thank you.
dazraf (Sep 29 2021 at 18:21):Ah, I just came across this message!
https://bytecodealliance.zulipchat.com/#narrow/stream/206238-general/topic/Java.20JNI.20bindings.20to.20Wasmtime/near/212244883
Slightly different to my approach (JNA + Kotlin) but never the less far more complete!
Alex Crichton (Sep 29 2021 at 18:42):At this time we don't have official JVM bindings for Wasmtime, although I think there's a least one community effort for having bindings (I forget where it's located though or if it's up-to-date)
Alex Crichton (Sep 29 2021 at 18:43):ah yes the one you linked is the one I was thinking of
Peter Huene (Sep 29 2021 at 19:47):There also seems to be this one with slightly newer commits (0.28.0): https://github.com/kawamuray/wasmtime-java
Jonathan Halliday (Sep 30 2021 at 08:03):Neither is anywhere near production ready, but kawamuray is easier to consume than bluejekyll. I've been prototyping one based on the new panama api rather than JNI, but it's not public yet. Depending on what you're doing, you're likely to need the Interface Types proposal implemented before you get a good user experience on the language boundaries.
dazraf (Sep 30 2021 at 15:01):Thank you all for you responses. I suppose the only different in the one that I was writing is that I'm using a higher level library (JNA) to reduce the need for bespoke JNI proxy files (usually done in C/C++/Rust) which is another level of maintenance overhead. Would be great if there was official JVM support. We have a number of enterprise clients that would be interested in a WASI compliant runtime for the JVM.
Till Schneidereit (Sep 30 2021 at 15:05):I very much agree that that'd be great to have! Would you by any chance be interested in working towards turning the one you're writing into an officially supported one?
dazraf (Sep 30 2021 at 15:21):I would be very happy to give my work to the group when it's ready! If the peer review of the work considers it satisfactory, could it be officially maintained under the bytecode alliance github group? (perhaps I'm getting ahead of myself).
Till Schneidereit (Sep 30 2021 at 15:31):I think that'd be a great outcome! Once things have progressed sufficiently, we should talk about what the sustainability story would look like, and about logistics—but trying to work through those now would indeed be getting ahead of ourselves :grinning:
dazraf (Sep 30 2021 at 15:34):Great, thank you all for your help!
Jonathan Halliday (Sep 30 2021 at 15:38):What's you client's use case for putting it on the JVM rather than running it direct?
dazraf (Sep 30 2021 at 15:46):I work in the area of decentralized ledgers for financial services. Our work is increasingly poly-network. Until recently, clients were happy with poker-chip-semantics: treating assets as simple tokens that could be issued, transferred, traded, settled, and importantly, 'teleported' or 'bridged' across networks. Networks include but are not limited to: Ethereum, Corda, XinFin, Polkadot, Polymesh, DAML, etc. The matter becomes interesting when we are dealing with asset classes that have more interestingly lifecycles. e.g. a FX option, Bonds, Equities etc. A token is insufficient to carry the semantics of the asset. In addition, issuers may decide on more complex semantics - e.g. conditions for trading, transfer etc. All in all, this kind needs a common way of thinking about assets and encoding the contractual aspects of the asset in a network agnostic fashion. This is a long term (five year horizon) roadmap for us, over and above our immediate pipeline of work. However, we and our clients see it important to form the right alliances in this space to start putting in place the components. Does that help in giving some background?
Jonathan Halliday (Sep 30 2021 at 15:48):Sure, but doesn't answer the question at all. What's the reason for embedded wasm in the JVM rather than e.g. having the JVM fork the wasm runtime as a separate process?
dazraf (Sep 30 2021 at 15:48):With apologies for the grammatical and spelling mistakes. I'm writing this whilst on a zoom meeting.
dazraf (Sep 30 2021 at 15:49):Ah ... sorry, that was implied. Imagine a contract that is written with any language that can compile to wasm. When the asset is transferred from one network to another, the wasm payload for the contract is transferred (with proofs of authenticity). Certain networks and deployments use the JVM. Examples include Corda and Hyperledger Besu.
dazraf (Sep 30 2021 at 15:51):The contract will need to interact with its contract execution container to retrieve transaction information, referenced prior transactions and states. There would be a 'contract ABI' to support the contract.
Jonathan Halliday (Sep 30 2021 at 15:52):Ahh, so you're exporting functions from the JVM to the wasm module so it can get that tx info?
dazraf (Sep 30 2021 at 15:52):Yes. forking a separate process would require some form of IPC for the bidirectional aspects of that contract.
Jonathan Halliday (Sep 30 2021 at 15:53):yup, and embedding it will require interface types, otherwise it's going to be painful. IPC gives you transport and encoding. You don't need the transport, but you still need the encoding.
dazraf (Sep 30 2021 at 15:55):Yes, that's it.
Jonathan Halliday (Sep 30 2021 at 15:57):stick around long enough, someone will reinvent CORBA/SOAP/... again. :-)
Till Schneidereit (Sep 30 2021 at 15:57):Interface Types should definitely be part of the embedding, at least eventually :smile:
Till Schneidereit (Sep 30 2021 at 15:57):s/reinvent/improve upon and reuse the good parts/ :wink:
Jonathan Halliday (Sep 30 2021 at 15:59):yup. Embedding is going to need the equivalent of JSR-223's .bind() but that's awful hard until wasm has something approximating object types.
Till Schneidereit (Sep 30 2021 at 16:21):I think that'd roughly be done using Interface Types resources, which allow you to expose an unforgeable handle and methods to operate on it across component (and host/component) boundaries
dazraf (Oct 01 2021 at 17:46):I'm okay with this. So far, I haven't seen any issues. Will post on anything relevant that I come across.
Notification Bot (Oct 03 2021 at 10:08):dazraf has marked this topic as resolved.
Last updated: Dec 23 2024 at 14:03 UTC