Please see the change log
for a detailed list of changes.
For a discussion of breaking changes when migrating from install4j 5.1, please see
this blog post.
install4j 6.0 introduces the following notable new features:
install4j 6 introduces a fast edit-compile-test loop with the new "Test installer" tool bar button.
Instead of building the entire media file, it just recompiles scripts, screens and actions and updates an
existing media file.
When you click on "Test installer", the installer is launched automatically after a short compilation phase.
The first time before using the "Test installer" feature, or whenever you need changed files or launchers in
the installer, you build the first media file that runs on your current platform. To select a particular
media file, you can reorder the list of media files correspondingly.
Properties file actions now help you with reading, writing and manipulating properties files.
The "Read a properties file" action reads a properties file to an installer variable. Arbitrary encodings
as well the special java.util.Properties format are supported.
The "Write properties to file" action can not only write properties to a file, it also merges new or updated
property definitions into an existing property file.
The property definitions can come from a variety of sources. You can provide an installer variable of type
java.util.Map, enter the property definitions directly in the install4j IDE or specify
yet another properties file.
Unlike the simple java.util.Properties class, the actions in install4j can handle comments
on property definitions and can optionally sort property keys.
Finally, the "Remove keys from properties file" action deletes selected properties from a properties file, while
preserving comments and key ordering.
The new JDBC file actions can check database connections and execute SQL queries.
The "Check JDBC connection" action tests whether the connection to a configured JDBC database can be
established. The action fails if an error occurs.
With the "Execute SQL query" action you can retrieve data from a JDBC database and store the result in an
installer variable. The action supports multiple rows and columns, and provides easy access to values if only
one row, one column or a single value are returned by the SQL statement.
If you want to execute multiple SQL statements without the need to process the return values, the
"Execute SQL script" action performs this task for you. You can enter the SQL statements directly in the
install4j IDE or read them from a file.
New XML file actions have been added for common use cases.
The "Insert XML fragment into XML files" action allows you to merge new nodes in places defined
by an XPath expression and a configurable insertion mode. The XML fragment can be entered directly in the
install4j IDE, or an XML file can be read from which the children of the root element are extracted.
The "Remove nodes from XML files" action is the complementary action and removes nodes that match a specified
New HTTP and network actions make it easier to deal with servers.
The "HTTP request" action can perform all types of HTTP requests including REST operations.
Response body, response code and response headers can be saved to installer variables.
Form data can be entered conveniently and is added as URL query parameters or as encoded data in the request body,
depending on the HTTP request method.
If a rollback occurs, you can specify a separate request to undo any changes on the server.
The new "Upload file" action has been added to provide complementary functionality to the existing
"Download file" action.
With the new "Wait for socket" action, you can wait for arbitrary servers to become available
and not just for HTTP servers which is handled by the existing "Wait for HTTP server" action.
DMGs on Mac OS X. In previous versions, install4j could only write DMGs in ISO format. This was
only suitable for installers, because the contained files had to be compressed.
install4j 6 can write DMGs in
UDIF-compressed HFS+. This means that archives on Mac OS X can now also be written as DMG. The old
.tgz option is still available and may still be preferable for command line and server applications.
You can now add additional top-level files to DMGs. This could be a README file or an additional installer.
Most importantly, you can use this feature to style the Finder window for the mounted DMG.
Creating the .DS_Store file for styling the Finder window is explained in detail in a new
install4j ships with background images for archives and installers in the resources/macos directory
that you can use, but the .DS_Store file must be created for each project, because it references a
unique project-specific volume ID.
For DMGs, the volume name and - for installers - the name of the contained installer can now be customized.
If the installer name is entered with an i18n variable, the file name will be localized.
Improved launchers on Mac OS X. The names of GUI launchers on Mac OS X can now be
internationalized. This uses the i18n mechanism of application bundles on Mac OS X. All you
have to do is to specify the launcher name as an i18n variable. For each configured language in your project
a localized name will be written to the application bundle.
On Mac OS X, the launcher name may have to be more descriptive than on other platforms, so install4j 6
offers the possibility to specify a different launcher name on Mac OS X, both for launchers and installer
The uninstaller name that was previously fixed can now be set in the install4j IDE.
To assign an icon to a Mac OS X launcher, you previously had to create an ICNS icon file. install4j 6 can generate
the ICNS file from the cross-platform icon images, just like for Windows. Note that you should supply at least
an image of size 128x128 pixels for this feature.
Mac OS X launchers can now create a debug log, just like Windows launchers. To enable log file creation, you have
to specify the environment variable INSTALL4J_LOG=yes. You can do that by calling
launchctl setenv INSTALL4J_LOG=yes in a terminal. By executing open $TMPDIR you can then show the directory that
contains the log file whose name starts with "i4j"
Starting with install6j, command line launchers and services are included in single-bundle archives and installers.
Previously, only the selected GUI launcher was available.
Many other improvements on Mac OS X. In this release several features that were missing on Mac OS X
with respect to Windows have been implemented.
Oracle JREs for Mac OS X have been supported since install4j 5.1 but the JRE bundle creation wizard was previously
not available on Mac OS X. This has been implemented in install4j 6 together with the ability to create
unpacked JRE bundles for archives.
Retina icons are now supported for all image properties. Next to the selected image file, create another
image file with twice the resolution and append "@2x" to its name, then the install4j compiler will pick it up
and use it on Mac OS X retina displays.
The "Check for running processes" action now works on Mac OS as well. If a launcher is still running,
installation or uninstallation will alert that the applications should be closed first. The class
com.install4j.api.macos.MacProcesses was added to the API so that you can list and close Mac OS X
processes programatically as well.
Other features that previously only worked on Windows have been extended to Mac OS X. This includes
the "Reboot computer" action and the installer variables "sys.appDataDir", "sys.localAppdataDir", "sys.docsDir",
"sys.fontsDir" and "sys.programsDir".
Finally, the updater template has been adjusted so that updaters work with Mac OS X single bundle archives.
Response files improvements. Variable definitions in response files can now have comments. The
comments are written to the response file and are configurable in the IDE and through the API.
Response files are now sorted alphabetically and variables that have been read from a response
file are now registered automatically as response file variables. The "Load a response file" action now has
a property to revert this change to the previous behavior and a new "Overwrite strategy" property. The latter is
set by default so that variables that have been set on the command line are not overridden.
The "Create a response file" action is now more flexible with respect to the selection of installer
variables that will be written to the response file. In addition to the exclusive filter there is now also an
inclusive filter mode.
The new "Modify a response file" action allows you to update all variables in an existing response file
without losing previous variable definitions. This can be useful in custom installer applications.
Installer variables for which no value is available in the current installer application will be kept as is.
You can also add selected installer variables to an existing response file.
Java code editor improvements. Until now, reusing code across different scripts could only be done
with custom code that was compiled in your Java IDE and added on the "Installer->Custom code & resources"
In install4j 6, a script for defining static fields and methods has been added on that step.
You can declare fields, methods and even classes, and as long as they are declared as "static", they can be
referenced by other scripts in your project.
All static definitions will be suggested by code completion and can be used without any prefix in all other
When you code-complete an abstract class or an interface, stubs for all abstract methods are
inserted automatically. When auto-completing a class that is not in the default or explicit imports, an
import statement will be added instead of using the fully qualified class name.
install4j now shows the correct line numbers for script compilation errors and script runtime exception
stack traces. Previously, the line number referred to generated source code and did not help with finding the exact
location of an error. In stack traces, line numbers that only exist in generated source code are prefixed with an
Configurable DPI-awareness setting for Windows launchers. By default, Windows launchers are scaled up
for DPI settings larger than 100%. If your launcher is DPI aware, you can enable DPI awareness in the
launcher wizard. This will add an entry to the executable manifest that enables your GUI to be shown with
If you do not explicitly handle high-DPI cases, this will most likely lead to unacceptable results, so this
setting is disabled by default and corresponds to the previous behavior of install4j launchers.
Splash screen improvements. The minimum Java version for launchers is now Java 6, so the custom
splash screen implementation for Unix and Mac OS X has been replaced with the Java splash screen.
This means that the splash screen is now displayed much faster on non-Windows platforms than before.
The text line overlays and the splash screen manipulation API now work with the Java splash screen.
The splash screen settings in the launcher wizard have been adjusted to reflect these new realities.
On Windows, the native splash screen is optionally still available. It is displayed even faster than the
Java splash screen, but does not handle transparent images.
RPM improvements. You can now configure the operating system and the architecture for
Hidden variables can be configured in the IDE. If an installer variable contains sensitive information
that should not be written to the log file, you previously had to call a method in the API. Now you can
configure this setting for predefined installer variables in the install4j IDE.
The new "Return to parent screen" failure strategy makes it easy to perform long-running input
validations in actions. If an error occurs, the current screen will be shown again. Previously, this
required using the API.
The new "Disable JRE bundling" build option lets you reduce compile times for testing purposes
or allow compilation in the case where the configured JRE bundles are not locally available. The option is also
available from the command line or in the ant and gradle integrations.
Command line option to run services in a terminal. For debug purposes, it can often be desirable
to run a service directly in a terminal instead of installing it and starting it in the background.
Previously, you had to create another command line launcher.
In install4j 6, service launchers support two direct run modes:
With the argument /run on Windows or run on other platforms you start the
service executable in the foreground. All output is printed directly on the terminal.
With the argument /run-redirect on Windows or run-redirect on other platforms you start the
service executable in the foreground, but keep the configured redirection.
Support for very large installers. Previously, installers could not be bigger than 2GB.
In install4j 6, there are new platform-dependent limits:
On Windows there is a 4GB limit due to the fact that executables (even 64-bit executables)
cannot be larger than 4GB.
On Mac OS X and on Linux/Unix there is no relevant limit to the size of the installer.
If you use external data files, there is no relevant limit on any platform.
A gradle plugin was added. A simple usage of the plugin looks like this: