good job, and kodus to you guys. BUT, it's sad to see that java (as a language not VM) still exists. It's such a bad language compared to many other existing options
Could you elaborate on how it's bad compared to the alternatives?
CheerpJ 3.0: a JVM replacement in HTML5 and WASM to run Java on modern browsers
61–70 of 179 posts
Re: CheerpJ 3.0: a JVM replacement in HTML5 and WASM to run Java on modern browsers
#62Java in the browser? I am having a deja vu to gray background slow loading boxes
Yes, running bins in the browser. This is ActiveX all over again, but with java.
Re: CheerpJ 3.0: a JVM replacement in HTML5 and WASM to run Java on modern browsers
#63good job, and kodus to you guys. BUT, it's sad to see that java (as a language not VM) still exists. It's such a bad language compared to many other existing options
It still exists because it's "bad". Very small language initially, with some 1990s warts that we all understand, and new features are only added long after they've proved their worth elsewhere. This means a lot for long-term hiring and maintenance.
Take it easy. It was all just a troll !
Re: CheerpJ 3.0: a JVM replacement in HTML5 and WASM to run Java on modern browsers
#64Amusingly, there were two different ways of running Java in the browser when it came out in the late 90s. One was Applet style where Java takes over a part of the canvas of the page and has to implement everything, like Flash or ActiveX. The other was headless and you had access to the DOM. Why no one built interesting applications with the latter is beyond me.
https://docs.oracle.com/javase/tutorial/deployment/applet/ma...
Now we are doing it all over again with WASM when it already existed and just wasn't used.
Re: CheerpJ 3.0: a JVM replacement in HTML5 and WASM to run Java on modern browsers
#65Earlier quoted context omitted.
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.
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.
What IO devices would you even have access to from a browser sandbox?
Re: CheerpJ 3.0: a JVM replacement in HTML5 and WASM to run Java on modern browsers
#66> multithreading ... but can it actually use multiple cores without limit, like the JVM itself? Is it a bug or a feature that I can not move the swing window despite it having a top-bar and closing X button?
RE Multithreading: just tried this: public class JavaFiddle { public static void main(String[] args) { new Thread(() -> System.out.println("Hello World from another thread!")).start(); System.out.println("Hello World!"); } } on https://javafiddle.leaningtech.com/ and it works...
Being able to execute Java threads does not imply that they are being mapped to actual OS-level threads (or any other concurrent construct).
Back in the days of J2ME, some embedded JVMs emulated threads at the VM level, for example (due to the OS they were running on itself not supporting any threads, which was true for e.g. Palm OS and many non-smartphone OSes). This was called "green threads", as far as I remember.
Re: CheerpJ 3.0: a JVM replacement in HTML5 and WASM to run Java on modern browsers
#67With this and Ruffle, we will soon return to the days of Internet Explorer 6 but with 4k monitors! All we need now is to run ActiveX. I think BottledWine can run Windows executables in the browser, how hard would it be to simulate the ActiveX bindings?
When everything else fails, you can just boot up a full Windows VM: https://copy.sh/v86/?profile=windows98
Re: CheerpJ 3.0: a JVM replacement in HTML5 and WASM to run Java on modern browsers
#68Amusingly, there were two different ways of running Java in the browser when it came out in the late 90s. One was Applet style where Java takes over a part of the canvas of the page and has to implement everything, like Flash or ActiveX. The other was headless and you had access to the DOM. Why no one built interesting applications with the latter is beyond me. https://docs.oracle.com/javase/tutorial/deployment/apple…
>The other was headless and you had access to the DOM. Why no one built interesting applications with the latter is beyond me.
Frameworks, HTML5 or even DHTML/AJAX didn't exist at the time. If you were already paying the cost of invoking Java/Flash/ActiveX, why would you access the DOM and pay extra rendering price - for an interface suited for documents, not applications?
Re: CheerpJ 3.0: a JVM replacement in HTML5 and WASM to run Java on modern browsers
#69Earlier quoted context omitted.
Yes, and it will JIT compile the code to native if you're using GraalVM: https://github.com/oracle/graal/tree/master/wasm But the point of JNI is to provide language bindings. WASM doesn't automatically fix the need for those.
> But the point of JNI is to provide language bindings. WASM doesn't automatically fix the need for those. True. I was imprecise. I'm fine with needing the language bindings / JNI. My main beef is with the platform specific native binaries that JNI binds too, and the complications (size or platform targeting) that they introduce to the build and distribution process.
Android folks are thinking about using WASM for NDK, with compilation to native code on the PlayStore.