You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
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.
@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.
@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,.
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
injadx-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
OS
The text was updated successfully, but these errors were encountered: