Packages your JAR, assets and a JVM for distribution on Windows, Linux and Mac OS X

Related tags

Build packr
Overview

About

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. Packr is most suitable for GUI applications, such as games made with libGDX.

On the topic of games, Packr version 2.4.2+ supports Java 14 and the Z garbage collector has been verified to work. Because who doesn't want GC pause times guaranteed to not exceed 10ms with work in progress for sub 1ms GC pauses. When bundling Java 14+ make sure to use --useZgcIfSupportedOs instead of passing --vmargs XX:+UseZGC because versions of Windows before Windows 10 1803 are not supported by the Z garbage collector.

Starting with Java 14, there's a new tool that is included with the JDK called jpackage. There's a lot of overlap between jpackage and packr. Considering jpackage is supported by the broader OpenJDK community, it's worth looking into. It might be a better solution for your product.

Download

The latest build is available for download here.

Resource artifacts are available at Maven Central

Usage

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.

Invoking packr from the command line may look like the following. For a more complete example look at the PackrAllTestApp/packrAllTestApp.gradle.kts:

java -jar packr-all.jar \
     --platform mac \
     --jdk OpenJDK11U-jre_x64_mac_hotspot_11.0.10_9.tar.gz \
     --useZgcIfSupportedOs \
     --executable myapp \
     --classpath myjar.jar \
     --mainclass com.my.app.MainClass \
     --vmargs Xmx1G \
     --resources src/main/resources path/to/other/assets \
     --output out-mac
Parameter Meaning
platform one of "windows64", "linux64", "mac"
jdk Directory, zip file, tar.gz file, or URL to an archive file of a JRE or Java 8 JDK with a JRE folder in it. Adopt OpenJDK 8, 11, and 15 are tested against https://adoptopenjdk.net/releases.html. You can also specify a directory to an unpacked JDK distribution. E.g. using ${java.home} in a build script.
executable name of the native executable, without extension such as ".exe"
jrePath (optional) path to the bundled JRE. By default, the JRE will be placed in a folder called "jre".
classpath file locations of the JAR files to package
removelibs (optional) file locations of JAR files to remove native libraries which do not match the target platform. See below for details.
mainclass the fully qualified name of the main class, using dots to delimit package names
vmargs (optional) list of arguments for the JVM, without leading dashes, e.g. "Xmx1G"
useZgcIfSupportedOs (optional) When bundling a Java 14+ JRE, the launcher will check if the operating system supports the Z garbage collector and use it. At the time of this writing, the supported operating systems are Linux, macOS, and Windows version 1803 (Windows 10 or Windows Server 2019) or later."
resources (optional) list of files and directories to be packaged next to the native executable
minimizejre (optional) Only use on Java 8 or lower. Minimize the JRE by removing directories and files as specified by an additional config file. Comes with a few config files out of the box. See below for details on the minimization config file.
output the output directory. This must be an existing empty directory or a path that does not exist. Packr will create the directory if it doesn't exist but will fail if the path is not a directory or is not an empty directory.
cachejre (optional) An optional directory to cache the result of JRE extraction and minimization. See below for details.
icon (optional, OS X) location of an AppBundle icon resource (.icns file)
bundle (optional, OS X) the bundle identifier of your Java application, e.g. "com.my.app"
verbose (optional) prints more status information during processing, which can be useful for debugging
help shows the command line interface help

Alternatively, you can put all the command line arguments into a JSON file which might look like this:

{
    "platform": "mac",
    "jdk": "/Users/badlogic/Downloads/OpenJDK8U-jdk_x64_mac_hotspot_8u252b09.tar.gz",
    "executable": "myapp",
    "classpath": [
        "myjar.jar"
    ],
    "removelibs": [
        "myjar.jar"
    ],
    "mainclass": "com.my.app.MainClass",
    "vmargs": [
       "Xmx1G"
    ],
    "resources": [
        "src/main/resources",
        "path/to/other/assets"
    ],
    "minimizejre": "soft",
    "output": "out-mac"
}

You can then invoke the tool like this:

java -jar packr-all.jar my-packr-config.json

It is possible to combine a JSON configuration, and the command line. For single options, the command line parameter overrides the equivalent JSON option. For multi-options (e.g. classpath or vmargs), the options are merged.

This is an example which overrides the output folder and adds another VM argument. Note that the config file name is delimited by -- because the option prior to it, --vmargs, allows multiple arguments:

java -jar packr-all.jar --output target/out-mac --vmargs Xms256m -- my-packr-config.json

Finally, you can use packr from within your Java code. Just add the JAR file to your project, either manually, or via the following Gradle dependency:

repositories {
   mavenCentral() // Packr artifacts will be published to Maven Central in the future
   maven(uri("https://oss.sonatype.org/content/repositories/snapshots/")) // Packr snapshot artifacts will be published to Maven Central in the future

   // The following repositories are available until artifacts can be published to Maven Central
   maven(uri("http://artifactory.nimblygames.com/artifactory/ng-public-snapshot/"))
   maven(uri("http://artifactory.nimblygames.com/artifactory/ng-public-release/"))
}
dependencies {
   implementation("com.badlogicgames.packr:packr:3.0.3")
}

To invoke packr, you need to create an instance of PackrConfig and pass it to Packr.pack():

PackrConfig config = new PackrConfig();
config.platform = PackrConfig.Platform.Windows32;
config.jdk = "/User/badlogic/Downloads/openjdk-for-mac.zip";
config.executable = "myapp";
config.classpath = Arrays.asList("myjar.jar");
config.removePlatformLibs = config.classpath;
config.mainClass = "com.my.app.MainClass";
config.vmArgs = Arrays.asList("Xmx1G");
config.minimizeJre = "soft";
config.outDir = new java.io.File("out-mac");
config.useZgcIfSupportedOs = true;

