imgui-java: a JNI binding for Dear ImGui

Dear ImGui from the JVM

imgui-java is described as a JNI based binding for Dear ImGui, and the features list explains what the project is trying to be.

The JNI code is generated, and the project states that the generated code carries no third-party runtime dependencies. The footprint is small, with direct native calls rather than a layered abstraction. And the coverage is complete across the public Dear ImGui API, adapted for idiomatic Java usage.

That last point is where the real work is, and it is worth being clear about what a binding is not. It is not a port. Dear ImGui itself is a C++ library that draws widgets through an immediate mode API where you describe the interface in code each frame. The binding exposes that API as Java methods, and the interesting part is the adaptation: how the Java side expresses callbacks, how it handles the variant types the C++ API uses, how strings and textures cross the boundary.

The upstream version matters for that reason. The README says the project tracks Dear ImGui version 1.92.7 on the docking branch, and the docking branch is what enables the multi-viewport and docking features that the binding also supports.

The repository is MIT licensed, and the current release is v1.92.7.1, published on 2026-07-27.

Three artifacts, three levels of control

The repo ships three Maven artifacts, and the split is the clearest statement of the design.

The application module is the batteries included option. It is a high-level wrapper with GLFW, OpenGL and the native libraries bundled, and you subclass Application and override the process method. The README makes the recommendation explicit: the application module is the best choice if everything you care about is the GUI itself.

The binding module is the binding itself, with no backend included. Using it without the application module means you attach it to your application manually, and the README points at the application module as the reference for how that is done.

The LWJGL 3 module is a ready-made GLFW and OpenGL backend built on LWJGL, for use with the binding. It exists so you do not have to write the plumbing yourself.

The README is explicit that backends are optional, because Dear ImGui is renderer agnostic. You can copy the LWJGL module as a starting point and adapt it to your own stack. That is the honest framing: the three artifacts are a convenience ladder, and the project expects that some users will write their own backend eventually.

The choice comes down to one question. If you want a window and a render loop, take the application module. If you already have a render loop and want ImGui inside it, take the binding and wire the backend yourself, or use the LWJGL one.

Building the example and trying the SDL path

The build needs a recent JDK and a recursive clone, because the upstream sources are pulled in as submodules.

git clone --recurse-submodules https://github.com/SpaiR/imgui-java.git
cd imgui-java
./gradlew :example:run
# SDL3 + SDL_GPU backend smoke test:
./gradlew :example:run -PmainClass=MainSdl

The version requirements are spelled out and they are asymmetric in a useful way. JDK 17 or later is required to run the build, because the Gradle toolchain pins it. The published artifacts target Java 8 bytecode, so consuming them as a dependency only needs JDK 8 or later at runtime.

That gap between build and runtime requirements is common in native binding projects, where the build needs a modern toolchain but the shipped library stays compatible with older runtimes.

The example module is described as a runnable showcase for every widget and extension, with the instruction to start at Main.java and then explore the per-extension example files. The SDL smoke test is run by passing a different main class to the Gradle task, which is a neat way to have two entry points in one example project.

Apple Silicon needs nothing extra, because the published macOS native is a universal binary covering both x86_64 and aarch64.

The application layer in one subclass

The application module is the part most people will use, and the example in the README is short enough to memorise.

import imgui.ImGui;
import imgui.app.Application;
import imgui.app.Configuration;

public class Main extends Application {
    @Override
    protected void configure(Configuration config) {
        config.setTitle("Dear ImGui is Awesome!");
    }

    @Override
    public void process() {
        ImGui.text("Hello, World!");
    }

    public static void main(String[] args) {
        launch(new Main());
    }
}

Three things are happening there. The application is launched with a static launch call taking your instance, the configure method sets up window properties through a Configuration object, and the process method is called every frame, where you describe the interface by calling ImGui methods.

That last method is the whole mental model of immediate mode GUI in one signature. There is no widget tree to build, no layout to declare and no component to instantiate. The process method is a loop body that returns.

The application module is described as a one jar solution including GLFW, OpenGL and Dear ImGui itself, so you need one dependency line or one jar on the classpath, and the README adds that you do not need separate dependencies for LWJGL or the native libraries. At the same time, it says you can override any life cycle method it has, so the low-level control is available when you want it, which is the right balance for a wrapper.

