What's new in install4j

MSIX is completely separate from MSI. For MSI, install4j only generates a wrapper around the installer generated by install4j. This is because install4j concepts such as screens, actions, and scripts cannot be mapped seamlessly into the MSI model. MSIX, on the other hand, is declarative, so concepts like services, file associations, and startup tasks are translated directly into manifest entries.

An MSIX package is installed by double-clicking the .msix file or by running Add-AppxPackage in PowerShell, and no install4j installer wizard runs at install time.

Note that Code signing is mandatory for distribution of this media file type, because unsigned MSIX packages can only be installed in Windows' development mode.

All MSIX-specific settings are configured in dedicated sub-steps of the media file wizard. On the "MSIX options" step, the package identity name, the package version, and the minimum and maximum tested Windows versions are set. You can also set a launcher as a sign-in launcher that runs automatically when the user logs on and that the user can later disable in the Windows "Startup apps" settings.

The package icon is customized on the "Package icon" sub-step. It is shown in the Windows installation dialog. A background color can be set for it so that icons with transparency are given an opaque tile. For the start menu and the task bar, the icons configured in the launcher wizard are used.

Services are chosen from the generated service launchers and are registered as Windows services through the manifest. The startup type and the service account are configured per launcher on the "Services" sub-step.

File associations bind one or more file extensions to a launcher, so that double-clicking such a file opens your application. For each association, a description, an optional MIME type, and a custom icon can be configured.

URL scheme handlers are declared in the same way, so that a custom scheme such as myapp:// is routed to the launcher. Both are set up on the "File associations and URL handlers" sub-step.

App URI handlers let a launcher handle ordinary https:// links for a specific host. When a matching link is opened, Windows can route it to your application instead of the browser. Because a site's links cannot be claimed without its consent, the host must publish the generated windows-app-web-link.json file under /.well-known/ that lists your package.

App execution aliases expose selected launchers under their executable name on the user's PATH, so that they can be invoked by name from a command prompt or the Run dialog. The aliases are scoped to the package and are removed together with it. They are selected on the "Applications on PATH" sub-step.

For auto-updates, MSIX packages rely on the App Installer mechanism built into Windows rather than on the install4j update architecture. The required .appinstaller file is generated by install4j, and the hosted URL is then checked periodically by Windows so that new package versions are installed in the background. The hosting URL and the update behavior, such as how often to check and whether to prompt the user, are configured on the "Auto-update" sub-step.

All languages configured for the project are declared in the manifest automatically.

The skill is a self-contained knowledge package. It bundles the project file schema, a catalog of every available bean class (screens, actions, form components, screen and widget styles), runnable sample projects, the install4j API, and the complete documentation, all in an AI-friendly format together with instructions for common workflows. With it, the assistant can verify against accurate information and does not have to guess.

A compatible assistant loads the skill on its own whenever you give it a task related to install4j. For example, when it is asked to add a startup check to the hello sample that detects an already installed version and prompts before a second installation, the assistant locates the right registry API, inserts the new action into the project file, and confirms that the project still compiles.

To install the skill, click the "Install AI Skill" button in the toolbar. From the dialog, it can be written into the skills directory of your AI agent. Supported agents include Claude Code, Claude Desktop, Cursor, Codex CLI, Gemini CLI, OpenCode, and Junie.

It can be installed globally, so it is available in every project on your machine, or per project, where it is only available when the agent runs from that project. The skill is generated from your exact install4j version, so its schema, bean catalog, and samples always match the compiler in your installation.

When you associate the schema with your .install4j files in an XML editor, you get auto-completion, inline documentation, and validation as you edit. In addition, the project file is now validated against the schema whenever you compile from the command line, so structural errors are caught early with precise messages.

