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>.jrc beside the exe, on Windows or macOS. With nothing baked in, jr runs as plain jr.exe myapp.jar [args], exactly as before when there was no .jrc.
• -Xjr:create-config is 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