ATLauncher builds a modpack launcher from source with Gradle and a Java 8 target

What the project actually is

The README states the purpose in two sentences. ATLauncher is a launcher for Minecraft which integrates multiple different modpacks to allow you to download and install modpacks easily and quickly.

That description is short, but it points at the shape of the application. A modpack launcher is not a launcher for the base game. It manages a curated set of modpacks, each of which pins a Minecraft version, a set of mods, a configuration and often a server profile, and the launcher's job is to fetch all of that, keep it in step, and start the game with the right arguments. The integration of multiple modpacks is the product, and the download and install path is where most of the work sits.

The links section points at the project website, a Discord server, and the usual social accounts, and the repository carries the civic files you would expect from a project with a community, with a `CONTRIBUTING.md`, a `TESTING.md`, a `CODE_OF_CONDUCT.md`, a `SECURITY.md` and a `SUPPORT.md`.

The primary language is Java, the licence is GPL-3.0 with the text in the `LICENSE` file, and the default branch is `master`. The release history shows a steady patch line, with v3.4.41.1 on 2026-07-04, v3.4.41.2 on 2026-08-19 and v3.4.41.3 on 2026-09-19, and the last push was on 2026-09-19, so the project ships frequently and is currently worked on.

The repository tree also hints at the scale of the thing. Alongside `src/` there is a `legacy-launch/` directory, a `packaging/` directory for the installers, a `scripts/` directory, Gradle files, and both `.idea/` and `.vscode/` directories, so the application is a large codebase with a history of older launcher code kept alongside the current one.

The Gradle build produces three platform artifacts

The build instructions are short because Gradle does the work, and the wrapper is the entry point.

The prerequisite is any Java version 8 or above, with Java 8 recommended since the project compiles to Java 8 compatibility regardless of the JDK you build with. The README is precise about that, and it is the kind of detail that decides whether your build works on a modern JDK.

Everything else comes from Gradle, invoked through the wrapper.

./gradlew build

The output lands in the `dist` directory, and the README says it covers Windows, Linux and OSX. So a single build produces the three platform artifacts rather than requiring three separate machines.

For running the application while working on it, the README offers the IDE route and then a command line route, and the command line one has a detail that is easy to miss.

./gradlew run --args="--debug --working-dir=testLauncher"

The `--working-dir=testLauncher` argument is not optional in practice, and the README explains why: it ensures the launcher's files are not spewed in the root directory and are instead contained within a gitignored folder. A launcher that writes its instance data, logs and settings into whatever the working directory happens to be is a launcher that will dirty your working tree, and this is the fix the project chose.

The IDE section carries a correction that is worth reading, because it is the kind of thing that sends a new contributor down the wrong path. The README originally said the project was mainly set up for VSCode, then struck that out and added that VSCode no longer works well after the upgrade to part Kotlin, so IntelliJ is recommended. Base project files are provided for IntelliJ IDEA, with correct launch tasks for the application and tasks for running the UI and unit tests.

GraphQL queries are generated from a downloaded schema

The application talks to a GraphQL API, and the README documents the codegen loop for it, which is a workflow worth understanding before you change any query.

Queries and mutations live in the `src/main/graphql` directory. When you add one, you first download the JSON schema from the public Apollo Studio endpoint for the ATLauncher schema, and then run a Gradle task to generate the Java sources for the new operation.

./gradlew generateApolloSources

The README says this codegens the Java files so you can use the query or mutation. The practical consequence is that the schema is not vendored in the repository, it is fetched from a live endpoint, which means a query that compiles on your machine compiles because the remote schema says it exists. If the schema endpoint changes shape, your build stops working for a reason that has nothing to do with your change.

That is a deliberate trade for a project whose backend is developed alongside the client, and it is also the kind of coupling that makes the codegen step a mandatory part of the workflow rather than an occasional chore.

The other Gradle task worth knowing is the dependency check.

./gradlew dependencyUpdates

It prints a report to the console about any dependencies which have updates, which is the standard way to keep a Gradle project current without wiring a plugin into the build.

Licence headers are checked in CI, so new files need them

The licence header workflow is a small section of the README that determines whether your pull request passes, and it is worth understanding before you write code rather than after a failed check.

When you add new files, or update the `LICENSEHEADER` file, you can add it to all source files by running a task.

./gradlew updateLicenses

To check that they are all correct, there is a second task.

./gradlew checkLicenses

The README states that this runs during the CI process and will fail if the licence is missing or not up to date, and it says plainly that you should add the headers to all new files you create. The `LICENSEHEADER` file at the top of the repository is the template, and the `LICENSE` file holds the GPL-3.0 terms themselves.

