HMCL: a cross-platform Minecraft launcher with its own boot layer

The problem HMCL solves is platform, not launching

Launching Minecraft is not hard. Doing it on FreeBSD, on an ARM board, or on a RISC-V machine is. The README states that HMCL runs on Windows, Linux, macOS and FreeBSD, and supports x86, ARM, RISC-V, MIPS and LoongArch, with a link to a PLATFORM.md table for the exact combinations. That breadth is the product. Most launchers treat Linux as a second-class target and stop there.

The second problem is ModLoader sprawl. HMCL lists Forge, NeoForge, Cleanroom, Fabric, Legacy Fabric, Quilt, LiteLoader and OptiFine as installable loaders, alongside mod management, game customizing and modpack creation. A player who moves between a Forge modpack and a Fabric one does not need a second tool. The intended user is a player who wants one launcher across several machines, or a modpack author who needs to assemble and export a pack without leaving the launcher.

HMCLBoot: the launcher is itself a bootstrapped Java program

The repository root splits the code into HMCL/, HMCLCore/ and HMCLBoot/, with a Gradle Kotlin build (build.gradle.kts, settings.gradle.kts, buildSrc/) and a checked-in Gradle wrapper. That three-module layout is the architecture worth understanding before you adopt it.

HMCLBoot is a separate module from the launcher itself. A boot layer of this kind exists so the JAR can start, check for a newer build, and hand control to the current launcher code without the user reinstalling anything. HMCLCore holds the logic that is not tied to the JavaFX interface, which is why the project carries the javafx topic: the UI is a JavaFX application, and HMCLCore is what a headless or alternative front end would reuse.

The consequence for an adopter is that the artifact you download is not a frozen binary. It is a small program whose job is to fetch and run the real one. That is convenient for players and awkward for anyone who wants a pinned, auditable build.

Installing HMCL and creating a first game instance

The README does not give shell install steps. It points to three download sources: the official website at hmcl.huangyuhui.net, the GitHub Release page, and a CNB Release mirror. Take the JAR from one of those and run it with a Java runtime, since the project is written in Java and has no native installer in the README.

The launcher window should open. On first run you need a Java runtime for the game itself, separate from the one running the launcher; HMCL manages the game's Java installation rather than replacing it.

To build from source instead, the Contributing Guide is the entry point the README names. It documents building and running HMCL from source, and a set of debug options for adjusting launcher behaviour. The repository ships gradlew, gradlew.bat and gradlew.ps1, so the wrapper works without a system Gradle install. If the build fails, check the Java version your wrapper resolves against before filing anything: the Contributing Guide is where the project documents the supported toolchain, not the README.

Once the launcher is open, the first real task is creating an instance and installing a loader. The README lists Forge, NeoForge, Cleanroom, Fabric, Legacy Fabric, Quilt, LiteLoader and OptiFine as the loaders HMCL can install. Pick the Minecraft version, pick the loader, and let the launcher fetch the game files. Mod management and modpack creation are then handled inside the same window.

Where HMCL is the wrong tool

HMCL assumes a graphical desktop. It is a JavaFX application, and the README's supported-platform claim is about operating systems and CPU architectures, not about running without a display. A server operator who wants to script account and instance setup on a headless box gets nothing from this project; the launcher is for people sitting in front of a screen.

The second limitation is the boot layer. Because HMCLBoot fetches and runs the launcher, the version you started is not necessarily the version you end up running. If you are testing a specific release, or you need a build whose contents you can hash and pin, that self-updating behaviour works against you. The README does not document a way to disable it.

The third is Java. HMCL is a Java program, so it needs a Java runtime on the machine, and the game needs one too. On a minimal Linux or FreeBSD install that is a real prerequisite, not a formality. Users who expect a self-contained native binary will be disappointed.

Finally, the licence. HMCL is GPL-3.0, and the README adds terms under GPLv3 Section 7. If you intend to modify and redistribute it, those terms apply to you. If you just play the game, they do not.

HMCL against Prism Launcher and the official launcher

The obvious comparison is Prism Launcher, which is also an open-source, multi-instance Minecraft launcher. The difference in approach is the runtime. Prism Launcher is a native application built with Qt; HMCL is a Java application built on JavaFX and bootstrapped through HMCLBoot. That choice is exactly why HMCL reaches FreeBSD, RISC-V, MIPS and LoongArch: a JVM exists or can be built for those targets, while a Qt desktop stack often does not. If your platform is mainstream x86 Windows or macOS, the native route is the more conventional pick and the Java runtime requirement disappears.

The official Minecraft launcher is the other reference point. It launches the game and little else. HMCL's README leads with mod management, game customizing, loader installation and modpack creation, so the two are not competing on the same task. The official launcher is the right tool if you play vanilla and never touch a mod; HMCL is the right tool if managing loaders and packs is the reason you open a launcher at all.

Maintenance cadence, updates and what the licence asks of you

The repository is not archived, and its last push was on 2026-09-20. Recent releases include v3.17.0.357 on 2026-09-20, v3.16.4 on 2026-09-17 and v3.17.0.356 on 2026-09-12. The project also publishes through a CNB mirror and a Gitee mirror, which matters if GitHub is slow or blocked where you are.

The upgrade cost is close to zero for players: the boot layer exists to fetch newer builds, so you keep one JAR and let it update. The cost lands on anyone building from source, who has to track the Gradle Kotlin build and the JavaFX toolchain the Contributing Guide describes.

Licensing is where a redistributor needs to pay attention. HMCL is GPL-3.0 with additional terms under Section 7. Two are stated in the README: a modified distribution must change the software name or version number in a reasonable way to distinguish it from the original, and the copyright declaration displayed in the software must not be removed. The README points at Metadata.java for the name and version strings. This is a description of the project's terms, not legal advice; if you plan to ship a fork, read the LICENSE file yourself.

Editorial conclusion

Adopt HMCL if you play Minecraft on Linux, FreeBSD, ARM or RISC-V hardware and want mod, ModLoader and modpack management in one launcher. Do not adopt it if you need a launcher you can rebrand and ship closed: the GPL-3.0 terms carry additional Section 7 conditions requiring a changed name or version number on modified distributions and the retention of the copyright notice. Before installing, open PLATFORM.md and confirm your operating system and CPU architecture are listed, then take the JAR from the official website or the GitHub Release page rather than a mirror of unknown provenance.

Frequently asked questions

Official sources

1. HMCL-dev/HMCL on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases