If I have a Java source file (*.java) or a class file (*.class), how can I convert it to a .exe file?
I also need an installer for my program.
javapackager
The Java Packager tool compiles, packages, and prepares Java and JavaFX applications for distribution. The javapackager command is the command-line version.
– Oracle's documentation
The javapackager utility ships with the JDK. It can generate .exe files with the -native exe flag, among many other things.
WinRun4J
WinRun4j is a java launcher for windows. It is an alternative to javaw.exe and provides the following benefits:
Uses an INI file for specifying classpath, main class, vm args, program args.
Custom executable name that appears in task manager.
Additional JVM args for more flexible memory use.
Built-in icon replacer for custom icon.
[more bullet points follow]
– WinRun4J's webpage
WinRun4J is an open source utility. It has many features.
packr
Packages your JAR, assets and a JVM for distribution on Windows, Linux and Mac OS X, adding a native executable file to make it appear like a native app. Packr is most suitable for GUI applications.
– packr README
packr is another open source tool.
JSmooth
JSmooth is a Java Executable Wrapper. It creates native Windows launchers (standard .exe) for your java applications. It makes java deployment much smoother and user-friendly, as it is able to find any installed Java VM by itself.
– JSmooth's website
JSmooth is open source and has features, but it is very old. The last release was in 2007.
JexePack
JexePack is a command line tool (great for automated scripting) that allows you to package your Java application (class files), optionally along with its resources (like GIF/JPG/TXT/etc), into a single compressed 32-bit Windows EXE, which runs using Sun's Java Runtime Environment. Both console and windowed applications are supported.
– JexePack's website
JexePack is trialware. Payment is required for production use, and exe files created with this tool will display "reminders" without payment. Also, the last release was in 2013.
InstallAnywhere
InstallAnywhere makes it easy for developers to create professional installation software for any platform. With InstallAnywhere, you’ll adapt to industry changes quickly, get to market faster and deliver an engaging customer experience. And know the vulnerability of your project’s OSS components before you ship.
– InstallAnywhere's website
InstallAnywhere is a commercial/enterprise package that generates installers for Java-based programs. It's probably capable of creating .exe files.
Executable JAR files
As an alternative to .exe files, you can create a JAR file that automatically runs when double-clicked, by adding an entry point to the JAR manifest.
For more information
An excellent source of information on this topic is Excelsior's article "Convert Java to EXE – Why, When, When Not and How".
See also the companion article "Best JAR to EXE Conversion Tools, Free and Commercial".
Launch4j
Launch4j is a cross-platform tool for wrapping Java applications distributed as jars in lightweight Windows native executables. The executable can be configured to search for a certain JRE version or use a bundled one, and it's possible to set runtime options, like the initial/max heap size. The wrapper also provides better user experience through an application icon, a native pre-JRE splash screen, a custom process name, and a Java download page in case the appropriate JRE cannot be found.
– Launch4j's website
UPDATE: GCJ is dead. It was officially removed from the GCC project in 2016. Even before that, it was practically abandoned for seven years, and in any case it was never sufficiently complete to serve as a viable alternative Java implementation.
Go find another Java AOT compiler.
GCJ: The GNU Compiler for Java can compile Java source code into native machine code, including Windows executables.
Although not everything in Java is supported under GCJ, especially the GUI components (see
What Java API's are supported? How complete is the support? question from the FAQ). I haven't used GCJ much, but from the limited testing I've done with console applications, it seems fine.
One downside of using GCJ to create an standalone executable is that the size of the resulting EXE can be quite large. One time I compiled a trivial console application in GCJ and the result was an executable about 1 MB. (There may be ways around this that I am not aware of. Another option would be executable compression programs.)
In terms of open-source installers, the Nullsoft Scriptable Install System is a scriptable installer. If you're curious, there are user contributed examples on how to detect the presence of a JRE and install it automatically if the required JRE is not installed. (Just to let you know, I haven't used NSIS before.)
For more information on using NSIS for installing Java applications, please take a look at my response for the question "What's the best way to distribute Java applications?"
You could make a batch file with the following code:
start javaw -jar JarFile.jar
and convert the .bat to an .exe using any .bat to .exe converter.
We're using Install4J to build installers for windows or unix environments.
It's easily customizable up to the point where you want to write scripts for special actions that cannot be done with standard dialogues. But even though we're setting up windows services with it, we're only using standard components.
installer + launcher
windows or unix
scriptable in Java
ant task
lots of customizable standard panels and actions
optionally includes or downloads a JRE
can also launch windows services
multiple languages
I think Launch4J is from the same company (just the launcher - no installer).
PS: sadly i'm not getting paid for this endorsement. I just like that tool.
The latest Java Web Start has been enhanced to allow good offline operation as well as allowing "local installation". It is worth looking into.
EDIT 2018: Java Web Start is no longer bundled with the newest JDK's. Oracle is pushing towards a "deploy your app locally with an enclosed JRE" model instead.
IMHO JSmooth seems to do a pretty good job.
If you need to convert your entire application to native code, i.e. an EXE plus DLLs, there is ExcelsiorJET. I found it works well and provided an alternative to bundling a JRE.
EDIT: This was posted in 2010 - the product is no longer available.
I would say launch4j is the best tool for converting a java source code(.java) to .exe file
You can even bundle a jre with it for distribution and the exe can even be iconified.
Although the size of application increases, it makes sure that the application will work perfectly even if the user does not have a jre installed. It also makes sure that you are able to provide the specific jre required for your app without the user having to install it separately.
But unfortunately, java loses its importance. Its multi platform support is totally ignored and the final app is only supported for windows. But that is not a big deal, if you are catering only to windows users.
As of JDK14, jpackage replaces javapackager mentioned in #Jay answer. The Windows version requires Wix 3.0 and it is fairly straightforward to take a java application and build an installer which provides EXE launcher.
It can also be used with jlink to build a cut-down Java runtime image which is bundled with the installer and only contains the set of modules needed to support your application. The jlink step will also be run implicitly by jpackage if no runtime is specified, but I prefer to make the JRE image separately as it will only change when you update JDK or add new module dependencies to your project.
Example main for Java class:
package exe;
public class Main {
public static void main(String[] args) {
for (int i = 0; i < args.length; i++) {
System.out.println("args["+i+"]="+args[i]);
}
}
}
Here are example steps to build on Windows - obviously you'd set up your local build environment (Maven / ant / etc) to re-produce this:
mkdir jpackage.input\jars tmp
javac -d tmp src\exe\Main.java
pushd tmp && jar cvf ..\jpackage.input\jars\myapp.jar . && popd
Check it runs:
java -cp jpackage.input\jars\myapp.jar exe.Main X Y Z
Create a runtime image with jlink for the set of modules use by your application:
set jlink.modules=java.base
jlink --add-modules %jlink.modules% --strip-debug --no-man-pages --no-header-files --compress=1 --output jpackage.jre
In case there are missing modules above, you should check the jlink JRE runtime image can run your app:
jpackage.jre\bin\java -cp jpackage.input\jars\myapp.jar exe.Main X Y Z
Use jpackage to generate installer, with app version based on date+hour (this saves on need to un-install every re-install) and to print out all system properties - remove the parameter "-XshowSettings:properties" after testing:
set appver=%date:~6,2%.%date:~3,2%.%date:~0,2%%time:~0,2%
jpackage --win-console --input jpackage.input --runtime-image jpackage.jre --app-version %appver% --type exe --name "MyApp" --dest jpackage.dest --java-options "-XshowSettings:properties" --main-jar jars\myapp.jar --main-class exe.Main
Run the installer:
jpackage.dest\MyApp-%appver%.exe
Test the application:
"C:\Program Files\MyApp\MyApp.exe" ONE 2 THREE
... Prints system properties ...
args[0]=ONE
args[1]=2
args[2]=THREE
You can use Janel. This last works as an application launcher or service launcher (available from 4.x).
Alternatively, you can use some java-to-c translator (e.g., JCGO) and compile the generated C files to a native binary (.exe) file for the target platform.
I can be forgiven for being against converting a java program to a .exe Application and I have My reasons. the Major one being that a java program can be compiled to a jar file from A lot of IDE's. When the program is in .jar format, it can run in Multiple Platforms as opposed to .exe which would run Only in very limited Environment. I am for the Idea that Java Programs shoudl not be converted to Exe unless it is very neccesary. One can always write .bat files that runs the Java program while it is a jar file.
if it is really neccesary to convert it to exe, Jar2Exe converter silently does that and one can also attach Libraries that are compiled together with the Main Application.
You can convert jar to exe using jar2exe. However you need to purchase the software. If you need a open source software i would suggest JSmooth.
Cautionary note: Much has changed with packaging and deployment since this question was first asked. Most of the answers given are not even current with JIGSAW (Java 9+).
If the goal is to create OS specific packages, information is provided in Oracle Docs Java 17 Packaging Tool User Guide. This guide includes documentation for the jpackage tool, which allows one to create platform-specific packages for Linux, macOS and Windows. I assume the Windows-specific instructions should include arriving at an .exe file, since that remains the most familiar way for Windows users to install and run applications.
My own personal experience creating an exe (for sale on itch.io) was with the Java Platform, Standard Edition Deployment Guide, which included making use of the tool Inno Setup 5. This documentation is older, is for Java 9. The section directly pertaining to .exe packaging is located here As a first step, I used jlink to make a self-contained package. At the time I was first wrangling with this, I was unable to figure out how to get jpackage to work with my modular program. But now that Jigsaw has been around for several years, jpackage is now likely much easier to use, and would be my first choice for the next Java app I might publish for Windows users.
Java projects are exported as Jar executables. When you wanna do a .exe file of a java project, what you can do is 'convert' the JAR to EXE (i remark that i putted between quotes convert because isn't exactly this).
From intelij you gonna be able to generate only the jar
Try following the next example : https://www.genuinecoder.com/convert-java-jar-to-exe/
I would like to build a .msi, .deb, and .pkg from the same source tree and on the same machine.
Distributable runtimes for Java9+ are no longer downloadable, so perfectly sane solutions like launch4j+nsis no longer work.
javapackager has been abandoned by Oracle.
OpenJDK's jpackager can't (and will never) cross compile for different build projects, and it isn't even a real product yet.
Is there a way to build installers for win/linux/macos from the same machine?
Is the promise of "compile once, run everywhere" is truly dead and buried?
I have a legacy java application that is now in limbo, since MacOS java8 doesn't support java.awt.desktop, which requires java9+
I use since Java 9 and the inception of jlink and jpackage a cross platform setup made of different docker images and Virtual Machines, where I can build the runtimes and the installers (MSI, DEB/RPM and DMG/PKG) on the target platforms within' my host system.
For Mac, you can use a KVM image, if you don't have Apple Hardware, where you can issue commands over ssh.
For Windows, a Linux docker container is used, packed with wine, the OpenJDK for Windows, the Visual Studio build tools, WIX and CMake to perform the build of the runtime image and a customised MSI installer (since the javapackage version is too simple)
The answer to your question is not short. But I'll try to be brief and point to all relevant information.
The short answer is: you can do this.
The longer answer is: you still have to build a runtime for each target environment from within that target environment, but you only have to do this once. You can then save that runtime and reuse it to automatically build installers with your latest Java jars/code in a single environment. For example, use jlink to build the runtime image and jpackage to build the app image for Windows, Linux, and macOS (on those respective systems) then copy those app images to macOS and build an nsis installer (or installer builder of your choice) for each platform from within macOS.
When you update your code and recompile, you can just copy the new jars into the pre-built app image. You'll have to copy in all your dependencies, too, but that would be necessary for any installer. There is a config file in the runtime built by jpackage that has options, classpath, etc., which you can change without a need to rebuild the runtime.
Create a runable program, something as simple as
package com.example;
public class Greeter {
public static void main(String[] args) {
System.out.println("Hi, I'm the greeter. Welcome.");
}
}
compile the program and place in a jar (call it greeter.jar for this example and place in the build directory, called target for this example)
run jilnk to build a runtime. The following command uses jlink from JDK11 and puts the result in a directory called runtime. This example includes all modules on the module path, but you can use jdeps to get just the modules you need. I suggest including all modules if you do not want to ever have to rebuid this runtime when your project evolves and depends on more of the Java runtime. Not to mention transitive dependencies on the JRE.
> set JLINK=C:\Program Files\Java\jdk-11.0.6\bin\jlink.exe
> "%JLINK%" --no-header-files --no-man-pages --compress=2 --strip-debug --add-modules ALL-MODULE-PATH --output runtime
run jpackage to build an app image suitable for packaging in an installer. This uses jpackage from JDK14 early access (the only version of the JDK that has jpackage at the time of this writing). The command line option —win-console is only for Windows and is only necessary if the program does something with stdin/stdout (the console). Our example writes to the console, so we need this. This argument will likely sometimes open a console window when running your application, so remove it if you have a pure windows based (gui) application.
> set JPKG=C:\Program Files\Java\jdk-14-ea\bin\jpackage.exe
> "%JPKG%" --type app-image -i target —win-console -n Greeter --main-class com.example.Greeter --main-jar greeter.jar --runtime-image runtime
run the application with .\Greeter\Greeter.exe
The resulting app image (in the app-image directory) can be used to build an installer with your favorite install builder (I use NSIS). You can do this on any platform. Furthermore, when you update you program you only have to copy your new jars into the app image. There is no need to rebuild the app image or the runtime. This copy of the jars can take place on any platform, and there is no need for Windows to be run in order to build a new installer for a new version of your application.
If your application has jar dependencies (say from Maven central), you’ll need to copy those jars to the Greeter/app directory and update app.classpath in the Greeter/app/Greeter.cfg file. Again, all this can be done on any platform, no need to start up the target platform (Windows in my case).
Also, jpackage is an officially supported tool but only available in EA JDK 14 (it's Feb 2020 as I write). JDK 14 may be downloaded and jpackage can be used with other versions of JDK (like JDK 11 LTS).
See https://blogs.oracle.com/jtc/a-brief-example-using-the-early-access-jpackage-utility
The JEP for jpackage has been marked "Closed/Delivered" suggesting the tool is mature and just waiting for JDK 14 to be released: https://openjdk.java.net/jeps/343
There is an example project on GitHub that has a lot of useful command line examples on how to run jlink and jpackage: https://github.com/jtconnors/SocketClientFX
Though this project uses outdated command options. You can run jpackage --help to get the new options.
Useful Links:
JDK 14 (early access until March 17th, 2020): http://jdk.java.net/14/
Explains non-modular usage of jlink: https://medium.com/azulsystems/using-jlink-to-build-java-runtimes-for-non-modular-applications-9568c5e70ef4
jlink manual: https://docs.oracle.com/javase/9/tools/jlink.htm#JSWOR-GUID-CECAC52B-CFEE-46CB-8166-F17A8E9280E9
jpackage - run with the -help option to get good reference information
Creating a Windows MyApp.exe and MyApp-setup.exe on linux:
I don't need jpackage at all, only jlink, launch4j, and nsis:
Use jlink once natively to create the runtime and tar off the
results for use on other machines.
launch4j can be instructed to use that runtime, and nsis can be
told to copy the whole runtime on install.
Creating a MacOS MyApp.app on linux:
Use jlink to create a tarfile that can be reused to recreate
Contents/runtime/Contents/Home (like for windows above)
Copy in the jpackage generated
Contents/runtime/Contents/Info.plist and
Contents/runtime/Contents/MacOS/libjli.dylib
Copy in the jpackage generated Contents/MacOS/MyApp stub and
Contents/MacOS/libapplauncher.dynand hope they never have to
change.
Create Contents/Info.plist and Contents/app/MyApp.cfg file from
templates using the jpackage generated ones as a reference
Fill in Contents/app, Contents/Resources with my jar files and other resources
Creating a pkg on linux:
https://gist.github.com/msabramo/2a8e44eb6dcc3b89437d33649b0b1841
Creating a dmg on linux:
https://askubuntu.com/questions/1117461/how-do-i-create-a-dmg-file-on-linux-ubuntu-for-macos
Alternately, migrate from nsis to install4j
https://www.ej-technologies.com/products/install4j/overview.html
In theory once I get it all working on linux, I can port the effort to both Darwin and cygwin (WSL just doesn't work right for me atm, will get that working last)
Proof of concept is here (linux, MacOS, cygwin):
https://github.com/nyetwurk/ecuxplot
It is kind of ridiculous this multiplatform crosscompile tooling doesn't exist anywhere, considering the rise of CI/CD, and that the whole point of java is portability and architecture independence.
I have an application that I wrote, using JavaFX, that runs normally on Windows and Linux. On OSX, however, the application starts (is listed in the process list), but the GUI never appears. It is launched from another application that ensures that it is up to date, using the standard convention of "java -cp <all of the required libraries, including the jfxrt.jar> <main-class> <args>"
Is there something I'm missing that OSX needs to make JavaFX work correctly?
The command line smbarbour used to run the application includes a jfxrt.jar location of:
/usr/lib/jvm/java-7-oracle/jre/lib/jfxrt.jar
As mentioned in EulerGeek's answer to Compile code using JavaFX 2.0 (using command line), on OS X, this location needs to be:
java -cp ".:/Library/Java/JavaVirtualMachines/jdk1.7.0_09.jdk/Contents/Home/jre/lib/jfxrt.jar" <app class>
Replace jdk1.7.0_09.jdk with whatever version of java is installed on the machine, or require Java 8 when it is released (which does not require jfxrt.jar to be manually added to the classpath).
Deployment Recommendation
If you are deploying applications to users, even with Java 8, it is recommended that you package applications using relevant packaging tools (e.g. JavaFX ant tasks, javafxpackager, javafx-maven-plugin or javafx-gradle-plugin).
I have installed jdk1.7.0_07 and changed PATH but i still cannot import javafx, is there something that i should do fix this?
Make sure that /jre/lib/jfxrt.jar is on your compile path.
For example for the 64 bit jdk7u6 version on win7, the jfxrt.jar is located here:
C:\Program Files\Java\jdk1.7.0_06\jre\lib\jfxrt.jar
jfxrt.jar was left off of the java runtime path on purpose for jdk1.7.0_06 until further testing between JavaFX and rest of the java infrastructure has been completed. This means that non-JavaFX programs cannot possibly be impacted by possible compatibility issues which may be caused by JavaFX. To date I have never encountered any compatibility issue - this was just a cautious move by Oracle in this regard I believe.
In a future release the jfxrt.jar should be added to the default compile and runtime classpath for Java and some of the information below should be irrelevant. You can track the request to add jfxrt.jar to the default java runtime.
Compiling and Running a JavaFX program from the command line
Example below is for a JavaFX application class named javafxsamples.AudioPlaylist
If you are compiling from a command line, compile with:
javac -cp ".;C:\Program Files\Java\jdk1.7.0_06\jre\lib\jfxrt.jar" javafxsamples/AudioPlaylist.java
To run from the command line, you can use:
java -cp ".;C:\Program Files\Java\jdk1.7.0_06\jre\lib\jfxrt.jar" javafxsamples.AudioPlaylist
Though, it is recommended that you package your applications with the javafxpackager, rather than manually adding jfxrt.jar to your classpath (javafxpackager packaged applications will embed a launcher which finds jfxrt.jar and adds it to the classpath for you).
javafxpackager -createjar -nocss2bin -appclass javafxsamples.AudioPlaylist -srcdir . -outfile AudioPlaylist.jar
After that you can run the app without needing to specify a jfxrt.jar location on the classpath:
java -jar AudioPlaylist.jar
Compiling and Running a JavaFX program using IDEs
NetBeans
If you are using NetBeans 7.2+, you can create a JavaFX project type and it should automatically find JavaFX jfxrt.jar and place it on your project's classpath when you set up jdk1.7.0_07 as your platform.
Eclipse
If you are using e(fx)clipse make sure you are using the latest version (0.0.14+) which is features better facilities for detecting JavaFX.
Idea
Intellij Idea 11.1.3 will automatically add all of the files from the jre lib directory to it's project classpath, so you shouldn't get compile errors with it. Note that Idea's behaviour is erroneous in this regard, it shouldn't really do this, but it in the end you end up with the expected behaviour of being able to compile and run your JavaFX classes from idea.
Building a JavaFX program using maven
Make the jfxrt.jar a system dependency for your maven project to get it on the path.
Use the maven antrunner to execute the javafx ant tasks for deployment packaging.
An example of packaging JavaFX with maven is provided in this maven project.
Even if you use an IDE or Maven for your build, it is still recommended, you package your app for delivery using the javafx ant tasks or javafxpackager utility as this should provide the most robust deployment solutions for your application.
This installer will first check if jvm is present on the system or not. If not then it will first install the jvm. After that it will include the java code (may be in jar) alongwith the database used. And finally it will create a desktop shortcut and make changes to registry as other s/w does.
First you need to decide on a setup authoring tool. Here is a list which can get you started:
http://en.wikipedia.org/wiki/List_of_installation_software
Advanced Installer is one of the tools which has a dedicated Java project type.
To detect and install JVM, you can add it as a prerequisite. This is done differently for each setup tool.
There is a new tool being developed for that: jpackage
If your project is build using Gradle then you can easily use the Badass jlink plugin: https://github.com/beryx/badass-jlink-plugin
to build an installer / package using jpackage
Here's an article how to build an app image using OpenJDK 11 and using OpenJDK 14 with jpackage only for building the installer / package:
https://walczak.it/blog/distributing-javafx-desktop-applications-without-requiring-jvm-using-jlink-and-jpackage