apignotti

What you describe is 100% possible. Rails is one of our priorities. PHP is also easy to achieve.

React native can indeed target the We. Instead we are referring to running the native build toolchain for react native, which is required to build android apps, in the browser.

We are working on it. Firefox is currently unsupported due to Atomics.waitAsync being not yet enabled by default. Safari on the other hand has some subtle inconsistent behavior at the edge between getters, global variables and `this`.

BrowserPod is intended to work across all browsers, but we are not there yet.

Hi, thanks for the mention :-)

Lead dev of CheerpJ and CTO of Leaning Technologies here. Happy to answer any question from the community.

BigInts are the current solution. There are other solutions as well.

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.

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.

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.

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?

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

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

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.

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.

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

Thanks. Architecturally, beside the unmodified Minecraft and LWJGL jars, this demo uses the original JNI code from LWJGL, compiled from C++ to WebAssembly.

Does anyone know if there is work on the idea of letting MCP-like "servers" run on the client-side? I.e. in the same browser tab as ChatGPT or Claude?

This specific example would make much more sense if it could run sandboxed client-side.

Shameless plug: CheerpJ is our solution to run any JVM language in the browser, including Clojure. Reflections, Multithreading and Swing / AWT apps are all supported.

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

And yes, it can run Minecraft :-)

https://browsercraft.cheerpj.com/

I meant the JVM in an extended sense: the combination of the bytecode parsing, JIT compiler and OpenJDK runtime. You are right, I should have been more precise and refer to only the runtime part, which is by far the most significant.

The VM itself is very small, it's the OpenJDK runtime that is quite sizeable. Byte ranges are used to only download the parts of the runtime (in terms of bytecode) that are required.

There is no server-side computation. CheerpJ runs code exclusively client-side.

> That's interesting! May I ask how it works? Does that also happen with e.g. IntelliJ?

Byte ranges request do most of the heavy lifting, data is loading exclusively on-demand.

> Doesn't the JVM run everywhere in 2025?

What about iOS? Android has Java, but can't run desktop Java apps. Chromebooks also have limits.

With CheerpJ you are downloading the subset of the JVM that you need, and actually only once thanks to the standard browser cache.

There are many reasons why shipping via the browser is a better choice compared to shipping desktop apps. The main 3 in my opinion are:

1. Distribution: Give your user a link and the app will start 2. Isolation: The user can have confidence the app won't read his personal files. 3. Cross-platform: Every OS and every device, for real this time

No, this is the unmodified Minecraft JAR running on top of CheerpJ, a WebAssembly-based JVM.

Small Business licenses will be available with the release of CheerpJ 4.0, expected in mid April 2025.

They will allow self-hosting and will be priced on a per application / per website basis. They will be priced to be affordable and ensure that CheerpJ enjoys a wide reach.

If you are interested before the release, please do get in touch (info@leaningtech.com).

JavaFX is not yet supported, but we plan to get it to work soon.

The issue here is that there is very little Java in JavaFX, it's mostly native C++ code. This makes it actually quite similar to the LWJGL library used by Minecraft.

Our plan is to use for JavaFX the same technology we have developed for LWJGL.

Thanks for spotting this, we'll get it fixed ASAP

Hi everybody, happy to see our CheerpJ demo is appreciated.

CheerpJ is a WebAssembly-based JVM that can run unmodified Java 8 and Java 11 applications. Java 17 will be supported later in year.

I am the lead developer of CheerpJ and CTO of Leaning Technologies. AMA.

This is actually running on top of a WebAssembly-based Java Virtual Machine (CheerpJ).

You are probably thinking about our independent x86 virtualization product CheerpX (https://cheerpx.io)

Mobile is indeed supported, although the performance is not yet as nice as we would like.

The trickiest issue is input, since the "look around with your mouse" interaction maps very poorly on a mobile platform where "mousemove" implies touching / clicking.

We plan to eventually figure out a mobile-optimize UX, but we will most likely prioritize improving the performance first.

Thanks for your kind words, appreciated.

Link to our blog, we try to regularly publish high quality content: https://labs.leaningtech.com/blog

> Chromium is open source, with contributions from many organizations (who retain the copyright to their contributed code).

To contribute anything to Chromium or V8 you need to sign a CLA, afterwards there are very little rights you retain.