enarx
enarx copied to clipboard
enarx
[Feature]: Java -> Wasm guide
Is there an existing issue for this?
- [X] I have searched the existing issues
Description
There's currently no known when to compile from Java to an Enarx-compatible Wasm executable. This is a key use case for Enarx.
Acceptance Criteria
- [ ] Create a simple "Hello World" app in Java, compile to Wasm, run within an Enarx Keep
- [ ] Create a simple echo server app in Java, compile to Wasm, run within an Enarx Keep
- [ ] Write up how-to on Enarx documentation
Suggestions for a technical implementation
From https://github.com/appcypher/awesome-wasm-langs#java
- [X] ByteCoder (no success so far)
- [ ] TeaVM
- [ ] JWebAssembly
- [ ] CheerpJ (not open source) See also:
- [ ] GraalVM (runs Wasm, but apparently doesn't allow to compile Java to Wasm)
Regarding JWebAssembly and WASI support:
https://github.com/i-net-software/JWebAssembly/issues/32
Regarding JWebAssembly and WASI support:
Thanks for Posting the issue thread @nickvidal
During my course of Research during the Weekend, I have found out that with ByteCoder we will not be able to achieve what we want.
Compiling Java ByteCode to WebAssembly Binary gives out no issues but making it work on Wasmtime doesn't work. Today itself I have reached out to Mr. Mirko Setric who is the author of the ByteCoder Project and let's see what he has to say on the Support.
My Hypothesis is the reason for this not working can be that Maybe internally under the hood, the way the API is compiling stuff and while that compilation process is happening, it is trying to access the DOM.
I think we can also check out TeaVM from the list as well, since it's use case is only constrained to compiling Java ByteCode that emits JavaScript and WebAssembly that only runs inside the Browser, and since it is accessing the DOM in this case, it won't work with our use case as well.
@MikeCamel HI Mike, with some substantial efforts, I am now able to compile my Java Source Code to a WebAssembly Binary and then have it run on Wasmtime.
But, there is a Caveat Here:
As I updated you in our Scrum Call, as of now we will only be able to support Static Java Code without any Object Allocation. Since if we try to use any object allocation in our Source Code, it panics and gives out a GC Spec Error.
But the good thing is that with Static Code if we try to deploy the Binary on Wasmtime, it doesn't yield any error and the Binary is Parsed Successfully.
If we have a look on the Internet, I did not find any references which are talking about deploying the Binary even with Static Java Code, so in a way, this can give us a First Mover Advantage of researching into this Stuff and publishing it on the Internet.
My target now is to log out a meaningful message on the Console when I try to deploy the Binary on Wasmtime, and I am figuring out a way of how it can be done without doing any Object Allocation.
@MikeCamel HI Mike, with some substantial efforts, I am now able to compile my Java Source Code to a WebAssembly Binary and then have it run on Wasmtime.
But, there is a Caveat Here: As I updated you in our Scrum Call, as of now we will only be able to support Static Java Code without any Object Allocation. Since if we try to use any object allocation in our Source Code, it panics and gives out a
GC Spec Error.But the good thing is that with Static Code if we try to deploy the Binary on Wasmtime, it doesn't yield any error and the Binary is Parsed Successfully.
If we have a look on the Internet, I did not find any references which are talking about deploying the Binary even with Static Java Code and having it run outside the Browser, so in a way, this can give us a First Mover Advantage of researching into this Stuff and publishing it on the Internet.
My target now is to log out a meaningful message on the Console when I try to deploy the Binary on Wasmtime, and I am figuring out a way of how it can be done without doing any Object Allocation.
Great work - looking forward to seeing how this works out. Is there any hope for Object code in the near future, do you think?
Great work - looking forward to seeing how this works out. Is there any hope for Object code in the near future, do you think?
Yes, I guess there is Hope. It depends on the Progress of the Wasmtime toolchain and how far is it from integrating Garbage Collection Support into it. As soon as we have it, we would be able to run Object Oriented Code without any Blockers :)
It seems that garbage collection shouldn't be needed for allocation. Rust, Go, etc allocate memory for variables without issue. The garbage collection should be handled however WebAssembly runtimes decide to free unused memory (which happens automatically I think since WebAssembly is stack-based). It might be that bringing Java to WebAssembly might mean the entirety of the Java runtime, which is how Ruby & Python (at least currently) function (perhaps Go too, since it also has a runtime which it compiles into the target binary).
It seems that garbage collection shouldn't be needed for allocation. Rust, Go, etc allocate memory for variables without issue. The garbage collection should be handled however WebAssembly runtimes decide to free unused memory (which happens automatically I think since WebAssembly is stack-based). It might be that bringing Java to WebAssembly might mean the entirety of the Java runtime, which is how Ruby & Python (at least currently) function (perhaps Go too, since it also has a runtime which it compiles into the target binary).
True, I also agree with this. It might not be needed for allocation but as you said since we are bringing Java runtime to WebAssembly, that's why it's causing a hindrance because unlike Object oriented Languages like C++ where we have to explicitly free up space after we are doing using the object which we initialised in the first place, in Java it happens automatically because of Automatic Garbage Collection
Just my hypothesis, please correct if wrong 😅
The limited features of WebAssembly prevent the implementation of a Garbage Collection like used in Java. For example the inspection of the references that are hold from the stack only.
