Or going the other way, could hotspot be replaced with a wasm jit by compiling java to wasm? I know they have slightly different memory models, but I don't understand why they seem to be treated so separately.
But that is kind of my point - there are advanced vms out there. I don't see why the web needs its own vm apart from them. All the differences I see are fairly minimal.
I don't know all the JVM implementations out there, but it wouldn't surprise me if there was one with it implemented.
By the way, RMI and Jini worked by streaming code across the network.
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.
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.
Nashorn seems to be pretty close to node.js.
> 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.
> 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.