FastR runs R on GraalVM and calls the C API the hard part

Four goals, and the compatibility one is the load bearing

The README states FastR's aims as four adjectives, each pointing at a linked explanation. It aims to be efficient, executing R scripts faster than any other R runtime and as fast as Rcpp. It aims to be polyglot, allowing interoperability with other languages in the GraalVM ecosystem. It aims to be compatible with the reference R implementation including the R extensions C API. And it aims to be embeddable, so R can be integrated through the R embedding API or the GraalVM polyglot embedding SDK for Java. The third and fourth of these are what actually distinguish it from GNU R. Anyone who could run R as a subprocess already has efficiency; what they do not have is R living inside a JVM with a Java-facing API.

The C API compatibility is what makes FastR different from a reimplementation

The current status section is unusually direct. The goal is to be a drop-in replacement for GNU R including the R extensions C API, and the documentation states that any difference in behaviour is considered a bug. That is a strong statement, and it is the reason FastR exists at all. Plenty of projects implement an R interpreter; very few implement the R extensions C API with enough fidelity that a package calling into C keeps working. The compatibility target also extends to CRAN packages, where FastR can install and run basic examples of packages including ggplot2, jsonlite, testthat, assertthat, dplyr, knitr, Shiny, Rcpp and quantmod. The distinction between running a basic example and running a real application is where the risk sits.

CRAN is pinned to a snapshot by default, and that has to be overridden deliberately

For stability FastR uses by default a fixed snapshot of CRAN via MRAN, and the consequence is stated plainly: the install.packages function therefore does not install the latest versions. This is overridable by passing a repos argument to install.packages pointing at CRAN. The default is a sensible engineering choice for reproducibility, and an equally sensible trap for someone who expects current package versions on a new machine. FastR also ships its own replacements for the rJava and data.table packages, which are installed with a call to install.fastr.packages, so those two arrive from the project rather than from CRAN. The Makefile in the native module pins the snapshot, which is why the default is difficult to change by accident.

Native extensions pay a transition tax that the LLVM backend can reduce

Here is the honest limitation, and the README does not soften it. Packages that use the R extensions C API in hot paths, especially through Rcpp, may exhibit slower performance on FastR because of the high cost of transitions between native and managed code. The suggested mitigation is the GraalVM LLVM runtime, with support available in preview through the --R.BackEnd=llvm option. The documentation then adds the nuance that matters: most of the time, FastR running R code equivalent to a given Rcpp program is as fast as GNU R with Rcpp, and sometimes faster, thanks to the optimisations of the Graal dynamic compiler. The slowdown is specific to native calls in hot paths, not to R code in general. A workload that spends its time in compiled extension code will feel the tax; one that spends it in interpreted R will not.

Starting FastR means going through GraalVM first

There is no separate installer. The Getting Started section points at the GraalVM website for both getting GraalVM and installing and using FastR, which means the runtime is the product and FastR is a component of it. Once GraalVM is in place, the R executable is invoked through the Java home.

$JAVA_HOME/bin/R
Type 'q()' to quit R.
> print("Hello R!")
[1] "Hello R!"
>

What you should see is a standard R console, the same prompt and the same print output, because drop-in replacement is the whole design goal rather than a marketing line. The reference documentation explaining the advantages, the current limitations, the compatibility situation and the additional functionality lives on the GraalVM website, and contributor and developer documentation sits in the documentation folder of the repository. The README does not document a standalone FastR installation path.

Embedding R in a Java application is the use case the project demonstrates

The README shows a screenshot of a Java application with an embedded FastR engine, and points to the GraalVM examples repository for an r_java_embedding project. The embedding path is either the R embedding API or the GraalVM polyglot embedding SDK for Java. The plot in the README is generated by ggplot2 running on FastR, and it is a raytracing example, with the measurements reproduced independently by a third party as the README notes. The interesting structural fact for an engineering team is that this is a polyglot runtime: R is not an isolated interpreter that has to be marshalled across a process boundary, it is a language inside the same GraalVM execution environment as the Java code around it. That is the difference from embedding R through a subprocess or a native library.

Oracle's stack, a custom licence question, and a 2022 vintage of releases

Maintenance and licensing deserve attention. The repository is developed by Oracle Labs, is based on the GNU R runtime, and contains contributions from researchers at Purdue University, Northeastern University, JKU Linz, TU Dortmund and TU Berlin. Contributors must sign the Oracle Contributor Agreement, and the project asks to grow a free R implementation on the Truffle and Graal stack. The licence is described in the README as GPLv3, with COPYING and LICENSE.txt at the top level and a separate file listing third party licences, so any dependency review has two files to read rather than one. The release history is where the risk sits. The most recent tagged releases are vm-22.3.1 from January 2023, vm-22.3.0 from October 2022 and vm-22.2.0 from July 2022, all named after GraalVM Community Edition versions. The last push was on 2026-07-30, so work continues, but the shipped artefacts are aligned to a 2022 era of the platform.

Editorial conclusion

Adopt FastR when you need R inside a JVM process, want one runtime for several languages, or want an embeddable R engine with a documented API, since the polyglot embedding is the reason it exists and GNU R cannot offer that. Do not adopt it if your workload is dominated by Rcpp in hot paths, because the native to managed transition cost is exactly where FastR is slowest, and treat any CRAN package you rely on as a compatibility question until you have tried it. Verify first that the package you need installs and runs, that you can point install.packages at CRAN rather than the pinned snapshot if you need current versions, and that the --R.BackEnd=llvm option is worth the preview risk for your workload.

Frequently asked questions

Official sources

1. Issues
2. oracle/fastr on GitHub
3. README
4. Releases