Recent changes to feature-requests

Can't the developer of launch4j add feature to also wrap the jre?

Anish Saini — Thu, 31 Jul 2025 17:37:46 -0000

So I found out about launch4j in 2021 while I was dreaming to make my own exucatable (.exe) apps, I stumbled apon this near perfect solution. When launch4j wraps an exe, that .exe file needs a jre folder. I my theory was that it contained the machine code dll files to run the compiled file because Java compiled code is its own language. This is so you wont need to install java if running on another pc.

So I thought what could go wrong with along with wrapping the jar file, why not also the jre files?

Fun fact: I know all this while I was just 10 years old in 2021. I felt I wasn't old enough to chat with strangers but I am now currently 14, or as of creating this chat and I thought now is the time.

I set priority to 2 because I think its really recommended but not as urgent as 1.

Support for Windows (arm64)

rednoah — Tue, 10 Sep 2024 10:21:00 -0000

launch4j is currently limited to generating x86 executables. These work fine on win32-x86 and win32-x86_64 platforms. They even work on the new win32-arm64 machines with the new snapdragon chips.

I can use the x86 launch4j executable to launch a arm64 java executable to then run my application. This too works already.

x86 translation on arm64 works surprisingly well. However, there is a 2-4 seconds startup cost on first start, presumably some x86-to-arm64 translation running, generating arm64 code and caching it somewhere. A native arm64 launch4j exe would run instantly.

Feature Request: Support the creation of x86 exe files (for x86 and x86_64) and arm64 exe files.

If the project accepts donations / hiring the developer as freelancer then I'd be happy to contribute to the project financially.

Error File locked during exe generation - Antivirus

Patrice Mancini — Tue, 08 Aug 2023 18:13:16 -0000

Hello,
For a few weeks I have intermittent issue to generate exe with launch4j due to my infrastructure.
The issue is related to the anti-virus which is locking the generated exe file between the linking and the wrapping phases.

I am getting following error:
[INFO] launch4j: Compiling resources
[INFO] launch4j: Linking
[INFO] launch4j: Wrapping
WARNING: Sign the executable to minimize antivirus false positives or use launching instead of wrapping.
[INFO] launch4j: E:\JENKINS\workspace\xxx.exe (The process cannot access the file because it is being used by another process)
[ERROR]
net.sf.launch4j.BuilderException: java.io.FileNotFoundException: E:\JENKINS\workspace\xxx.exe (The process cannot access the file because it is being used by another process)
at net.sf.launch4j.Builder.build (Builder.java:135)

It would be great if you could add some delay + retry within Builder.java at
os = new FileOutputStream(outfile, true);

To wait the .exe file to be unlocked before trying to append the .jar

Many thanks for your help.

Kind regards
Patrice

#146 Java 17 support

larsen255 — Fri, 04 Aug 2023 15:23:42 -0000

See https://launch4j.sourceforge.net/docs.html#Configuration_file
-> "Required element that groups JRE settings."

You should set it to "<path>%JAVA_HOME%;%PATH%</path>"

#146 Java 17 support

Marijus — Thu, 22 Jun 2023 14:01:29 -0000

the problem is fixed, this ticket can be closed

Java 17 support

Marijus — Wed, 21 Jun 2023 16:36:48 -0000

Hello,
I would like to request for better support for java 17.
Whenever I run launch4j from maven with this configs:

