Scene Builder: a drag and drop designer for JavaFX FXML layouts

Design and logic are separated by editing FXML, not by editing code

Scene Builder is a visual, drag and drop layout tool for designing JavaFX application user interfaces, and the README's description of what it is for is short: it separates design from logic, allowing team members to quickly and easily focus on their specific aspect of application development.

The separation is concrete. The unit of work is an FXML layout, and the tool manipulates that layout visually. A designer arranges controls and connects them to a controller, and a developer writes the controller logic. Neither of them has to hand-write markup for the other, which is the friction the tool removes.

The second thing to know is the ecosystem it sits in. Scene Builder works with the JavaFX ecosystem, meaning the official controls, community projects, and Gluon offerings including Gluon Mobile, Gluon Desktop and Gluon CloudLink. Those last three are Gluon products, and the tool has a dedicated Gluon section in its control library for them, which is the clearest sign of the relationship between the tool and the vendor behind it.

The project is open source and freely licensed under the BSD licence, and Gluon sells consultancy, training and commercial support around it. That combination is the usual shape for a company-backed open source developer tool: the code is free, the support is not.

Three Maven modules, and the Kit is the part you can embed

The repository is a Maven multi-module project with three main components defined by three subprojects.

Scene Builder App is the JavaFX main application. It embeds the Scene Builder Kit and includes menus, preferences and dialogs to interact with it. In other words, the application is a shell around the interesting part.

Scene Builder Kit is the core of the project, and its three areas map directly onto the screenshot you see in the tool. On the left is the library of custom and built-in controls, the hierarchy and the controller of the FXML layout being edited. In the centre is the workspace area for displaying the content of that layout. On the right is the inspector with properties, layout and event handlers of the components.

The Gluon plugin is the third module, and it is what puts Gluon Mobile controls into the library and lets you set stylesheets from the Gluon themes and swatch colours. The README suggests starting with the Mobile Basic Screen template from the welcome dialog if you want to see it work.

The important part for an integrator is that the Kit contains an API which allows these components and their functionality to be integrated into other applications or IDEs. Scene Builder App is the best example of such an integration, and the repository points at an EmbeddedSceneBuilderDemo repository as a basic one. The controls available in the Kit can also be used directly in your own project.

The Kit is on Maven Central, so you can depend on it

Scene Builder Kit is published to Maven Central, which means you can add it as a regular dependency to the build of your app:

<dependency>
  <groupId>com.gluonhq.scenebuilder</groupId>
  <artifactId>kit</artifactId>
  <version>$version</version>
</dependency>

If you want the Kit in your local repository instead, the README gives the command, and it targets the kit module directly rather than the whole reactor:

./mvnw clean install -f kit

That distinction between the application and the Kit is the one to keep in mind when you are choosing an integration route. If your goal is to let your users lay out FXML in your own product, you depend on the Kit and embed it. If your goal is to give your developers a layout tool, you tell them to install the application.

The Kit being on Maven Central also means it participates in normal dependency management. It is versioned, it is resolvable, and it is a normal artifact rather than a source checkout, which is a different adoption profile from a project you can only clone.

Running it from source: JDK 23 for master, JDK 8 for the 8u-dev branch

Building Scene Builder is only required if you want to fork and build your own version, and the README says as much, since the project is frequently released. The prerequisites are a recent version of JDK 23 or later for building the master branch, and a recent version of JDK 8 for building the 8u-dev branch.

The build uses the Maven Wrapper, so you run ./mvnw on Linux or macOS and mvnw on Windows. To build the services, on the project root you run mvn clean package, or, using the wrapper, ./mvnw clean package. The result is a partial shadow cross-platform jar under app/target/lib/scenebuilder-$version-all.jar, which does not include the JavaFX dependencies.

Running it needs the dependencies installed locally, which is what ./mvnw install does. Then the app can be started with Maven:

./mvnw javafx:run -f app

The alternative is to run the partial shadow jar yourself, which requires downloading the JavaFX SDK:

java \
--module-path /path/to/javafx-sdk-$javafxVersion/lib \
--add-modules javafx.web,javafx.fxml,javafx.swing,javafx.media \
--add-opens=javafx.fxml/javafx.fxml=ALL-UNNAMED \
-cp app/target/lib/scenebuilder-$version-all.jar \
com.oracle.javafx.scenebuilder.app.SceneBuilderApp

