# ControlsFX fills the gaps JavaFX leaves, on a javadoc quality bar

> ControlsFX is a JavaFX control library published to Maven Central under org.controlsfx:controlsfx, licensed BSD-3-Clause and released at a steady monthly-ish cadence. Its unusual contribution rule is that a new control is only merged once the existing code, javadoc included, is at an acceptable level.

**controlsfx/controlsfx** — High quality UI controls to complement the core JavaFX distribution

- Repository: https://github.com/controlsfx/controlsfx
- Website: https://controlsfx.org
- Stars: 1,712 · Forks: 298
- Language: Java
- License: BSD-3-Clause
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/controlsfx-controlsfx

## A gap-filler, not a JavaFX replacement

ControlsFX positions itself as a project that provides high quality UI controls and other tools to complement the core JavaFX distribution. The word doing the work is complement. It is not a competing toolkit, a skinning engine or a rewrite, and it does not replace the standard scene graph. What it does is supply controls the core distribution leaves out.

The stated target is JavaFX 8.0 and beyond, which dates the project's origin and explains its compatibility posture. Older JavaFX source lives on a separate `jdk-8` branch, so the modern `master` branch and the legacy branch can be treated as different targets rather than one codebase with a flag.

The artefact is published to Maven Central under the coordinates `org.controlsfx:controlsfx`, so consumption is an ordinary dependency declaration in a Gradle or Maven build. The licence is BSD-3-Clause, which requires preservation of its licence and copyright notices when the software is redistributed.

## The contribution rule is the actual design constraint

The most distinctive thing about the project is not a control, it is an admission policy. The README states a guiding principle of only accepting new controls and features when all existing code is at an acceptably high level, and it names the thankless jobs explicitly, including high quality javadoc documentation.

The stated consequence is that a high quality release is available at all times, with all experimental work happening in branches rather than on the main code base. Read plainly, that means you can depend on a tag without waiting for the maintainers to finish someone else's feature, and it also means a good contribution can be turned down for reasons that have nothing to do with the contribution itself. If you are proposing a control, expect to be measured against the whole tree rather than against your own diff.

The documentation link is treated as a first class deliverable throughout. The README calls the javadoc the definitive location for API help, argues the docs are full of examples and commentary rather than empty descriptions, and asks that anything unclear be filed as a bug so the documentation can be corrected. Contributors are routed through a Contributing to ControlsFX wiki page before opening a pull request, which is a small signal that review here is deliberate.

## Building and running the samples

Two gradle invocations are documented, and both use the wrapper checked into the repository:

```bash
./gradlew build check
```

That builds the library and runs the checks. To explore the sample application instead:

```bash
./gradlew run
```

The README describes the sample code as the other place worth exploring, and points at the `controlsfx-samples` directory in the source tree. That directory is separate from `controlsfx/`, the library module, which is a useful signal about how the project is split.

The build layout at the repository root is worth noting for anyone automating it. There are `build.gradle`, `settings.gradle`, `gradle.properties`, a `mavenPublish.gradle` for publishing, and both `gradlew` and `gradlew.bat`, so Windows is a first class path rather than an afterthought. The `fxsampler/` directory suggests a separate sampler application alongside the samples.

Note what is absent from the documentation: no JDK version floor is stated, no Gradle version is pinned in the README, and there is no migration guide for moving between ControlsFX major versions. Those are the details you will have to establish from the build files or the release notes.

## The feature list lives off the repository

Here is a documentation decision that will frustrate anyone evaluating quickly. The README says ControlsFX includes so many features that they are listing them on a separate page, and sends you to the ControlsFX features page on the project website for a sample of what is included. The repository itself does not carry the catalogue.

That has a practical consequence for adoption. You cannot evaluate this library from the README the way you can evaluate most projects of this size, and the external page shows some of what is included rather than the whole surface. If you are choosing between ControlsFX and hand-rolling a control, the honest position is that you need to visit the site or read the javadoc index before deciding, since neither the control list nor the version compatibility table lives in version control.

The three quick links in the README cover the same ground from different directions: the JavaDoc for the API, the issue tracker for bugs and feature requests, and the release notes for change history. Issues are the channel for both bug fixes and enhancement requests, which tells you the two are triaged together.

## Release cadence, sponsorship and what to check

The recent tags show a project shipping steadily. Version 11.2.5 came on 2026-09-03, with 11.2.4 and 11.2.3 both on 2026-07-28 and the patch pair landing a minute apart. That double release is normal for a patch plus a documentation or metadata fix, and it is a reasonable signal that the release process is automated rather than hand assembled. The last push was on 2026-10-15.

Infrastructure support is acknowledged in the README. Gluon is credited with substantial contributions toward project hosting and development of major features, and JetBrains with IntelliJ IDEA licences. Both matter for a project whose value is partly in how long it will still exist, since maintaining a long-lived open source library is a hosting cost question as much as a code question.

The real comparison is with the standard JavaFX control set plus work you would do yourself. If you need one specific control, implementing it against the same property and binding conventions as the core controls may cost less than taking on the library and its release coupling. If you need several, the picture reverses. A third path is a different community library, which would mean evaluating its licence, its JavaFX version support and its documentation standards on the same terms, and ControlsFX's BSD-3-Clause licence plus long tag history is a reasonable bar to measure against.

## Conclusion

Adopt ControlsFX when you are building a JavaFX desktop application and the stock control set stops short of what your UI needs, since the library exists precisely for that gap and ships BSD-3-Clause with no copyleft obligation on your application. Do not adopt it on the strength of the feature count, because the README does not enumerate the controls and points to an external site for that, so verify your specific control exists before designing around it. Verify first that `./gradlew build check` passes on your JDK, and read the published javadoc rather than the README, which the project itself names as the definitive API reference.

## FAQ

### How do I build ControlsFX from source?

Run `./gradlew build check`, which builds the library and runs the checks. To play with the sample application instead, run `./gradlew run`.

### What Maven coordinates does ControlsFX publish under?

It is published to Maven Central as `org.controlsfx:controlsfx`, so it can be added as an ordinary dependency to a Gradle or Maven build.

### Which versions of JavaFX does ControlsFX support?

The project has been developed for JavaFX 8.0 and beyond. Source for JavaFX 8 lives on the separate `jdk-8` branch rather than on `master`.

### Why might a ControlsFX pull request be turned down?

The stated policy only accepts new controls and features when all existing code is already at an acceptably high level, javadoc included. A new feature can therefore be deferred until the surrounding code meets that bar.

## Sources

- [controlsfx/controlsfx on GitHub](https://github.com/controlsfx/controlsfx)
- [License: BSD-3-Clause](https://github.com/controlsfx/controlsfx/blob/master/LICENSE)
- [Project website](https://controlsfx.org)
- [README](https://github.com/controlsfx/controlsfx/blob/master/README.md)
- [Releases](https://github.com/controlsfx/controlsfx/releases)

---

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