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.
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.
(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.
(In reply to Sven Gothel from comment #2) https://jogamp.org/wiki/index.php?title=SW_Tracking_Report_Feature_Objectives_Overview#WebAssembly_%28wasm%29_Target_Platform updated wiki text
(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
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?
(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)