new Packr().pack(config);

macOS notarization and entitlements

The following entitlements when signing the PackrLauncher executable are known to work on macOS 10.15 (Catalina) and Java 14.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>com.apple.security.cs.allow-jit</key>
	<true/>
	<key>com.apple.security.cs.allow-unsigned-executable-memory</key>
	<true/>
	<key>com.apple.security.cs.disable-executable-page-protection</key>
	<true/>
	<key>com.apple.security.cs.disable-library-validation</key>
	<true/>
	<key>com.apple.security.cs.allow-dyld-environment-variables</key>
	<true/>
</dict>
</plist> 

If all the bundled dylibs are signed, fewer entitlements might be possible. When using Java 8, com.apple.security.cs.allow-unsigned-executable-memory, and com.apple.security.cs.disable-executable-page-protection were not needed.

Example macOS code signing and notarization command line steps

These steps assume you have an Apple developer account, have saved your Apple code signing certificate into Keychain and have generated an app-specific password for your Apple developer account, allowing you to pass your username and token as command line arguments. The example commands also assume you saved the app-specific password in your Keychain allowing these commands to run in an automated way, e.g., your CI pipeline can execute all these commands.

  1. codesign --sign <keychain id for certiticate> --verbose=10 --timestamp --force --options runtime --entitlements <path-to-entitlements-file> <path to exe or shared lib>
  2. /usr/bin/ditto -c -k --keepParent <app path> <app path>.zip
    • ditto is a commandline zip tool, any tool that creates a zip file from a directory can be used.
  3. xcrun altool --notarize-app --verbose --primary-bundle-id com.mydomain.myproduct --username '<username>' --password "@keychain:<app-specific password>" --file <app path>.zip
    • If this step fails, it will exit with a non-zero return code and provide good output as to why it failed. E.g., "You must first sign the relevant contracts online."

Optional steps, you can choose to wait for an email notification

  1. xcrun altool --notarization-history 0 -u <username> -p "@keychain:<app-specific password>" --output-format xml
    • This command grabs the history for the last call to xcrun altool --notarize-app, this will obviously fail if you're running multiple xcrun altool --notarize-app processes in parallel. You'll have to come up with a better way to parse the history.
  2. Parse the XML output for the last request UUID, regex: <string>(.*?)</string>
  3. In a loop, every minute check the notarization status.
    • xcrun altool --notarization-info <parsed uuid> -u <username> -p "@keychain:<app-specific password>"
  4. Parse the output for the status, regex: .*?Status:\s+(.*?)$
  5. When the status no longer matches in progress exit the loop.
  6. If the Status did not end up as success the output will provide a description of what went wrong.
  7. xcrun stapler staple --verbose <app path>

Minimization

Unless you're stuck with using Java 8, it's best to create a minimized JRE using jlink. See TestAppJreDist/testAppJreDist.gradle.kts for an example Gradle build script which generates JREs from downloaded JDKs.

JRE

A standard OpenJDK 8 JRE is about 91 MiB unpacked. Packr helps you cut down on that size, thus also reducing the download size of your app.

To minimize the JRE that is bundled with your app, you have to specify a minimization configuration file via the minimizejre flag you supply to Packr. A minimization configuration is a JSON file containing paths to files and directories within the JRE to be removed.

As an example, have a look at the soft profile configuration:

{
  "reduce": [
    {
      "archive": "jre/lib/rt.jar",
      "paths": [
        "com/sun/corba",
        "com/sun/jndi",
        "com/sun/media",
        "com/sun/naming",
        "com/sun/rowset",
        "sun/applet",
        "sun/corba",
        "sun/management"
      ]
    }
  ],
  "remove": [
    {
      "platform": "*",
      "paths": [
        "jre/lib/rhino.jar"
      ]
    },
    {
      "platform": "windows",
      "paths": [
        "jre/bin/*.exe",
        "jre/bin/client"
      ]
    }
  ]
}

This configuration will unpack rt.jar, remove all the listed packages and classes in com.sun.* and sun.*, then repack rt.jar again. By default, the JRE uses zero-compression on its JAR files to make application startup a little faster, so this step will reduce the size of rt.jar substantially.

Then, rhino.jar (about 1.1 MiB) and, in the JRE for Windows case, all executable files in jre/bin/ and the folder jre/bin/client/ will be removed.

Packr comes with two such configurations out of the box, soft. The hard profile removes a few more files, and repacks some additional JAR files.

The "removelibs" option

Minimization aside, packr can remove all dynamic libraries which do not match the target platform from your project JAR file(s):

platform files removed
Windows *.dylib, *.so
Linux *.dll, *.dylib
MacOS *.dll, *.so

This step is optional. If you don't need it, just remove the configuration parameter to speed up packr. This step doesn't preserve the META-INF directory or files in the jar.

Caching

Extracting and minimizing a JRE can take quite some time. When using the cachejre option, the result of these operations are cached in the given folder, and can be reused in subsequent runs of packr.

As of now, packr doesn't do any elaborate checks to validate the content of this cache folder. So if you update the JDK, or change the minimize profile, you need to empty or remove this folder manually to force a change.

Output

Windows

When packing for Windows, the following folder structure will be generated

outdir/
   myapp.exe
   myjar.jar
   myapp.json
   jre/

Linux

outdir/
   myapp
   myjar.jar
   myapp.json
   jre/

Mac OS X

outdir/
   Contents/
      Info.plist
      MacOS/
         myapp
      Resources/
         myjar.jar
         myapp.json
         jre/
         icons.icns [if config.icon is set]