That command is the honest summary of what running this looks like. The module path points at a JavaFX SDK you have to fetch, the add-modules list names the four modules the tool needs, and the add-opens for javafx.fxml is there because FXML loading reflects into private internals. Note that the main class is com.oracle.javafx.scenebuilder.app.SceneBuilderApp, in the oracle namespace.

One Linux dependency, and it is the kind that bites on Arch

There is a single platform requirement beyond the JDK, and the README devotes a section to it. On Linux systems, Scene Builder uses the xdg-open command to reveal files in the system's default file system browser or to open URLs in the default web browser.

Most modern Linux desktop environments already provide the xdg-utils package, and if it is missing it can be installed with the relevant package management tool such as yum, apt-get, dnf or pacman. The README adds two specifics: the package is usually available on KDE based systems, and some Arch based systems may require manual installations.

This is a small detail that tells you something about the shape of the tool. It shells out to a desktop helper for the reveal-in-file-manager action, which is the normal way to do that on a Unix desktop, and it is the kind of integration that is trivially available on macOS and Windows through the platform APIs and intermittently available on Linux depending on the distribution.

For anyone deploying Scene Builder into a locked environment, the reveal action is the thing to test first, because it is a feature of the tool that depends on an external command rather than on JavaFX.

Contributions need a signed CLA, and the checkstyle rules are still thin

Issues are reported through the GitHub issue tracker, and contributions go through pull requests, with one condition attached: you have to have signed the Gluon Individual Contributor License Agreement, linked from the README, and the contribution guide in CONTRIBUTING.md has the details. The CLA is a real gate on the contribution path, and it is worth reading before you invest time in a patch.

On the code style side, the README explains that the Maven Checkstyle plugin can be used to create a report listing possible coding style violations, and that contributors can run the Checkstyle Maven goal to check their own code. It also says the checkstyle configuration is currently in a very early stage and only checks for things like empty blocks, extra white space and padding.

So the style gate is thin today, which cuts both ways. It means a first contribution is unlikely to be rejected over formatting, and it means the project has not yet invested in enforcing a house style beyond whitespace. There is a checkstyle.xml at the root of the repository if you want to see the current rules.

The build is also on GitHub Actions, with the badge pointing at the early-access workflow.

Where Scene Builder is the wrong tool

The first wrong fit is a project that has left JavaFX. The tool edits FXML layouts for JavaFX controls, and there is no path from that to a different UI toolkit. If your application is built with something else, the Kit and the App are irrelevant to you, and the visual layout step has to be solved elsewhere.

The second wrong fit is a team that wants one tool. The README's own framing of separating design from logic is really a claim that two different people with two different jobs can work on the same FXML file, and that only works if the file is the shared contract. If your team is two developers who both want to write code, the designer and the layout tool add a step rather than remove one.

The third is a project that wants the designer inside its own product, and needs more than the Kit provides. The Kit exposes the three areas and an API for integration, and there is a demo repository showing the shape of that work. Building a production integration means embedding the Kit, handling its lifecycle and keeping up with its API across versions, which is a commitment to a fast-moving upstream.

The fourth is a sign that this snapshot may not be current. The last push to the repository was on 2026-04-17, and the releases follow the same pattern, with 26.0.0 on 2026-04-17, 25.0.0 on 2025-09-25 and an early-access build on 2026-03-23. There is also a separate early-access workflow in the continuous integration, which suggests a project that ships a stable release and a moving channel at the same time.

The practical advice is to use the released application rather than the source, because that is the artefact the project publishes, and to read the documentation at docs.gluonhq.com/scenebuilder for the features that have been added recently. For community questions, the README points to the Stack Overflow tag for scenebuilder.

Editorial conclusion

Scene Builder fits a JavaFX team that wants designers and developers to work on the same FXML layout without one of them writing the markup by hand, and that wants the designer's tool available inside its own IDE through the Kit API. It does not fit a project that has moved away from JavaFX, and it does not fit a team that needs an actively moving upstream. Before adopting it, download the released application rather than building it, and check the Kit dependency on Maven Central if the plan is to embed the designer rather than run the app.

Frequently asked questions

Official sources

1. gluonhq/scenebuilder on GitHub
2. Issues
3. Project website
4. README
5. Releases