JavaFX mainline: one repository, three build systems, and no releases
JavaFX mainline development
At a glance
- What is it?
- openjdk/jfx is where JavaFX itself is developed, under the OpenJDK charter and the same GPL v2 with Classpath exception terms as the JDK. The README is short by design and hands you to three different sites for building, downloading and reporting, while the repository itself carries Gradle, Maven and JDK build machinery side by side.
- Who is it for?
- Read this repository as the source of a platform rather than as a library you will vendor, because JavaFX ships as part of a JDK and the tree is set up to build into one. Three things decide whether it is useful to you.
- Can I use it commercially?
- Yes, with conditions. GPL-2.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly C++, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on November 14, 2026, and from our analysis. They are not legal advice.
Star history
- openjdk/jfx3,309 ★ · +18
| Repository | 2026-09-24 | 2026-11-14 |
|---|---|---|
| openjdk/jfx | 3.3k | 3.3k |
18 Stars in the last 51 days, measured from the daily GitHub snapshot. Compare with other projects
Editorial analysis
Gradle, Maven and JDK build files all sit in the same tree
The build machinery is the widest thing in this repository. A Gradle setup is there with build.gradle, settings.gradle, a buildSrc directory and a wrapper in both shell and batch form. A Maven publication path is there too, with javafx.pom and a maven-publish.gradle file. And the JDK's own build configuration appears as build.properties plus a gradle-local.properties.template for local overrides.
Three build descriptions for one project is unusual enough to be worth understanding rather than guessing. The likely reason is that JavaFX is consumed in two different ways: built into a JDK image, and published as ordinary artifacts for projects that want the libraries without a full JDK build. The file that names the version bump procedure, UPDATING-VERSION.md, and the version properties live alongside that machinery.
Style and review tooling is equally present. checkstyle.xml enforces Java conventions, and the OpenJDK review setup appears as a .jcheck directory with a separate README-code-reviews.md explaining how reviews are run on pull requests.
A first patch requires the Oracle Contributor Agreement, not just a good diff
Contribution here is a legal process before it is a technical one. The project operates under the charter of the OpenJDK, and the bylaws together with the license file govern the work. Membership is recorded on the OpenJDK census rather than in this repository, and the README names it as where the project's membership can be found.
The step that surprises newcomers is spelled out explicitly. Anyone contributing to an OpenJDK project for the first time has to review the rules on becoming a Contributor and sign the Oracle Contributor Agreement, which lives at a separate Oracle site. That happens before a pull request, not alongside it.
The remaining process is delegated rather than described. CONTRIBUTING.md holds the code of conduct and the process for submitting pull requests, and a SECURITY.md sits at the root for anything that should not travel as a public issue. The README itself stops at pointing you there.
The bug reporting instructions start by assuming your build is old
The issue tracking section is three instructions, and the first one is a filter. Before filing, make sure you are testing against the latest version, because the issue may already be fixed. Only after that does it tell you to search the existing issues list, and that list is not a GitHub tracker: it is the Java Bug System at bugs.openjdk.org, opened with a filter already applied to the project.
The third instruction sends you to bugreport.java.com for where and how to report. So the file's guidance is a three-stage funnel, and only the last stage produces something a committer sees.
The practical consequence for anyone tracking JavaFX bugs is that the project identifier matters. An issue in this repository is not the queue the project reads, which is why the number that appears in the filtered URL is the thing to search by rather than a GitHub issue number.
Build instructions and download instructions live on two different sites
The Getting Started section has two paragraphs and two outbound links, and they point in different directions.
Building is delegated to a wiki page on wiki.openjdk.org titled Building OpenJFX. That is where the toolchain, the Gradle invocation and any platform prerequisites are described, and none of it appears in this repository. Downloading and using JavaFX is delegated to openjfx.io, the community site.
So a first-time user has two destinations depending on what they want, and a contributor has a third, the review documentation in this tree. For a repository whose description is JavaFX mainline development, that is a deliberate division: the code is here, the knowledge is spread across a wiki, a community site and a Java Bug System.
It does mean the README cannot answer the questions people usually bring to it, which is why the sections below are mostly about what the tree itself reveals.
GPL v2 with the Classpath exception, and two extra license files besides LICENSE
The licensing paragraph is precise about matching the JDK. OpenJFX is free software under GPL v2 with the Classpath exception, described as the same terms the JDK uses, and the file says anybody is welcome to contribute, port it to other platforms or devices, or do anything else a free software license allows.
The license recorded for this repository is GPL-2.0, which is the short form of the same idea without the exception spelled out, so the two descriptions agree in substance and differ in precision. Two further files at the root handle the details: ASSEMBLY_EXCEPTION and ADDITIONAL_LICENSE_INFO.
This matters more than it does for a small library. The Classpath exception is what permits linking against the library from code under other terms, and it is the reason a client application can use JavaFX without its own source becoming subject to the copyleft terms. A second project assembling JavaFX into a JDK image inherits the same arrangement, which is why the exception has its own named file.
Eclipse and IntelliJ project files are both committed to the repository
The top level shows what a large multi-contributor project accumulates. There is an .idea directory for JetBrains tooling, and there are .project and .settings directories for Eclipse, so two different IDE configurations live side by side in version control. Neither is unusual on its own; both together is a reminder of how many people touch this tree.
Alongside them sits gradle-local.properties.template, a template rather than a live file, which is the polite way to keep machine-specific settings out of a shared build. The .gitattributes and .gitignore files are present for the usual reasons, and doc-files/, modules/, apps/ and tests/ carry the content.
One file is named for a limitation rather than a process: WEBKIT-MEDIA-STUBS.md. JavaFX's web content support is built on WebKit, and a document with that title at the root of the repository indicates that media playback in that engine is not uniformly available across platforms. The file is where the details are, and it is worth reading before assuming media works the same way on every target.
No GitHub releases, and a master branch that moved four days ago
The repository publishes no tagged releases. Nothing in the tree suggests a per-tag artefact flow, which is consistent with a project whose output is a JDK image and whose libraries follow the JDK's own release cadence rather than a GitHub release page.
The default branch is master, and it was pushed on 1 October 2026. The repository is not archived and carries a security policy, a code of conduct and a contributing guide, so the project is in the middle of its life rather than at either end of it. What it is not is a place where version numbers for JavaFX itself are published, which is why the description is the narrow one it is: JavaFX mainline development.
If you are trying to work out which JavaFX you have, the project points you off the repository for that, to the community site for downloads and to the JDK you are running for the version that shipped with it.
Editorial conclusion
Read this repository as the source of a platform rather than as a library you will vendor, because JavaFX ships as part of a JDK and the tree is set up to build into one. Three things decide whether it is useful to you. Building it is a documented wiki exercise rather than a script in the README, so budget time for the build page and for the toolchain it asks for. Getting a bug fixed means going through the Java Bug System with a specific project filter, and the project asks you to rule out an old build before filing. And contributing is gated on process rather than code, since a first patch requires reading the bylaws and signing the Oracle Contributor Agreement. If you only need JavaFX to run something, openjfx.io is the place the project points you to, and no part of that involves this repository.
Frequently asked questions
How do I build JavaFX from the openjdk/jfx repository?
The README sends you to the Building OpenJFX page on wiki.openjdk.org for build instructions. For downloading and using JavaFX it points to the JavaFX community site at openjfx.io.
What license is JavaFX released under?
GPL v2 with the Classpath exception, the same terms the JDK uses. The repository also carries ASSEMBLY_EXCEPTION and ADDITIONAL_LICENSE_INFO files alongside LICENSE.
Do I have to sign anything before contributing to openjdk/jfx?
Yes. The project runs under the OpenJDK charter, and anyone contributing to an OpenJDK project for the first time has to review the rules on becoming a Contributor and sign the Oracle Contributor Agreement.
Where should a JavaFX bug be reported?
First make sure you are testing against the latest version, because the issue may already be fixed. Then search the issues list in the Java Bug System at bugs.openjdk.org, filtered for this project, and follow the reporting guidance at bugreport.java.com.
Does openjdk/jfx publish tagged releases?
No GitHub releases exist for it. The tree carries a Maven publication setup with javafx.pom and maven-publish.gradle, and UPDATING-VERSION.md covers version changes.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/openjdk-jfx)Star history chart for your README
[](https://hysenlabs.com/projects/openjdk-jfx)Was this useful?