The minecraft demo is quite impressive
Thanks. Architecturally, beside the unmodified Minecraft and LWJGL jars, this demo uses the original JNI code from LWJGL, compiled from C++ to WebAssembly.
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.
Java Almanac has a list of all features https://javaalmanac.io/features/
And the main page let you compare API versions https://javaalmanac.io/
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.
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.
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.
> 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?
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.
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.
Thanks, that's super helpful. For #2, do you run the WASM plugins in a sandboxed browser?
> why Oracle doesn't seem interested
It doesn't come with any lucrative extortion options to squeeze millions out of enterprises.
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.
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.
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?
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.
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.
How has it been killed by mods?
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.
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.
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 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.
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.
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?
Yes, any JVM language should work. We did some experiments with Kotlin specifically in the past.
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.
> 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?
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.
For more general cases our Tailscale integration is required. For more information see: https://cheerpj.com/docs/guides/Networking
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.
"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)
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.
[1]: https://blog.chromium.org/2013/09/saying-goodbye-to-our-old-...
It compiles to JavaScript and not wasm AFAIK
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
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.
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.
Interesting how this is perceived as impressive (and it is!), but we had runescape running in the browser over 20 years ago already.
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.
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.
> 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.
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.)
I’d imagine the biggest one is that it doesn’t require the user to have installed a Java runtime on their computer.
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.