Wouldn't it be funny, after all that sandboxing and component modelling, if it was JNI and SwingSet3 that finally made enterprise Wasm a thing?
(also this is impressive, great job)
This is fundamentally an implementation detail though, when we adopt WasmGC there will be no user visible change beside a potential performance improvement
I do wonder though why Oracle doesn't seem interested in building or acquiring some JVM in the browser.
It doesn't come with any lucrative extortion options to squeeze millions out of enterprises.
May be they are aiming for graalvm to be the answer eventually. (actually I don't know whether graalvm in the browser is effectively aot and brings all the reflection/dynamic code issues with it.) Curious if someone knowledgeable in that ecosystem knows.
And then what? Everybody would write Java code and run their ... not quite "apps" but we can call it app-lets -- in the browser, so that "write once run everywhere" could be achieved?
Seriously, I do wonder what the real value of some of this WASM stuff is. I mean, seems cool to run a java (or rust or <insert language here>) app in the browser, but what is the real world use case? If I run an app in the browser, I still have to do all the server side business validation because "you should never trust the client".
What am I missing?
Edit: on reading other comments, apparently this is direct-to-js compilation, not WASM. The intent of the comment still stands.
CheerpJ is effectively just a very sophisticated JavaScript/WebAssembly library and it plays by the rules of the browser sandbox.
It is easy to forget Java (applets, web start) was a thing during the Windows 98 era, meaning a time when there was (almost?) no security. People were downloading and running random .exe files all the time.
There was no browser sandboxing and you could run wild Basic code in IE.
Sun with Java were the first one to try to solve that problem. It was imperfect but way better than what others were doing at the time.
Since it's the runtime being ran on wasm, does this also allow for kotlin, clojure, scala etc as long as it's valid bytecode?
I'm kind of curious what limitations happen with networking?
As far as I know, there's no way to do direct socket / network IO in WASM. (IE, you need to use the fetch API.) Likewise, what if a jar uses HTTP, but uses an HTTP library that uses sockets?
For more general cases our Tailscale integration is required. For more information see: https://cheerpj.com/docs/guides/Networking
What is the problem here?
CheerpJ provide "Library mode": an API to natively interact with Java objects from JavaScript: https://cheerpj.com/docs/guides/library-mode
CheerpJ also support Java 17 (currently in preview) and LTS parity is scheduled for next year.
CheerpJ might be better solution next time.
However, they were pretty insecure and caused a ton of problems for the browser [1] and I'm guessing Oracle had no interest in providing free work in a secure solution. So they got eliminated.
[1]: https://blog.chromium.org/2013/09/saying-goodbye-to-our-old-...
1. use libraries from ecosystem outside JS. In the past few months, I've added support for file types like psd, dbf, arrow, parquet and about 50 more. To give a concrete example: https://www.filestash.app/tools/parquet-viewer.html WASM open up a very exciting door. In the same idea, I stumbled upon a couple JAVA only libraries which I would love to ship on a browser and not have to create web service to interact with those.
2. enable third party to make plugin that can run in my app in a safe way. In my case, plugins are zip files containing a bunch of assets and the WIP piece is to be able to put wasm in there that will run server side without giving those plugins a blank check for acting crazy.
I don't think mods hand-downrank posts to certain pages.
And, in full transparency, we don't engage in any manipulation of upvote count.
We try to play as fair as possible here and in other communities.
letters90•1y ago
https://browsercraft.cheerpj.com/
apignotti•1y ago
90s_dev•1y ago
Java seems to have come a long way since 2015. Might be worth looking into, if only I could find a page that summarizes every new language feature.
_old_dude_•1y ago
And the main page let you compare API versions https://javaalmanac.io/
creatonez•1y ago
> The latest version of Minecraft. Newer releases of Minecraft use a newer version of Java and OpenGL which we currently do not support. [...] This demo demonstrate these capabilities by running an older version (1.2.5) of Minecraft and LWJGL entirely in the browser.
Sadly, no one seems to be able to get past Minecraft 1.5, which was released in 2013 :(
Edit: Hmm... not sure when this happened, but Eaglercraft supports 1.12 (2017) now. Neat! Might be hard to go further than that, since modern Minecraft uses Java 21 / OpenGL 3.2, and LWJGL itself has evolved significantly in its platform APIs.
apignotti•1y ago
The Java side of things works out-of-the-box, but LWJGL3 JNI code uses some subtle techniques that are yet supported in public builds of CheerpJ.
Now that we have Java 17 support we expect to be able to move even further.
bufferoverflow•1y ago