# godot-jvm puts Kotlin, Java, and Scala inside the Godot engine

> godot-jvm is a GDExtension that lets you write Godot game logic in Kotlin, Java, or Scala, with the addon dropped into the project root and code shipped as JARs or compiled with GraalVM native-image. Version 1.0.0 landed on 2026-10-16, so the API is meant to be stable but the project is young.

**utopia-rise/godot-jvm** — Godot JVM GDExtension. Support Kotlin, Java and Scala.

- Repository: https://github.com/utopia-rise/godot-jvm
- Website: https://godot-jvm.dev
- Stars: 983 · Forks: 62
- Language: Kotlin
- License: MIT
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/utopia-rise-godot-jvm

## Godot-JVM writes game logic in Kotlin, Java, or Scala

The project description calls itself a JVM binding for the Godot Game Engine, and the README states the scope plainly: Godot-JVM lets you write Godot game and application logic in Kotlin, Java, or Scala. That is the whole proposition. The engine stays Godot, with its scene tree, its editor, and its export pipeline, while the code that implements behaviour runs on a virtual machine. The audience is specific. A studio that has Java or Kotlin engineers but no GDScript experience gets a way to keep its existing skills and its existing build and deployment practices. A developer who wants to reuse a library already written for the JVM gets access to it from inside the engine. A team that wants to ship the same core logic in a game and in a server or mobile application gets that too. A small solo project with simple mechanics has no reason to leave the engine's built-in scripting language.

## The addon is a GDExtension dropped into the project root

The integration point is a Godot GDExtension, which is the engine's own mechanism for native extensions. The install instructions are concrete about the layout: after you extract the addon archive, the resulting layout must contain addons/jvm/jvm.gdextension. The presence of that single file is the check that the addon landed correctly, and it is the thing to look at first when an import fails to register. Because the extension is registered through the engine's standard extension mechanism, the same addon works in the editor and in exported builds, which is what the README means by using the JVM bindings with the official Godot editor and export templates. The repository layout matches this design. There is a cpp directory and a godot-cpp directory at the top level, a kt directory for the Kotlin side, a harness directory, and a specs directory, so the native bridge and the JVM layer are separate trees.

## Installing the addon and running your first script

The requirements are version floors rather than ranges: use Godot 4.7.2 or newer and JDK 17 or newer. The install step is to download the addon archive from the GitHub releases page and extract it into your project's root directory. After extraction, confirm the extension file is in place:

```
addons/jvm/jvm.gdextension
```

Then open the project with the release's minimum Godot version or newer, which in practice means Godot 4.7.2 for the 1.0 release. The README points you at the Start here guide for setting up a project and running your first script, and then to the guides for everyday development and the reference for detailed rules and settings. Two example projects are linked for orientation: a Godot-JVM project template, which is the shape of a working project, and a Godot-JVM 3D demo, which shows the extension used with a three dimensional scene rather than a minimal script.

## Two shipping options: JAR with an embedded JRE, or a native image

The Code Distribution section is where this project makes a decision most addons leave to you. The first option is to distribute desktop games as JARs with an embedded JRE, so players do not need to install Java. That is the friendly path for a desktop release, since the runtime travels with the artefact and the player sees a single executable with no prerequisites. The second option is to compile your JVM code into a native library with the GraalVM native-image workflow, documented on the project site. A native image trades startup time and memory behaviour for a self contained binary that does not look like a Java application at all. Which one to pick depends on your target: the repository topics list android, ios, linux, osx, and windows, and the native-image route is the more plausible answer for mobile and console style targets where shipping a JVM is awkward.

## Building from source means SCons, CMake, and the godot-cpp layer

The project is not a pure Kotlin repository and the tree shows the full toolchain. At the top level there are CMakeLists.txt, SConstruct, build_profile.json, a .gitmodules file with the godot-cpp submodule, a requirements.txt, and helper scripts generate_templates.py and generate_version.py. The Python build dependency is pinned tightly:

```
scons==4.1.0
```

The contribution documentation is split into a general guidelines page and a specific build from source page, and the README invites contributors to read both before starting. The presence of both SConstruct and CMakeLists.txt means the native side has two entry points, with SCons taking the pinned dependency in requirements.txt. The version and template generation scripts tell you that the build output is versioned and that export templates are produced as part of the process, which is consistent with the README telling users to use the release's export templates. If you are not building from source, all of this is background, but if you intend to contribute, the pinned SCons version is the first thing to match.

