Advantage over manual uberjar + jlink/jpackage: The main pain point jbundle solves is that jpackage generates installers (.deb, .rpm, .dmg, .msi), not plain ex

Advantage over manual uberjar + jlink/jpackage: The main pain point jbundle solves is that jpackage generates installers (.deb, .rpm, .dmg, .msi), not plain executables. jbundle produces a single self-contained binary — just a shell stub concatenated with a compressed payload. You chmod +x it, distribute it, and the user runs ./app. No installation step, no system-level changes. It also automates the full pipeline (detect build system → build uberjar → download JDK → jdeps → jlink → pack) so you don't need a JDK installed on the build machine — it fetches the exact version from Adoptium. Plus it includes startup optimizations like AppCDS (auto-created on first run, JDK 19+), CRaC checkpoints, and profile-tuned JVM flags for CLI vs server workloads. Cross-compilation: Yes — jbundle build --target linux-x64 (or linux-aarch64, macos-x64, macos-aarch64). Since the JAR is platform-independent, it just downloads the appropriate JDK runtime for the target OS/arch from Adoptium and bundles it. You can build a Linux binary from macOS and vice-versa. Plain executable (not an installer): That's exactly what jbundle produces. The output is a single file you can scp to a server or hand to someone. On first run it extracts the runtime and jar to ~/.jbundle/cache/ (keyed by content hash), so subsequent runs are instant. No .deb, no .dmg, no "install this first" — just a binary. For the macOS testing concern: since it's a CLI binary (not a .app bundle), it doesn't require signing/notarization to run. And with --target macos-aarch64 you can build it from a Linux CI without needing a Mac.