You can further modify the Info.plist to your liking, e.g. add icons, a bundle identifier etc. If your output folder has the .app extension it will be treated as an application bundle by Mac OS X.

Executable command line interface

By default, the native executables forward any command line parameters to your Java application's main() function. So, with the configurations above, ./myapp -x y.z is passed as com.my.app.MainClass.main(new String[] {"-x", "y.z" }).

The executables themselves expose an own interface, which has to be enabled explicitly by passing -c or --cli as the very first parameter. In this case, the special delimiter parameter -- is used to separate the native CLI from parameters to be passed to Java. In this case, the example above would be equal to ./myapp -c [arguments] -- -x y.z.

Try ./myapp -c --help for a list of available options.

Note: On Windows, the executable does not show any output by default. Here you can use myapp.exe -c --console [arguments] to spawn a console window, making terminal output visible.

Building from source code

If you want to modify the code invoke Gradle.

$ ./gradlew clean assemble

This will create a packr-VERSION-all.jar file in Packr/build/libs directory, you may invoke as described in the Usage section above.

Gradle project structure

The Gradle build is set up as a multi-project build. In order to fully build the multi-project you must have a compatible JRE (Java 8+) and C/C++ build tools that the Gradle build can find.

DrOpt Gradle sub-project

This is a downloaded and unzipped https://github.com/jamesderlin/dropt/releases version 1.1.1 source code with a Gradle script used to build it for consumption by the PackrLauncher Gradle project. The DrOpt source required a few modifications to get it compiling, namely some explicit casting in the C code.

Packr Gradle sub-project

This is the Java code for creating application bundles that can use the native launcher executables. This project also builds the packr-all uber/shadow jar that works as an executable jar.

PackrLauncher Gradle sub-project

This contains the platform native code for loading the JVM and starting the packr bundled application.

PackrAllTestApp Gradle sub-project

This is an example Hello world style application that bundles itself using packr and is used as a high level test suite to help reduce breaking changes.

TestAppJreDist Gradle sub-project

This project downloads JDKS 8, 11, and 14 and runs jlink on the 11 and 14 versions to create minimal JREs for use by PackrAllTestApp.

Limitations

  • Only Adopt OpenJDKs 8, 11, and 15 are tested (other JDKs probably work)
  • Icons aren't set yet on Windows and Linux, you need to do that manually.
  • Minimum platform requirement on MacOS is OS X 10.10 (Only 10.15 macOS Catalina is actively tested, there are users that report 10.14 works).
  • JRE minimization is very conservative. Depending on your app, you can carve out stuff from a JRE yourself, disable minimization and pass your custom JRE to packr. If you're using Java 11+ you should create a JRE using jlink.
  • On MacOS, the JVM is spawned in its own thread by default, which is a requirement of AWT. This does not work with code based on LWJGL3/GLFW, which needs the JVM be spawned on the main thread. You can enforce the latter with adding the -XstartOnFirstThread VM argument to your MacOS packr config.

License & Contributions

The code is licensed under the Apache 2 license. By contributing to this repository, you automatically agree that your contribution can be distributed under the Apache 2 license by the author of this project. You will not be able to revoke this right once your contribution has been merged into this repository.

Security

Distributing a bundled JVM has security implications, just like bundling any other runtimes like Mono, Air, etc. Make sure you understand the implications before deciding to use this tool. Here's a discussion on the topic.