## Where godot-jvm is the wrong choice

The clearest cost is that a JVM runtime comes along for the ride. For a project whose logic is small, the JVM startup cost and memory footprint buy you nothing, and you now have a second language toolchain, a dependency on the JVM being present or bundled, and a build that fails in ways a GDScript script never would. There is also a version floor in both Godot and the JDK, and the addon format can change between Godot releases, so a project pinned to an older engine version is excluded outright. On mobile, the platform list in the topics includes android and ios, but the README credits the MOE community specifically for helping bring Godot-JVM to iOS, which suggests iOS support is the newest and least settled part. Finally, the API surface is one version old. The README states that 1.0.0 is production-ready and welcomes suggestions and feedback to keep improving the project and its API, which is a candid way of saying the API can still move.

## The alternative is a plain GDExtension, or the engine's own scripting

The comparison is with the two other routes to the same outcome. The first is to write a GDExtension directly against godot-cpp, which is what the cpp directory and the godot-cpp submodule in this repository are built on. That route gives you the same extension mechanism and the same editor integration, without a virtual machine, at the cost of writing in C++ and losing access to the JVM ecosystem. The second is to stay inside Godot's own scripting support, which avoids any extension entirely but confines you to the engine's language and runtime. godot-jvm sits between the two, and it is worth choosing it only when the JVM side of that trade is real for you, whether that is an existing codebase, existing libraries, existing build tooling, or a team that hires for one language.

## MIT licensed, freshly released, and backed by JetBrains tooling

The project is MIT licensed, with the LICENSE file at the top of the repository, so the addon and the runtime can be embedded in a commercial game without licence fees or copyleft obligations beyond keeping the notice. The support story is more interesting than usual for a binding project. JetBrains supports the project by providing development tools to maintainers, and IntelliJ IDEA is named as the supported IDE for Godot-JVM development, which means the editor experience for Kotlin and Java in this ecosystem is a first class IDE rather than a text editor with a classpath. The release history is very recent and dense: 1.0.0 on 2026-10-16, 1.0.0-rc4 on 2026-10-15, and 1.0.0-rc3 on 2026-10-13, with the last push to the repository on 2026-10-18. A project shipping three tags in five days before its 1.0 has clearly been iterating hard, and it also means the API you bind against today may differ from what you read about last month.

## Conclusion

Adopt godot-jvm if your team already ships JVM code, if you want the Android and iOS tooling that comes with it, or if you need to share business logic between a game and a backend written in Kotlin. Do not adopt it for a small Godot project whose logic is a few hundred lines, because the JVM brings a runtime and a build step for no benefit, and do not adopt it if your Godot version is below 4.7.2. Before you start, confirm the addon layout contains addons/jvm/jvm.gdextension after extraction, check that your JDK is 17 or newer, and read the export guide to decide between shipping a JAR with an embedded JRE and building a native image with GraalVM.

## FAQ

### What languages does godot-jvm support?

The README states that Godot-JVM lets you write Godot game and application logic in Kotlin, Java, or Scala. It is installed as a GDExtension addon in the project.

### What do I need to install to use godot-jvm?

Use Godot 4.7.2 or newer and JDK 17 or newer. Download the addon archive from the GitHub releases page, extract it into your project root, and check that addons/jvm/jvm.gdextension exists in the result.

### How do I distribute a JVM game without asking players to install Java?

The README describes distributing desktop games as JARs with an embedded JRE, so players do not need to install Java. The alternative is compiling your JVM code into a native library with the GraalVM native-image workflow.

### Which IDE does godot-jvm support?

IntelliJ IDEA is named as the supported IDE for Godot-JVM development, with JetBrains providing development tools to the maintainers of the project.

## Sources

- [License: MIT](https://github.com/utopia-rise/godot-jvm/blob/master/LICENSE)
- [Project website](https://godot-jvm.dev)
- [README](https://github.com/utopia-rise/godot-jvm/blob/master/README.md)
- [Releases](https://github.com/utopia-rise/godot-jvm/releases)
- [utopia-rise/godot-jvm on GitHub](https://github.com/utopia-rise/godot-jvm)

---

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