Not compatible with Capsule.io jars but with Workaround

[shoon]

Summary: packr appears to extract/recompress the Capsule fat jar in the classPath and it no longer loads. Replacing the generated output jar with the original will return the Capsule functionality and the generated native executable is able to run it.

Tested environment:

• Windows 10 Enterprise x86_65
• Java 8u101 x86_64
• Latest downloaded Packr.jar
• Latest capsule-maven (from sg.enixsoft)

My current build process has Capsule build a fat jar to include all dependencies including the signed BouncyCastle provider. When I use packr on this jar file, it appears to modify the capsule.jar such that it no longer runs with java -jar name_of_capsule.jar . Here are the steps to recreate with a known good capsule.jar file (in this example ecc-tester-java-0.1-SNAPSHOT-capsule.jar)

java -jar packr.jar --platform windows64 --jdk jre\winx86_64\jdk1.8.0_101.zip --executable ecc_test_packr --mainclass Capsule --classpath jar\ecc-tester-java-0.1-SNAPSHOT-capsule.jar --output output --vmargs Xmx1G --verbose
Cleaning output directory 'D:\work\shoon\temp\installer\output' ...
Copying executable ... 
Copying classpath(s) ...
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.
Removing foreign platform libs ...
  # Unpacking 'jar\ecc-tester-java-0.1-SNAPSHOT-capsule.jar' ...
  # Repacking 'jar\ecc-tester-java-0.1-SNAPSHOT-capsule.jar' ...
  #3076 kb -> 3076 kb
Done!

Changing into the output directly, run the generated exe. Since there is no console log on windows send to log (native.exe > log) and see that it exits immediatly after invoking the Capsule class:

Loading JVM runtime library ...
Passing VM options ...
  # -Xmx1G
Creating Java VM ...
Passing command line arguments ...
Loading JAR file ...
Invoking static Capsule.main() function ...

Attempt to run the output jar file exhibits the same behavior - it simply exits

java -jar ecc-tester-java-0.1-SNAPSHOT-capsule.jar

Now I replaced that jar file with the original/source capsule jar to do a sanity check

 java -jar ecc-tester-java-0.1-SNAPSHOT-capsule.jar
...APPLICATION LOG STARTS HERE

Now that the jar is working again, retest the generated exe (but still no console output, have to send to a log (native.exe > log))

java -jar ecc-tester-java-0.1-SNAPSHOT-capsule.jar
Loading JVM runtime library ...
Passing VM options ...
  # -Xmx1G
Creating Java VM ...
Passing command line arguments ...
Loading JAR file ...
Invoking static Capsule.main() function ...
...APPLICATION LOG STARTS HERE

Final note: The original capsule jar file and the packr output jar file have binary diffs but extracting them (using 7zip) shows no internal differences.

[code-disaster]

Out of interest, what happens if you unpack and repack your JAR manually, using 7zip? Does it still run afterwards?

[shoon]

Extracting and then creating the known-working jar with 7zip did not work. I tried all compression levels from Store to Ultra with no successful result, Here's my environment:

• 7-Zip 16.02 (64-bit)
• JDK/JRE 1.8u101

[code-disaster]

I do not know how Capsule works, but this sounds like this is creating some non-trivial JAR archive. My only idea so far is to add a packr option to opt out of the step of un-/re-packing the JAR. This is only done right now to delete native libraries not matching the target platform.

[shoon]

I think that would be a valid option.

[stolp]

Capsule uses System.exit() when the wrapped program terminates. This may be reason for the abrupt termination you notice here.

Please have a look at puniverse/capsule#107 for more details.

[karlsabo]

Packr shouldn't repackage your JAR file unless you specified removelibs, e.g. --removelibs myapp.jar. Please try the latest version of packr and create a new issue if you're still running into issues.