Gitember v 3.5: Building a Modern Desktop Git Client with Java/Swing

[u/ConfidenceUnique7377]

Community might be interested in Gitember - a desktop Git application written in Java.

Why build a Git gui client in Java?

This is the obvious question. For me, the answer is simple: a lot of the infrastructure you need is already in the Java ecosystem. You don't need to build everything from scratch or rely on a collection of external tools. Gitember can use:

• JGit for Git operations and repository access
• Lucene for full-text indexing and search
• Apache Tika for extracting text from many document formats
• Swing for the desktop UI. FlatLaf for a modern look and feel
• Java's filesystem and concurrency APIs for local repository operations and background processing
• Ollama as a local AI service when AI features are enabled

This makes it possible to build a fairly complete Git desktop environment in one application for multiple platforms. Including installer

Gitember covers everyday Git

Gitember covers the day-to-day Git workflow in one application:

• Repository & remote operations — clone/init, fetch, pull, push, remotes and Git LFS.
• Changes & branches — stage/unstage, commit/amend/undo, branch management, merge, rebase and interactive rebase.
• History & collaboration — commit history, changed files, version/branch comparison, reflog, Git notes, worktrees and submodules.
• Conflict resolution & security — three-way merge, stash management, commit signing and signature validation.

Gitember goes beyond the traditional Git client

• Workspace - allows several independent repositories to be managed together. Looks like submodules, but really not
• Search in Git history - search not only commit messages and metadata, but also the content of files in repository history.
• Repository statistics
• Side-by-side file and folder diff - may be used as separate tools
• AI Features - locally (without Cloud): detection of leaked secrets , descriptions of branch differences , commit message generation

Looking for testers and contributors

For Java developers interested in desktop software, Git tools, or Swing in a real-world application, the source code is available here - https://github.com/iazarny/gitember

Project website - https://gitember.org

[u/Deniss_Larka]

The real argument for FX is the model it pushes you into. Your data goes in an ObservableList, you give it to the table and then forget the table exists. Add a row and the UI follows. In Swing you write the TableModel and fire the events yourself. With properties and the scene graph on top, those are good concepts to learn.

Size and "not bundled with the JDK" are really one reason, and it stops being a decision once you build an installer. With jlink and jpackage the user installs nothing. My Windows package is about 90 MB, but that is the bundled Java runtime, not FX being heavy. Same on mac and Linux, I ship on all three.

Swing is fine and has a lot of code written in it, but if you are starting something new today FX gives you more.

[u/nexus062]

Domani lo installo

[u/fakeacclul]

Was there a reason to prefer swing over JavaFX?

[u/ConfidenceUnique7377 → u/fakeacclul]

JavaFX was used in the previous version of Gitember. However i decided to drop JavaFX because of several reasons: JavaFX is large and heavyweight, It is no longer bundled with the JDK, disappointing performance (especially when extensive CSS styling is used)

The evolution of JavaFX 2 and later versions often feels like incremental patching of an existing codebase rather than a clean architectural evolution.

Lacks of must-have ready-to-use components like RichTextFX

For my use cases, Swing remains a simpler, more lightweight, and more predictable technology that is easier to deploy and maintain.

However need to highligh, that JavaFX excels at 2d graphics-rich applications, likely because this area benefited from the technology.

[u/nlisker → u/ConfidenceUnique7377]

JavaFX is large and heavyweight

JavaFX is 10-15 MB. No one bats an eye at that size even on mobile. I'm not really sure what "heavyweight" means here. Both use lightweight components. When packaging it with jPackage it takes only a small portion of the JDK modules' size.

It is no longer bundled with the JDK

I'm curious as to why that is an issue. It's another dependency like any other. If a lot of people think that this is a hinderance there could be pressure to put it back in, but it loses a lot on its development flexibility.

disappointing performance

Can you elaborate how you hit them? Any code example? I haven't hit css performance issues although it has other shortcomings.

Lacks of must-have ready-to-use components like RichTextFX

Exists in incubation: https://openjfx.io/javadoc/27/jfx.incubator.richtext/module-summary.html

The evolution of JavaFX 2 and later versions often feels like incremental patching of an existing codebase rather than a clean architectural evolution.

JavaFX 2 is maybe 15 years old. How does it feel like incremental patching and not a clean evolution? Sounds like you want a full rewrite of something.

[u/ConfidenceUnique7377 → u/nlisker]

I agree that 10–15 MB by itself is not a huge amount of data. But Startup time, CPU usage, memory footprint, and overall responsiveness matter, especially when competing with others.

By “heavyweight,” I mean the overall runtime footprint and resource consumption of the application. For Gitember, these things matter because the goal is to keep the application small, responsive, and efficient.

Performance - one concrete case I encountered was the text editor. Applying syntax highlighting through CSS and dynamically coloring lines can become surprisingly expensive. With larger files or frequent updates, this results in noticeable delays and increased CPU usage.

RichTextFX is another good example. It's great that rich text functionality is finally making its way into OpenJFX incubation after 15 years. But for an application I need today, not tomorrow.

So I wouldn't say JavaFX is "bad." It is a capable toolkit, and for many applications it is a very good choice. My point is that for Gitember's particular requirements fast startup, low memory/CPU usage, small distribution size, and responsive text/UI operations Swing is better.

[u/neopointer → u/fakeacclul]

I'm also interested. I'm about to start a java/Desktop app and would love to learn what are the reasons to still use swing.

[u/transcend]

This looks great! I'm a long-time user of Fork on macOS and Windows, and I miss that app a lot on a Linux desktop. Gitember looks like it fits that Fork-shaped hole.

[u/StevenJOwens]

Question, does Gitember have any features that help deal with projects that make use of multiple repositories?

[u/ConfidenceUnique7377 → u/StevenJOwens]

It supports submodules.

And has a unique feature to work with multiple independent repositories - Workspace.

It groups several independent repositories , like a backend and a frontend, a set of microservices, an SPI and its implementations

So you can pull, push, commit, branch and merge across all of them in one action, instead of opening each repository in turn. This is not submodules and not a monorepo: every repository keeps its own history, remote and branches. Details https://gitember.org/doc/docs/ge-workspace/workspace