I have a set of five applications which use a common launch4j configuration. Four of them generate working executables. One does not. The one that does not also fails to parse as a ZIP file using the built-in Java zip libs, nor does it parse with the MS Windows zip libs.
EDIT: Apache Commons-Compress yielded a more descriptive error:
java.util.zip.ZipException: archive's ZIP64 end of central directory locator is corrupt.
at org.apache.commons.compress.archivers.zip.ZipFile.positionAtCentralDirectory64(ZipFile.java:826)
at org.apache.commons.compress.archivers.zip.ZipFile.positionAtCentralDirectory(ZipFile.java:805)
at org.apache.commons.compress.archivers.zip.ZipFile.populateFromCentralDirectory(ZipFile.java:529)
at org.apache.commons.compress.archivers.zip.ZipFile.<init>(ZipFile.java:217)
at org.apache.commons.compress.archivers.zip.ZipFile.<init>(ZipFile.java:193)
at org.apache.commons.compress.archivers.zip.ZipFile.<init>(ZipFile.java:165)
at com.handshape.dimensions.ziptest.Main.main(Main.java:17)
Last edit: Joshua Turner 2016-05-26
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just to make sure, were you able to parse the jar before wrapping it with launch4J? As a temporary solution you can create a launcher without wrapping the jar.
Grzegorz
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have a set of five applications which use a common launch4j configuration. Four of them generate working executables. One does not. The one that does not also fails to parse as a ZIP file using the built-in Java zip libs, nor does it parse with the MS Windows zip libs.
Execution yields:
(With the real name of the application masked for client confidentiality reasons.)
The resultant file does have the full byte stream of the JAR from which it was made starting at offset 0xb800.
Output of --l4j-debug-all follows:
`Version: 3.8
CmdLine: C:\Users\jturner\Desktop\Cataloguer.exe --l4j-debug-all
WOW64: yes
Resource 101: An error occurred while starting the application.
Resource 2: 1.8.0
Resource 18: 1
Resource 30: 2
64-bit search: SOFTWARE\JavaSoft\Java Runtime Environment...
32-bit search: SOFTWARE\JavaSoft\Java Runtime Environment...
Check: SOFTWARE\JavaSoft\Java Runtime Environment\1.8
Ignore: 1.8
Check: SOFTWARE\JavaSoft\Java Runtime Environment\1.8.0_91
Check launcher: C:\Program Files (x86)\Java\jre1.8.0_91\bin\java.exe (OK)
Match: 1.8.0_91
64-bit search: SOFTWARE\JavaSoft\Java Development Kit...
32-bit search: SOFTWARE\JavaSoft\Java Development Kit...
Runtime used: 1.8.0_91 (32-bit)
Resource 20: 32
Resource 26: 10
Heap -Xms: Requested 0 MB / 10%, Available: 1432 MB, Heap size: 143 MB
Resource 28: 90
Heap limit: Reduced 1289 MB heap size to 32-bit maximum 1024 MB
Heap -Xmx: Requested 0 MB / 90%, Available: 1432 MB, Heap size: 1024 MB
Resource 17: true
Resource 15: the.real.fully.qualified.package.App
Info: Classpath not defined.
Launcher: C:\Program Files (x86)\Java\jre1.8.0_91\bin\java.exe
Launcher args: -Xms143m -Xmx1024m -classpath "C:\Users\jturner\Desktop\Cataloguer.exe" the.real.fully.qualified.package.App
Args length: 112/32768 chars
Exit code: 1
EDIT: Apache Commons-Compress yielded a more descriptive error:
java.util.zip.ZipException: archive's ZIP64 end of central directory locator is corrupt.
at org.apache.commons.compress.archivers.zip.ZipFile.positionAtCentralDirectory64(ZipFile.java:826)
at org.apache.commons.compress.archivers.zip.ZipFile.positionAtCentralDirectory(ZipFile.java:805)
at org.apache.commons.compress.archivers.zip.ZipFile.populateFromCentralDirectory(ZipFile.java:529)
at org.apache.commons.compress.archivers.zip.ZipFile.<init>(ZipFile.java:217)
at org.apache.commons.compress.archivers.zip.ZipFile.<init>(ZipFile.java:193)
at org.apache.commons.compress.archivers.zip.ZipFile.<init>(ZipFile.java:165)
at com.handshape.dimensions.ziptest.Main.main(Main.java:17)
Last edit: Joshua Turner 2016-05-26
Just to make sure, were you able to parse the jar before wrapping it with launch4J? As a temporary solution you can create a launcher without wrapping the jar.
Grzegorz
I've confirmed that the JAR parses fine without launch4j. I'll try the temp solution and see if it meets requirements at this end.