sbt-fxml: The missing link between FXML and your code


Greetings web! I was invited to write a guest post here about a little JavaFX project I started not long ago: sbt-fxml. It’s a plugin for SBT and it tries hard to generate boring code for you so you don’t have to.

It scans for FXML files - either hand written or created by Scene Builder - parses them and creates controller classes with a proper name, package structure, imports, declarations and types. That’s right: types! So now your FXML files suddenly type check thus allowing you to find mistakes almost instantly. And because of SBT, you don’t even have to manually start the build for it. It happens as soon as you save your files.


What exactly are controller classes?

Controllers are simple POJOs into which the JavaFX runtime injects nodes from an FXML scenegraph. They provide the coder with a way to reference these nodes, so she doesn’t have to use node.lookup("#cssSelector") which has issues itself. When loading an FXML, everything with an fx:id gets injected. To give an example, the following FXML:

<Button fx:id="meep" />

could be accessed by a controller like this:

public class MyController {
    private Button meep;

This is a minimalistic controller skeleton created by Scene Builder (View -> Show Sample Controller Skeleton) and it is indeed a good example of how little code is needed to use FXML files.

That’s easy! Why the plugin?

Even if it’s only 4 lines of code it’s still code I don’t want to write. DRY, you know. It’s code which was autogenerated by a tool and I don’t see why it shouldn’t stay that way. And although SceneBuilder can give you an example controller, the generated code is neither pretty nor is the generation automated, so you are likely to have a gap between FMXL and your codebase. Sbt-fxml does not have this limitation as it creates bindings the moment you save your FXML. Additionaly it does it’s best to format the code nicely so it looks as whether it was hand written:

// Auto generated by sbt-fxml, changes will be overwritten
package com.example
import javafx.fxml.FXML
import javafx.scene.control.Button
object MyController {
  var meep: Button = ???

What’s next?

The plugin currently emits Scala code only. This is not by design, but felt like the natural choice for me when creating the plugin. This is likely to change in the future, though. Speaking of future, here is a list of what will be next:

  • Support generic nodes like ListView<?>
  • Handle many FXML files using the same controller class
  • Delete outdated controller classes
  • Implement creation of Java controller classes
  • Add more options to customize the output (indentation, etc.)
  • De-couple from SBT to allow other build tools (e.g. Maven, Gradle, Buildr, Ant, …) to leverage sbt-fxml’s functionality
  • Create a stand alone main so it can be used from the command line

I am currently writing tests and refactor the code in order to meet those goals. At the end there will be a nice specification of what sbt-fxml can do and after the first three tasks, I will release a 1.0. You don’t have to wait that long, though: There is a 1.0-SNAPSHOT, so if you’re curious, feel free to try sbt-fxml!

Thanks for reading!

Phillip Dörfler @phdoerfler

This article is the first guest post at guigarage. I hope you like it :) In my eyes this article afford guigarage a wider range of JavaFX related stuff. If anyone is interested to write a guest post at guigarage please ping me!

Hendrik Ebbers

Hendrik Ebbers is the founder of Open Elements. He is a Java champion, a member of JSR expert groups and a JavaOne rockstar. Hendrik is a member of the Eclipse JakartaEE working group (WG) and the Eclipse Adoptium WG. In addition, Hendrik Ebbers is a member of the Board of Directors of the Eclipse Foundation.

Circle Circle

Open Source made right


Privacy Policy Cookie Policy Privacy Config Impressum