<configuration>
                            <chdir>.</chdir>
                            <headerType>gui</headerType>
                            <downloadUrl>https://docs.aws.amazon.com/corretto/latest/corretto-17-ug/downloads-list.html</downloadUrl>
                            <jar>target/${project.build.finalName}.jar</jar>
                            <outfile>${staging.dir}/${info.appName}.exe</outfile>
                            <icon>${staging.dir}/images/256.ico</icon>
                            <classPath>
                                <mainClass>${mainClass}</mainClass>
                                <jarLocation>lib</jarLocation>
                            </classPath>
                            <jre>
                                <path>$JAVA_HOME</path>
                                <bundledJre64Bit>true</bundledJre64Bit>
                                <bundledJreAsFallback>true</bundledJreAsFallback>
                                <minVersion>17</minVersion>
                                <jdkPreference>preferJdk</jdkPreference>
                                <runtimeBits>64/32</runtimeBits>
                            </jre>
                            <versionInfo>
                                <fileVersion>${info.exeVersion}</fileVersion>
                                <txtFileVersion>${info.exeVersion}</txtFileVersion>
                                <fileDescription>${project.name}</fileDescription>
                                <copyright>C</copyright>
                                <productVersion>${info.exeVersion}</productVersion>
                                <txtProductVersion>${info.exeVersion}</txtProductVersion>
                                <productName>${project.name}</productName>
                                <internalName>${project.artifactId}</internalName>
                                <originalFilename>${project.artifactId}.exe</originalFilename>
                            </versionInfo>
                        </configuration>

I get an error:

[ERROR]
net.sf.launch4j.BuilderException: Enter: JRE path
    at net.sf.launch4j.Builder.build (Builder.java:76)
    at com.akathist.maven.plugins.launch4j.Launch4jMojo.doExecute (Launch4jMojo.java:478)
    at com.akathist.maven.plugins.launch4j.Launch4jMojo.execute (Launch4jMojo.java:342)
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:126)
    at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2 (MojoExecutor.java:342)
    at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute (MojoExecutor.java:330)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:213)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:175)
    at org.apache.maven.lifecycle.internal.MojoExecutor.access$000 (MojoExecutor.java:76)
    at org.apache.maven.lifecycle.internal.MojoExecutor$1.run (MojoExecutor.java:163)
    at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute (DefaultMojosExecutionStrategy.java:39)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:160)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:105)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:73)
    at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:53)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:118)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:261)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:173)
    at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:101)
    at org.apache.maven.cli.MavenCli.execute (MavenCli.java:910)
    at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:283)
    at org.apache.maven.cli.MavenCli.main (MavenCli.java:206)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:77)
    at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke (Method.java:568)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:283)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:226)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:407)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:348)
    [ERROR] Failed to execute goal com.akathist.maven.plugins.launch4j:launch4j-maven-plugin:2.4.1:launch4j (l4j-create_installer_without_JRE) on project CryptoTool: Failed to build the executable; please verify your configuration.

Running the same code with java 11 seems to work fine. Any help with this would be much apreciated!

Executables from 3.50 crash on 64-bit system

Joel Uckelman — Sun, 18 Jun 2023 18:43:27 -0000

I have a user who can reproduce a crash every time with a launcher executable produced with 3.50, but never has a crash with a launcher executable produced the same way with 3.14. The breaking commit is fa9a7cbd.

I can't troubleshoot further myself because I can't rebuild head.o in a way that Launch4j can link correctly. I'd be happy to continue troubleshooting if I could get some assistance with doing that.

The thread where I've been working with this user is here.

#144 allow .ini or other configuration file to specify both JVM and application options

Václav Haisman — Thu, 27 Apr 2023 09:22:44 -0000

This is the same as #122.

allow .ini or other configuration file to specify both JVM and application options

Václav Haisman — Thu, 27 Apr 2023 09:19:44 -0000

I am looking for a replacement for InstallAnywhere executable for our application. Launch4j is close to being perfect but misses a feature. The InstallAnywhere executable loads a .lax file which has some properties. There is a separate property for JVM command line arguments and another property for application command line arguments which are added after -jar foo.jar. This second part is what is missing in Launch4j.

It would be nice if either the existing .l4j.ini file could be enhanced to pass these two separate sets of arguments (JVM args and separate application args). Or alternatively, if I could, e.g., say -Dlaunch4j.appargsfile=appargs.ini in .l4j.ini and have Launch4j parse this appargs.ini file and add those arguments after the -jar foo.jar .

Basically, anything that does not require me to write a separate batch file would be great.

#143 Make the jar attribute optional

Grzegorz Kowal — Wed, 30 Nov 2022 18:32:51 -0000

status: open --> accepted
assigned_to: Grzegorz Kowal