Janex packages and launches Java applications and manages Java, Node.js, Gradle, and Maven installations.
The long-term goal is a cross-platform, cross-language SDK manager, package manager, and build tool,
with .janex as a general application container for managed languages. See the roadmap
for planned capabilities and priorities.
Download and extract a distribution, then run ./janex self install
(.\janex.exe self install on Windows). This copies Janex into JANEX_HOME/bin, writes shell
loaders, and prints commands for loading them. You can also keep the executable elsewhere on PATH.
The optional janex-launcher executable is a prefix for creating self-launching application packages.
janex install sdk:bellsoft/liberica-jdk@21
janex default sdk:bellsoft/liberica-jdk@21janex shell init writes shell integration scripts into JANEX_HOME/shell and prints loading commands.
JANEX_HOME defaults to ~/.janex; set it to an absolute path to use another directory.
The executable can reside elsewhere. SDK installations are separate from disposable dependency caches.
Shell startup files are not modified automatically.
Use janex self update to update a managed installation from the latest stable GitHub Release.
Until releases are published, use a downloaded Actions archive:
janex self update --from <archive.zip-or-tar.xz>.
Load shell/init.sh for Bash or Zsh, shell/init.fish for Fish, or shell/init.ps1 for PowerShell.
For example:
. "$HOME/.janex/shell/init.ps1"
janex activateAfter moving the executable, run janex shell init again and reload the script.
See the CLI guide for packaging, launching, and SDK commands.
Use janex integration register to add Janex to the system's file-opening options, and
janex integration unregister to remove the registration. Registration defaults to the current
user and preserves the default application. Pass --allow-unsigned to allow opening unsigned
local packages, or configure signer pins as with janex run. Linux additionally supports
janex integration register --system --binfmt for direct execution of executable .janex files.
janex integration export --output <directory> generates assets for distribution installers.
Install JDK 25, Rust, and the platform's native build tools. Use the root Gradle Wrapper
(.\gradlew.bat on Windows):
./gradlew assembleRelease
./gradlew check
./gradlew installJanex -PjanexInstallDir=<absolute-directory>Release binaries are written to target/release/ unless Cargo output settings override it.
installJanex copies executables into the specified directory; run janex shell init separately.
Use packageArtifacts -PjanexTarget=<rust-target> to build, check, and package a distribution
under build/distributions/. Windows archives use ZIP; Unix archives use tar.xz and require xz.
Linux musl and FreeBSD cross-builds also require Zig and cargo-zigbuild.
Supported targets and tool versions are maintained in the artifact workflow.
Download prebuilt archives from its GitHub Actions runs or published GitHub Releases.
workspace.package.version in Cargo.toml is shared by Rust, Java, and the Gradle plugin.
Development versions end in -SNAPSHOT. For a release, remove the suffix, refresh Cargo.lock
with cargo check --workspace, and commit both files before creating the matching v<version> tag.
Then set the next development version and refresh the lockfile. Release builds do not change versions.
Publishing a GitHub Release builds all supported platforms and uploads their distribution archives
after every platform build succeeds. The release tag must match v<workspace.package.version>.
The file format version is independent.
See LICENSE for license terms.