Issues
  • Mac OS X: X11 installation is required to start app

    Mac OS X: X11 installation is required to start app

    The freshly built Mac OS X app starts (Max OS X 10.9.5) lead to:

    • terminal window is opened
    • the message "X11 installation required. Install?" appears on the screen.

    Is X11 really required to start java app? Or it is a kind of bug? Just not sure that the users will do it to run a small game.

    opened by titovmaxim 38
  • Packr-generated exe prints nothing, does nothing

    Packr-generated exe prints nothing, does nothing

    I'm unsure what's causing this, but after running Packr with the command line

    java -jar packr.jar -platform windows -jdk "C:/Users/user/.lein-packr-cache/windows.zip" -executable perlin -appjar "target/perlin-0.0.1-SNAPSHOT-standalone.jar" -mainclass "perlin/core/desktop_launcher" -minimizejre "hard" -resources resources -outdir out-win32
    

    it successfully generates an exe in the directory out-win32. Running this exe in the Windows 7 64-bit command prompt with no args causes nothing to be printed, and it immediately closes. Double clicking the exe causes the cursor on Windows 7 to show the spinning circle next to it for a few seconds, but opens no windows. What could cause this?

    The JDK I'm using is from the recommended unofficial builds project (zip file link). I can run the jar with java -jar perlin-0.0.1-SNAPSHOT-standalone.jar and it displays a libgdx window and renders some perlin noise. This problem with the packed output happens whether -minimizejre is set or not, and I suspect it may be related to finding the main class, or to the structure of the unofficial build zips changing. The demo is written in Clojure using the play-clj binding to libgdx, and I was able to run Packr 1.0 on Clojure apps before, so I suspect something broke in the meanwhile. I tried this with the latest Packr link available in the Readme, and programatically with the 1.2 version on Maven Central (more on that in a bit). I did modify the soft and hard profiles as I mentioned in a comment on #18 . The non-working exe and working jar are bundled here, with a jre from Packr, so you can inspect it more closely.

    I am also trying to make a plugin for the Clojure build tool called Leiningen, so it can use Packr to bundle JREs as part of a build step. My code for this plugin (which is in Clojure, but very small right now) is available on my Github. Generating anything programatically suffered the same fate as running Packr manually.

    I'm at a loss for what to do here. The output it generates is totally normal:

    Unpacking JRE
    SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
    SLF4J: Defaulting to no-operation (NOP) logger implementation
    SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
    copying resources
    minimizing JRE
    unpacking rt.jar
    packing rt.jar
    Done!
    

    But of course, it generates an exe that doesn't do anything. Does anyone have an idea what could be wrong, and whether it's on my side or a bug with Packr?

    opened by tommyettinger 32
  • Could not initialize class java.awt.Toolkit

    Could not initialize class java.awt.Toolkit

    When running the following command .\Jumpai.exe --cli --console --verbose I get:

    Changing working directory to C:\Users\Winter\Desktop\Jumpai-0.0.0-Windows ...
    Loading JVM runtime library ...
    Added DLL search directory C:\Users\Winter\Desktop\Jumpai-0.0.0-Windows\jre\bin
    Added DLL search directory C:\Users\Winter\Desktop\Jumpai-0.0.0-Windows\jre\bin\server
    Passing VM options ...
    versionInformation.dwMajorVersion=10, versionInformation.dwMinorVersion=0, versionInformation.dwBuildNumber=19042
    isZgcSupported()=1, hasJsonValue(jsonRoot, "useZgcIfSupportedOs", sajson::TYPE_TRUE)=0
    versionInformation.dwMajorVersion=10, versionInformation.dwMinorVersion=0, versionInformation.dwBuildNumber=19042
    Passing VM options:
    Creating Java VM ...
    Passing command line arguments ...
    Loading JAR file ...
    Adding 1 classpaths ...
      # Jumpai.data
    Invoking static net.jumpai.client.desktop.DesktopLauncher.main() function ...
    Checked for an exception from the main method, exceptionOccurred=1
    Calling java.lang.Thread#dispatchUncaughtException(Throwable) on main thread
    Exception in thread "main" java.lang.NoClassDefFoundError: Could not initialize class java.awt.Toolkit
            at java.desktop/java.awt.Component.<clinit>(Component.java:621)
            at net.jumpai.client.desktop.DesktopLauncher.main(DesktopLauncher.java:34)
    Destroyed Java VM ...
    Press ENTER key to exit.
    

    I'm using AdoptOpenJDK 11 LTS with hotspot

    My packr config is the following

    {
        "platform": "windows64",
        "jdk": "out/jdks/win64-jdk",
        "executable": "Jumpai",
        "classpath": [
            "desktop/build/libs/Jumpai.data"
        ],
        "removelibs": [
            "desktop/build/libs/Jumpai.data"
        ],
        "mainclass": "net.jumpai.client.desktop.DesktopLauncher",
        "minimizejre": "none",
        "output": "out/packr/win64"
    }
    

    (I'm not minimizing the JRE).

    This error is only happening on a fresh Windows 10 installation. On my old Windows 7, everything works fine. If I instead launch the game using .\jre\bin\java.exe -jar Jumpai.data, everything works fine. (This is using the JRE that was output by packr).

    Any idea? Does packr gets rid of java.awt despite minimizejre being unspecified? If so, how come it works when using the same JRE and not the .exe?

    bug 
    opened by WinterAlexander 29
  • Executables for Windows32 and Windows64 do not work

    Executables for Windows32 and Windows64 do not work

    Nothing happens after building and trying to run the executable in the output directly.

    opened by littletinman 19
  • Segfault 11 on startup

    Segfault 11 on startup

    I'm trying to create a test application using packr, but when I try to launch the app it crashes out with a segmentation fault 11. I tried it with the bit.ly linked packr.jar and with a freshly built from the git repo.

    This is the json file: { "platform": "mac", "jdk": "openjdk-1.7.0-u60-unofficial-macosx-x86_64-image.zip", "executable": "test-packr", "appjar": "dist/test-packr.jar", "mainclass": "test/packr/TestPackr", "vmargs": [ "-Xmx1G" ], "outdir": "mac-test-packr.app" }

    This is the crash report:

    Process: launchd [958] Path: /Users/USER/*/mac-test-packr.app/Contents/MacOS/test-packr Identifier: com.yourcompany.identifier Version: ??? (???) Code Type: X86-64 (Native) Parent Process: launchd [223]

    Date/Time: 2014-07-16 10:15:11.561 -0400 OS Version: Mac OS X 10.7.5 (11G63) Report Version: 9

    Interval Since Last Report: 195531 sec Crashes Since Last Report: 25 Per-App Crashes Since Last Report: 11

    Crashed Thread: Unknown

    Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x00007fff5fc01028

    Backtrace not available

    Unknown thread crashed with X86 Thread State (64-bit): rax: 0x0000000000000055 rbx: 0x0000000000000000 rcx: 0x0000000000000000 rdx: 0x0000000000000000 rdi: 0x0000000000000000 rsi: 0x0000000000000000 rbp: 0x0000000000000000 rsp: 0x0000000000000000 r8: 0x0000000000000000 r9: 0x0000000000000000 r10: 0x0000000000000000 r11: 0x0000000000000000 r12: 0x0000000000000000 r13: 0x0000000000000000 r14: 0x0000000000000000 r15: 0x0000000000000000 rip: 0x00007fff5fc01028 rfl: 0x0000000000010203 cr2: 0x00007fff5fc01028 Logical CPU: 2

    Binary images description not available

    External Modification Summary: Calls made by other processes targeting this process: task_for_pid: 1 thread_create: 0 thread_set_state: 0 Calls made by this process: task_for_pid: 0 thread_create: 0 thread_set_state: 0 Calls made by all processes on this machine: task_for_pid: 5194 thread_create: 1 thread_set_state: 0

    Model: MacBookPro10,1, BootROM MBP101.00EE.B02, 4 processors, Intel Core i7, 2.6 GHz, 16 GB, SMC 2.3f36 Graphics: NVIDIA GeForce GT 650M, NVIDIA GeForce GT 650M, PCIe, 1024 MB Graphics: Intel HD Graphics 4000, Intel HD Graphics 4000, Built-In, 512 MB Memory Module: BANK 0/DIMM0, 8 GB, DDR3, 1600 MHz, 0x80AD, 0x484D5434314753364D465238432D50422020 Memory Module: BANK 1/DIMM0, 8 GB, DDR3, 1600 MHz, 0x80AD, 0x484D5434314753364D465238432D50422020 AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0xEF), Broadcom BCM43xx 1.0 (5.106.198.19.22) Bluetooth: Version 4.0.8f17, 2 service, 18 devices, 1 incoming serial ports Network Service: Wi-Fi, AirPort, en0 Serial ATA Device: APPLE SSD SM512E, 500.28 GB USB Device: hub_device, 0x8087 (Intel Corporation), 0x0024, 0x1a100000 / 2 USB Device: FaceTime HD Camera (Built-in), apple_vendor_id, 0x8510, 0x1a110000 / 3 USB Device: hub_device, 0x8087 (Intel Corporation), 0x0024, 0x1d100000 / 2 USB Device: hub_device, 0x0424 (SMSC), 0x2512, 0x1d180000 / 3 USB Device: Apple Internal Keyboard / Trackpad, apple_vendor_id, 0x0262, 0x1d182000 / 5 USB Device: BRCM20702 Hub, 0x0a5c (Broadcom Corp.), 0x4500, 0x1d181000 / 4 USB Device: Bluetooth USB Host Controller, apple_vendor_id, 0x8286, 0x1d181300 / 7

    opened by petriborg 16
  • Can't start new processes on MacOS with .app

    Can't start new processes on MacOS with .app

    When using ProcessBuilder, one cannot start a new process within a .app packaged by packr. The same code, run from the same embedded JRE directly, actually can start the processes.

    starting the process throws an IOException with error number 2 or 20, error=2, No such file or directory, both seem to be from posix.

    enhancement 
    opened by idontusenumbers 15
  • Can't run Java 8 on Windows 10 x64 without Windows SDK?

    Can't run Java 8 on Windows 10 x64 without Windows SDK?

    I have a near vanilla Windows 10 VM that cannot run any of the executables with Java 8u111. Running with the console shows

    Loading JVM runtime library ...
    Error code [126]: The specified module could not be found.
    Error: failed to load VM runtime library!
    Press ENTER key to exit.
    

    Things I've tried

    • Verified I'm using the windows64 platform with 64-bit JREs
    • Tried both Oracle JRE and OpenJDK
    • Verified jre\bin\server\jvm.dll exists
    • Installed VC 2013 and 2015 x64 Redistributable (reset to previous snapshot between tries)
    • Searched packr documentation for any Windows runtime dependencies
    • Watched Process Monitor although I'm not sure what I should be looking for
    • No minimize and soft minimize

    The only thing that did work is installing the Windows SDK as specified in #49 . However I clearly can't install that on every users machine. What exactly is required to be installed on a vanilla Windows machine to run the executable?

    Config below

    {
        "platform": "windows64",
        "jdk": "/home/leon/jre-extract/java-1.8.0-openjdk-1.8.0.111-1.b15.ojdkbuild.windows.x86_64.zip",
        "executable": "brailleblaster-packr",
        "classpath": [
            "brailleblaster.jar"
        ],
        "mainclass": "org.brailleblaster.Main",
        "output": "out-packr-win"
    }
    
    opened by TheLQ 14
  • Mac non executable app / cannot launch

    Mac non executable app / cannot launch

    Hallo,

    I'm using packr to pack a jar for osx but can't get it working. Im using the equivalent config with win/linux which work but the resulting osx program isn't working. I tried with a minimal java program (no dependancies etc) and it still didnt work. When i manually launch the executable in Contents/MacOS/ i get up a terminal which goes until "Invoking static mainPackage.AppMain.main() function..." and then nothing happens, it stops there and i can only force terminate the program. (if I add .app extension to the Contents folder and then launch the MacOS/ executable i get "Error: failed to load configuration: config.json"). Otherwise for win/linux packr performed great and is a really handy and flexible packaging tool.

    Any help is deeply appreciated, thanks

    Macbook air - version 10.10.5

    opened by mtsamis 11
  • jspawnhelper execute permissions

    jspawnhelper execute permissions

    If the jre/lib/jspawnhelper executable doesn't have execute permissions, calling Runtime.exec, Process.start, etc. will fail. This patch sets jspawnhelper to executable after jre extraction.

    opened by karlsabo 10
  • Embedded JVM not used

    Embedded JVM not used

    Hello,

    I started using your application, and I seem to have finally found the way to distribute my Java application on OSx as well, without forcing users to install a whole JVM. I am currently facing only a (hopefully) last problem, which I am sure you can help me fixing. The problem happens only on MACOSx. I embedded the openjdk 1.7_u45_x86-64_OSx in my application, and I am currently able to fully run my application from command line (using a bash script similar to the one suggested in a previous discussion). Actually, I am stucked because of the following problem:

    1 - if I call the script from Info.plist (set as Executable file), the application is not able to start, actually it seems to completely ignore the embedded JVM and it tries to use the JVM 1.6 which was installed on OSx (10.10.5). When doing the same thing on 10.11 El Capitan, I am prompted for installing the JRE

    2 - I wanted to try recompiling the native packr for OSx, but when I try to run the build-mac.sh script, the system complains that no Xcode project is found in the specified directory.

    So, actually my questions are the following:

    1 - can you help me understanding why the script works fine when launched from command line, while it fails when double clicking on the .app?

    2 - can you tell me what I should do to recompile the packr_mac with the suggested modification?

    Thank you very much,

    Lorenzo

    opened by lorenberg 9
  • Splash screen in Packr on macOS

    Splash screen in Packr on macOS

    Hi, Build platform: Ubuntu focal fossa 20.0.4.3 LTS Test platform: macOS Catalina and Big Sur Packr: release version 4.0.0 build jdk: adoptopenjdk 11.0.x packed jre: adoptopenjdk 11.0.x

    (This refers also to issue #65 :Some ambiguity with vmargs in config.json)

    I build my java jar for Linux, Windows and macOS with the splashscreen functionality from java itself, as that is the easiest. On macOS I use packr v4 recently (I could not make it work with v3, maybe my fault). Before that I created a bundle manually and use a script to start the app with java -jar jExifToolGUI.jar with some vmargs. That showed the splashscreen. (my app is jExifToolGUI in case you're interested or in case it matters) Now with pack 4.0.0, even with my builtin java splashscreen, it doesn't work. If I double-click the the app, it doesn't show the splash screen. If I do an open jExifToolGUI.app, it doesn't show the splash screen. If I do an ./jExifToolGUI.app/Contents/MacOS/jexiftoolgui, it doesn't show the splash screen. If I do a 'java -jar jExifToolGUI.app/Contents/Resources/jExifToolGUI.jar`, I do get the splash screen.

    I already created a jexiftoolgui.json with or without a vmargs splash:my_splash_screen and splash:my_splash_screen.png (although the latter with extension should not be needed) and adding the png to my bundle, but that doesn't work either, which is of course in ling with issue #65. I understand the explanation in issue #65, but why does the Packr binary block my java builtin splash screen?

    (It does work on Windows (using launch4j), it works using a .deb and an AppImage, or simply using java -jar ...)

    question 
    opened by hvdwolf 7
  • please help me

    please help me

    The first time the software is normal, the second time the software crashes, the file resources are too large

    download

    # jdk17
    wget https://download.oracle.com/java/17/latest/jdk-17_macos-x64_bin.tar.gz
    # packr
    wget -O packr.jar https://github.com/libgdx/packr/releases/download/4.0.0/packr-all-4.0.0.jar
    # Behinder
    wget https://github.com/BeichenDream/Godzilla/releases/download/v3.03-godzilla/Godzilla.jar
    # openjfx
    wget -O openjfx-16.zip https://download2.gluonhq.com/openjfx/16/openjfx-16_osx-x64_bin-sdk.zip
    unzip openjfx-16.zip
    

    json

    {
        "platform": "mac",
        "jdk": "jdk-17_macos-x64_bin.tar.gz",
        "executable": "Godzilla",
        "mainclass": "core.ui.MainActivity",
        "classpath": [
            "Godzilla.jar"
        ],
        "vmargs": [
            "Dfile.encoding=utf-8", 
            "ParallelGCThreads=4 ", 
            "AggressiveHeap", 
            "+UseParallelGC", 
            "Xms512M",
            "Xmx1024M"
        ],
        "output": "Godzilla.app"
    }
    
    opened by ran-xing 1
  • github action support

    github action support

          - 
            name: Docker Setup Buildx
            uses: docker/[email protected]
            with:
              json: test.json
              jdk: 16
              platform: mac
              executable: test
              mainclass: core.ui.MainActivity
              classpath: test.jar
              vmargs: |
                "Dfile.encoding=utf-8",
                "ParallelGCThreads=4 ", 
                "AggressiveHeap", 
                "+UseParallelGC", 
                "Xms512M",
                "Xmx1024M"
              output: test.app
              icon: test.icns
    

    Hope to support

    opened by ran-xing 3
  • Single instance application

    Single instance application

    Hi, love this project, is there anyhow a possibility to have a flag to keep a single instance application on windows?

    enhancement 
    opened by PatrickWegmann 1
  • windows 32bit support no more present in ENUMeration

    windows 32bit support no more present in ENUMeration

    this setting is not available: config.platform = PackrConfig.Platform.Windows32;

    the enum for platform is here, and it's only Window64 https://github.com/libgdx/packr/blob/master/Packr/src/main/java/com/badlogicgames/packr/PackrConfig.java

    opened by naarani 1
  • JNI Version 9 and 10

    JNI Version 9 and 10

    It appears that packr currently supports only JNI Version 6 and 8

    https://github.com/libgdx/packr/blob/9c9bb9d050524eec58acddfca85e606fbab31637/PackrLauncher/src/main/cpp/packr.cpp#L582-L590

    https://github.com/libgdx/packr/blob/9c9bb9d050524eec58acddfca85e606fbab31637/PackrLauncher/src/main/headers/packr.h#L23-L25

    But there are now two newer versions (link). JNI_VERSION_10 is used for Java 10 through to at least 17.

    #define JNI_VERSION_9   0x00090000
    #define JNI_VERSION_10  0x000a0000
    

    I haven't encountered any problems with this so far, but I know that I did need to set "jniVersion": 8 in my config.json. For people upgrading to newer JVMs, if you are encountering issues with JNI, you might want to investigate here.

    opened by nedtwigg 2
  • vmArgs argument header needs its arguments to lead with `-`

    vmArgs argument header needs its arguments to lead with `-`

    The documentation claims that arguments header vmArgs should not have a leading -, but my testing shows that is incorrect, and they do need to have a leading -.

    opened by nedtwigg 3
  • Installed JRE is used instead of bundled JRE

    Installed JRE is used instead of bundled JRE

    I'm developing a game and using packr to bundle it (it is a very useful tool so first of all thank you!).

    The issue I am having is regarding windows-64 users who already have Java installed. When they execute the packr bundled .exe their local Java is used instead to run the JAR instead of the bundled JRE as expected.

    I know this is happening because:

    • users who were receiving a blank screen when executing the game were able to fix this by updating their local Java version
    • I can reproduce the error user are seeing by executing the JAR with their version of java.

    Any help would be appreciated, thank you.

    Here are my settings:

    java -jar packr-all.jar --platform windows64 --jdk "[JDK PATH]" --useZgcIfSupportedOs --executable [NAME] --classpath [NAME].jar --mainclass [NAME].Main --output out-windows

    opened by jdonkers 1
  • PACKR Issue building on Catalina

    PACKR Issue building on Catalina

    PROBLEM: Modern PACKR releases (4.0, 3.0)+ do not create functional (unsigned) LibGDX apps for Catalina ENVIRONMENT: We can reproduce this on builds from multiple Macs (Catalina and Big Sur) as well as from Windows 10 WORKAROUND: We have found an older (pre-2020) version of PACKR that works correctly

    Summary

    Unsigned LibGDX applications built by the current version of PACKR on Catalina do not run. They quit immediately with the crash error

    # Problematic frame:
    # C  [AppKit+0x3e5abc]  -[NSOpenGLContext setView:]+0xe5
    

    This is a known issue with Catalina where the OpenGL context is accessed outside the main frame, and introduced by how Catalina manages security. This is a problem introduced by PACKR, since the original JAR files run normally.

    We did not have this problem last year (I use PACKR for a course). Indeed when we revert to our older version of PACKR, it successfully creates applications for Catalina. I have no idea which version of PACKR that is, but when I expand the JAR file I see that it was built on March 19, 2019. So I suspect it may be 1.2.

    From research on the Internet (and the build date of the older version of PACKR), I think the problem is with the Mac SDK used to build the executables used by PACKR. I refer you to this thread for a similar issue with JOGAMP:

    https://jogamp.org/bugzilla//show_bug.cgi?id=1398

    In that case error was introduced by using the default Catalina SDK 'macosx10.15'. Use of an older SDK, such as 'macosx10.11' (even on Catalina or Big Sur Macs) caused the error to disappear.

    We have not verified whether or not this problem goes away when you sign the app with a MacOS Developer Certificate. But ideally this should not be required for informal LibGDX distribution.

    question 
    opened by WalkerWhite 34
  • Reflection Issue When Packing Jar

    Reflection Issue When Packing Jar

    WARNING: sun.reflect.Reflection.getCallerClass is not supported. This will impact performance.

    AdoptOpenJDK 15.0.2 Packr version: 4.0.0 Occurs when packaging Windows, Linux, or Mac. Imports: LibGdx 1.9.14 base packages.

    I've been looking around - it seems that this can be fixed with adding a multi-build attribute to the .pom file.

    opened by farnorthgames 0
Releases(4.0.0)
Owner
libgdx
libgdx
A fast build system that encourages the creation of small, reusable modules over a variety of platforms and languages.

Buck Buck is a build tool. To see what Buck can do for you, check out the documentation at http://buck.build/. Installation Since Buck is used to buil

Facebook 8.2k Dec 4, 2021
a fast, scalable, multi-language and extensible build system

Bazel {Fast, Correct} - Choose two Build and test software of any size, quickly and reliably. Speed up your builds and tests: Bazel rebuilds only what

Bazel 17.7k Dec 6, 2021
Documentation and issues of https://jitpack.io

JitPack.io JitPack is a novel package repository for JVM and Android projects. It builds Git projects on demand and provides you with ready-to-use art

JitPack 2.2k Dec 6, 2021
Packages your JAR, assets and a JVM for distribution on Windows, Linux and Mac OS X

About 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 nativ

libgdx 2.3k Nov 21, 2021
:package: Gradle/Maven plugin to package Java applications as native Windows, Mac OS X, or GNU/Linux executables and create installers for them.

JavaPackager JavaPackager is a hybrid plugin for Maven and Gradle which provides an easy way to package Java applications in native Windows, Mac OS X

Francisco Vargas Ruiz 425 Nov 30, 2021
Jansi is a small java library that allows you to use ANSI escape sequences to format your console output which works even on windows.

Description Jansi is a small java library that allows you to use ANSI escape codes to format your console output which works even on Windows. It also

FuseSource 858 Nov 30, 2021
Bouncy Castle Java Distribution (Mirror)

The Bouncy Castle Crypto Package For Java The Bouncy Castle Crypto package is a Java implementation of cryptographic algorithms, it was developed by t

Legion of the Bouncy Castle Inc 1.6k Dec 6, 2021
Tencent Kona JDK11 is a no-cost, production-ready distribution of the Open Java Development Kit (OpenJDK), Long-Term Support(LTS) with quarterly updates. Tencent Kona JDK11 is certified as compatible with the Java SE standard.

Tencent Kona JDK11 Tencent Kona JDK11 is a no-cost, production-ready distribution of the Open Java Development Kit (OpenJDK), Long-Term Support(LTS) w

Tencent 197 Nov 25, 2021
Your Software. Your Structures. Your Rules.

jQAssistant Master Repository We splitted jQAssistant in multiple single repositories to be able to build a better and more flexible build an release

null 168 Nov 4, 2021
A Java 8+ Jar & Android APK Reverse Engineering Suite (Decompiler, Editor, Debugger & More)

Bytecode Viewer Bytecode Viewer - a lightweight user friendly Java Bytecode Viewer. New Features WAR & JSP Loading JADX-Core Decompiler Fixed APK & de

Kalen (Konloch) Kinloch 12.6k Nov 30, 2021
MariaDB Embedded in Java JAR

What? MariaDB4j is a Java (!) "launcher" for MariaDB (the "backward compatible, drop-in replacement of the MySQL(R) Database Server", see FAQ and Wiki

Michael Vorburger ⛑️ 645 Dec 7, 2021
maven plugin for making chmod +x jar files

To use it, add a plugin to your pom like <!-- You need to build an exectuable uberjar, I like Shade for that --> <plugin> <groupId>org.apache.mave

Brian McCallister 104 Nov 26, 2021
Buildable src reconstructed from the clean Phobos 1.9.0 jar

CLEAN_Phobos_1.9.0-BUILDABLE-SRC Buildable src reconstructed from the clean Phobos 1.9.0 jar. Full buildable and functional, jar in releases is built

null 57 Nov 26, 2021
spring boot Fat Jar 应用文件上传漏洞到 RCE 的利用技巧

spring-boot-upload-file-lead-to-rce-tricks 一. 原理文章 Spring Boot Fat Jar 写文件漏洞到稳定 RCE 的探索 二. docker 漏洞环境搭建 docker pull landgrey/spring-boot-fat-jar-writ

LandGrey 324 Nov 28, 2021
Pcap editing and replay tools for *NIX and Windows - Users please download source from

Tcpreplay Tcpreplay is a suite of GPLv3 licensed utilities for UNIX (and Win32 under Cygwin) operating systems for editing and replaying network traff

AppNeta, Inc. 822 Nov 22, 2021
BCC - Tools for BPF-based Linux IO analysis, networking, monitoring, and more

BPF Compiler Collection (BCC) BCC is a toolkit for creating efficient kernel tracing and manipulation programs, and includes several useful tools and

IO Visor Project 13.1k Dec 6, 2021
Performance analysis tools based on Linux perf_events (aka perf) and ftrace

perf-tools A miscellaneous collection of in-development and unsupported performance analysis tools for Linux ftrace and perf_events (aka the "perf" co

Brendan Gregg 7.9k Nov 25, 2021
💠 Undecorated JavaFX Scene with implemented move, resize, minimise, maximise, close and Windows Aero Snap controls.

Support me joining PI Network app with invitation code AlexKent FX-BorderlessScene ( Library ) ?? Undecorated JavaFX Scene with implemented move, resi

Alexander Kentros 115 Nov 27, 2021
A Linux packet crafting tool.

Pig Pig (which can be understood as Packet intruder generator) is a Linux packet crafting tool. You can use Pig to test your IDS/IPS among other stuff

Rafael Santiago 408 Nov 18, 2021
A java agent to generate method mappings to use with the linux `perf` tool

perf-map-agent A java agent to generate /tmp/perf-<pid>.map files for just-in-time(JIT)-compiled methods for use with the Linux perf tools. Build Make

null 1.4k Dec 6, 2021
PerfJ is a wrapper of linux perf for java programs.

PerfJ PerfJ is a wrapper of linux perf for java programs. As Brendan Gregg's words In order to profile java programs, you need a profiler that can sam

Min Zhou 356 Jun 20, 2021
A JavaFX UI framework to create fully customized undecorated windows

CustomStage A JavaFX undecorated stage which can fully be customized Donations If this project is helpful to you and love my work and feel like showin

Oshan Mendis 162 Dec 2, 2021
A library for JavaFX that gives you the ability to show progress on the Windows taskbar.

A clean and easy way to implement this amazing native Windows taskbar-progressbar functionality in javaFX Background Since Windows 7 there is a taskba

Daniel Gyoerffy 62 Nov 14, 2021
Decorate "Undecorated" JavaFX windows

DEPRECATED: The latest version of this project is UndecoratorBis https://github.com/in-sideFX/UndecoratorBis Undecorator Decorate undecorated Java

null 117 Oct 17, 2021
A minecraft mod that allows additional windows to be opened alongside the game

Breakout API BreakoutAPI is a Minecraft mod which allows developers to create new windows that run alongside Minecraft. All the windows run on the sam

Raph Hennessy 9 May 31, 2021
这是一个利用 Linux Crontab , Docker等方式实现哔哩哔哩(Bilibili)每日任务投币,点赞,分享视频,直播签到,银瓜子兑换硬币,漫画每日签到,简单配置即可每日轻松获取 65 经验值,快来和我一起成为 Lv6 吧~~~~

BILIBILI-HELPER 工具简介 这是一个利用 Linux Crontab ,云函数, Docker 等方式实现哔哩哔哩(Bilibili)每日任务投币,点赞,分享视频,直播签到,银瓜子兑换硬币,漫画每日签到,简单配置即可每日轻松获取 65 经验值,快来和我一起成为 Lv6 吧~~~~ 如果

Junzhou Liu 260 Sep 29, 2021
A cracked Minecraft launcher for Linux

Usage Usage: ./run.sh Usage for the first time: ./run.sh <game directory> <player name (optional)> Building Prerequisites Java 16 (for Minecraft and t

null 4 Sep 7, 2021
A project to cause (controlled) destruction on your jvm application

Perses Cause (controlled) destruction to your jvm application Perses (Ancient Greek: Πέρσης) was the Titan god of destruction. His name is derived fro

Nikolaos Kanakis 55 Nov 21, 2021