A session is started with one of the session builders: InstallerSessionBuilder.forMediaFile(...) to test a generated installer, UninstallerSessionBuilder.forInstallation(...) to test an uninstaller, or InstallerApplicationSessionBuilder.forInstallation(...) for custom installer applications such as update downloaders. Builder options include a timeout, additional command line arguments, system properties, a working directory, a log file, and a debug mode that runs the installer in process for easy breakpoint debugging.

Within a session you wait for screens by id, navigate with the Next, Previous, Cancel, and Finish buttons, interact with strongly typed handles for form components and dialogs, and finally verify installer variables, the installation directory, the log, and the exit code:

InstallerSession session = InstallerSessionBuilder
    .forMediaFile(new File("media/myApp_windows-x64.exe"))
    .installationDirectory(targetDirectory)
    .start();

session.waitForScreenId("welcome").nextScreen();

// Accept the license, then fill in a custom form screen
session.currentScreen().checkBox("acceptCheckBox").setSelected(true);
session.currentScreen().nextScreen();
session.currentScreen().textField("port").setText("8443");
session.currentScreen().nextScreen();

// Modal dialogs can be handled when they appear
session.alert().clickYes();

session.currentScreen().finish();

// Verify the outcome after the installer has exited
int exitCode = session.awaitExit(Duration.ofMinutes(2));
assertEquals(0, exitCode);

For Kotlin users, extension functions are included to make the API more idiomatic. A useSession { } block starts the session and closes it automatically, helpers like onScreen and onAlert run a code block on a screen or dialog, and a session["name"] accessor reads installer variables:

InstallerSessionBuilder
    .forMediaFile(File("media/myApp_windows-x64.exe"))
    .useSession {
        onScreen("welcome") { nextScreen() }
        onCurrentScreen {
            checkBox("acceptCheckBox").setSelected(true)
            nextScreen()
        }
        onAlert { clickYes() }
        onCurrentScreen { finish() }
        awaitExit()
    }

The Test API is published to Maven Central as com.install4j:install4j-test and is also bundled as install4j-test.jar in the resource directory of your installation.

These GUI tests can even be run headless in CI. On Linux without a display, such as a GitHub Actions runner, the installer subprocess is automatically wrapped in xvfb-run together with a lightweight window manager, so the installer is rendered into a virtual framebuffer and the tests run without any physical screen. All that is required on the machine is xvfb-run and one of the supported window managers (metacity, mutter, openbox, fluxbox, or marco).

When the installer runs with Java 25 or later in an ANSI-capable terminal, console mode now renders a modern, interactive UI:

• Colored output so that success and error messages stand out.

  
• A live progress bar with a percentage, with status and detail rows that update in place instead of scrolling past. Long files paths are shortened in the middle so that the beginning and the end stay visible.

  
• A spinner for work whose duration is not known.

  
• Single-choice lists navigated with the arrow keys, used for option menus and for Yes/No and OK/Cancel confirmations.

  
• Multi-selection from a checkbox list.

  
• Text and masked password input, and file and directory prompts with tab completion.

  
• A built-in pager for long text such as license agreements, optionally requiring the user to scroll to the end.

  

The rich renderer falls back to the plain console automatically when running on an older Java version or when there is no terminal with sufficient capabilities, for example when output is redirected to a file or piped to another process. The plain renderer can be forced by passing -J-Dinstall4j.plainConsole=true to the installer.

This capability now allows the install4j IDE to run on Linux with all OpenJDK variants and for all HiDPI resolutions. Previously, only the JetBrains runtime was supported on Linux with HiDPI resolutions.

Also, artwork and icons in the generated installers have been updated to a more modern look. All images and icons in the generated installers remain replaceable, but the default icons and images that are shown by the built-in screen styles are updated automatically to the new style.

A default styling is applied with a background image and a drop target for the /Applications directory in the case of single-bundle archives. You can also choose not to apply any styling, which is the default when migrating install4j projects from previous versions.

Additional top-level files for the DMG can be specified in a sub-step. You can optionally set icon coordinates to arrange items on the Finder window background.

