Current Feasibility of Java Support

[jacobjzhang]

Forgive the fact that this doesn't really fall into a bug or feature request, it's more of an inquiry into how feasible it is to support Java-- especially entirely client-side.

Looking at the Python and PHP examples, it seems the pattern we've established is to find a language runtime that's been ported to wasm (pyodide and php-wasm respectively). We'd then simply load the runtime via JS in the browser and execute a given string against it.

I've been investigating Java support (still #3 on the most used languages list!) and haven't found anything similar. Looking at the awesome-wasm-languages list, it looks like all the aforementioned libraries are compilers, rather than anything that can actually take a Java string/class and give us an output.

Apparently CheerpJ does have a runtime but:

1. is a paid product and
2. seems to require compilation of the desired code to be executed before being loaded into a browser - in other words, to get the REPL effect, we'd need to send ship the string to the server, compile it with CheerpJ, get the wasm file back, and execute the wasm output in the browser

I also looked into Wasmer, but it seems to do the opposite of what we want -- namely, run wasm within Java.

The other issue that comes to mind is the size of a Java runtime. Both pyodide and php-wasm isolate the core methods and packages in the languages. With Java, you're already having to import large standard-sized libraries just to work with basic data structures like Arrays. This isn't a problem with an ahead-of-time approach, but goes against the "established" pattern.

I'm not really a Java guy, so hopefully someone else can chime in with their understanding, but wanted to open up this discussion to see what others think.

[jsjoeio]

Not a Java guy, but I wanted to take a second to say thanks for doing the research and sharing your findings!