

resources src/main/resources path/to/other/assets \ĭirectory, zip file, tar.gz file, or URL to an archive file of a JRE or Java 8 JDK with a JRE folder in it. For a more complete example look at the PackrAllTestApp/: Invoking packr from the command line may look like the following. You point packr at your JAR file(s) containing your code and assets, some configuration parameters, and a URL or local file location to a JDK build for your target platform.

There's a lot of overlap between jpackage and packr. Starting with Java 14, there's a new tool that is included with the JDK called jpackage. When bundling Java 14+ make sure to use -useZgcIfSupportedOs instead of passing -vmargs XX:+UseZGC because versions of Windows before Windare not supported by the Z garbage collector. Because who doesn't want GC pause times guaranteed to not exceed 10ms with work in progress for sub 1ms GC pauses. On the topic of games, Packr version 2.4.2+ supports Java 14 and the Z garbage collector has been verified to work. Packr is most suitable for GUI applications, such as games made with libGDX. Packages your JAR, assets and a JVM for distribution on Windows, Linux and macOS, adding a native executable file to make it appear like a native app.
