{"slug": "graalvm", "name": "GraalVM", "category": "dev-libs", "category_name": "Libraries and frameworks", "description": "", "recommenders": 17, "commenters": 30, "warners": 6, "score": 10.107, "rising": 1.07, "first": "2025-11-17", "latest": "2026-10-24", "why": "GraalVM's Native Image [1] already let's do AOT compilation suitable for distribution", "why_is_quote": true, "has_verdict": false, "sentiment": {"recommend": 18, "neutral": 9, "compare": 3, "warn": 6}, "spark": [1, 5, 1, 1, 1, 1, 3, 0, 0, 0, 3, 2], "listed": true, "loved": [], "caveat": "", "short_quote": "GraalVM's Native Image [1] already let's do AOT compilation suitable for distribution", "kind": "", "icon": true, "domain": "graalvm.org", "github_repo": null, "official_url": "https://www.graalvm.org", "pricing": "", "aliases": ["GraalVM", "GraalVM Native Image", "GraalVM native-image"], "verdict": null, "praise": [{"label": "", "summary": "", "quotes": [{"id": 802191136, "item_id": 50136946, "url": "https://news.ycombinator.com/item?id=50136946", "by": "invalidname", "date": "2026-10-18", "version": null, "stance": "recommend", "quote": "There are other solutions that give you MUCH faster startup with lower memory", "excerpt": "Other posters here seem to misunderstand what AOT means in today's Java. It just means caching some state. There's still a JIT involved, it's just warmer. There are other solutions that give you MUCH faster startup with lower memory e.g.: https://foojay.io/today/java-server-work-before-startup/ Edit: it seems I missed that 28 added the actual native code compilation phase so it will probably be closer to the GraalVM ", "context": "", "use_case": "Fast Java startup", "switched_from": "", "story": "JDK 28"}, {"id": 799557968, "item_id": 49972373, "url": "https://news.ycombinator.com/item?id=49972373", "by": "edwardkmett", "date": "2026-10-05", "version": null, "stance": "recommend", "quote": "Without Truffle/Graal the limitations of the JVM are just too severe.", "excerpt": "We get a JITTed runtime, which can actually beat compiled GHC in performance in cases. We get first-class cross-language FFI to truffled language implementations: Python, Ruby, R, Javascript with shared objects, which can JIT together. The idea is that fully fleshed out this would give Haskell a clean path to reach over to pytorch to run an AI model, take the answers, smash them through some statistical analysis usin", "context": "", "use_case": "JIT runtime, polyglot interop", "switched_from": "", "story": "Turbo Haskell"}, {"id": 795419392, "item_id": 49713712, "url": "https://news.ycombinator.com/item?id=49713712", "by": "cavoirom", "date": "2026-09-15", "version": null, "stance": "recommend", "quote": "you can run that JDK version in a modern JVM", "excerpt": "If your app requires a specific JDK version and your OS wont support, you can run that JDK version in a modern JVM: https://www.graalvm.org/latest/reference-manual/espresso/", "context": "", "use_case": "Running older JDK versions", "switched_from": "", "story": "Java 27"}, {"id": 795154930, "item_id": 49697183, "url": "https://news.ycombinator.com/item?id=49697183", "by": "khaliostr", "date": "2026-09-14", "version": null, "stance": "recommend", "quote": "GraalVM\u2019s new WebAssembly support finally made this possible", "excerpt": "I\u2019ve been working on getting MTG Forge (a 15+ year old Java Magic: the Gathering rules engine) to run in the browser. GraalVM\u2019s new WebAssembly support finally made this possible, and we now use it for local games in Manabrew. We also packaged the Forge build as @manabrew/forge-wasm (AGPL). https://manabrew.app/blog/graalvm/", "context": "", "use_case": "Java to WebAssembly", "switched_from": "", "story": "Ask HN: What are you working on? (September 2026)"}, {"id": 794370688, "item_id": 49648168, "url": "https://news.ycombinator.com/item?id=49648168", "by": "nirvdrum", "date": "2026-09-10", "version": null, "stance": "recommend", "quote": "GraalVM's Native Image [1] already let's do AOT compilation suitable for distribution", "excerpt": "If you haven't checked it out yet, GraalVM's Native Image [1] already let's do AOT compilation suitable for distribution. You have to do some configuration to deal with reflection and dynamic class loading since there's no JVM in the produced build, but it comes with tooling to simplify that. And that restriction is being addressed by Project Crema [2]. [1] -- https://www.graalvm.org/latest/reference-manual/native-im", "context": "", "use_case": "", "switched_from": "", "story": "JEP 544: Ahead-of-Time Code Compilation"}]}], "caveats": [{"label": "", "summary": "", "quotes": [{"id": 743843571, "item_id": 46490223, "url": "https://news.ycombinator.com/item?id=46490223", "by": "simonw", "date": "2026-01-04", "version": null, "stance": "warn", "quote": "I looked at GraalVM but was put off by the licensing situation", "excerpt": "The challenge with V8 is finding a wrapper for it that doesn't come with a big warning NOT to use it as a sandbox for untrusted code - here's the workerd one https://github.com/cloudflare/workerd?tab=readme-ov-file#warning-workerd-is-not-a-hardened-sandbox and here's the PyMiniRacer section: https://bpcreech.com/PyMiniRacer/architecture/#security-goals I looked at GraalVM but was put off by the licensing situation: h", "context": "", "use_case": "", "switched_from": "", "story": "JavaScript engines zoo \u2013 Compare every JavaScript engine"}, {"id": 743159840, "item_id": 46447490, "url": "https://news.ycombinator.com/item?id=46447490", "by": "cb321", "date": "2025-12-31", "version": null, "stance": "warn", "quote": "it's still pretty slow compared to some other competition", "excerpt": "Haven't checked graalvm in a long time. So, I got graalvm-jdk-25.0.1+8.1 for x86_64. It's a lot faster than Julia, and maybe 43ms is not slow in \"human terms\", but it's still pretty slow compared to some other competition. This was for a helloworld.jar [1]. On my laptop (i7-1370P, p-cores) using tim[2]: $ tim \"awk '{}'</n\" 'tcc -run /tmp/true.c' 'perl</n' 'py2</n' 'py3</n' 'java -jar helloworld.jar>/n' 97.5 +- 1.5 \u03bcs", "context": "", "use_case": "Java startup benchmarking", "switched_from": "", "story": "2026: The Year of Java in the Terminal"}, {"id": 743146512, "item_id": 46446657, "url": "https://news.ycombinator.com/item?id=46446657", "by": "mbreese", "date": "2025-12-31", "version": null, "stance": "warn", "quote": "so Graal has been difficult to get working", "excerpt": "I\u2019m about the same. I\u2019ve had one Java project going for over 10 years. It\u2019s a collection of utilities that I use for work everyday that has grown substantially over the years. It is a CLI program that runs in my Mac, Linux servers and Linux HPC clusters. It is built with a fat-JAR concatenated to a shell stub in front that makes it effectively a single-file install. I also wrote a complete library for defining CLI pr", "context": "", "use_case": "", "switched_from": "", "story": "2026: The Year of Java in the Terminal"}, {"id": 743135825, "item_id": 46445989, "url": "https://news.ycombinator.com/item?id=46445989", "by": "gunnarmorling", "date": "2025-12-31", "version": null, "stance": "warn", "quote": "Build times with GraalVM are still not ideal", "excerpt": "As a practical example for a Java-based CLI tool in the wild, here's kcctl, a command line client for Kafka Connect: https://github.com/kcctl/kcctl/. It's a native binary (via GraalVM), starting up in a few ms, so that it actually be invoked during tab completions and do a round-trip to the Kafka Connect REST API without any noticeable delay whatsoever. Installation is via brew, so same experience as for all the othe", "context": "", "use_case": "", "switched_from": "", "story": "2026: The Year of Java in the Terminal"}]}], "who": [{"by": "p2detar", "context": "ships on-premises Windows Server product, moving to cloud", "url": "https://news.ycombinator.com/item?id=49723545", "date": "2026-09-16"}], "tags": [], "use_cases": ["native image compilation", "fast java startup", "jit runtime, polyglot interop", "native java executables", "running older jdk versions", "java to webassembly"], "compared": [{"slug": "jbang", "name": "jbang", "co": 4, "switched_from": 0, "switched_to": 0}], "makers": [{"id": 738960353, "item_id": 46185022, "url": "https://news.ycombinator.com/item?id=46185022", "by": "fniephaus", "date": "2025-12-07", "version": null, "stance": "neutral", "quote": "We (the GraalVM team) maintain", "excerpt": "BTW: We (the GraalVM team) maintain a full-blown LLVM bitcode runtime that can be embedded in Spring or any other JVM application and compiled to native: https://github.com/oracle/graal/tree/master/sulong", "context": "", "use_case": "", "switched_from": "", "story": "Java Hello World, LLVM Edition"}], "threads": [{"url": "https://news.ycombinator.com/item?id=46445229", "title": "2026: The Year of Java in the Terminal", "mentions": 8}, {"url": "https://news.ycombinator.com/item?id=49712041", "title": "Java 27", "mentions": 2}, {"url": "https://news.ycombinator.com/item?id=48311490", "title": "Endive: A JVM native WebAssembly runtime", "mentions": 2}, {"url": "https://news.ycombinator.com/item?id=48270265", "title": "Ruby vs. Java vs. TypeScript: my experience on building a Cowork DOCX plugin", "mentions": 2}, {"url": "https://news.ycombinator.com/item?id=47557171", "title": "TruffleRuby", "mentions": 2}, {"url": "https://news.ycombinator.com/item?id=46486978", "title": "JavaScript engines zoo \u2013 Compare every JavaScript engine", "mentions": 2}], "sentiment_by_month": {"2025-11": {"compare": 1, "recommend": 1, "neutral": 1}, "2025-12": {"recommend": 5, "warn": 3}, "2026-01": {"neutral": 1, "warn": 2, "recommend": 1}, "2026-02": {"neutral": 2, "recommend": 1}, "2026-03": {"recommend": 1, "warn": 1}, "2026-04": {"compare": 2, "neutral": 1, "recommend": 1}, "2026-05": {"neutral": 2, "recommend": 3}, "2026-06": {}, "2026-07": {}, "2026-08": {}, "2026-09": {"recommend": 3, "neutral": 1}, "2026-10": {"recommend": 2, "neutral": 1}}, "versions": [], "version_unnamed": 0, "family_ref": null, "runs_on": null, "lines": [], "quotes": [{"id": 803578994, "item_id": 50223687, "url": "https://news.ycombinator.com/item?id=50223687", "by": "mike_hearn", "date": "2026-10-24", "version": null, "stance": "neutral", "quote": "At least as long as you run on GraalVM", "excerpt": "Yes (or any JVM lang). There is also this: https://qxotic.ai/ ... which is a single JAR that does SIMD accelerated inferencing of local models, dependency free. Everything is written in Java from the tokenizer up. It can also use Metal on macOS. Small models can be surprisingly powerful these days and all you need is a fast CPU. It works not only for LLMs but also image models, video models and speech. Remarkably, it", "context": "", "use_case": "", "switched_from": "", "story": "TornadoVM 7 Enables GPU-Native Workloads from Java Applications"}, {"id": 802191136, "item_id": 50136946, "url": "https://news.ycombinator.com/item?id=50136946", "by": "invalidname", "date": "2026-10-18", "version": null, "stance": "recommend", "quote": "There are other solutions that give you MUCH faster startup with lower memory", "excerpt": "Other posters here seem to misunderstand what AOT means in today's Java. It just means caching some state. There's still a JIT involved, it's just warmer. There are other solutions that give you MUCH faster startup with lower memory e.g.: https://foojay.io/today/java-server-work-before-startup/ Edit: it seems I missed that 28 added the actual native code compilation phase so it will probably be closer to the GraalVM ", "context": "", "use_case": "Fast Java startup", "switched_from": "", "story": "JDK 28"}, {"id": 799557968, "item_id": 49972373, "url": "https://news.ycombinator.com/item?id=49972373", "by": "edwardkmett", "date": "2026-10-05", "version": null, "stance": "recommend", "quote": "Without Truffle/Graal the limitations of the JVM are just too severe.", "excerpt": "We get a JITTed runtime, which can actually beat compiled GHC in performance in cases. We get first-class cross-language FFI to truffled language implementations: Python, Ruby, R, Javascript with shared objects, which can JIT together. The idea is that fully fleshed out this would give Haskell a clean path to reach over to pytorch to run an AI model, take the answers, smash them through some statistical analysis usin", "context": "", "use_case": "JIT runtime, polyglot interop", "switched_from": "", "story": "Turbo Haskell"}, {"id": 795576720, "item_id": 49723545, "url": "https://news.ycombinator.com/item?id=49723545", "by": "p2detar", "date": "2026-09-16", "version": null, "stance": "neutral", "quote": "I did try GraalVM-compiled Java executables a couple of years ago and they were not bad, but the binaries were quite big", "excerpt": "> Btw, have you tried Leyden/AOT for better startup times? Curious about your experiences with that. Nope, not yet. It's a good question given that up to now we used to deliver our product only on-premises and Windows Server-only, but this year we are now finally going with the Cloud, which means Docker containers and Linux. If I remember correctly Leyden required some sort of warm-up and training data collection bef", "context": "ships on-premises Windows Server product, moving to cloud", "use_case": "native Java executables", "switched_from": "", "story": "Java 27"}, {"id": 795419392, "item_id": 49713712, "url": "https://news.ycombinator.com/item?id=49713712", "by": "cavoirom", "date": "2026-09-15", "version": null, "stance": "recommend", "quote": "you can run that JDK version in a modern JVM", "excerpt": "If your app requires a specific JDK version and your OS wont support, you can run that JDK version in a modern JVM: https://www.graalvm.org/latest/reference-manual/espresso/", "context": "", "use_case": "Running older JDK versions", "switched_from": "", "story": "Java 27"}, {"id": 795154930, "item_id": 49697183, "url": "https://news.ycombinator.com/item?id=49697183", "by": "khaliostr", "date": "2026-09-14", "version": null, "stance": "recommend", "quote": "GraalVM\u2019s new WebAssembly support finally made this possible", "excerpt": "I\u2019ve been working on getting MTG Forge (a 15+ year old Java Magic: the Gathering rules engine) to run in the browser. GraalVM\u2019s new WebAssembly support finally made this possible, and we now use it for local games in Manabrew. We also packaged the Forge build as @manabrew/forge-wasm (AGPL). https://manabrew.app/blog/graalvm/", "context": "", "use_case": "Java to WebAssembly", "switched_from": "", "story": "Ask HN: What are you working on? (September 2026)"}, {"id": 794370688, "item_id": 49648168, "url": "https://news.ycombinator.com/item?id=49648168", "by": "nirvdrum", "date": "2026-09-10", "version": null, "stance": "recommend", "quote": "GraalVM's Native Image [1] already let's do AOT compilation suitable for distribution", "excerpt": "If you haven't checked it out yet, GraalVM's Native Image [1] already let's do AOT compilation suitable for distribution. You have to do some configuration to deal with reflection and dynamic class loading since there's no JVM in the produced build, but it comes with tooling to simplify that. And that restriction is being addressed by Project Crema [2]. [1] -- https://www.graalvm.org/latest/reference-manual/native-im", "context": "", "use_case": "", "switched_from": "", "story": "JEP 544: Ahead-of-Time Code Compilation"}, {"id": 773189312, "item_id": 48324332, "url": "https://news.ycombinator.com/item?id=48324332", "by": "bhelx", "date": "2026-05-29", "version": null, "stance": "recommend", "quote": "Agree about Graal being really good.", "excerpt": "Agree about Graal being really good. there are some different use cases for embedding wasm in an application. chicory / endive is not just for embedding another language. the main use case was always secure plugin-systems. but there are other use cases. also it's not controlled by Oracle and works well outside of their ecosystem, which i think some people value. this question came up a few times and were addressed in", "context": "", "use_case": "polyglot embedding on JVM", "switched_from": "", "story": "Endive: A JVM native WebAssembly runtime"}, {"id": 773004752, "item_id": 48312797, "url": "https://news.ycombinator.com/item?id=48312797", "by": "gavinray", "date": "2026-05-28", "version": null, "stance": "neutral", "quote": "See also: https://www.graalvm.org/webassembly/docs/", "excerpt": "See also: https://www.graalvm.org/webassembly/docs/", "context": "", "use_case": "", "switched_from": "", "story": "Endive: A JVM native WebAssembly runtime"}, {"id": 772961666, "item_id": 48310104, "url": "https://news.ycombinator.com/item?id=48310104", "by": "chromanoid", "date": "2026-05-28", "version": null, "stance": "recommend", "quote": "complex CLI tools running locally/native via graalvm", "excerpt": "MCPs and complex CLI tools running locally/native via graalvm might be a great usecase for Java. https://quarkus.io/blog/mcp-server/", "context": "", "use_case": "Native-image compilation", "switched_from": "", "story": "Ruby vs. Java vs. TypeScript: my experience on building a Cowork DOCX plugin"}, {"id": 772928528, "item_id": 48308033, "url": "https://news.ycombinator.com/item?id=48308033", "by": "flossly", "date": "2026-05-28", "version": null, "stance": "recommend", "quote": "I'm currently using GraalVM compile to native for a Kotlin CLI tool.", "excerpt": "Nice to see Ruby vs Java. Must say that in this context Kotlin deserves a mention: my Kotlin code basically looks+feels like Ruby-with-types. Both Ruby and Kotlin are essentially OO, but with \"lots of FP features where it makes sense\". On the side of the jpackage: I'm currently using GraalVM compile to native for a Kotlin CLI tool. I do the build in a build container so I use an older glib to ensure compatibility on ", "context": "", "use_case": "native compile of Kotlin CLI", "switched_from": "", "story": "Ruby vs. Java vs. TypeScript: my experience on building a Cowork DOCX plugin"}, {"id": 771277840, "item_id": 48204865, "url": "https://news.ycombinator.com/item?id=48204865", "by": "elch", "date": "2026-05-20", "version": null, "stance": "recommend", "quote": "If you don't like JIT/JVM there's GraalVM Native Image.", "excerpt": "If you don't like JIT/JVM there's GraalVM Native Image. https://www.graalvm.org/latest/reference-manual/native-image/ In the past you could use e.g. Excelsior JET.", "context": "", "use_case": "Ahead-of-time Java compilation", "switched_from": "", "story": "Everything in C is undefined behavior"}, {"id": 770699984, "item_id": 48168749, "url": "https://news.ycombinator.com/item?id=48168749", "by": "flossly", "date": "2026-05-17", "version": null, "stance": "neutral", "quote": "I use GraalVM and Native Image now", "excerpt": "I use GraalVM and Native Image now and while the project --a small CLI tool-- is tiny (2kLOC with mainly AWS-SDK deps) the compile times are huge (~3 minutes), the OS-dependencies many (so much I use a build container to ease the burden of installing all) and the resulting binary is huge (~60MB). But then it distributes as one binary and starts in milliseconds. Rust would have been a better fit (cargo-and-done, small", "context": "", "use_case": "Java native binary builds", "switched_from": "", "story": "Zerostack \u2013 A Unix-inspired coding agent written in pure Rust"}, {"id": 765045410, "item_id": 47815338, "url": "https://news.ycombinator.com/item?id=47815338", "by": "shevy-java", "date": "2026-04-18", "version": null, "stance": "neutral", "quote": "generating a binary via GraalVM", "excerpt": "> This reminds me of what zed Shaw said, for some reason code written without an ide is better and he's not sure why. I am not sure whether the statement is correct; I am not sure whether the statement is incorrect either. But I tested many editors and IDEs over the years. IDEs can be useful, but they also hide abstractions. I noticed this with IntelliJ IDEA in particular; before I used it I was using my old, simple ", "context": "", "use_case": "", "switched_from": "", "story": "I'm Coding by Hand"}, {"id": 763834594, "item_id": 47739662, "url": "https://news.ycombinator.com/item?id=47739662", "by": "TacticalCoder", "date": "2026-04-12", "version": null, "stance": "compare", "quote": "GraalVM is even faster but much more complicated/annoying to get right.", "excerpt": "> 1843 options is too many. You could never even consider all of the possible combinations and interactions, let alone test them. You can search for those that may concern you. Good old search or AI \"search\". For example I recently did test the AOT compilation of Clojure (on top of the JVM) code using \"Leyden\". I used an abandoned Github project as a base but all the JVM parameters related to Leyden had changed names", "context": "", "use_case": "fast JVM startup", "switched_from": "", "story": "JVM Options Explorer"}, {"id": 763145520, "item_id": 47696595, "url": "https://news.ycombinator.com/item?id=47696595", "by": "SureshG", "date": "2026-04-08", "version": null, "stance": "recommend", "quote": "New GraalVM project Crema now supports runtime class-loading.", "excerpt": "New GraalVM project Crema now supports runtime class-loading. Here's a full Clojure runtime built with GraalVM native-image + Crema: https://github.com/borkdude/cream", "context": "", "use_case": "", "switched_from": "", "story": "GraalVM and Java and Native Images, compile Java to standalone executables"}, {"id": 761590113, "item_id": 47599382, "url": "https://news.ycombinator.com/item?id=47599382", "by": "shevy-java", "date": "2026-04-01", "version": null, "stance": "neutral", "quote": "GraalVM is pretty cool though - I don't quite feel it is 100% \"ready yet\"", "excerpt": "For me jruby is a lot more accessible, so I have been using jruby rather than TruffleRuby. GraalVM is pretty cool though - I don't quite feel it is 100% \"ready yet\", even if you can go very far with it (statically compiled binaries on linux worked well for me). Some things have a low priority such as swing-support; some got it to work, others did not. I understand that swing is legacy, but still it works out of the b", "context": "", "use_case": "static binaries", "switched_from": "", "story": "TruffleRuby"}, {"id": 761579056, "item_id": 47598691, "url": "https://news.ycombinator.com/item?id=47598691", "by": "pjmlp", "date": "2026-04-01", "version": null, "stance": "compare", "quote": "The Graal folks have their own agenda servicing Oracle DB, Oracle serverless, and less trying to replace the OpenJDK.", "excerpt": "GraalVM builds upon the research done previously at Sun with MaximeVM [0] and SquawVM [1] (SunSPOTs [2] before arduinos were even an idea). The Graal folks have their own agenda servicing Oracle DB, Oracle serverless, and less trying to replace the OpenJDK. See this interview with Thomas Wuerthinger, the founder and project lead of GraalVM. https://www.youtube.com/watch?v=naO1Up63I7Q Apparently there tends to exist s", "context": "", "use_case": "", "switched_from": "", "story": "TruffleRuby"}, {"id": 759324192, "item_id": 47457762, "url": "https://news.ycombinator.com/item?id=47457762", "by": "brabel", "date": "2026-03-20", "version": null, "stance": "warn", "quote": "", "excerpt": "I used to be really excited about GraalVM but this, together with limitations in what Java code can run (reflection must be whitelisted - i.e. pain) made me run away from it. I do use Go, but my favourite substitute for Java is actually Dart. It can run as a script, compile to a binary or to a multiplatform \"fast\" format (a bit like a jar), and performance wise it's par on par with Java! It's faster on some things, a", "context": "", "use_case": "", "switched_from": "", "story": "Java Is Fast. Your Code Might Not Be"}, {"id": 758639168, "item_id": 47414948, "url": "https://news.ycombinator.com/item?id=47414948", "by": "mike_hearn", "date": "2026-03-17", "version": null, "stance": "recommend", "quote": "Java also has a JIT compiling JS engine that can be sandboxed and given a VFS", "excerpt": "Most obviously, Java has JDBC. I think .NET has an equivalent. Drivers are needed but they're often first party, coming directly from the DB vendor itself. Java also has a JIT compiling JS engine that can be sandboxed and given a VFS: https://www.graalvm.org/latest/security-guide/sandboxing/ N.B. there's a NodeJS compatible mode, but you can't use VFS+sandboxing and NodeJS compatibility together because the NodeJS mo", "context": "", "use_case": "sandboxed JS engine", "switched_from": "", "story": "Why Node.js needs a virtual file system"}, {"id": 753915889, "item_id": 47119743, "url": "https://news.ycombinator.com/item?id=47119743", "by": "Borkdude", "date": "2026-02-23", "version": null, "stance": "neutral", "quote": "run the Clojure compiler in a GraalVM native-image with Crema enabled", "excerpt": "Author here. This is an experiment to run the Clojure compiler in a GraalVM native-image with Crema enabled. Crema is a new way to dynamically load JVM bytecode in a native-image using an interpreter. More info about Crema: https://github.com/oracle/graal/issues/11327 I'm also the author of babashka, a native fast-starting scripting tool for Clojure. For me it's interesting to contrast both approaches and learn more ", "context": "", "use_case": "", "switched_from": "", "story": "Fast starting Clojure runtime built with GraalVM native-image and Crema"}, {"id": 753025364, "item_id": 47064085, "url": "https://news.ycombinator.com/item?id=47064085", "by": "mkj6", "date": "2026-02-18", "version": null, "stance": "recommend", "quote": "Built on proven foundations: Java (RESTHeart), MongoDB, GraalVM", "excerpt": "We built Facet to solve a real problem we've seen repeated across teams: the separation between backend and frontend developers creates friction that shouldn't exist. The idea is simple: the same REST endpoint serves JSON to APIs and HTML to browsers (via HTTP content negotiation). A web developer can now: - Build complete admin panels, dashboards, and internal tools without writing backend code - Access data directl", "context": "", "use_case": "", "switched_from": "", "story": null}, {"id": 751914336, "item_id": 46994646, "url": "https://news.ycombinator.com/item?id=46994646", "by": "splix", "date": "2026-02-12", "version": null, "stance": "neutral", "quote": "I'm using GraalVM that executes JS on the server", "excerpt": "Nice project, thank you for working on it. I was trying to figure out the architecture, and I understand that it runs a Deno VM to execute JS on the backend? I was working on something similar, but for JVM backends [1]. And it seems there are a lot to learn from your project. For example, I'm using GraalVM that executes JS on the server. But I have to compile JS to WebAssembly because otherwise it produces a lot inte", "context": "", "use_case": "Running JS on JVM backend", "switched_from": "", "story": "Show HN: rari, the rust-powered react framework"}, {"id": 748070784, "item_id": 46754424, "url": "https://news.ycombinator.com/item?id=46754424", "by": "mike_hearn", "date": "2026-01-25", "version": null, "stance": "recommend", "quote": "Native Image can make macOS binaries just fine.", "excerpt": "Sure. The hard part of iOS is the JIT ban, Native Image can make macOS binaries just fine. > The Android ecosystem became Kotlin ecosystem because Google said so, not because it was successful This is not how I remember events unfolding. I used Kotlin before Google ever talked about it and it was doing fine as a language for desktop and backend JVM apps. When Google started officially supporting it, it was just recog", "context": "", "use_case": "", "switched_from": "", "story": "Kotlin's Rich Errors: Native, Typed Errors Without Exceptions"}, {"id": 743845840, "item_id": 46490365, "url": "https://news.ycombinator.com/item?id=46490365", "by": "mike_hearn", "date": "2026-01-04", "version": null, "stance": "recommend", "quote": "It has all the sandboxing features you might want.", "excerpt": "Licensing has changed since that release. You can use the EE for free, both for personal and commercial use cases: https://www.graalvm.org/latest/introduction/#licensing-and-support > Oracle GraalVM is licensed under GraalVM Free Terms and Conditions (GFTC) including License for Early Adopter Versions. Subject to the conditions in the license, including the License for Early Adopter Versions, the GFTC is intended to ", "context": "", "use_case": "sandboxed code execution", "switched_from": "", "story": "JavaScript engines zoo \u2013 Compare every JavaScript engine"}, {"id": 743843571, "item_id": 46490223, "url": "https://news.ycombinator.com/item?id=46490223", "by": "simonw", "date": "2026-01-04", "version": null, "stance": "warn", "quote": "I looked at GraalVM but was put off by the licensing situation", "excerpt": "The challenge with V8 is finding a wrapper for it that doesn't come with a big warning NOT to use it as a sandbox for untrusted code - here's the workerd one https://github.com/cloudflare/workerd?tab=readme-ov-file#warning-workerd-is-not-a-hardened-sandbox and here's the PyMiniRacer section: https://bpcreech.com/PyMiniRacer/architecture/#security-goals I looked at GraalVM but was put off by the licensing situation: h", "context": "", "use_case": "", "switched_from": "", "story": "JavaScript engines zoo \u2013 Compare every JavaScript engine"}, {"id": 743363668, "item_id": 46460229, "url": "https://news.ycombinator.com/item?id=46460229", "by": "maxandersen", "date": "2026-01-01", "version": null, "stance": "neutral", "quote": "it simply doesn\u2019t work with Windows binaries generated by Graal", "excerpt": "You've largely ignored everything I\u2019ve said. Instead, you proposed workarounds \u2013 which is precisely what most people want to avoid. Who distributes applications as fat jars? What is this? 2004? You\u2019re supposed to distribute your application as executables. and still npm, python, and other ecosystems don't do that. they effectively ships what corresponds to jars with dependency metadata. I also did not say fat jars (e", "context": "", "use_case": "native image compilation", "switched_from": "", "story": "2026: The Year of Java in the Terminal"}, {"id": 743358851, "item_id": 46459928, "url": "https://news.ycombinator.com/item?id=46459928", "by": "pregnenolone", "date": "2026-01-01", "version": null, "stance": "warn", "quote": "", "excerpt": "You've largely ignored everything I\u2019ve said. Instead, you proposed workarounds \u2013 which is precisely what most people want to avoid. Who distributes applications as fat jars? What is this? 2004? You\u2019re supposed to distribute your application as executables. I\u2019ve brought up numerous complaint regarding jpackage and jlink, and none of them have been addressed by jbang. Furthermore, you accuse me of not having used Java ", "context": "", "use_case": "", "switched_from": "", "story": "2026: The Year of Java in the Terminal"}, {"id": 743271505, "item_id": 46454469, "url": "https://news.ycombinator.com/item?id=46454469", "by": "maxandersen", "date": "2026-01-01", "version": null, "stance": "neutral", "quote": "I used graalvm", "excerpt": "jar + vm into single binary feels like a solvable problem. I haven't really had the burning need for app+jvm since I used graalvm and made jbang and its now trivial to run app + shared jvm for me - but I can see the utility for it. Noted down the various pointers and existing attempt to explore in 2026 ! About build and publishing - this I feel is also solvable. Especially if we stop trying to solve it for all possib", "context": "", "use_case": "", "switched_from": "", "story": "2026: The Year of Java in the Terminal"}, {"id": 743159840, "item_id": 46447490, "url": "https://news.ycombinator.com/item?id=46447490", "by": "cb321", "date": "2025-12-31", "version": null, "stance": "warn", "quote": "it's still pretty slow compared to some other competition", "excerpt": "Haven't checked graalvm in a long time. So, I got graalvm-jdk-25.0.1+8.1 for x86_64. It's a lot faster than Julia, and maybe 43ms is not slow in \"human terms\", but it's still pretty slow compared to some other competition. This was for a helloworld.jar [1]. On my laptop (i7-1370P, p-cores) using tim[2]: $ tim \"awk '{}'</n\" 'tcc -run /tmp/true.c' 'perl</n' 'py2</n' 'py3</n' 'java -jar helloworld.jar>/n' 97.5 +- 1.5 \u03bcs", "context": "", "use_case": "Java startup benchmarking", "switched_from": "", "story": "2026: The Year of Java in the Terminal"}, {"id": 743147938, "item_id": 46446746, "url": "https://news.ycombinator.com/item?id=46446746", "by": "martylamb", "date": "2025-12-31", "version": null, "stance": "recommend", "quote": "GraalVM native-image have eliminated most of the old excuses", "excerpt": "I spent a long time caring about JVM startup time and CLI suitability (and wrote nailgun [0] over 20 years ago and jsap [1] shortly after specifically because of it), so it's pretty wild to see how far things have come. Modern JVM startup speed and GraalVM native-image have eliminated most of the old excuses. jlink+jpackage help a lot with distribution, and JBang takes it to another level. I've used JBang before but ", "context": "", "use_case": "Native image compilation", "switched_from": "", "story": "2026: The Year of Java in the Terminal"}, {"id": 743146512, "item_id": 46446657, "url": "https://news.ycombinator.com/item?id=46446657", "by": "mbreese", "date": "2025-12-31", "version": null, "stance": "warn", "quote": "so Graal has been difficult to get working", "excerpt": "I\u2019m about the same. I\u2019ve had one Java project going for over 10 years. It\u2019s a collection of utilities that I use for work everyday that has grown substantially over the years. It is a CLI program that runs in my Mac, Linux servers and Linux HPC clusters. It is built with a fat-JAR concatenated to a shell stub in front that makes it effectively a single-file install. I also wrote a complete library for defining CLI pr", "context": "", "use_case": "", "switched_from": "", "story": "2026: The Year of Java in the Terminal"}, {"id": 743142753, "item_id": 46446422, "url": "https://news.ycombinator.com/item?id=46446422", "by": "voidfunc", "date": "2025-12-31", "version": null, "stance": "recommend", "quote": "This will give you what you want", "excerpt": "You're asking about a fundamentally different thing. An app bundle (.app, .rpm, .deb, .msi/.exe etc.) are things jpackage can build for you and are a single shippable artifact for a user with a JRE included so they don't need to do that. It's designed to make it easy to ship Java applications around. If you want a fully statically linked binary you're diving into graalvm and native-image: https://www.graalvm.org/late", "context": "", "use_case": "", "switched_from": "", "story": "2026: The Year of Java in the Terminal"}, {"id": 743135825, "item_id": 46445989, "url": "https://news.ycombinator.com/item?id=46445989", "by": "gunnarmorling", "date": "2025-12-31", "version": null, "stance": "warn", "quote": "Build times with GraalVM are still not ideal", "excerpt": "As a practical example for a Java-based CLI tool in the wild, here's kcctl, a command line client for Kafka Connect: https://github.com/kcctl/kcctl/. It's a native binary (via GraalVM), starting up in a few ms, so that it actually be invoked during tab completions and do a round-trip to the Kafka Connect REST API without any noticeable delay whatsoever. Installation is via brew, so same experience as for all the othe", "context": "", "use_case": "", "switched_from": "", "story": "2026: The Year of Java in the Terminal"}, {"id": 742397984, "item_id": 46399874, "url": "https://news.ycombinator.com/item?id=46399874", "by": "pjmlp", "date": "2025-12-26", "version": null, "stance": "recommend", "quote": "GraalVM supports native libraries", "excerpt": "Depends on what is done, GraalVM supports native libraries. https://www.graalvm.org/latest/reference-manual/native-image/guides/build-native-shared-library/ Then again, many times OS IPC is a much better option.", "context": "", "use_case": "", "switched_from": "", "story": "Memory Safety"}, {"id": 741943888, "item_id": 46371493, "url": "https://news.ycombinator.com/item?id=46371493", "by": "santadays", "date": "2025-12-23", "version": null, "stance": "recommend", "quote": "GraalVM supports running javascript in a sandbox with a bunch of convenient options for running untrusted code.", "excerpt": "GraalVM supports running javascript in a sandbox with a bunch of convenient options for running untrusted code. https://www.graalvm.org/latest/security-guide/sandboxing/", "context": "", "use_case": "Sandboxed JavaScript execution", "switched_from": "", "story": "Fabrice Bellard Releases MicroQuickJS"}, {"id": 738962480, "item_id": 46185155, "url": "https://news.ycombinator.com/item?id=46185155", "by": "gavinray", "date": "2025-12-07", "version": null, "stance": "recommend", "quote": "One of the neatest things I've been able to do is compile a .dll library \"plugin\" for an application", "excerpt": "May as well throw the Native Image C API for FFM-like capabilities out there too https://www.graalvm.org/latest/reference-manual/native-image/native-code-interoperability/JNIInvocationAPI/ One of the neatest things I've been able to do is compile a .dll library \"plugin\" for an application which loads plug-ins by invoking a special exported symbol name like \"int plugin_main()\" using GraalVM and @CEntryPoint The entryp", "context": "", "use_case": "Native image compilation", "switched_from": "", "story": "Java Hello World, LLVM Edition"}, {"id": 736637394, "item_id": 46039837, "url": "https://news.ycombinator.com/item?id=46039837", "by": "gunnarmorling", "date": "2025-11-24", "version": null, "stance": "neutral", "quote": "via GraalVM native binaries", "excerpt": "Great to see more love for using Lucene on Lambda via GraalVM native binaries! Explored that same idea few years back for my personal blog [1]. It worked pretty well, but I moved eventually away from Lambda as I wanted to close down my personal AWS account. One thing I always meant to explore was embedding the (in my case small) Lucene index directly into the binary image using Lucene's RAMDirectory via Quarkus' byte", "context": "", "use_case": "", "switched_from": "", "story": "I put a real search engine into a Lambda, so you only pay when you search"}, {"id": 735849328, "item_id": 45990583, "url": "https://news.ycombinator.com/item?id=45990583", "by": "gunnarmorling", "date": "2025-11-20", "version": null, "stance": "neutral", "quote": "GraalVM native images certainly are being adopted", "excerpt": "> I never understood why AOT never took off for Java. GraalVM native images certainly are being adopted, the creation of native binaries via GraalVM is seamlessly integrated into stacks like Quarkus or Spring Boot. One small example would be kcctl, a CLI client for Kafka Connect (https://github.com/kcctl/kcctl/). I guess it boils down to the question of what constitutes \"taking off\" for you? But it's also not that na", "context": "", "use_case": "", "switched_from": "", "story": "Implementation of a Java Processor on a FPGA (2016)"}, {"id": 735847008, "item_id": 45990438, "url": "https://news.ycombinator.com/item?id=45990438", "by": "pjmlp", "date": "2025-11-20", "version": null, "stance": "recommend", "quote": "GraalVM and OpenJ9 are available for free", "excerpt": "Because developers don't like to pay for tools. https://en.wikipedia.org/wiki/Excelsior_JET https://www.ptc.com/en/products/developer-tools/perc https://www.aicas.com/products-services/jamaicavm/ It is now getting adopted because GraalVM and OpenJ9 are available for free. Also while not being proper Java, Android does AOT since version 5, mixed JIT/AOT since version 7. EDIT: Fixed the sentence regarding Android versi", "context": "", "use_case": "Java AOT compilation", "switched_from": "", "story": "Implementation of a Java Processor on a FPGA (2016)"}]}