The widgets that are most frequently styled in different ways are buttons. Beyond custom font and custom background and foreground colors, install4j offers different types of buttons, such as borderless buttons, buttons with rounded rectangle borders, or toolbar-style buttons. Colors when hovering over or pressing a button and the colors for the focused state can be configured separately if required.

Besides buttons, the list of stylable widget types includes

• Drop-down lists and combo boxes
• Hyperlinks
• Labels
• Lists and trees
• Progress bars
• Sliders
• Text components
• Toggle buttons

Also, the background color for frames and dialogs can be set in the widget style.

To apply a widget style other than the default style, you can assign it to a screen style. Screen styles in turn are applied to installer applications, screen groups, and single screens, and widget styles are cascaded along with them.

Alternatively, widget styles can be applied on the form component level. Form components can have multiple widget styles for their contained widgets. For example, most form components have an optional leading label that has a separate widget style property.

For one-off style changes, a custom inline style can be configured directly in the form component. To do that, choose the "Define a custom widget style" option and all the relevant style properties will appear as child properties.

To support different colors in light mode and dark mode, all color properties support a notation with separate colors for both modes. The property popup also allows you to configure both colors.

You can preview widget styles directly in the install4j IDE. The preview window also takes screen styles into account.

The decision whether to set a user-specific or global installation location is determined by the "Installation scope property". Apart from the fixed options for global and user-specific installations, the outcome can depend on whether full admin rights are available, whether the installation directory for all users is writable, or whether the sys.installForAllUsers installer variable is set to true.

The action can also search for previous installations. This is based on the installation scope by default, but configurable to always include user-specific or global installations.

The "Set installation directory" action itself sets the boolean sys.installForAllUsers installer variable so that subsequent actions and screens can be wired together accordingly. For example, you could start with a "Set installation directory" action in the "Startup" node of the installer, followed by a "Request privileges" action with a condition expression of context.getBooleanVariable("sys.installForAllUsers").

Another component that is coupled to the sys.installForAllUsers installer variable is the new "Installation scope chooser" form component. It is part of the new "Installation scope" screen and provides a standard way to ask users whether to perform a user-specific or a global installation.

The "Installation scope chooser" form component consists of two radio buttons, one for each option, and is bound to the sys.installForAllUsers installer variable.

The "Installation scope" screen combines these radio buttons with default wording and two associated actions: A "Request privileges" action that is executed conditionally if the sys.installForAllUsers installer variable is set to true and a "Set installation directory" action with an installation scope of "According to the sys.installForAllUsers variable".

With these new building blocks you can implement different and more complex scenarios for determining the installation directory.

When using PKCS #11, usually both certificate and private key are contained in the keystore. In install4j 12, matching of private keys and certificates has been improved considerably, leading to fewer code signing errors. In addition, the PKCS #11 session is now kept alive to speed up code signing.

In incomplete or non-standard setups, code signing can fail when the compiler cannot find the certificate or the full certificate chain. To handle these cases, install4j now offers an optional separate PKCS #11 certificate file entry, both for Windows and macOS code signing.

By default, install4j tries to use the certificate with the maximum validity if you do not select a specific certificate from the keystore. With the new mode, where a separate certificate file is specified, only the private key is loaded from the keystore and install4j tries to find a private key that matches the certificate. You can also select a specific private key by label or id manually.

Finally, the environment variable DYLD_LIBRARY_PATH can now be set on macOS for the install4j command line compiler to load PKCS #11 libraries.

In the terminology of install4j, a "launch agent" corresponds to a "startup executable" and a "launch daemon" corresponds to a "service". We've named them with Apple's terminology because you need to read the Apple documentation to understand what is happening in the background to use this feature.

Both launch agents and daemons need an identifier. Launch agents additionally support arguments. Because they can show a UI by default, you can choose to hide them from the Dock when they only perform background operations.

