# Cloud: a command dispatcher for the JVM where commands are typed chains

> Cloud is a general purpose Java command dispatcher and framework in which a command is a deterministic chain of strongly typed arguments, parsed from a user supplied string, with a builder or an annotation approach and a set of platform implementations for Discord, Minecraft, IRC and Spring Shell. Cloud 2 is a breaking rewrite of version 1.

**Incendo/cloud** — Command framework & dispatcher for the JVM

- Repository: https://github.com/Incendo/cloud
- Website: https://cloud.incendo.org
- Stars: 549 · Forks: 60
- Language: Java
- License: MIT
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/incendo-cloud

## A command is a chain of typed arguments

Cloud allows programmers to define command chains that are then parsed and invoked from user-supplied string inputs to execute pre-defined actions, and the key property is that those chains are deterministic and strongly typed. The README spells out the consequence, that when you define a command you know exactly what type of data you are going to be working with, and you know that there will be no ambiguity at runtime. That is the whole argument for a framework of this kind, because the alternative is the familiar pattern where a command has a name, a list of string arguments and a switch statement, and the type of each argument is only established inside the handler where a cast or a parse call happens. Cloud pushes that knowledge to the definition, so the parser and the handler agree by construction, and the same property makes the commands reusable, since a chain built once can be mounted under different names or on different platforms. The project promotes writing reusable code and makes it very easy to define new commands, and the primary language is Java with a Kotlin module alongside it, so the framework is aimed at JVM teams rather than at a single ecosystem.

## Two ways to define a command, shown side by side

The README shows that Cloud allows you to build commands in many different ways according to your preferences, and the images in that section are the ones that carry the information, since the text around them is minimal. There are four images, and they pair up into two axes. The first pair is the builder style against the annotations style, and the second pair is Java against Kotlin, so you can see the same command written four ways. That is the design decision in one picture. The builder style constructs a command chain programmatically, which is the more explicit and the more refactorable of the two, and the annotation style puts the definition on the method itself, which is how the surrounding Java command frameworks tend to work and which reads well when the command is the main thing a class does. The Java and Kotlin comparison matters because Cloud ships a Kotlin module, so the same framework can be used from a Kotlin codebase with its own idioms rather than being a Java library awkwardly consumed from Kotlin. The annotations images are also the ones that hint at the extension point, since the annotation parsing system is described as something you can extend with your own annotations.

## Handlers and processors can be injected along the whole chain

The customisation story is stated in terms of the chain rather than the command, and that is the useful detail. Cloud is built to be very customisable in order to fit your needs, and you can inject handlers and processors along the entire command chain. If the pre-existing command parsers are not enough for your needs, you are easily able to create your own parsers, and if you use the annotation parsing system you can also define your own annotations and register them to further customise the behaviour of the library. That is a much larger extension surface than a fixed parser, because it means the parsing, the validation and the execution stages are each replaceable. A team with an existing parser, say one that already handles a domain specific syntax, can drop it into the chain rather than fighting the default. It also explains the separate repositories, since cloud-processors holds extra pre- and post-processors, which is the same idea published as an add-on rather than baked into the core.

## Platform implementations, and the core that has no platform

Cloud ships with implementations and mappings for the most common Minecraft server platforms, and for Discord bots you get Discord4J, JDA4, JDA5, Kord and Javacord, then PircBotX for IRC and cloud-spring for Spring Shell. The point of that list is that the API differences between those platforms are absorbed, so a command defined once can be dispatched through a Minecraft server, a Discord bot, an IRC channel or a Spring shell terminal. The catch, stated plainly in the same paragraph, is that the core module allows you to use Cloud anywhere simply by implementing the CommandManager for the platform of your choice. That is the extension point for anything not on the list, and it is a small interface to implement, which is what makes the framework usable for a bespoke platform nobody else has a client for. The repository list shows how the family is split, with cloud-minecraft and cloud-minecraft-modded for the server side, cloud-discord, cloud-spring, cloud-processors for the extra processors, cloud-build-logic as a Gradle plugin for building Cloud itself, cloud-docs for the documentation sources, and a cloud-bom directory in the tree for the bill of materials, which is how a multi-module project keeps its module versions in step.

## Building it, and the licensing of the design

