Thanks. Architecturally, beside the unmodified Minecraft and LWJGL jars, this demo uses the original JNI code from LWJGL, compiled from C++ to WebAssembly.
90s_dev · 22h ago
Clever.
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.
I love this... but I've grown disappointed by these technically impressive demos, now that older Minecraft running in WASM is no longer novel ever since Eaglercraft came out. As per the readme:
> 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 · 22h ago
As a matter of fact we have internally achieved 1.16.5.
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.
hawk_ · 22h ago
This is incredible. Kudos to the team behind it. This requires knowing both the browser and JVM quite well.
I do wonder though why Oracle doesn't seem interested in building or acquiring some JVM in the browser.
maratc · 22h ago
> I do wonder though why Oracle doesn't seem interested
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?
mooreds · 21h ago
Nooo! I spent a summer in college writing physics education applets. The scars are still there.
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.
mickael-kerjean · 21h ago
For my use case of building Filestash, WASM is a game changer in those 2 areas:
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.
mooreds · 15h ago
Thanks, that's super helpful. For #2, do you run the WASM plugins in a sandboxed browser?
devrandoom · 22h ago
> why Oracle doesn't seem interested
It doesn't come with any lucrative extortion options to squeeze millions out of enterprises.
hawk_ · 22h ago
There ought be a fair amount of legacy Java code sitting in enterprises that they would be willing to pay for an Oracle® seal of approval for running parts in the browser.
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.
jeffreportmill1 · 19h ago
I totally agree with this! Oracle still spends time and money promoting Java client, and the browser is now the largest client platform. They could really revitalize Java client by backing CheerpJ.
apignotti · 21h ago
I see the post has been killed by moderators. I would like to be contacted to discuss why this is the case. Our content is of obvious interest to the community and we always engage in productive ways.
What is the problem here?
gavinray · 20h ago
It could be that it got upvoted so rapidly it triggered vote-spam detection.
I don't think mods hand-downrank posts to certain pages.
apignotti · 20h ago
I suspect something else is amiss here, since it is not the first time this happens.
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.
Alifatisk · 20h ago
How has it been killed by mods?
apignotti · 20h ago
Sent straight down to 3rd page from the very first position in home. I assume there must be some internal "send this down to hell" button.
ConfusedDog · 20h ago
Not OP here, but it did disappear from the frontpage. I was still pondering about it and left this tab open... frankly I can't think of a good use case for it besides making legacy java apps available via browser. For gaming, I'd probably still use Unity or other game engines. For app development, I probably not gonna develop on Java 11 again which the support gonna be ending in 2026. I'm impressed by this project though.
apignotti · 20h ago
The legacy use case is indeed very important, but there are many other opportunities that can come from using Java libraries as part of Web apps.
CheerpJ also support Java 17 (currently in preview) and LTS parity is scheduled for next year.
jeffreportmill1 · 19h ago
I use CheerpJ to do new development that is spectacularly cross-platform, runs native on all the major platforms and everywhere else in the browser with a single code base. I don't think there are too many alternatives for that and I suspect Java + CheerpJ is one of the best.
Being able to access the entirety of the JVM ecosystem of libraries from JS without glue code is kind of insane.
ConfusedDog · 18h ago
Yes, I'm super impressed by that.
matsemann · 21h ago
Wow, seriously impressive. GWT had so many drawbacks this seems to solve (like everything with reflection not working).
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?
apignotti · 21h ago
Yes, any JVM language should work. We did some experiments with Kotlin specifically in the past.
matsemann · 21h ago
Thanks! I know kotlin has a JS target, but being able to just deploy the software as-is without a separate codebase for the interface, dealing with all the differences of the platforms etc is something else entirely. Very cool.
gwbas1c · 21h ago
> CheerpJ can run existing, full Java applications from unmodified JARs, with no recompilation or pre-processing, straight from 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?
apignotti · 21h ago
CheerpJ does out-of-the-box support HTTP/HTTPS requests using fetch when the application uses the standard Java UrlConnection APIs. Of course the requests must be to the same domain (which a common case) or to a domain which is CORS enabled, since CheerpJ is subject to the same limitations as any other JavaScript library.
I need to check out the tailscale solution, although CheerpJ also makes it trivial to plug in a proxy server, which I currently do in my app that supports cross origin.
quaintdev · 21h ago
They ran freaking Intellij IDE inside the browser. Insane!
Alifatisk · 20h ago
That's actually very impressive, wow
boomskats · 22h ago
"Ha! I KNEW it! WebAssembly literally IS just a reinvention of the JVM!!1"
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)
lesuorac · 21h ago
Java Applets probably would've snuffed out WASM if it was added into a browser by default (instead of an extension).
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.
The target of the JIT compiler is indeed JavaScript, since WasmGC is still too limited.
This is fundamentally an implementation detail though, when we adopt WasmGC there will be no user visible change beside a potential performance improvement
dunham · 19h ago
How do you deal with numbers? Javascript doesn't do 64-bit numbers and naively multiplying 32-bit numbers can loose lower bits. If I remember right GWT used two numbers to represent 64-bit and ignored the 32-bit issue.
apignotti · 3h ago
BigInts are the current solution. There are other solutions as well.
txdv · 14h ago
Can you point out the limitations?
Alifatisk · 20h ago
I once wanted to port a little Java application (with no libs except JavaFX) to the web, so I converted it into Dart lang and then compiled it to the web, a bit painful but cool thing.
CheerpJ might be better solution next time.
nopcode · 19h ago
Interesting how this is perceived as impressive (and it is!), but we had runescape running in the browser over 20 years ago already.
soco · 22h ago
I don't see what for me would be the key document: how is this technology addressing the plethora of reasons which made the applets fail.
apignotti · 22h ago
Applets were executed completely outside of the browser sandbox. An absolute disaster from the security standpoint.
CheerpJ is effectively just a very sophisticated JavaScript/WebAssembly library and it plays by the rules of the browser sandbox.
sunshine-o · 21h ago
> Applets were executed completely outside of the browser sandbox. An absolute disaster from the security standpoint.
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.
rst · 21h ago
WASM has a better security sandbox. (Designed in from the beginning, not the thousand-fingers-in-the-dike retrofit that was the Java SecurityManager -- which was eventually deprecated and abandoned along with the Applet tech it was intended to support.)
afavour · 21h ago
I’d imagine the biggest one is that it doesn’t require the user to have installed a Java runtime on their computer.
maratc · 11h ago
Applets didn’t fail because of missing JRE, it was included in IE. It was only after Microsoft started playing around with the implementation that Sun asked them to stop, which they did. Only then did a missing JRE become an issue.
https://browsercraft.cheerpj.com/
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.
And the main page let you compare API versions https://javaalmanac.io/
> 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.
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.
I do wonder though why Oracle doesn't seem interested in building or acquiring some JVM in the browser.
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.
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.
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.
What is the problem here?
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.
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.
https://reportmill.com/SnapCode
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
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)
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-...
This is fundamentally an implementation detail though, when we adopt WasmGC there will be no user visible change beside a potential performance improvement
CheerpJ might be better solution next time.
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.