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.
I used it to make a program that logs all activity happening on the Pioneer CDJs. The best reverse engineering of the Pioneer protocols is a Java project, but I wanted to write the rest of my application in Go.
GraalVM plus a GitHub action spits out native binaries that I can exec and interact with over stdio from Go.
If/when the WASM backend supports UDP networking and threads I'd love to run it as WASM instead of a binary.
> Starting from v25 GraalVM added support for WASM
GraalVM is so amazing technically, but gets so little love by HN.
sureglymop 65 days ago [-]
When I tried it it was great but also not easy to use. Things become hard quickly, e.g. If your jvm code uses something like reflection.
perrygeo 65 days ago [-]
Clojure code ends up using a lot of reflection if you're doing generic Java interop. Most code destined for the GraalVM will add `(set! warn-on-reflection true)` and get repl warnings and you can set type hints accordingly.
hocuspocus 65 days ago [-]
Native images are just one feature though. Many people would benefit from the Graal JIT even if they don't care about anything else.
Capricorn2481 64 days ago [-]
My understanding is GraalVM's JIT keeps some optimizations for the enterprise edition, and is otherwise comparable to Hotspot, with some niche exceptions. I'm not sure "many" would benefit without paying.
hocuspocus 64 days ago [-]
It's been entirely free since mid-2023. Even if you care rather about native images, you probably want to use the proprietary distribution anyway.
90s_dev 65 days ago [-]
I vaguely remember using it about 10 years ago for work, can't remember what for, or anything about that situation, but the one takeaway that I do remember is that it was neat and innovative, but ultimately not good enough to overthrow whatever we were using instead.
piranha 65 days ago [-]
First release happened in 2019
90s_dev 64 days ago [-]
My memory is not great, as implied by that very comment.
pjmlp 64 days ago [-]
GraalVM has evolved from another Sun Research Labs project, MaximeVM, but that was never released as a product.
gavinray 65 days ago [-]
Just to clarify -- GraalVM had support for RUNNING WASM for quite a long time.
This post references the ability to compile programs via native images to WASM as an output format.
hardwaresofton 65 days ago [-]
Does it have to do with the somewhat complicated licensing?
hocuspocus 65 days ago [-]
Current licenses for Oracle JDK and GraalVM are essentially the same terms. It's pretty straightforward.
Any company using Java should be willing to read and understand Oracle's terms, whether they use third party OpenJDK distributions or Oracle's builds.
If you're leaving significant performance gains on the table because you can't read, that's on you.
pjmlp 64 days ago [-]
Just like most FOSS licenses, that in big corps always got through legal.
In the projects where that isn't required, usually we have licence validation tooling on the CI/CD pipeline, that breaks the build if the legal wishes aren't fulfilled.
amelius 65 days ago [-]
And Oracle's army of lawyers.
kokada 65 days ago [-]
Not really, but one thing that bothers me is how unreproducible GraalVM is. AFAIK every distro that has binaries for it just repacks the binaries released from Oracle, and the last time I searched I couldn't find instructions on how to build from scratch (I was the maintainer of GraalVM in nixpkgs, not anymore because I just got fed-up with it).
an-unknown 64 days ago [-]
Not sure why people always say it's so hard to build GraalVM ... all you need is roughly 2 prerequisites and one build command. The prerequisites are a "Labs JDK" which is essentially a slightly modified OpenJDK with more up to date JVMCI (the JIT interface used by Graal) and the build tool "mx".
Since you want to build completely from source, you start by installing OpenJDK. Then you clone the Labs JDK repo [0] and build it just like how you would build any other OpenJDK. Once you have the Labs JDK, you don't need the OpenJDK anymore, since that's only necessary to build the Labs JDK. If you use a normal OpenJDK instead of Labs JDK for Graal, the Graal build will most likely tell you something about "too old JVMCI" and fail. Don't do that.
Next you clone mx [1] and graal [2] into some folder and add the mx folder to PATH. You also need Python and Ninja installed, and maybe something else which I can't remember anymore (but you'd quickly figure it out if the build fails). Once you have that, you go to graal/vm and run the relevant "mx build" command. You specify the path to the Labs JDK via the "--java-home" CLI option and you have to decide which components to include by adding them to the build command line. I can't remember what exactly happens with just "mx build" but chances are this only gives you a bare GraalVM without anything else, which means also no SubstrateVM ("native-image"). By adding projects on the command line, you can include whatever languages/features are available. And that's it. After some time (depending on how beefy your computer is), you get the final GraalVM distribution in some folder, with a nice symlink to find it.
It's not exactly documented in a good way, but you can figure it out from the CI scripts which are in the git repos of Graal and Labs JDK. The "mx build" command is where you decide which languages and features to include; if you want to include languages from external repositories, you have to clone them next to the graal and mx folder and add the relevant projects to the mx build command.
I think the fact that you had to write a 4 paragraph about the process say more about it than anything.
pjmlp 65 days ago [-]
That is how people lose out on great technology, while worshiping the ways of 1980's server room computing.
dlachausse 65 days ago [-]
> The output WASM of this simple program is 5.6MB binary, which can be pruned a bit via wasm-opt tool, just make sure that it doesn't break anything for you. Luckily when compressed (gzip, brotli, etc) the binary becomes just ~2.5MB in size.
That’s much better than I expected! Very impressive work here. It actually looks viable for certain applications.
sjrd 65 days ago [-]
It's acceptable. Meanwhile 5.6MB of Wasm is about the size of the entire test suite of Scala.js. :-p
GraalVM is excellent technology, but when it comes to targeting Wasm, I believe the core language compilers will always have an edge.
65 days ago [-]
croemer 65 days ago [-]
The analysis of the benchmark is wrong. Native is faster than JVM for 2 out of 4 operations. The 2-3x vs 5-12x are hence not correct.
yes sir, i kinda love seeing all the different ways folks mash stuff together to get dev setups working, so much trial and error that never gets seen - you ever feel like the real blocker is always some weird little detail nobody warns you about?
rgyams 65 days ago [-]
Nice, I will revisit closure to try this out
millerm 65 days ago [-]
Clojure. ;)
tomjakubowski 65 days ago [-]
For quite some time (maybe even still today?), ClojureScript was compiled to JS using the Google Closure Compiler. I felt sympathy for anyone who had to discuss that out loud.
sjrd 65 days ago [-]
The trick is to call the latter GCC. Much less confusing. ;-)
tonyarkles 65 days ago [-]
And now I've got coffee in my sinus. Thanks for that :D
superhoops540 65 days ago [-]
Would have been good to create a pamphlet to inform on the differences. A Clojure/Closure Brochure, if you will
timgilbert 64 days ago [-]
For sure.
shawn_w 65 days ago [-]
Imagine the pain of talking about Clozure Common Lisp.
kazinator 64 days ago [-]
Lucky we can do "CCL".
90s_dev 65 days ago [-]
You have no idea how many times I typed clojure when I meant to type closure throughout my career. Bizarrely backwards.
https://labs.leaningtech.com/blog/cheerpj-4.0
And yes, it can run Minecraft :-)
https://browsercraft.cheerpj.com/
I used it to make a program that logs all activity happening on the Pioneer CDJs. The best reverse engineering of the Pioneer protocols is a Java project, but I wanted to write the rest of my application in Go.
GraalVM plus a GitHub action spits out native binaries that I can exec and interact with over stdio from Go.
If/when the WASM backend supports UDP networking and threads I'd love to run it as WASM instead of a binary.
- https://github.com/nzoschke/vizlink
- https://github.com/nzoschke/vizlink/blob/main/.github/workfl...
GraalVM is so amazing technically, but gets so little love by HN.
This post references the ability to compile programs via native images to WASM as an output format.
https://www.oracle.com/downloads/licenses/graal-free-license...
Everyone else in the world probably does not see this as "straight forward".
So Step 0, be a lawyer.
https://blogs.oracle.com/java/post/free-java-license
Any company using Java should be willing to read and understand Oracle's terms, whether they use third party OpenJDK distributions or Oracle's builds.
If you're leaving significant performance gains on the table because you can't read, that's on you.
In the projects where that isn't required, usually we have licence validation tooling on the CI/CD pipeline, that breaks the build if the legal wishes aren't fulfilled.
Since you want to build completely from source, you start by installing OpenJDK. Then you clone the Labs JDK repo [0] and build it just like how you would build any other OpenJDK. Once you have the Labs JDK, you don't need the OpenJDK anymore, since that's only necessary to build the Labs JDK. If you use a normal OpenJDK instead of Labs JDK for Graal, the Graal build will most likely tell you something about "too old JVMCI" and fail. Don't do that.
Next you clone mx [1] and graal [2] into some folder and add the mx folder to PATH. You also need Python and Ninja installed, and maybe something else which I can't remember anymore (but you'd quickly figure it out if the build fails). Once you have that, you go to graal/vm and run the relevant "mx build" command. You specify the path to the Labs JDK via the "--java-home" CLI option and you have to decide which components to include by adding them to the build command line. I can't remember what exactly happens with just "mx build" but chances are this only gives you a bare GraalVM without anything else, which means also no SubstrateVM ("native-image"). By adding projects on the command line, you can include whatever languages/features are available. And that's it. After some time (depending on how beefy your computer is), you get the final GraalVM distribution in some folder, with a nice symlink to find it.
It's not exactly documented in a good way, but you can figure it out from the CI scripts which are in the git repos of Graal and Labs JDK. The "mx build" command is where you decide which languages and features to include; if you want to include languages from external repositories, you have to clone them next to the graal and mx folder and add the relevant projects to the mx build command.
[0] https://github.com/graalvm/labs-openjdk
[1] https://github.com/graalvm/mx
[2] https://github.com/oracle/graal
That’s much better than I expected! Very impressive work here. It actually looks viable for certain applications.
GraalVM is excellent technology, but when it comes to targeting Wasm, I believe the core language compilers will always have an edge.
https://youtu.be/nnDo0i6NbsI?si=XSqgSVoV6ISBWg2n&t=185
https://webassembly.org/