Bug 1506

Summary: Support WebAssembly (wasm) Target Platform (browser/web)
Product: [JogAmp] General Reporter: Sven Gothel <sgothel>
Component: genericAssignee: Sven Gothel <sgothel>
Status: UNCONFIRMED ---    
Severity: normal CC: gouessej, mfery
Priority: P4    
Version: tbd   
Hardware: All   
OS: all   
Type: FEATURE SCM Refs:
Workaround: ---

Description Sven Gothel 2024-04-02 10:03:54 CEST 
Since Java Applets are not more supported within browser or by OpenJDK for years,
it may seems feasible to evaluate the WebAssembly target running within e.g. web browser nowadays.

An initial evaluation on small C++ projects using the emscripten front-end for LLVM's clang++ to wasm compiler, which supports many ported system libraries like SDL, OpenGL, .. has been undertaken successfully with variable results.
- Own gfxbox2 C++/wasm evaluation https://jausoft.com/cgit/cs_class/gfxbox2.git/about/
- emscripten https://emscripten.org/
- WebAssembly https://webassembly.org/

+++

Java support for the WebAssembly target are claimed to be supported by
- GraalVM https://www.graalvm.org/latest/reference-manual/wasm/
-- with the help of emscripten
-- GraalVM + JNI: https://www.graalvm.org/22.0/reference-manual/native-image/JNI/

- JWebAssembly https://github.com/i-net-software/JWebAssembly
- TeaVM https://github.com/konsoletyper/teavm

+++

Our own C++/wasm evaluation so far:

For once, the wasm target is comparable to Java bytecode but the virtual machine might not be as performant, efficient or flexible. The lack of hassle free native threads and performance may remind one of the first JVM steps. The wasm code runs within a virtual machine like the JVM and additionally lacks of native binding capabilities, besides aforementioned limitations.

Some limitations may be overcome, others are likely by design as it usually runs on the same browser virtual machine as the JavaScript companion.

So far the only question arises why reinventing the wheel once again? Dropping utilization of a well working JVM for the web had not technical reasoning.

GraalVM seems to support the wasm target, hence one might want to evaluate this Java target platform as well before recoding the whole application.
Opening the door for any language to be compiled to a platform independent intermediate representation (IR) like Java’s bytecode suitable for a versatile runtime environment including its virtual machine is surely still desirable.
Hopefully this technology will mature and be maintained for the years to come.
Comment 1 Julien Gouesse 2024-04-02 20:41:57 CEST 
As far as I know, GraalVM is able to run WebAssembly but it's unable to convert JVM bytecode into WebAssembly.

This helps a lot to parse the bytecode:
https://openjdk.org/jeps/457

This project is worth interest too and it targets OpenCL (bonus):
https://mirkosertic.github.io/Bytecoder/

I don't know yet if the project Babylon could help:
https://openjdk.org/projects/babylon/articles/linq

I'll see what I can do. It's a major research field for me.
Comment 2 Sven Gothel 2024-04-03 05:32:58 CEST 
(In reply to Julien Gouesse from comment #1)
Correct. 
GraalVM hosts wasm, but is not producing a wasm target
for the wasm (browser) runtime.
Sorry .. didn't take enough time.

Bottom line, either one brings back the JVM to the browser
allowing Java bytecode execution using existing tech
- or the wasm target compiler path.

Alternatively, drop Java and use C++ etc.
Comment 4 Julien Gouesse 2024-04-03 10:12:11 CEST 
(In reply to Sven Gothel from comment #2)
In my humble opinion, the wasm target compiler path is more viable, especially now that there are garbage collectors for WebAssembly in many major web browsers.

There is a request for enhancement about wasm target in GraalVM:
https://github.com/oracle/graal/issues/3391

Google J2wasm within J2CL can be a source of inspiration too, it emits very naïve Wasm using the text format and it relies on Binaryen toolchain to assemble, link, and optimize:
https://github.com/google/j2cl/blob/master/docs/getting-started-j2wasm.md
https://www.wingolog.org/pub/epfl-wasm-gc-feb-2024-slides.pdf
Comment 5 Julien Gouesse 2024-04-03 23:06:45 CEST 
I have to be more accurate. Mozilla Firefox >= 120, Chrome and Chromium-based web browsers >= 119 support the WASM garbage collector by default.

Importing host functions to manipulate the DOM tree and to call the web APIs seems to be still necessary, am I missing something obvious?
Comment 6 Sven Gothel 2024-04-04 08:21:51 CEST 
(In reply to Julien Gouesse from comment #4)
Whether re-animating the JVM within the browser or having a webassembly compilation target, not sure what would be best on a technical basis.
In general I prefer less layers of complexity, which also often cause (a) bugs and (b) reduce performance. 
However, if working well, both would allow using Java on the web.

TeaVM also seems to be close, if willing to drop certain features.

A long road ahead :)

+++

Extracted the big section to its own wiki (w/ back/forth link to features)
https://jogamp.org/wiki/index.php?title=WebAssembly_(wasm)_Target_Platform

(added your infos, please feel free to edit this page as well as you seem fit)
Comment 7 Julien Gouesse 2024-05-16 09:48:33 CEST 
I started using the class-file API a few weeks ago to evaluate it, I'll post an example soon just to show what I mean.
Comment 8 Julien Gouesse 2024-09-04 00:34:14 CEST 
Just for the follow-up, I've succeeded in using Java 22 with preview features enabled in a Gradle 8.10 project, I use TestNG too, the class-file API works like a charm. I'm able to find the enum constants within an enum class, it's a first step. I'll publish the source code somewhere when it can emit a simple WAT file.