GraalVM in this repository: a distribution factory whose release tags stopped in 2020

The release tags stop in January 2020 while the branch keeps moving

The most recent GitHub releases on this repository stop in January 2020. vm-19.3.1 was published on 2020-01-23 and its title is not a version announcement at all, it reads Releases have moved. Before it, vm-19.3.0, titled GraalVM Community Edition 19.3.0, landed on 2019-11-20, and vm-19.2.1 landed on 2019-10-15. The default branch meanwhile was last pushed on 2026-11-01, so the source is current while the tag history is not. What this repository cannot do is tell you which build you should run: nothing here ranks a distribution, names a release channel, or maps a commit to a downloadable binary. The route out is the website, which is where the README sends you to get started and where the download and documentation links point.

vm/ is a factory for distributions, not a distribution you can run

The table of directories describes vm/ as the components for building GraalVM distributions, and the README routes instructions for building GraalVM from source to vm/README.md. That makes this repository the factory rather than the artifact. The opening claim, ahead-of-time compilation into standalone binaries that start instantly and provide peak performance with no warmup, describes the result of producing a distribution, not something you obtain by cloning this tree. You are also told you can use GraalVM like any other Java Development Kit in your IDE, which only holds once a distribution exists. Documentation lives in docs/, with component specific developer instructions in each component's own docs subdirectory, and the Truffle framework documentation sits in truffle/docs/. Sequence matters here: read vm/README.md first.

Three directories exist to prop up one bytecode interpreter

The component table spends three rows on a single feature. espresso/ is Espresso, a meta-circular Java bytecode interpreter for GraalVM. espresso-shared/ holds Espresso shared code for runtime class loading. espresso-compiler-stub/ is described without ceremony as a dummy GraalJVMCICompiler implementation for Espresso. A directory count therefore overstates the surface you are dealing with, since one third of the Espresso footprint is scaffolding its own description calls a dummy. If you are sizing what you must understand or must build, count espresso/ and treat the other two as its dependencies. The same surprise applies to the foreign-language engines: wasm/ is GraalWasm for running WebAssembly programs, sulong/ runs LLVM bitcode, and regex/ is TRegex, a regular expression engine for other GraalVM languages. Alongside them sit truffle/, the language implementation framework, tools/, built on the instrumentation framework, and sdk/, the long-term supported APIs.

The repository itself calls web-image/ experimental

One component carries a stability adjective in the table: web-image/ is an experimental WebAssembly backend for Native Image. Nothing else in the seventeen rows is qualified that way, so the word is doing real work rather than adding polish. It is also one of only three components licensed as plain GPL 2, beside visualizer/ and espresso/. The backend attaches to Native Image, and Native Image has no directory of its own here. It arrives through substratevm/, described as the framework for ahead-of-time compilation with Native Image, and the build tool plugins for that path live in a separate repository under the name Native Build Tools. Read the qualifier literally and keep it out of anything carrying an availability expectation.

Five license regimes sit underneath one top-level LICENSE

GraalVM Community Edition is distributed under version 2 of the GNU General Public License with the Classpath Exception, described as the same terms as for Java. The component table underneath splits into four license rows, three of which differ from it. Espresso, the Ideal Graph Visualizer and Web Image are GPL 2. The GraalVM Compiler, SubstrateVM, Tools and VM are GPL 2 with the Classpath Exception. The GraalVM SDK, GraalWasm, the Truffle Framework and TRegex carry the Universal Permissive License. Sulong alone is 3-clause BSD. The top-level LICENSE covers the Community Edition, and THIRD_PARTY_LICENSE.txt sits beside it for dependencies, and each component in the table links its own license file, such as sulong/LICENSE. The machine-readable license field for this repository is unset, so anything reading metadata sees no license at all and a reader consulting only the top-level file misses the BSD and permissive rows entirely.

The root formatter config ends by switching itself off

Python formatting at the root is configured carefully and then disabled. The whole pyproject.toml is three settings for one tool, and the last of them, force-exclude set to a pattern matching everything, means a formatter run at the root changes nothing.

[tool.black]
line-length = 120
# Require black version 23 for formatting.
# Black's code style can change for major versions (beginning of the calendar
# year), to ensure a consistent code-style, the version is fixed to a major
# version.
required-version = '23'
# Disables the black formatter in this repository
# If individual suites want to enable the formatter, they can create a
# pyproject.toml with their own configuration in their suite folder
force-exclude = '.*'

The version pin carries a stated reason, since Black's code style can shift at the start of a calendar year, and line-length is 120. The consequence for you is that style is not uniform across the tree and you cannot predict a diff's formatting from the root, because whether Python here is formatted at all depends on a config file you have to go find in the suite folder.

Not one runnable sample ships in this tree

Seven projects are named as related repositories. GraalJS covers JavaScript and Node.js, GraalPy covers Python, graalvm-reachability-metadata holds reachability metadata for open-source libraries, Native Build Tools supplies build tool plugins for GraalVM Native Image, setup-graalvm is a GitHub Action, and SimpleLanguage and SimpleTool are Truffle examples. Three more are named for examples and tutorials: GraalVM Demos, GraalVM Workshops and Tutorials, and guides covering GraalJS, GraalPy and GraalWasm. Those samples live in separate repositories. For ahead-of-time compilation the metadata matters most, because a library's reachability information comes from that separate repository, and a library missing from it is a gap nothing here will report to you. Support follows the same split: reproducible bugs go to a GitHub issue, questions and design discussion go to GitHub Discussions or Slack.

Branch behaviour is generated from Jsonnet, not written in a script

The root carries ci.jsonnet, ci-branch-config.jsonnet, common.json and graal-common.json, next to the ci/ and ci_includes/ directories the table describes as internal CI/CD configuration and its configuration includes. What runs on a given branch is therefore a function of Jsonnet inputs rather than a script you can read straight through to predict the outcome. The default branch is master, while the build badge at the top of the README points at an Actions workflow named main.yml, so do not reconstruct branch identity or pipeline state from that badge. Contributors get build instructions from vm/README.md and local checks from a pre-commit configuration, with AGENTS.md, CODING_ASSISTANTS.md and CENSUS.md also at the root. Alongside them sit scripts/, sandbox-toolchains/ and SECURITY.md; the README says vulnerabilities are reported according to its Reporting Vulnerabilities guide rather than in public issues.

Editorial conclusion

GraalVM fits you if you want ahead-of-time compilation into standalone binaries and are willing to read vm/README.md plus at least three other repositories to get there. It fits you badly if you expected this tree to hand you a version number or a runnable example. Before you plan anything, settle the distribution channel outside this repository, check the license row for the exact component you plan to vendor, and confirm that reachability metadata exists for the third-party libraries you depend on.

Frequently asked questions

Official sources

1. Issues
2. oracle/graal on GitHub
3. Project website
4. README
5. Releases