For a GPL project this is not busywork. A launcher that ships third party code, and a codebase that has absorbed contributions from many people, needs the headers to keep the provenance of every file visible, and a mechanical check is the only way to keep that true across a tree this size.

The same repository also has a `CHANGELOG.md`, a `SECURITY.md` and a `SUPPORT.md`, and the CI badge in the README is for the Application workflow, so a pull request is judged by an automated build before anyone looks at the change.

A theme is a class, a properties file and one registration

The theme system is the part of the README with the most detail, and it is a good illustration of how a Swing application is customised in 2026 without a plugin API.

The process is three steps. First you create a `MyThemeName.java` in the `src/main/java/com/atlauncher/themes/` directory, extending one of the base themes. The `Dark` theme is the default and a good starting point for new dark themes, `Light` is the light equivalent, and `ATLauncherLaf` is a base class which every theme must at some point extend, providing defaults including the brand colours, which the README says should not be extended from unless you need absolute power.

Second, you create a properties file in the `src/main/resources/com/atlauncher/themes/` directory, and that file is how you set up and change UI elements, with the existing examples in that directory as the model.

Third, you register the theme in `src/main/java/com/atlauncher/gui/tabs/settings/GeneralSettingsTab.java`, and then you can open the launcher and switch to your theme.

The properties approach comes from FlatLaf, the library the project uses for theme support. The README links the base properties files for all themes, for light themes and for dark themes in the FlatLaf repository, so the full set of overridable values is public, and it is the reference for what you can change.

The README is also honest about the difficulty, saying the process is fairly straight forward but may require a lot of trial and error.

IntelliJ themes need a manual conversion step

There is a second route into the theme system, and it comes with a caveat that catches people out.

You can take IntelliJ `theme.json` files and convert them for ATLauncher. The process described is to take the `UI` object out of the `theme.json` file and plug it into a JSON to properties converter on the web, to convert it from JSON into the properties format the launcher uses.

The caveat is in the next paragraph. There are special rules you need to apply, because the project does not support these `theme.json` files out of the box, and you have to apply the transformations manually, in order for the theme to work exactly right. The transformations the README points at are in the IntelliJTheme class in the FlatLaf repository.

So the conversion is a two step process with a manual stage in the middle, and the README offers a worked example, the `DraculaContrast` theme, which uses this method.

There are also two development tools worth knowing about, and both are only available with the launcher running in development rather than in the release version. Pressing `Ctrl + Shift + Alt + X` brings up a tool that highlights UI components so you can see their properties, and pressing `Ctrl + Shift + Alt + Y` brings up a list of all the default properties in the UIManager, with values that can then be modified in your `.properties` file.

That is the workflow for a theme author. Rather than reading the FlatLaf properties files to find out what a component is called, you click the component in the running application and read the values off the screen.

Maintenance, packaging and where the ceiling is

The project is a large Java application with an active release line, and the maintenance signals are consistent with that.

The three most recent tags are patch releases roughly a month apart, v3.4.41.1 on 2026-07-04, v3.4.41.2 on 2026-08-19 and v3.4.41.3 on 2026-09-19, and the last push is on the same day as the newest tag. A launcher has to keep working against a game client that changes, and a monthly patch line is a sensible response to that.

The build system carries the cost of that. The Gradle wrapper, the Java 8 target, the Apollo codegen against a live schema endpoint, the licence header check in CI, and the multi platform packaging in the `dist` directory are all pieces of a pipeline that has to keep working rather than a one-off setup.

Two constraints are worth naming for anyone evaluating whether to build on this. The first is the Java 8 target, which is generous in compatibility and restrictive in what you can use, and it is a deliberate choice to reach as many machines as possible. The second is the schema dependency, which means the build depends on a service that is outside the repository.

And the one thing the repository cannot give you is the thing most users actually want, which is a working launcher with a working modpack catalogue. That is the released application, built from this code, and the README's own website link is the route to it. For most people the right relationship with this repository is to install the application and, if you want to change it, to build it once with `./gradlew build` and work from there.

Editorial conclusion

ATLauncher fits a developer who wants to work on a Minecraft launcher with a large modpack catalogue, or a user who wants to build the application themselves rather than take a packaged binary. Skip it if you only want to install modpacks, since the released launcher already does that, or if your team cannot run a Java 8 compatible Gradle build. Verify first that the Gradle build completes on your JDK, that the Apollo schema download still matches the queries in `src/main/graphql`, and that any new file you add carries the expected licence header.

Frequently asked questions

Official sources

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