[gui][unstable] Windows EXE versions do nothing when started

[jpstotz]

Issue details

Starting with commit b85900a the generated Jadx-GUI exe version does nothing when executed.

My guess is that this is caused by the isZip64 = true in jadx-gui/build.gradle.kts.
A post on Stackoverflow describes a similar behavior, also caused by enabling zip64 support for the shadowJar task and launch4J

Java version

latest unstable

Affected Builds

• jadx-gui-r2197.09fa35f-with-jre-win
• jadx-gui-r2197.09fa35f-no-jre-win.exe

OS

• Windows

[jpstotz]

The problem doesn't seem to be the Launch4j but the used Java runtime. Launch4j just generates a comand-line that is executed like this:

"C:\Path\to\java.exe" -Xms873m -Xmx12233m -Xms128M -XX:MaxRAMPercentage=70.0 -Dawt.useSystemAAFontSettings=lcd -Dswing.aatext=true -Djava.util.Arrays.useLegacyMergeSort=true -Djdk.util.zip.disableZip64ExtraFieldValidation=true -XX:+IgnoreUnrecognizedVMOptions --add-opens=java.base/java.lang=ALL-UNNAMED -classpath "C:\Path\to\jadx-gui.exe" jadx.gui.JadxGUI

Executing this command-line with Java 17 I don't get any output and nothing happens (Eclipse Adoptium Java 17).

Doing the same with Java 21 I get the output:

Error: Could not find or load main class jadx.gui.JadxGUI 
Cause: java.lang.ClassNotFoundException: jadx.gui.JadxGUI

It seems to me like Java isn't capable of loading a ZIP64 JAR file if it doesn't starts at offset 0 within the file. For regular ZIP files the Java runtime doesn't seem to have problems finding the ZIP file inside the EXE at offset 80384.

[skylot]

@jpstotz thanks for notice.
We not really need to use shadow jar inside Launch4j exe, it is only needed to reduce command line length for run scripts.
I will check if we can use deps jars as is.
Although, zip64 support can be an issue elsewhere, so it is also worth checking other approaches.
One option is to use 'classpath jar' - list all deps in manifest classpath inside one jar, this effectively replace deps list in command line.

[jpstotz]

@skylot You don't have disable the shadow jar. The shadowed Jar just needs to be kept separate to the Launch4j exe. Java doesn't have problems loading a ZIP64 JAR file if it starts at offset 0 (no self-launching EXE before the JAR).

For Jadx this would required adding dontWrapJar.set(true) to the launch4j config.

Afterwards the Launch4j generated executable will start Java with classpath set to lib\jadx-gui-dev-all.jar, or we configure it manually to what we prefer using classpath property of launch4j task,.