install4j will generate the required files in Contents/Library/LaunchAgents and Contents/Library/LaunchDaemons, but they will not automatically be registered. You need to add logic to your app to alert the user, and then call the com.install4j.api.macos.MacServiceManagement API to register them. This will trigger a confirmation from the OS.

The registration is a simple static method call that uses the identifier that you configured for the launch daemon or the launch agent:

MacServiceManagement.registerLaunchAgent("com.mycorp.sync.plist");
MacServiceManagement.registerLaunchDaemon("com.mycorp.protocolserver.plist");

In addition, MacServiceManagement contains methods for checking the status and unregistering launch agents and launch daemons, opening System Settings in the "Login Items" section, and registering the main bundle itself as a login item.

By default, streamlining offers either a "default" installation or a "customized" installation. The result of the user selection is saved to the boolean installer variable sys.streamlinedInstallation. That variable can be used to conditionally execute other screens and actions. By default, several screens in install4j have such condition expressions when you add them.

Alternatively, you can choose to only alert the user for update installations and offer streamlining only in that case. This corresponds to the behavior in previous versions of install4j.

To assist with the conversion of .icon files into .car and .icns files, a new command line utility iconcompiler has been added. It only runs on macOS and requires Xcode 26 or newer. Use "Project->Command Line Tools->Reveal Command Line Tools in Finder" to find the executable in your install4j installation.

Since you should always include an .icns file in addition to the .car file in your app bundle, there is no separate entry for the .car file in install4j. Instead, install4j will pick up a .car file with the same name beside the specified .icns file automatically.

Scaling will be applied to all widgets, icons, and fonts, here with a 150% enlargement:

In this release, we added a selection dialog for the PKCS #11 slot index that lists HSM descriptions and manufacturers. This is important if you have multiple HSMs.

In install4j 11, you can now select a certificate by its label, as well as by its issuer and serial number Also, if you leave the certificate selection empty, install4j will automatically select the code signing certificate with the longest validity period.

Up to install4j 11, PKCS #11 was only available for Windows code signing. Now there is a PKCS #11 option for macOS code signing as well.

With the chained certificates directory, it is now possible to tell install4j about intermediate certificates that need to be taken into account for code signing to establish the complete hierarchy of trust.

Code completion has been improved. It now suggests automatically as you type by default. You can disable this behavior in the Java editor settings dialog.

There are now a number of templates that are tab-expandable for common code snippets, such as printing to stderr with "serr", as shown in the screenshot below. Other snippets, for example, are "log" to write to the log file and "ex" to log an exception.

Also, all static methods in install4j API classes are suggested without having to first type the class name. In that way, you can start with a method name and install4j will add the static import for the class automatically.

An action to rename variables has been added (Code → Rename).

A new action allows you to reformat the entire script or selected code (Code → Reformat Code). Reformatting is done according to the Eclipse default Java formatting style. If you would like to use custom formatting settings, you can export a single Eclipse profile and specify it in the Java editor settings. Exporting Eclipse XML profile files is supported by Eclipse, IntelliJ IDEA and the RedHat Java plugin of VS Code. The tab size used for editing and reformatting is directly configurable in the Java editor settings.

Also, typing a closing brace now reformats the preceding block. This behavior can be disabled in the Java editor settings.

An action to optimize the imports for the current script has been added (Code → Optimize Imports).

An action to show the available parameters for all overloaded methods of the method call at the caret has been added (Code → Parameter Info). It highlights the matched arguments up to caret and selects the overloaded variant chosen during code completion if possible.

Actions to navigate between problems have been added to the script editor. Problems are either warnings or errors and can be shown by hovering over the underlined text or the indicator in the right gutter.

Selecting code blocks is now possible with the new "Extend selection" and "Shrink selection" actions. Repeated invocations of those actions select surrounding or contained blocks of code around the current caret position.

The script editor now has support for quick fixes. If the caret is on a detected problem, a floating popup with a lightbulb or the Code → Quick Fix action will show a context menu with automatic modifications that will resolve the problem. The list of available quick fixes include:

• Remove unused, duplicate, conflicting or non-existent imports
• Import ambiguous or unresolved types
• Fix unterminated strings
• Fix type mismatches
• Fix wrong return statements
• Fix instance access to static members
• Fix wrong visibilities and method modifiers in overrides
• Fix abstract modifier problems
• Implement unimplemented methods
• Create local unresolved variable
• Remove unused local variables
• Remove dead code
• Remove casts

An new action has been introduced to refactor code (Code → Refactor). When invoked, a popup with applicable refactorings for the current caret position is shown. The list of available refactorings include:

• Extract to local variable
• Inline local variable
• Convert to lambda expression
• Convert to anonymous class creation
• Convert var to an explicit type and vice versa
• Convert to static import
• Surround with try/catch
• Convert to enhanced for loop
• Add inferred lambda parameter type
• Replace lambda parameter types with var
• Change lambda body expression to block
• Change body block to expression
• Remove lambda parameter types
• Convert lambda to method reference
• Use MessageFormat for string concatenation
• Use StringBuilder for string concatenation
• Use "String.format" for string concatenation
• Convert String concatenation to text block
• Convert to switch expression
• Split variable declaration
• Join variable declaration
• Invert equals comparison

Alternative keymaps for popular IDEs are now supported by the script editor. When first using the script editor, install4j will ask you to choose an initial keymap.

You can change the keymap or customize it at any later time by invoking Settings → Keymap in the Java editor settings.

Compiler variables can be now declared to contain sensitive information. In that case, their value is not written to the runtime configuration and cannot be retrieved via context.getCompilerVariable("variableName"). You can still use the compiler variable in all text fields with the ${compiler:variableName} syntax because these usages are replaced at build time.

Platform-specific overrides for compiler variables were added. While it was always possible to override compiler variable values for media files, it was inconvenient when the overriding value was always identical for the same platform. Now, you can override for Windows, macOS and Linux/Unix. These overrides can be further refined with the media-specific overrides.

You can now refer to the base value when overriding a compiler variable with the syntax ${compiler:variableName}. This applies to both platform-specific and media-specific overrides. There are many related use cases, for example, a list of VM parameters with common values and additional values for each platform. Previously, you would have had to introduce a separate compiler variable for the additional value.

File and path separators can be converted to the build or the target platform. This means you do not have to repeatedly use the compiler variables sys.fileSeparator, sys.pathlistSeparator, sys.mediaFileSeparator or sys.mediaPathlistSeparator anymore. Instead, you can use either Unix-style ('/' and ':') or Windows-style ('\' and ';') file and path separators in the value. Both styles are converted in the same way.

This feature has also been implemented for pre-defined installer variables of type String.

The "Read value from a JSON file" action saves the match of the JSONPath to the specified variable. Depending on the JSONPath expression, the variable is either a primitive value, an instance of java.util.List for array matches, or an instance of java.util.Map for object matches.

The "Count occurrences in a JSON file" action counts the number of matches of the JSONPath and saves the result to the specified variable. In this case, the JSONPath expression should be an indefinite expression.

Finally, the "Modify JSON files" action replaces the matches of a JSONPath expression in one or multiple files. You can choose to

• Set values
• Replace values
• Add to arrays
• Delete values
• Add or update object keys
• Rename object keys

by adjusting the "Modification type" property and filling out its child properties.

The "Create a symbolic link" action now also supports Windows. Execution on Windows is controlled by the "Execute on Windows" property and is disabled by default.

Update downloaders can now make decisions based on the Java version of the update installer by inspecting com.install4j.api.update.UpdateDescriptorEntry#getJreMinVersion and #getJreMaxVersion. In that way, you can choose to download an update installer without a bundled JRE if you can determine that the requirements for the JRE have not changed. Other attributes in the update descriptor can also be used for this purpose. These attributes are configurable under "Installer → Auto Update Options".

Here's an example of a minimal Gradle script that builds an installer with install4j 11.0:

import com.install4j.gradle.Install4jTask

plugins {
    id("com.install4j.gradle") version "11.0"
}

tasks.register<Install4jTask>("media") {
  projectFile = file("hello.install4j")
}

A Maven POM to compile an installer will look like this:

<project>
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.test.hello</groupId>
  <artifactId>hello-world</artifactId>
  <version>1.0</version>

  <pluginRepositories>
    <pluginRepository>
      <id>ej-technologies</id>
      <url>https://maven.ej-technologies.com/repository</url>
    </pluginRepository>
  </pluginRepositories>

  <build>
    <plugins>
      <plugin>
        <groupId>com.install4j</groupId>
        <artifactId>install4j-maven</artifactId>
        <version>11.0</version>
        <executions>
          <execution>
            <goals>
              <goal>compile</goal>
            </goals>
            <configuration>
              <projectFile>${project.basedir}/hello.install4j</projectFile>
            </configuration>
          </execution>
        </executions>
      </plugin>
    </plugins>
  </build>
</project>

The earlier method of specifying the "installDir" property remains available.

You can track input files with calls like

...
inputs.dir(stagingDir)
inputs.files(file1, file2)
...

in the task definition.

To support the configuration cache, we had to migrate all properties to Gradle providers. This means that the binary interface of the tasks has changed and you will likely have to adjust your build script.

Both the installer as well as the generated launchers will be native arm64 executables in that case and will require a JRE with the windows-aarch64 architecture. The Zulu and Liberica JDK providers contain such builds for recent Java releases.

Also, installers will find installed Microsoft JREs on Windows ARM machines if no JRE is bundled.

An app that is submitted to the App Store must fulfill a number of requirements and pass a review process by Apple. In the launcher, you can configure a number of properties that are relevant for this purpose. A custom bundle identifier must be set to match the identifier in the Apple Developer Account configuration, and the application category is required for an App Store submission. In addition, your app may require entitlements such as the right to read and write user-selectable files. This is done in an entitlements file. The sandbox is switched on automatically by install4j.

install4j will build a .pkg file that you can test locally to check the effects of the sandbox and your entitlements. The .pkg file is then uploaded with the Transporter app or Xcode command line tools. A dedicated chapter has been added in the documentation that deals with Apple App Store submission.

Each firewall rule applies to a selected launcher and handles either incoming or outgoing connections. Because firewall rules are shown in the Windows management console, they need a rule name and optionally a rule group as well as a detailed description.

The properties of the action mirror the available settings when editing firewall rules in the Windows management console. By default, any ports and IP addresses can be used on both local and remote side, but you can optionally restrict them for a more secure configuration. Windows offers different profiles for network connections that determine the security of the connection. Rules can be created in selected profiles only.

As recommended by Microsoft, rules are not created for the public profile by default. If you really want to include it, consider selecting the "Avoid public profile" child property. In that case, the public profile is only included if it is the only profile that is currently active.

Clicking on the drop-down arrow on the right side of the undo/redo tool bar buttons, will bring up a list of undoable or redoable items. By clicking on an item you can undo or redo all items up to the selected item.

Modifications that were performed in modal dialogs such as the launcher wizard or the media wizard show as one atomic item. In the form component configuration dialog there are separate undo/redo buttons for the life cycle of the current dialog.

The context menu of properties contains a menu item to reset the selected property to its default value. This will also revert the text input mode if it was set for the property.

You can either add a file association or a URL handler. A file association is defined by its extension, a description and an optional icon file. The role indicates whether the application just displays files or also edits their content.

The URL handler is defined by the URL scheme, so for a scheme of "hello" it handles requests in the browser that start with "hello://".

The "Create a file association" and the "Register a URL handler" actions now only work for Windows and Linux. If you open projects that were saved with previous versions of install4j, the information from these actions is migrated into the new settings for macOS in the launcher wizard.

In addition, single instance mode has previously always been per session in Windows. The same user can run multiple RDP sessions to a remote machine, and single instance mode should be able to cover all such sessions if desired. To do that, you can deselect the "Per session on Windows" check box.

Startup notifications through the com.install4j.api.launcher.StartupNotification API are only delivered if the same user in the same UI session starts the application again.

Overridden file modes that are defined for single entries in the distribution tree still take precedence over the detected file modes.

While setting up the auto update process, you may want to perform several updates in a row for testing or debugging purposes. Because the inhibition time for auto updates is set to 24 hours, this was not possible before. Starting with install4j 10, the "Schedule update installation" action has a "Retry inhibition in minutes" property that can be reduced appropriately.

Finally, the documentation for auto-update functionality and background downloaders has been improved with more background information and trouble-shooting assistance.

While previously you could only grant additional rights, you now have a complete set of tools at your disposal to modify access rights of installed files and directories.

These properties are in the "Hyperlink label" property section which is different from the "Label" property section for the optional leading label that you can set for most form components.

For example, a "Drop-down list" form component expands the array value into separate items.

Apart from the new comment indicator, moving between comments is facilitated by the "Show next comment" and "Show previous comment" actions.

In this case, VM parameters are not split into separate lines as it is done for other properties that hold sequences of values or the .vmoptions files where each VM parameter is on a separate line. This is because quoting is not resolved at this point, and compiler or installer variables can inject unquoted sequences of VM parameters. As a result, the dialog soft-breaks the VM parameters with spaces as a delimiter so you can see the entire line at once.

In addition, it is now easier to spot version-specific VM parameter configurations. In the "Java invocation step" of the launcher wizard, the number of version-specific VM parameters is displayed next to the button that shows the configuration UI.

Version-specific VM parameters are defined as pairs of Java version expressions and corresponding VM parameters. The cell editor for the VM parameters in the table also has a button that shows the separate dialog for editing VM parameters.

You can adjust the look and feel on the new "Look & Feel" step. You can choose between two built-in themes for the light mode and two built-in themes for the dark mode. The auto-detection of light and dark mode is implemented on macOS, Windows and Linux. On macOS, switching between dark mode and light mode is also detected while the installer is running, on Windows this is only supported with the JetBrains Runtime. You can choose to disable auto-detection and only use either light or dark mode.

In addition to the built-in themes, you can select themes for IntelliJ IDEA. These themes are based on JSON files that define the colors and other properties of UI elements. Using this mechanism, you can develop your own custom theme for the installer UI.

JAR files containing themes have to be added on the "Custom Code" step. After that, you can select the resource path to the JSON file of an IntelliJ theme with the theme chooser.

To allow the user to manually switch between dark and light mode, a "Dark mode switcher" form component has been added that can also be used in styles.

If only the icon is shown, the dark mode switcher button has a flat appearance. This makes it a good addition to the footer area, here shown with the "Cyan" light theme.

To support light and dark mode with the same screens, all color properties now support light and dark variants. If you develop custom code, this will automatically be available for all properties of type java.util.Color.

In the color editor, you can choose whether to provide separate colors for light and dark mode or not. For custom code, if different variants are configured, the color instance will be a derived class that seamlessly switches its color component values during a theme change.

The Java native look & feel that is built into the JRE is still supported, although not recommended, because it does not work well with recent releases of macOS and fractional HiDPI resolutions on Windows.

Finally, you can now integrate your own look and feel by implementing com.install4j.api.laf.LookAndFeelHandler and adding your class on the "Custom Code" step together with the dependencies of the look & feel. LookAndFeelHandler extends com.install4j.api.laf.LookAndFeelEnhancer that contains methods for UI elements where the runtime needs special collaboration from the look & feel, such as the creation of a tri-state check box. You can override the default implementation of these methods to improve the fidelity of your look and feel in the context of install4j.

The "customCode" sample project contains an example of a custom look and feel.

Finally, you may have noticed from the above screenshots that the install4j IDE is now using FlatLaf as well. Please consider starring FlatLaf on GitHub.

Dark mode and light mode settings for the install4j IDE continue to be available in the preferences dialog.

Besides Liberica, Azul Zulu is another option with JavaFX included for recent Java versions. It also offers Java 8 without JavaFX, making the JRE bundles much smaller. In addition, recent releases already include the macos-aarch64 target for machines with Apple Silicon.

Amazon Corretto is an OpenJDK distribution that focuses on including additional fixes and patches from the main branch and other sources into LTS releases. Recently, they have started to add support for the latest feature release as well.

Universal binaries will not only be generated for the launchers and the installer, but also for the JRE bundle. This only works if the selected JDK provider has published both the macos-amd64 and the macos-aarch64 architectures for the selected release. install4j will then download both archives and merge them into a universal JRE bundle.

The old "Java version" step is now ordered below the "General Settings → JRE bundles" step, and its minimum Java version setting has become optional. If empty, the required Java version is the major version of the selected JDK. JDK versions now have the syntax <major version>/<provider-specific version> across JDK providers.

Since install4j 9, you can specify a provider-specific version "latest" to use the latest release of the selected major version. Because media files require a particular platform, this mechanism searches for the latest release in which that platform is available, separately for each media file. You can also insert this version string in the release selection dialog by selecting the folder node of the major version.

For the configured JDK, it is now possible to inspect all available modules with the "Show All Modules" button. Previously, you could only see which modules would be included in the JRE bundle. That functionality continues to be available with the "Show Included Modules" button.

In install4j 9, there is no need to configure the JDK for script compilation and for the script editor, because the configured JDK for the JRE bundle will be used for that purpose automatically. If you do not bundle a JDK, the JRE that install4j is running with will be used as a fallback and you can still manually configure a JDK in the Java editor settings dialog.

For shared JRE bundles, a sharing ID has been introduced. This limits the sharing to a scope of projects that is defined and controlled by yourself. This also deals with the variable module contents of JREs in the post-Java 9 world. The sharing ID should start with a domain name that is controlled by you and must be configured both by media files that publish a shared JRE as well as by media files whose Java search sequence wants to find a shared JRE.

Warnings can be suppressed on a per-warning basis with special compiler variables. If you build in verbose mode, after each warning, an instruction is printed on how to disable it. In the install4j IDE, the description comes with a hyperlink to define the corresponding compiler variable.

As you can see in the above screen shot, script compilation warnings are now printed during the build. This makes it easier to eliminate new deprecations and find possible bugs across the whole project.

Installer applications are added on the "Installer → Screens & Actions" step and can contain links into other installer application such as the installer itself. In this way, you can reuse screens and actions in different contexts.

pkexec is a PolicyKit application that is available on most Linux distributions and uses the authentication dialog of the desktop environment to execute the elevated helper process with root privileges.

pkexec cannot be used in console mode, so install4j asks the user which command line authentication method (su or sudo) should be performed.

When searching for an ID, all screens, actions and form components that are reachable in some way from the current view are included.

The matching elements are shown at the top of the result tree together with the reverse path to the top-level element. When you confirm the search dialog, the match is shown in the install4j IDE.

For text values a similar dialog is shown that provides optional text matching options like wildcards, regular expressions and case sensitivity. You can also choose whether to include element names, comments or property values.

By default, the first match is shown when confirming the dialog. You can show any other element in the result tree by selecting it beforehand.

In addition, you can now specify the file mode for single files.

The update downloader template propagates the execution mode to the downloaded installers. Since install4j 9, it also propagates this alert setting. Because the update downloader is a template, this is not automatically updated for your existing projects. You would have to locate the action named "Set installer arguments" in the update downloader and replace the script with that from a new updater application.