JetUML: a small JavaFX UML editor with no dependencies of its own

Sketching, not modelling

The description sets the scope in one line: a desktop application for fast UML diagramming, and the README calls it a simple free and open-source UML editor that supports sketching software design ideas quickly and with a minimum of hassle. That word sketching is the honest one, and it is worth reading as a constraint rather than a limitation to be worked around. The audience is someone who needs a picture of a design idea, not a model that a team maintains over months. The endorsement quoted in the README makes the same point from a working user's angle: a fair bit of modeling with some commercial tools which can be quite heavyweight, and whenever a quick sketch of a design before writing code is needed, JetUML is preferred in most cases. So the comparison JetUML invites is not with other UML editors feature by feature, but with the heavyweight tools: what you gain is the speed of starting one and the low cost of running it, and what you give up is whatever those tools do with a model as a long-lived artefact. The project is written in Java with JavaFX, and the topics list covers desktop-application, diagram, javafx, modeling, uml and uml-diagrams.

Zero dependencies means a plain JDK is enough

One detail in the README header is unusual enough to be worth pulling out. The project carries a badge from 0dependencies.dev reading 0 dependencies, and a badge for the code style from the XO project, and a GPL v3 licence badge. For a Java desktop application the zero-dependency claim is a real deployment property rather than a slogan. There is no build tool pulling a tree of jars, no application framework to configure, no native library to satisfy, which means the application should run on a machine that has nothing but a JDK installed. That matters in two places. On a teaching machine or a locked-down corporate desktop where installing a package graph is friction, the difference is decisive. And for anyone reading the source, an application whose entire dependency list is the platform is far easier to audit and far easier to build from scratch, because there is no version matrix to reason about. The trade is the usual one for a small tool: everything JetUML does, it does with the platform primitives, and any feature that would need a third-party library is either implemented in the project or absent.

Export to images and to the clipboard

The two integration paths the README names are the ones that matter for the sketching workflow. Diagrams can be exported to popular image formats, and they can be copied to the system clipboard for integration with other tools. Both are aimed at the same scenario, which is that the diagram exists to be shown rather than to be maintained. A class diagram pasted into a slide, a chat message or a document is a picture of a design at a point in time, and the export paths make that one action. The repository includes a screenshot of a JetUML class diagram in the docs directory as a banner, which is a reasonable hint at the default output. The copy-to-clipboard route is the more interesting of the two, because it removes the intermediate file entirely: a diagram made in JetUML can be pasted into another tool as an image without a save, an upload and a re-insert. For a tool whose stated purpose is quick sketching, that is the right emphasis, and it is also a hint about what the tool is not trying to be, which is a model repository with round-trip import from other suites.

The file format is documented as a schema

The documentation list is short and unusually pointed. There is a Download and Installation page, a User Guide, a JetUML File Format page, a Guide for Developers, and a page of external blogs and articles. The file format document is the one that separates JetUML from a sketchpad. A diagram that you draw in a tool and can only read back in that same tool is a scratchpad, whereas a format that is documented as a schema can be inspected, diffed, generated by a script, or checked into version control alongside the code it describes. The schema document is linked as docs/schemas.md in the repository. For an academic audience this is the most load-bearing feature in the project, because it means a diagram can be a reviewable artefact in a course, a paper or a repository rather than a binary blob. The repository layout backs this up, with a testdata directory and a tipdata directory alongside the test directory, which are the two kinds of fixture a format-sensitive tool needs, and a .checkstyle file at the root that indicates the code is held to a style checker.

Maven, a site, and a Java project with its history in it

The repository is a conventional Java project built with Maven, with pom.xml at the root and the source under src, style and test directories, plus the .project, .classpath and .gitignore files that come from an Eclipse-based workflow. Alongside the application code there is a documentation website: a CNAME file, a _config.yml and a _layouts directory, which is a Jekyll site published through GitHub Pages, and a docs directory holding the markdown pages the README links to. The icons directory holds application assets, and a .github directory holds the workflow configuration. Two things suggest a project with a long institutional life rather than a weekend experiment. The GPL-3.0 licence is a deliberate choice for a tool from a university-affiliated author, and the README asks readers to consider supporting the project by starring the repository and by writing an endorsement to [email protected], an address at McGill. The releases are v3.10 on 2026-09-08, v3.9 on 2025-07-29 and v3.8 on 2024-08-13, and the last push to the repository was on 2026-10-12, so the project is on a 3.x line with a release roughly every year and recent commits behind the newest tag.

Where JetUML is the wrong tool

The honest limits come from the same positioning that gives the tool its value. A sketch that must become a maintained model is a bad fit, because the workflow the project optimises for is starting fast rather than iterating over a large artefact, and nothing in the documentation describes importing an existing model from a commercial suite. Second, the README does not enumerate the diagram types JetUML supports, which is a gap worth noting for anyone whose need is a specific notation. The documentation list mentions a class diagram in the banner image and the general UML label, but the set of supported diagram types is not stated in the README. Third, the GPL-3.0 licence has consequences for a commercial organisation embedding the tool in a larger workflow, and a Java runtime is a prerequisite even for the zero-dependency build, so the tool is not a single self-contained binary. And fourth, the picture a reader should keep in mind is that this is a desktop application with a graphical interface, not a service or a library, so it does not slot into a headless pipeline the way a diagram-as-code tool would.

Editorial conclusion

JetUML suits a developer or student who needs to sketch a class diagram, a sequence diagram or a state machine in the minute before a design meeting, and the zero-dependency claim means it will run on a machine with a JDK and nothing else, which is exactly what a teaching lab or a locked-down corporate desktop needs. It is the wrong tool for a large modelling project, since the README describes sketching design ideas quickly with a minimum of hassle rather than managing a model across a team, and it is the wrong tool if you need round-trip import from a commercial modelling suite, because the documented interchange is its own file format plus image export and the clipboard. Verify first which diagram types you actually need, since the README does not enumerate them, read docs/schemas.md before you commit to the file format, and note that the newest release is 3.10 from 2026-09-08 with the last push on 2026-10-12.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. prmr/JetUML on GitHub
4. README
5. Releases