4 ms·

It is absolutely a real JVM. From the link: "CheerpJ is based on an unmodified OpenJDK environment, guaranteeing the same behavior on the browser compared to

• jasmer 4y ago
  Direct buffers? I mean, they're going to be 'virtual direct'? Or can I can't fathom how but I would imagine they're not going to be 'actually direct'.
  • brabel 4y ago
    WASM has memory, and any native code compiled to WASM will allocate on WASM memory. CheerpJ's runtime is written in C++, which when compiled to WASM knows how to allocate memory, so there's no reason why direct buffers won't work.
    • jasmer 4y ago
      Direct ByteBuffers are used to interop with the underlying platform, particularly for the purpose of IO. I could be wrong, but I fail to see how 'WASM memory direct Buffers' will work in that scenario.
      • lxgr 4y ago
        What IO devices would you even have access to from a browser sandbox?
        • jasmer 4y ago
          What app is going to function without IO?
          • pjmlp 4y ago
            A CPU warmer. :)
            • jasmer 4y ago
              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.
              • lxgr 4y ago
                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.
                • jasmer 4y ago
                  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.
      • brabel 4y ago
        Why don't you just try? It seems to work fine: https://javafiddle.leaningtech.com/#JYWwDg9gTgLgBAKwIYDckDoB2wLoEICeMApngK4BmFxUA3AFD0XCZIA2cAxm0gM69wAUqiQAxYABMJbYvThwA3nPlwwZAEZtgnOLxhIY2uCgiS4IJCwAUAZRhQWAcwDaAXThIoj3gEpl8pRUguEIScioaOHU4AF4QolJKaih0djYITgNiABFgKGJOGCsAJgAGcoqfBmCVGwI9YhB0CDIYdDAHTBg2TCsAIgBBNnTMkgk4PrgAaij0TLAkTmAYAisfaYmohN4+qv84AF9lI6A https://javafiddle.leaningtech.com/#JYWwDg9gTgLgBAKwIYDckDoB...
        • jasmer 4y ago
          I did, as I said, those are likely 'Virtual WASM Direct Buffers' which are not really 'Direct (Memory) Buffers' - and therefore, not really what they are meant for, though it's impossible to tell. Given how WASM works, I'm pretty sure (but not certain) that anything that uses nio to interface to anything else is not going to work, other than maybe things which are 'fully contained'. The 'test' would be to dynamically load a lib/dll and see if the references are valid, which I doubt, firstly that'd imply that native dll/libs are possible, which I also doubt. These ports generally don't work 'as expected' the whole endeavour is about identifying the parts that work differently, and if/how to work around them or live within the constraints.
          • brabel 4y ago
            So your complaint about a JVM environment in the browser is that it can't load DLLs from your Operating System? Anyway, let's assume you're talking about a DLL or native lib it gets from the same origin. That also should work totally fine. Because CherpJ implements a virtual file system. I suspect even JNI will work fine. Anyway, doing stuff like that on a browser is way out of the norm, so it seems to me you're looking for a challenge and are not really interested in whether this can be used to run nearly every Java application out there, which it seems it can easily do.
            • jasmer 4y ago
              No, it's not going to load native libs, and 'jni' almost certainly does not work as normal, nio is widespread in java depends on 'native' buffers (actually native) and is a core part of Java. This is just one of a few examples of where 'this isn't really Java'. 'Most' apps will not run out of the box in this WASM config.