CheerpJ 4.1: Java in the browser, now supporting Java 17 (preview)

https://labs.leaningtech.com/blog/cheerpj-4.1

by pjmlp • 1 year ago

120 49 1 year ago

labs.leaningtech.com

letters90• 1 year ago

The minecraft demo is quite impressive

https://browsercraft.cheerpj.com/

apignotti11• 1 year ago

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• 1 year 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.

creatonez• 1 year ago

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.

apignotti11• 1 year 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.

bufferoverflow• 1 year ago

Works on my smartphone. That's wild.

boomskats• 1 year 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)

txdv2• 1 year ago

It compiles to JavaScript and not wasm AFAIK

apignotti11• 1 year ago

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

lesuorac• 1 year 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.

[1] https://blog.chromium.org/2013/09/saying-goodbye-to-our-old-...

hawk_2• 1 year 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.

devrandoom• 1 year ago

why Oracle doesn't seem interested

It doesn't come with any lucrative extortion options to squeeze millions out of enterprises.

hawk_2• 1 year 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.

maratc2• 1 year 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?

mooreds2• 1 year 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.

jeffreportmill13• 1 year 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.

soco• 1 year 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.

apignotti11• 1 year 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• 1 year 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• 1 year 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• 1 year ago

I’d imagine the biggest one is that it doesn’t require the user to have installed a Java runtime on their computer.

maratc2• 1 year 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.

matsemann2• 1 year 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?

apignotti11• 1 year ago

Yes, any JVM language should work. We did some experiments with Kotlin specifically in the past.

matsemann2• 1 year 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.

quaintdev• 1 year ago

They ran freaking Intellij IDE inside the browser. Insane!

Alifatisk3• 1 year ago

That's actually very impressive, wow

gwbas1c• 1 year 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?

apignotti11• 1 year 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.

For more general cases our Tailscale integration is required. For more information see: https://cheerpj.com/docs/guides/Networking

jeffreportmill13• 1 year ago

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.

apignotti11• 1 year 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?

Alifatisk3• 1 year ago

How has it been killed by mods?

apignotti11• 1 year 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.

ConfusedDog3• 1 year 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.

gavinray2• 1 year 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.

apignotti11• 1 year 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.

Alifatisk3• 1 year 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• 1 year ago

Interesting how this is perceived as impressive (and it is!), but we had runescape running in the browser over 20 years ago already.

CheerpJ 4.1: Java in the browser, now supporting Java 17 (preview)

Related Stories