The develop and build section is two commands. To clone the repository, use `git clone https://github.com/Incendo/cloud.git`, and to then build it, use `./gradlew clean build`, and if you want to build the examples as well, use `./gradlew clean build -Pcompile-examples`. The build is Gradle with the Kotlin DSL, since the tree has build.gradle.kts and settings.gradle.kts, and the quality tooling is visible in the directory names, with a.checkstyle/ directory, a.spotless/ directory for formatting, a.palantir/ directory, a HEADER file and a gradle.properties. The release history shows the 2.x line, with 2.1.0 from 2026-07-20, 2.0.0 from 2024-08-24 and 2.0.0-rc.2 from 2024-05-30, and the last push to the repository was on 2026-10-22. The licensing note is unusual and worth reading. The library is licensed under the MIT licence and the code copyright belongs to Alexander Söderberg, but the implementation is based on a paper written by the copyright holder, and that paper exists under a CC Attribution 4 licence. So the design itself is published as a paper and the code is an implementation of it, which is a good pattern for a framework because the design rationale is legible separately from the code. The icon is credited to a named contributor on Iconscout, with digital rights purchased under a premium plan.

## Where Cloud is the wrong choice

The first limit is the version break, and the README puts it at the top in a note. Cloud 2 is a major update with many significant changes and it is not compatible with version 1, with the changelog linked for the migration. So a project on Cloud 1 is looking at a migration rather than an upgrade, and a project choosing today is choosing Cloud 2 with no compatibility path back. The second is the size of the concept count for what looks like a small job. A typed argument chain with injectable parsers, handlers and processors is a well-built tool, and it is still a framework with a builder, an annotation system, a plugin model and a CommandManager interface, which is a lot to learn before you have parsed a single argument. A team with one command and a simple string parser is over-engineering. The third is that the platform implementations are not uniform in quality, since they are maintained alongside a fast moving core and a Java and Kotlin API surface that is now in its second major version, and the Discord ecosystem in particular has changed its client libraries several times over the life of this project, which is why the list still names both JDA4 and JDA5. The fourth is the dependency on the platform, because a Minecraft server or a Discord bot can only use commands that the platform's own permission and message model can express, so a chain that is well typed on the JVM can still be impossible to expose in a Discord channel. And the fifth is the build, since a Gradle multi-module project with a BOM, a build-logic plugin, code style configuration and a Checkstyle setup is a substantial thing to contribute to, which shapes who can realistically maintain a fork.

## Conclusion

Adopt Cloud if you are writing a bot or a command line interface on the JVM and want argument parsing to be typed at compile time rather than assembled by hand at runtime, and you want the same command model across Discord, Minecraft, IRC and a Spring shell. Skip it if you are still on Cloud 1, since the README states Cloud 2 is not compatible with version 1, and skip it if you only need a single trivial command. Verify first which platform implementation you need, that the command manager you implement or use matches your platform, and that the annotation processors or the builder style suit the way your team already writes parsers.

## FAQ

### What is the Cloud command framework for Java?

It is a general purpose Java command dispatcher and framework in which commands are defined as deterministic chains of strongly typed arguments, parsed and invoked from user supplied string inputs. The point is that the argument types are known when the command is defined, so there is no ambiguity at runtime, and the framework is designed to promote reusable command code.

### Which platforms does Cloud support?

It ships implementations for the common Minecraft server platforms, for Discord bots through Discord4J, JDA4, JDA5, Kord and Javacord, for IRC through PircBotX, and for Spring Shell through cloud-spring. The core module can be used on any platform by implementing the CommandManager for it.

### How do I build Cloud and is Cloud 2 compatible with version 1?

The README says to clone the repository with git clone https://github.com/Incendo/cloud.git and build with ./gradlew clean build, adding -Pcompile-examples to build the examples as well. It also states plainly that Cloud 2 is a major update with many significant changes and is not compatible with version 1, with a changelog linked for the migration.

## Sources

- [Incendo/cloud on GitHub](https://github.com/Incendo/cloud)
- [License: MIT](https://github.com/Incendo/cloud/blob/master/LICENSE)
- [Project website](https://cloud.incendo.org)
- [README](https://github.com/Incendo/cloud/blob/master/README.md)
- [Releases](https://github.com/Incendo/cloud/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/incendo-cloud