SDL3, multi-viewports and the bundled extensions

The application module supports two backends through the setBackend call on the configuration object: Backend.GLFW, which is the default, and Backend.SDL, which is SDL3 with SDL_GPU.

Switching is a one line override in the configure method.

protected void configure(final Configuration config) {
    config.setBackend(Backend.SDL);
}

There is a stated limitation right after that, and it is the kind you want to know before designing around the backend. At the moment, the SDL backend in the application module is focused on a single-window flow, and multi-viewport is not supported there.

That matters because multi-viewport is one of the two Dear ImGui features the project highlights, alongside docking. Both are supported on the docking branch of upstream, and the binding exposes them. But the SDL path does not, so the combination of SDL3 and a docked ImGui interface is not on the table yet.

The extensions are bundled rather than left to the user. The list is ImPlot, ImNodes, imgui-node-editor, ImGuizmo, ImGuiColorTextEdit, ImGuiFileDialog, the ImGui Club MemoryEditor and imgui-knobs, which covers plotting, node graphs, gizmos, a text editor, a file dialog, a memory editor and knobs. There is also an optional FreeType font renderer for higher-quality text.

That set is what makes the binding usable for a real tool rather than a demo, since the plugins are the ones that take the longest to wire up by hand.

Dependency wiring and the packaged jars

The application module is published to Maven Central under the group io.github.spair, and the README gives the dependency snippet for both Gradle and Maven.

dependencies {
    implementation "io.github.spair:imgui-java-app:${version}"
}

The raw jar route is documented too. You go to the release page, download the java-libraries archive, take the application jar with the all classifier, and put it on the classpath. The README explains that a jar with the all classifier already contains the binding and the LWJGL modules, and that if you use a jar without that classifier you need to add the appropriate jars as well. Both variants, with or without the classifier, already contain the required native libraries.

For the binding module without the application module, the natives are separate artifacts per platform: a Windows one, a Linux one and a macOS one.

If you are using the Java 9 module system, the README notes that you need to require the imgui.app module.

The repository layout matches the artifact split, with imgui-app, imgui-binding, imgui-binding-natives and imgui-lwjgl3 directories, an include directory for the C++ headers, a patches directory for modifications to upstream, a vendor directory, a buildSrc directory and a publish.gradle script for the release process, plus an example project.

Versions, and what to check before you depend on it

The release tags are v1.92.7.1 from 2026-07-27, v1.92.0 from 2026-04-27 and v1.90.0 from 2025-08-26, and the last push was on 2026-10-05.

The version numbers are the upstream Dear ImGui version with a patch suffix, which is a useful convention to know: the binding version tells you which Dear ImGui API it was generated against. When upstream moves, this project regenerates and bumps.

That is the main thing to verify before you depend on it, because a binding regenerated against a newer upstream can change behaviour in ways that affect your layout code. If you are pinning to a Dear ImGui version for your own reasons, match the binding to it.

Four further checks. Which artifact you need depends on whether you have a render loop already. Which platform natives you need, since Windows, Linux and macOS are separate artifacts and only the macOS one is a universal binary. Whether you need multi-viewport, which rules out the SDL backend for now. And how you will take updates, since the binding follows upstream closely and a major Dear ImGui release can arrive between two of your dependency bumps.

The project is MIT licensed and the repository includes a contributing guide and an agents file, so the contributor workflow is documented in the usual places.

Editorial conclusion

imgui-java is the right choice for a Java team that wants an immediate mode GUI without leaving the JVM, since the application module gives a working window and a render loop with one dependency and a small subclass, and the binding plus the LWJGL backend is there when you need to drop ImGui into an existing render loop. It is the wrong choice if your application needs multi viewport ImGui with the SDL backend, since the README says that path is limited to a single window flow, and the wrong choice for a project that cannot ship native libraries. Verify first which Dear ImGui version the release tracks, since the binding is regenerated against upstream, and check the platform natives you need, because Windows, Linux and macOS are separate artifacts and the macOS one is a universal binary covering x86_64 and aarch64.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. SpaiR/imgui-java on GitHub