Ikonli: icon packs for Java Swing and JavaFX applications

What the project is, and where it stops

Ikonli is described in one line as icon packs for Java applications, and the README states that it provides icon packs that can be used in Java applications, with the Swing and JavaFX UI toolkits currently supported.

That last clause is the whole scope, and it is worth being clear about it before anything else. This is a desktop Java library. There is no web support, no Android support, and no SVG-rendering library in the browser. If your project is a web application, this is not the tool.

The primary language is Java, the licence is Apache-2.0, and the homepage is http://kordamp.org/ikonli/. The project is organised by Kordamp, the same author behind the Gradle plugin ecosystem, and the repository root shows the shape of it: a core/ directory, an icon-packs/ directory holding the individual packs, apps/ for the applications, docs/, infra/, buildSrc/ and a settings.gradle with a build.gradle at the top.

The README is an AsciiDoc document with a structured project header, listing the project owner as kordamp, the project repo as maven, the project group as org.kordamp.ikonli, the project name as ikonli and the project version as 12.4.0.

One group on Maven Central, one artifact per pack

The distribution model is the part that determines how you actually use it. The README says you can get the latest version of Ikonli directly from Maven Central, and the badge in the project header points at a Maven Central search for the group org.kordamp.ikonli.

So the coordinates are org.kordamp.ikonli with the artifact name ikonli for the core, and the packs follow the same group. The repository layout confirms the structure: a core/ module and an icon-packs/ directory, which in a Gradle multi-project build means the packs are separate subprojects that each publish their own artifact.

That is the right shape for this kind of library, and it is the reason Ikonli is worth a dependency. Icon sets are large. If a core artifact contained every pack, every application that wanted one icon family would pull the whole collection into its distribution. With one artifact per pack, an application declares only the two or three packs it draws from, and the other packs never reach the classpath or the jar.

The version shown in the README header is 12.4.0, and the releases show the same numbering with an EarlyAccess suffix for pre-release builds, including 12.5.0.EarlyAccess and 12.4.0.EarlyAccess alongside the stable v12.4.0.

Building the project and the three sample applications

The build requirements are JDK11 as a minimum and Gradle 6.4 or newer, and you may use the included gradle wrapper script if you do not have gradle installed.

The build is driven through Gum, a wrapper script that facilitates invoking gradle tasks anywhere within a Gradle project, described as smart enough to use the gradle wrapper if available or your global gradle command. The documentation gives three routes to installing it, and Gum is the optional download, with the instructions to follow the guide at https://github.com/kordamp/gm to install it.

A full build is issued as a single command, gm build, and then there are three applications to run, each a separate Gradle task. The sampler JavaFX application, the sampler Swing application, and the Ikonli Browser application.

$ gm :sampler-javafx:run

$ gm :sampler-swing:run

$ gm :ikonli-browser:run

The Ikonli Browser is the one that matters most for evaluating the library, because the packs contain far more icons than any application would use, and browsing the catalogue is how you find the ones you want. The two samplers exist to show the same icons rendered through the two supported toolkits, which is a useful check if you are unsure how a particular glyph will look in Swing.

The command style itself is worth noting. The colon separated task path, gm :sampler-javafx:run, addresses a subproject's task directly, and it works because of Gum's behaviour of resolving the project from the current directory.

Publishing a local snapshot, and what the release setup implies

If you want to test a local build against your own application before it goes to Maven Central, the README gives two routes. With Gum installed, the command is a single step.

$ gm install

Without Gum, the fallback uses the Gradle wrapper directly.

$ ./gradlew publishToMavenLocal

Both publish a SNAPSHOT into your local Maven repository, which is what lets you depend on an unreleased icon pack from an application you also build locally. This matters more than it sounds for this project, because icon packs are frequently added and revised, and the first question an adopter has about a new pack is what it looks like before it is released.

The release infrastructure is visible in the tree. There is a jreleaser.yml, which is the configuration for the JReleaser tool that handles tagging, building and publishing the artifacts, and an infra/ directory for the shared build infrastructure, with a VERSION file at the root and a gradle.properties alongside it. There is also a .bach/ directory and bach.args, which is the Bash automated script helper Kordamp uses across projects, plus a SECURITY.md.

The two release naming conventions in the release list, v12.4.0 and 12.4.0.EarlyAccess, tell you the project publishes early access builds alongside stable ones, and the EarlyAccess release of 12.4.0 and the stable v12.4.0 were cut on the same day in April 2025, which is the usual pattern of promoting a tested pre-release to a stable tag.

The limits of a desktop-only icon library

The scope is narrow, and there are two ways that narrowness bites.

The first is platform coverage. Swing and JavaFX only. An application that is partly desktop and partly web, or an Electron or native mobile front end backed by a Java service, cannot share the same icon handling. Teams in that situation end up with a Java library for the desktop UI and a second, separate asset pipeline for the web side, and the icons drift apart.

The second is the nature of the artifacts themselves. These are image resources, and image resources mean a jar with binaries in it. That is fine for a desktop application that is installed as a distribution anyway, and it is a real cost for a Java application that is otherwise a small server jar or a library of its own. The mitigation the project structure already offers is per-pack artifacts, so you take only the packs you draw from, and you can also pick a small subset of a pack, since individual icons within a pack can be selected by name.

The third limitation is about consistency of appearance rather than availability. A pack gives you a coherent visual language, which is the point of a pack rather than a folder of loose SVGs. It does not give you a pack that matches your product's existing design, so if you have a brand, an icon library is a starting point to adapt rather than a substitute for that work.

How Ikonli compares with bundling your own assets

The realistic alternatives are three, and they differ in approach rather than in features.

The first is bundling the image files yourself. A directory of PNGs or SVGs on the classpath, loaded by a helper you wrote. The difference is that you now own the asset pipeline, the licence provenance, the sizing for different densities, the dark mode variant if you need one, and the maintenance when the design changes. Ikonli moves all of that into versioned artifacts, at the cost of a dependency and a fixed set of choices.

The second is a general purpose icon font or SVG sprite library used from Java, where you would still write the Java side of the loading, the code point mapping and the colour handling. Ikonli is that work already done, with the icon set included.

The third is a design system component library of your own, generated from your design source, which is the approach that matches a brand exactly. The difference in approach is that this is generated per project and per design change, while an icon pack is a fixed, versioned collection of ready-made glyphs. A team with a designer and a pipeline should probably generate; a team that needs a decent set of icons today should use a pack.

The practical test is maintenance appetite. A pack is cheap to adopt and stays static until you upgrade it. Generated assets are cheap to adopt only if you already have the tooling, and cost work on every design change.

Editorial conclusion

Adopt Ikonli when you are building a Java desktop UI and want a maintained set of icons with a single lookup API across Swing and JavaFX, rather than bundling individual image files and hand-wiring them. Do not adopt it for a web front end, since the supported toolkits are Swing and JavaFX only. Before you add a pack, check which artifacts exist under the org.kordamp.ikonli group on Maven Central and read the configuration guide, and note that the last push was on 2026-10-13 with release 12.5.0.EarlyAccess the same day.

Frequently asked questions

Official sources

1. kordamp/ikonli on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases