Recent changes to bugs

#241 Java 25 is not detected

2025-10-26T08:02:36.282000Z

FYI: The version 25.0.1 is correctly detected. Perhaps it is just a problem with the comparison operator "greater than" or "greater than or equal to".

Java 25 is not detected

2025-09-29T12:28:19.639000Z

Hello,

there appears to be a problem detecting Java version 25. If the current version 25.0.0 is specified as the minimum version, the application will not start. The log file reads:

Version:    3.50
CmdLine:    D:\02_JAG3D\01_JAG3DvFX\JAG3Dv20250829\JAG3Dv20250829_Windows\jag3d.exe --l4j-debug
JNI:        No
WOW64:      Yes
Working dir:    D:\02_JAG3D\01_JAG3DvFX\JAG3Dv20250829\JAG3Dv20250829_Windows\.
Requires JDK:   No
Requires 64-Bit: Yes
Java min ver:   1.025.000_000
Java max ver:   
JRE paths:  openjdk\
Check launcher: D:\02_JAG3D\01_JAG3DvFX\JAG3Dv20250829\JAG3Dv20250829_Windows\openjdk\bin\javaw.exe (OK)
Version string: 1.025.000 / 64-Bit (Ignore)
64-bit search:  SOFTWARE\JavaSoft\Java Runtime Environment...
64-bit search:  SOFTWARE\JavaSoft\Java Development Kit...
64-bit search:  SOFTWARE\JavaSoft\JRE...
64-bit search:  SOFTWARE\JavaSoft\JDK...
Check:      SOFTWARE\JavaSoft\JDK\25
Version string: 1.025.000 / 64-Bit (Ignore)
Ignore:     1.025.000
64-bit search:  SOFTWARE\IBM\Java Runtime Environment...
64-bit search:  SOFTWARE\IBM\Java Development Kit...
64-bit search:  SOFTWARE\IBM\Java2 Runtime Environment...
64-bit search:  SOFTWARE\IBM\Java Development Kit...
Error msg:  This application requires a Java Runtime Environment 25.0.0 (64-bit)
Error:      Die Pipe wurde beendet.

Reagds
Micha

`ld` does not find the header objects and libraries when they are not relative to the JAR file

2025-08-01T12:40:47.712000Z

I have a Gradle task that executes Launch4j.
I use the Ant integration in Gralde for that.
I'd like to use the Launch4j and dependency JAR files directly from the Gradle dependencies cache.
For this I unpack the respective workdir artifact and set the launch4j.bindir system property so that windres and ld are found in that unpacked directory while the Launch4j jar is used from the original location.

The problem is, that this only affects where windres and ld are searched in. The windres call succeeds, but then the ld call fails as it given the header and library files relative to the jar containing the Util class still.

It would be nice if this could work somehow.
For example by specifying also that directory, or by being able to configure the whole basedir instead of the bindir.
Builder has a constructor that accepts a whole basedir, but it is used nowhere in the source code.

So I'd like to ask for a way to configure the basedir when calling the Ant task so that not only the executable, but also the header and library files are taken from there.

Please consider to make this an Ant task property (and also bindir) and not a System property (or additionally). If you use Launch4j from within another software, like the Gradle daemon and maybe even run things in parallel, using system properties is always building a race condition.

#190 Dual-signing sometimes result in a corrupted jar file error

2025-06-26T17:56:36.112000Z

After testing, I was able to verify the root cause I suspected earlier: the size of the appended signature can change from one run to the next. Timestamping could be a contributing factor.

Fortunately, the size isn't completely unstable; it usually differs by a few bytes, and toggles between two (or occasionally three) possibilities. This makes it feasible to produce a successful signature by iterating until the sizes match in two consecutive runs.

I took a look at modifying the original sign4j.c program, but C isn't my forte. Since all users of launch4j are Java developers anyway, I wrote a Java version of the sign4j utility that includes a fix for this bug. I took care to make sure I was command-line compatible with the original C version, so it works as a drop-in replacement. I also added an Ant task. I've published it here: https://github.com/dtuma/sign4j-java

#190 Dual-signing sometimes result in a corrupted jar file error

2025-06-09T21:33:30.410000Z

I've been experiencing this too. Unfortunately it is nondeterministic; sometimes it works and sometimes it doesn't. When it works the file is signed successfully; when it doesn't, running the EXE results in an error message "Invalid or corrupt jarfile" from the launched javaw.exe process. Nothing in my build process changes; I can run the build again, and it might work the next time or it might not. Overall my success rate is only about 50%.

The worst problem is that I can't detect this failure in my build process. The sign4j step completes successfully and returns a 0 exit code. I have to go back at the end of the build and manually run all the EXEs that were generated to see if they are corrupt. Then resign the corrupt files again, manually repeating and testing in a loop, until I get a version that isn't corrupt.

I'm using jsign version 7.0 (not the 2.0 version bundled in launch4j) because I needed support for Azure Trusted Signing. If it helps, I can share a copy of the unsigned exe that launch4j produced (which works fine) along with corrupt and successful versions produced by sign4j.

With empty classpath process cannot start

2025-06-03T18:24:23.734000Z

When not specifying a classpath, or when specifying a pattern like lib/*.jar and it does not find any matches, the built commandline contains the -classpath parameter with a single double-quote as argument which fails to start.

As a work-around, a dummy entry that does not contain wildcards can be specified as non-existing classpath entries are ignored by the JRE as per the Java spec.

The standard classpath wildcard should not get expanded

2025-06-03T17:51:07.975000Z

If you specify in the l4j configuration as classpath lib/*, l4j expands this to all entries in the directory, including . and ...

If you give lib/* as classpath entry to the Java process, this means "all jars in that directory".

IF the filename only consists of the standard Java wildcard *, this should not get expanded, but forwarded as-is to the Java process.

Besides being unexpected as it puts things on the classpath it shouldn't put there, this also has a practical consequence. With non-exe means to start an application, like a batch script, it happens that the commandline becomes too long for Windows if you list each jar manually, which can be prevented by either using an @-file if the JRE supports it, or by using the wildcard if you don't depend on the classpath order which is bad anyway.

I don't know whether l4j has measures for too long command lines like using an @-file or similar, or whether it does anyway not have that problem no matter how long the commanline becomes, but it imho is wrong to expand this standard-wildcard.

The work-around to get expected behavior is to use .../*.jar instead of .../* as long as the length limit does not get hit.

#237 Ticket 232 (JAVA_TOOLS_OPTIONS bug) was not properly fixed nor was it closed

2024-12-20T16:24:54.424000Z

After my tests, I think there is a java for windows bug that manifests only when JNI_CreateJavaVM. I think a reasonable workaround for the bug is to strip bounding characters (if they're used) before calling JNI_CreateJavaVM in jnihead.c.

Ticket 232 (JAVA_TOOLS_OPTIONS bug) was not properly fixed nor was it closed

2024-12-20T15:41:00.576000Z

Ticket 232 describes a problem with interpreting the environment variable JAVA_TOOLS_OPTIONS. It describes how version 3.5 abnormally terminates if the variable's value is bounded by the apostrophe character. In 3.50, presently the latest version, using the apostrophe character works as a bounding character.

However, the obvious bounding character, the quote, is a problem. Perhaps, it was a problem in 3.5 but nobody properly tested that version.

At any rate, the launcher terminates without any fanfare. I can't tell from the lauch4j.log file if it launched the jvm and the jvm died or if it died after writing a seemingly normal log file.

But I do know that if I set JAVA_TOOLS_OPTIONS and run a hello world from a java 21 command line that the JVM has no problem printing the "Picked up ..." message whether. So the problem has to be somewhere in the launcher.

#232 3.5 crash with JAVA_TOOL_OPTIONS containing quotes

2024-12-20T15:32:45.568000Z

With version 3.50, I have no problem if apostrophes are used but I do have a problem with quotes are used. Of course, neither apostrophes nor quotes are necessary but some people don't care.

These work in 3.50
set JAVA_TOOL_OPTIONS='something in the way'

This also works in 3.50 but it's DOS insanity
set JAVA_TOOL_OPTIONS=something in the way

This does not work in 3.50
set JAVA_TOOL_OPTIONS="something in the way"