# Javet embeds Node.js and V8 inside the JVM

> Javet is a Java library that puts a JavaScript engine inside your JVM, and the interesting part is that it offers two of them. In Node.js mode you get the whole runtime with its module system, in V8 mode you get the bare engine with none of that, and a program can switch between the two at runtime. The price is a native artifact per platform, and the payoff is that Java code and JavaScript code can call each other directly.

**caoccao/Javet** — Javet is Java + V8 (JAVa + V + EighT). It is an awesome way of embedding Node.js and V8 in Java.

- Repository: https://github.com/caoccao/Javet
- Website: https://www.caoccao.com/Javet/
- Stars: 967 · Forks: 102
- Language: Java
- License: Apache-2.0
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/caoccao-javet

## Two engines, and the choice between them is a flag

The name is the pitch, Javet is Java plus V8, spelled JAVa plus V plus EighT, and the description is that it is an awesome way of embedding Node.js and V8 in Java. The first feature in the list is the one that shapes everything else, the dynamic switch between Node.js mode and V8 mode. Node.js mode gives you the complete runtime, the module system and the ecosystem, and V8 mode gives you the engine on its own with none of that, so a program that needs a CommonJS module in one place and a bare isolate in another does not need two libraries. The two modes are not equally complete on purpose, and the list also has i18n and non-i18n builds, which is the difference between a V8 configured for internationalised strings and one that is not. The current pairing in the README is Node.js v26.10.0 with V8 v15.5.35.14, which tells you how closely the two are tracked.

## The support matrix is a table you can read in ten seconds

There is a matrix in the README that answers the question every adopter asks first, which platforms work. For x86_64 the answer is yes everywhere, Android, Linux, macOS and Windows. For arm64 it is yes on Android, Linux and macOS, and explicitly no on Windows. For plain x86 and for arm it is Android only. That last pair is the one to notice, because x86 and 32 bit arm are still common in embedded and Android device work but nowhere else, so the library is essentially a 64 bit library. The build matrix in the repository mirrors the support matrix exactly, with separate workflows for Linux x86_64, macOS x86_64, macOS arm64, Windows x86_64, and two for Android, one for the Node build and one for the V8 build. That the two Android workflows are separate tells you the mobile packaging is a first class case rather than an afterthought.

## One core dependency and one native artifact

The dependency layout is unusual and worth understanding before you write any build file, because there is more than one artifact in play. The core is `com.caoccao.javet:javet`, described as must-have, and then every platform and mode has its own artifact, such as `javet-node-linux-x86_64` and `javet-v8-macos-arm64`, with the version matching the core. In Maven that is a dependency block for the core and a dependency block for each native artifact you need, and in Gradle the same set is expressed in either the Kotlin or the Groovy DSL:

```kotlin
implementation("com.caoccao.javet:javet:6.0.2") // Core (Must-have)
implementation("com.caoccao.javet:javet-node-linux-arm64:6.0.2")
```

The upshot is that your build file has to name the operating system and the architecture, which is a step that trips people up when a build server is not the machine they develop on. The native code lives in the `cpp/` directory in the repository, with Java sources in `src/`, and the artifacts are published to Maven Central under the `com.caoccao.javet` group.

## Interop, an engine pool and a debugger attached

The feature list is a good catalogue of what an embedded engine has to offer. There is JavaScript and Java interop, which is the reason to embed an engine at all, and V8 API exposure in the JVM for the cases where the Java wrapper is not enough. There is native BigInt and Date handling, which is a detail that matters because a JavaScript value crossing into Java has to arrive as something the JVM can hold. There is a Javet engine pool, so a server can reuse an isolate instead of paying to start one per request, which is the difference between a scripting feature that works in a demo and one that works under load. And there is live debugging with Chrome DevTools, which is a genuinely useful piece of tooling, since a script running inside a JVM is otherwise a black box when it goes wrong. Easy Spring integration is listed as well, which tells you what the intended Java audience is.

## The companion projects carry a lot of the capability

Several of the headline features are delivered by separate projects by the same author, and a reader should know which parts are in the box and which are one dependency away. V8 mode can be polyfilled with Javenode, which fills in the Node.js API surface that V8 mode does not provide. AST analysis and the transformation and transpilation of JavaScript, TypeScript, JSX and TSX are handled by swc4j, so a Java application can accept modern source and have it compiled before it reaches the engine. The JVM itself can be extended with JavetBuddy, which does the work at the bytecode level, and JavetShell gives live interaction with a running engine, a REPL for a process that otherwise has no console. So the boundary of the project is the embedding itself, the interop, the pool and the toolchain, and the rest is a small ecosystem of satellites that you choose to adopt.

## One maintainer, and a support channel that says so

The project is maintained by a single author, and the README is candid about the situation in a way that is worth reading. The support channel is a Discord server, the author asks for stars and follows on the social network, and there is an OpenCollective donation page. There is also a line that explains why the donations matter, that the author is no longer able to renew the JetBrains open-source licence with this project, which tells you that a commercial licence for the IDE was part of the cost of running the build. The licence of the code itself is Apache-2.0. On releases the project is quick, with 6.0.0 on 2026-09-08, 6.0.1 on 2026-09-20 and 6.0.2 on 2026-10-04, and the last push to the repository was on 2026-10-04, so the code and the releases are in step. The repository also carries a `CLAUDE.md` and a `.serena/` directory, which is the current sign of a project that has made room for tooling in its workflow.

## Conclusion

Javet suits a Java team that needs a scriptable runtime inside its own process, whether that is for a configuration language, a plugin system or a rules engine, and it suits a team that has to choose between the full Node.js runtime and the bare V8 engine, since that choice is a runtime flag rather than a redesign. It is a poor fit if you need a single dependency with no native code, since the platform artifacts are unavoidable, and it is a poor fit if you are on Windows on arm64, which the support matrix marks as unsupported. Before you adopt it, check three things: which platform artifact you need, since the matrix covers x86_64 everywhere plus arm64 on Android, Linux and macOS but not Windows, which mode you want, Node.js or V8, and which version you pin, with 6.0.2 published on 2026-10-04 and a 6.0.0 major line that arrived on 2026-09-08.

## FAQ

### What is the difference between Javet's Node.js mode and V8 mode?

Node.js mode gives you the full runtime with its module system, and V8 mode gives you the bare engine without it. The README lists a dynamic switch between the two as a major feature, and V8 mode can be polyfilled with the Javenode project if you need some of the Node.js surface.

### Which platforms does Javet support?

The README has a matrix: x86_64 works on Android, Linux, macOS and Windows, arm64 works on Android, Linux and macOS but not Windows, and x86 and arm are Android only. The build workflows in the repository mirror that matrix, with separate Linux, macOS, Windows and two Android builds.

### What do I need to add to my build file?

The core artifact `com.caoccao.javet:javet`, which is marked as must-have, plus one native artifact for your platform and mode, for example `com.caoccao.javet:javet-node-linux-arm64`. In Gradle the same set is expressed as implementation lines in either the Kotlin or the Groovy DSL.

### Can I debug JavaScript running inside the JVM?

Yes, live debugging with Chrome DevTools is one of the listed major features, and there is also an engine pool for reusing isolates under load. For a REPL against a running engine, the JavetShell project provides live interaction.

### Who maintains Javet and under what licence?

It is maintained by a single author with a Discord server as the official support channel and an OpenCollective donation page, and the README notes that the author can no longer renew the JetBrains open-source licence with the project. The code itself is under the Apache-2.0 licence, with 6.0.2 published on 2026-10-04.

## Sources

- [caoccao/Javet on GitHub](https://github.com/caoccao/Javet)
- [License: Apache-2.0](https://github.com/caoccao/Javet/blob/main/LICENSE)
- [Project website](https://www.caoccao.com/Javet/)
- [README](https://github.com/caoccao/Javet/blob/main/README.md)
- [Releases](https://github.com/caoccao/Javet/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/caoccao-javet