This was tried (search for "LiveConnect"). It failed for many reasons, but the one that's most relevant to today is probably that most interesting client-side stuff (that isn't already written in JS) is written in C and C++, not a JVM language.
If that is why out failed, then wouldn't wasm fail for the same reason?
It looks like LiveConnect was a much bigger thing that MS pushed.
I'm not really understanding how this means anything. Why not just compile js et al to java bytecode? Or is wasm just another NIH protect in a long list of them in the JavaScript world? That is what it is looking like.
Sure hotspot itself couldn't be used straight up, but the changes are certainly much less than creating a whole new vm.
> If that is why out failed, then wouldn't wasm fail for the same reason?
Web Assembly targets C and C++ as source languages, unlike the JVM.
> Why not just compile js et al to java bytecode?
Because JS and Java semantics are different, and emulating JS semantics on top of the JVM is slow.
> Sure hotspot itself couldn't be used straight up, but the changes are certainly much less than creating a whole new vm.
The Web Assembly VM shares as much code as possible with the engine's JS VM. This is obviously better than using HotSpot, as the relevant code is already shipping in browsers.
Nobody is going around rewriting code for no reason.
> Web Assembly targets C and C++ as source languages, unlike the JVM.
So wasm (and hence JavaScript if you translating js into wasm) are closer c/c++ than to java? Considering all the UB in C, this cannot possibly be true.
> Because JS and Java semantics are different, and emulating JS semantics on top of the JVM is slow.
Given javas JavaScript implementation is pretty comparable, not very big, and even written in java, this also doesn't seem to be true at all.
Once you add gc into wasm, it is almost guaranteed to be closer to java than c/c++.
Yes. For example, Web Assembly has unsigned integer arithmetic and explicit memory allocation/deallocation, neither of which the JVM has.
> Considering all the UB in C, this cannot possibly be true.
Undefined behavior is a concern of the compiler of the source language. Web Assembly doesn't compile C or C++. It simply interprets a VM, the semantics of which are designed to be relatively free of undefined behavior.
> Given javas JavaScript implementation is pretty comparable, not very big, and even written in java, this also doesn't seem to be true at all.
I would highly doubt it's performance competitive at the level that browsers are at now. It strikes me as likely impossible to get performance competitive on, say, SunSpider if you aren't highly tuned for it.
Nashorn is anywhere to faster on primitive heavy computation to 50% slower post JIT. Graal is supposed to be even faster.
> Web Assembly has unsigned integer arithmetic
This is your idea of a major difference that affects implementation so much that is separate VM needs to be written? Many Java programs already do essentially manual memory management already too. Those aren't the big differences. Things like safe-memory access are bigger issues. And once wasm gets gc, it will even be closer to Java and JS.
I hope Graal outperforms everything else, so we can stop pretending like WASM is something different than what Java has been trying to do.
