Exactly. These 'ports' are more intellectually exciting than the are pragmatically useful, but they definitely can be useful, it's a matter of having the right product parameters around what they are good for and what not.
This is really an exercise in engineering thinking vs. product or 'solution oriented' thinking. You can usually tell where people's heads are at by how they react to these kinds of things.
Should note that 'people doing stuff because' is a core part of organic development, most things would not exist without that ethos floating around.
Have you looked at the vendor’s website? This doesn’t strike me as a purely academic/intellectual "because we can" project at all.
And you still haven’t explained in any way why the lack of DirectBuffers or "IO" is a disqualifier for being able to run legacy applets in a modern browser without a JRE or other plugins.
Just the opposite, the company has been around for 10 years and they have are an intellectually oriented professional services provider. This is quite common. The VM they built may or may not be a direct demand from a customer, my bet is it was an idea that someone had and they decided to make it, to see if there was some customer buy-in. There might be a niche need.
The problem with the 'A Customer Can Run An Applet In A Browser' as a solution, is because this won't materially work for most wide, public style deployments - there will be any number of snafus, and for more 'internal' style IT deployments, there are just easier, more robust ways to deploy a Java app.
I have explained how 'Direct Buffers' are a problem to anyone who understands what VM and Direct Buffers used for (they are inherently about bridging to native memory), which obviously is not going to be accessed in WASM context.
Actually - WASM itself is a great analogy for what is going on here. It's 'perennially almost there' tech aka a neat idea that has limited value in the real world, it's been around for so long and there isn't that much activity, or at least not commensurate with what it's supposed to be able to do. By the time WASM catches up, the performance of JS in V8 gets so much better it becomes 'good enough' which obviates the need for WASM. And so on it goes.
Something may eventually come from JVM in WASM, but what we see is a very early experiment.
> By the time WASM catches up, the performance of JS in V8 gets so much better it becomes 'good enough' which obviates the need for WASM.
One main benefit of WASM arguably isn't performance of newly developed applications, but the possibility to run arbitrary old applications (or new applications built on massive stacks of historically grown libraries) much more efficiently than emscripten alone allows.
> There might be a niche need.
Of course it's a niche need, Java applets haven't been mainstream for many years now! But as with any technology, a long tail exists.
> I have explained how 'Direct Buffers' are a problem to anyone who understands what VM and Direct Buffers used for (they are inherently about bridging to native memory), which obviously is not going to be accessed in WASM context.
I've only ever used Java on the server – are "Direct Buffers" commonly used by Java applets not bridging to JNI (which obviously won't run in a pure Java emulation/compatibility layer)?
