Repository navigation
Releases: jarrunner/jr
Release list
jr 1.4.1
A small fix release on top of 1.4.0.
- Resource editing never opens a dialog.
-Xjr:editand-Xjr:make(used by jr-maven-plugin to stamp an app's exe) always write their report to stdout/stderr and return an exit code. Under 1.4.0, when the calling build had no console (a CI agent, a scheduler, a shell that had gone away), jr showed its report in a modal dialog instead, and the build waited on it. - macOS: no PATH advice when an app drives
-Xjr:install. Under-Xjr:batchthe app's own install (jr-apputils) adds~/.local/binto PATH itself, so jr no longer tells the user to do it just before it is done.
Built by CI, not code-signed. Check downloads against SHA256SUMS. The exe size is unchanged (622,592 bytes for jr-windows-x86_64.exe).
jr 1.4.0
jr 1.4.0: the 1.4.0 betas, released as final. The binaries are identical to 1.4.0-beta.3.
- One-file install and update for jr apps on Windows and macOS:
-Xjr:update,-Xjr:install(macOS: the.appand a command link in~/.local/bin), and-Xjr:batch(no prompts, one JSON line on stdout) for apps that drive these themselves, as jr-apputils does. - macOS: Java download when none is found, dialogs when an app is opened from Finder or the Dock, and the JVM inside the app's own process by default (
jvm=dll). - Update channels: a beta takes over from stable once stable is newer.
jr-maven-plugin 1.2.0 on Maven Central bundles this release. Built by CI, not code-signed. Check downloads against SHA256SUMS.
jr 1.4.0-beta.3
jr 1.4.0-beta.2
jr 1.4.0-beta.1
jr 1.3.1
jr 1.3.1 fixes a hang on Windows: jr 1.3.0 and earlier froze, with one CPU core at 100% and before starting Java, when an argument contained certain non-ASCII characters, for example jr.exe app.jar café. Please use 1.3.1 instead of any earlier Windows build.
What changed:
- The Windows exes are now built against the Universal C Runtime (UCRT) instead of the older msvcrt.dll. With msvcrt, the conversion of the program's arguments could loop for ever on a character such as
é; the UCRT passes the argument through correctly. - The release workflow now runs an app with
caféandéaas arguments, and fails if jr hangs or the app does not start. - No other change in behaviour. The x86_64 exe is 617,472 bytes (1.5 KB smaller).
Windows versions: the UCRT is part of Windows 10 and 11. On Windows 7 SP1 and 8.1 it comes with Windows Update (KB2999226) or with any Visual C++ 2015 or later redistributable, which most machines already have; without it the exe does not start.
Exes built by jr-maven-plugin carry the jr build the plugin bundles, so rebuild them with a plugin version that bundles 1.3.1 or later.
Assets: jr.exe and jr-windows-x86_64.exe are the same x86_64 build. jr-windows-arm64.exe is the ARM64 cross-build. The jr-noicon-* exes are the same builds without the jr icon, for stamping your own. jr-macos is the universal macOS binary, and jr-macos-arm64 and jr-macos-x86_64 are its two slices; the macOS binaries are unchanged in behaviour. On macOS, install with curl -fsSL https://github.com/jarrunner/jr/releases/latest/download/install.sh | sh.
Where these binaries come from: built from this tag by the repository's release workflow on GitHub's Windows and macOS runners (mvn package, llvm-mingw's UCRT build, TeaVM 0.16.0 with our C-backend fixes from io.github.jarrunner.teavm on Maven Central). Before publishing, the workflow checks that the exes and binaries run, that the x86_64 macOS slice runs under Rosetta, and the non-ASCII argument above. Check a download against SHA256SUMS. The binaries are not code-signed.
Full Changelog: v1.3.0...v1.3.1
jr 1.3.0
jr 1.3.0 no longer reads a .jrc file. An app's settings now live only in the config baked into its own exe (or embedded in its macOS binary), which jr-maven-plugin writes.
What changed:
- jr does not look for
<exe>.jrcbeside the exe, on Windows or macOS. With nothing baked in, jr runs as plainjr.exe myapp.jar [args], exactly as before when there was no.jrc. -Xjr:create-configis gone. It now gives an error that points to jr-maven-plugin.-Xjr:<key>=<value>overrides for one run still work (-Xjr:aot=false,-Xjr:java.home=PATH,-Xjr:jvm=dll, ...).- Baking a key=value file into an exe with
-Xjr:resource.RCDATA.JRC=is refused; the config must be a jrc-json. - The x86_64 exe is about 15 KB smaller (619,008 bytes).
What to use instead: build your app's exe with io.github.jarrunner:jr-maven-plugin. It bakes in the same settings (vm.args becomes vmArgs, java.version becomes javaVersion, jvm becomes jvmMode, and so on), and a file beside the exe can no longer change it. See the guide: https://github.com/jarrunner/jr/blob/main/docs/guide.md
Exes made from an older jr carry their own copy of it and keep reading their .jrc until you rebuild them.
Assets: jr.exe and jr-windows-x86_64.exe are the same x86_64 build. jr-windows-arm64.exe is the ARM64 cross-build. The jr-noicon-* exes are the same builds without the jr icon, for stamping your own. jr-macos is the universal macOS binary, and jr-macos-arm64 and jr-macos-x86_64 are its two slices. On macOS, install with curl -fsSL https://github.com/jarrunner/jr/releases/latest/download/install.sh | sh.
Where these binaries come from: built from this tag by the repository's release workflow on GitHub's Windows and macOS runners (mvn package, TeaVM 0.16.0 with our C-backend fixes from io.github.jarrunner.teavm on Maven Central). Before publishing, the workflow checks that the exes and binaries run, and that the x86_64 macOS slice runs under Rosetta. Check a download against SHA256SUMS. The binaries are not code-signed.
Full Changelog: v1.2.1...v1.3.0
jr 1.2.1
jr 1.2.1 is 1.2.0 with version information in the Windows exes (company, product, description, version). 1.2.0's exes carried none, and Windows Defender flagged 1.2.0's jr.exe as a trojan (a machine-learning false positive). No code changes; use this release rather than 1.2.0.
A Java launcher: one native file that carries its config, fetches and verifies its jar, finds or installs Java, and updates itself. Now for macOS as well as Windows.
New since 1.1.0 (released as 1.2.0):
- macOS: jr-macos (universal), with the arm64 and x86_64 slices on their own. Each is signed ad hoc. Install with
curl -fsSL https://github.com/jarrunner/jr/releases/latest/download/install.sh | sh; curl sets no quarantine flag, so Gatekeeper does not block it. - -Xjr:doctor shows which Java a launch would use and why; -Xjr:repair fixes what jr made (AOT caches, a changed jar, damaged JDKs). -Xjr:java.home=PATH picks a Java by its home folder.
- A launch that finds a broken cache or JDK heals itself rather than failing.
- Error dialogs share one standard layout, copy their message with one click, and close with Esc.
- Unicode paths and arguments throughout (Windows wide-character APIs, UTF-8 on macOS).
Assets: jr.exe and jr-windows-x86_64.exe are the same x86_64 build. jr-windows-arm64.exe is the ARM64 cross-build. The jr-noicon-* exes are the same builds without the jr icon, for stamping your own. jr-macos is the universal macOS binary, and jr-macos-arm64 and jr-macos-x86_64 are its two slices.
Where these binaries come from: built from this tag by the repository's release workflow on GitHub's Windows and macOS runners (mvn package, TeaVM 0.16.0 with our C-backend fixes from io.github.jarrunner.teavm on Maven Central). Before publishing, the workflow checks that the exes and binaries run, and that the x86_64 macOS slice runs under Rosetta. Check a download against SHA256SUMS. The binaries are not code-signed.
To build a branded launcher for your own app in your Maven build, use io.github.jarrunner:jr-maven-plugin. The 1.1.0 plugin on Maven Central bundles the 1.1.0 launcher; a plugin release with this build follows.
Full Changelog: v1.1.0...v1.2.1
jr 1.2.0
Superseded by jr 1.2.1. 1.2.0's Windows exes carry no version information, and Windows Defender flags its jr.exe as a trojan (a false positive). 1.2.1 is the same code with that fixed.
A Java launcher: one native file that carries its config, fetches and verifies its jar, finds or installs Java, and updates itself. Now for macOS as well as Windows.
New since 1.1.0:
- macOS: jr-macos (universal), with the arm64 and x86_64 slices on their own. Each is signed ad hoc. Install with
curl -fsSL https://github.com/jarrunner/jr/releases/latest/download/install.sh | sh; curl sets no quarantine flag, so Gatekeeper does not block it. - -Xjr:doctor shows which Java a launch would use and why; -Xjr:repair fixes what jr made (AOT caches, a changed jar, damaged JDKs). -Xjr:java.home=PATH picks a Java by its home folder.
- A launch that finds a broken cache or JDK heals itself rather than failing.
- Error dialogs share one standard layout, copy their message with one click, and close with Esc.
- Unicode paths and arguments throughout (Windows wide-character APIs, UTF-8 on macOS).
Assets: jr.exe and jr-windows-x86_64.exe are the same x86_64 build. jr-windows-arm64.exe is the ARM64 cross-build. The jr-noicon-* exes are the same builds without the jr icon, for stamping your own. jr-macos is the universal macOS binary, and jr-macos-arm64 and jr-macos-x86_64 are its two slices.
Where these binaries come from: built from this tag by the repository's release workflow on GitHub's Windows and macOS runners (mvn package, TeaVM 0.16.0 with our C-backend fixes from io.github.jarrunner.teavm on Maven Central). Before publishing, the workflow checks that the exes and binaries run, and that the x86_64 macOS slice runs under Rosetta. Check a download against SHA256SUMS. The binaries are not code-signed.
To build a branded launcher for your own app in your Maven build, use io.github.jarrunner:jr-maven-plugin. The 1.1.0 plugin on Maven Central bundles the 1.1.0 launcher; a plugin release with this build follows.
Full Changelog: v1.1.0...v1.2.0
jr 1.1.0
A Java launcher exe: one file that carries its config, fetches and verifies its jar, finds or installs Java, and updates itself.
New since 1.0.0:
- jrc-json: the config as JSON, embedded in the exe; it cannot be overridden by a file beside the exe.
- Self-update: -Xjr:update-check and -Xjr:update, from a per-app update file.
- jar.sources tried in order; SHA-256 checked on download, CRC32 (default) on every run.
- The app receives its whole config as -Dio.github.jarrunner.jr. properties.
- Progress, prompts and errors go to stderr, as does the JVM's AOT cache creation output, so a CLI's stdout stays clean.
Assets: jr.exe and jr-windows-x86_64.exe are the same x86_64 build (jr.exe keeps 1.0.0's name). jr-windows-arm64.exe is built but not yet run on ARM hardware.
To build a branded launcher for your own app in your Maven build, use io.github.jarrunner:jr-maven-plugin:1.1.0, which bundles this build without the jr icon.
Where these binaries come from: built from this tag on the maintainer's machine (llvm-mingw, jr\build-win.ps1). The repository's release workflow still builds the older C launcher (jr_legacy_c), because the TeaVM build cannot run on CI yet; that build was replaced here, since it does not contain the 1.1.0 features. Check a download against SHA256SUMS.