What's New in install4j 7.0

Change release:

Please see the change log for a detailed list of changes.

install4j 7.0 introduces the following notable new features:

install4j 7 adds full support for Java 9. Java 9 JREs are now found by the JRE search sequence and can be used to run installers and launchers. If you use jlink to prepare your custom JRE, only the "java.desktop" module is required for running installers and installer applications. Some actions require other modules, depending on their functionality. For example, the JDBC actions require the "java.sql" module.

Java 9 JRE bundles are also supported and we have added an EA-build to the JREs that can be downloaded from within the install4j JRE. You can use the JRE bundle creation wizard to create bundles from new builds as they become available.

The module path for Java 9 applications can now be configured for launchers. Both module path and class path can be defined side by side, the main class can be selected either from the class path or from the module path.

With Java 9, many applications need a number of command line parameters that are not recognized by earlier Java versions. If you plan to support Java 9 and Java 8 at the same time, the "Version-specific" VM parameters come in handy.

Java 9 adds support for HiDPI on Windows and Linux. Retina displays on macOS were already supported by earlier versions of install4j. With Java 9+ as a minimum version, installers and installer applications now run with DPI-awareness enabled and show high-resolution images.

For Windows, install4j already had an option to make launchers DPI-aware, the new default option "Java 9+" now enables DPI-awareness if the minimum Java version is at least 9.

If you have configured a splash screen for your launcher, and a high-resolution version of the image is available, that image is now also used for the splash screen on Windows and Linux if the DPI value requires it.

Background auto-update functionality has been added to install4j. You can activate it in your project with three simple steps:

Step 1: Add a new installer application from the "background update downloader" template. That installer application downloads an update if available and schedules it for execution. In contrast to the traditional update downloader templates it does not execute the installer immediately, but splits download and execution into two phases in order to make updates less disruptive for your users.

Step 2: To start the background updater, use its launcher integration and set the launch mode to "Non-blocking at startup". The background updater does not have a UI and will complete a download even if your application is shut down.

Step 3: In the launcher wizard of a GUI launcher that should process scheduled update installers, go to the new "Auto-update integration" step and select the "Execute downloaded update installers at startup" check box. By default, the execution mode is set to "Unattended mode with progress dialog".

For services and command line launchers, the UpdateChecker API allows you to execute scheduled update installers programatically.

At the heart of the background update downloader is the new "Schedule update installation" action. It can set arguments for the installer with its "Installer arguments" property and has additional properties to configure error handling. To avoid looping execution in case of an error, a failed installation is retried at most once per day.

You can take more control over the auto-update process if you use the API. The HelloGui class in the "hello" sample project shows how to do everything with the API and without launcher integration or auto-update integration in the launchers.

install4j 7 introduces flexible styling of installers and installer applications. On the new "Installer->Styles" step you configure styles that can be assigned to installer applications, screen groups or single screens.

Styles are configured like form screens, with a limited selection of form components that do not take any user input. Horizontal and vertical form component groups are used for layouting.

In addition, a special set of style components is available for capturing content and executing navigation logic in screens:

  • The "Screen content" style component displays the content of the current screen
  • The "Screen title" style component is a label that displays the title or the subtitle of the current screen
  • The "Control button" style component is a button that is associated with a navigation action, one of "Next", "Previous" or "Cancel"
  • The "Nested style" component embeds another style

Styles that have their "Standalone style" property selected can be chosen in the "Style" property of installer applications, screen groups or screens. Installer applications have a default value of "Default" for that property and use the style that has been marked as the default style. Screen groups and screens have a default value of "Inherit from parent", so style changes are recursive by default.

install4j 7 comes with two styles that exactly match the default styles in previous versions of install4j. Some properties of these styles can be overridden when the style is applied to a particular element. The "Standard" style has a configurable header image and configurable background and foreground colors. The "Banner" style has a configurable sidebar image and background color. This matches the previously configurable properties and ensures a seamless migration of settings from older projects.

The overridable elements are not hard-coded but can be configured by yourself in the configuration of the style. Each style component has a "Allow external overriding" property. If you select it, the "Override title" child property must be set to a text that is unique for the entire style. Also, you can choose the properties that should be overridable. When you select the containing style for an installer application, screen group or screen, check box properties for each overridable style component are shown as child properties.

Styles can be merged from other projects. This allows you to share a common style with multiple installers. To enable style merging, select the "Style" check box in the configuration of a merged project. If style merging is not enabled, styles with the same name are used from the main project when you link to screens from other projects.

Styles have full preview functionality. While you are editing style components and their properties, you can preview the result of your configuration with a single click.

Similar to screens, styles can also be developed with the API. Many new classes have been added in the com.install4j.api.styles package to support development of custom styles. The "customCode" sample project contains a custom style implementation that wraps another user-selectable style and draws a dynamic background image.

When used for a form screen, the preview shows what the custom style will look like.

install4j 7 brings many enhancements for form components.

The following new form components have been added:

  • File associations selector: A list of check boxes showing all file association actions that are found after the current form screen. This was previously handled directly by the "File associations" screen.
  • Installation components selector: Shows a tree of all installation components together with their descriptions and check boxes for selecting which set of components should be installed. This was previously part of the "Installation components" screen.
  • License agreement: Displays a license agreement with radio buttons for accepting the agreement. This was factored out of the "License agreement" screen.
  • PDF display: A cross-platform PDF viewer. Previously, this was only available as a screen.
  • Program group selector: A component to select a program group name for Windows. Previously only available through the customizable "Program group selection" screen which has now been retired.
  • Update alert: A UI component that alerts the user that an update installation can be performed. It sets the "sys.confirmedUpdateInstallation" installer variable. This functionality was previously contained in the "Welcome" screen.

Many new properties have been added for styling layout groups:

  • Image file: An image can be specified to be displayed inside the layout group.
  • Image anchor: The image can be anchored at the center, at the side or at the corners.
  • Image edge: Unless the image is anchored at the center, it cuts off an entire side from the layout group. If anchored at a corner, you can select whether to cut off a horizontal or a vertical side.
  • Image edge background color: By setting a background color for the image edge, the image can blend seamlessly into its surroundings. For example, the "Banner" style does this with the default banner image.
  • Image insets: The image can be displayed with specified insets around it.
  • Overlap with contained components: If selected, other form components are layouted on top of the image.
  • Image edge border: A border of variable color and width between the side that is cut-off by the image and the remaining area of the layout group can be defined.
  • Background and foreground color: Setting a background color will make the layout group opaque, the foreground color is used by form components that display text.
  • Border sides: Layout groups can have a border on selected sides with a selected border color and width.

For coordinating between form components or between a containing screen and its form components, a new variable system has been added that is scoped to the current form. To reference such variables in text fields, the prefix "form:" is used with the usual variable syntax. New methods have been added to FormEnvironment and AbstractFormComponent to work with form variables.

For example, the "Welcome" screen now sets a form variable for a header message that is picked up by a multi-line label in its default form components.

Form components can now export configuration to the containing screen. Each form component has a "Allow configuration on screen" property. If you select that property, you have to specify a category title under which the form component configuration will appear in the screen. Also, you can select the properties that should be exported.

For example, the "Installation directory chooser" form component exports several properties to the containing "Installation location" screen, so you can quickly access these important properties without searching for them in the form components.

Fonts for many form components can now be set as derived fonts. Previously, an absolute font specification could be given, which was often impractical. Now, a size and a style change to the default font can be configured.

The anchor for the entire form can be configured if the form should not fill the horizontal or vertical space. If the "Fill horizontal space" or "Fill vertical space" properties of the form are not selected, child properties are shown to set the anchor along the corresponding axis. The same properties are available for styles.

Action lists can now supply fixed parameters for all scripts. In install4j 6.1, actions lists were introduced. One of their use cases is the "Action list" property of the "Button" and "Hyperlink action label" form components.

One major usability problem was that there was no way to refer to form components from the configured actions, such as from a "Run script" action. install4j 7 adds the concept of fixed parameters for all scripts that occur in action lists and now passes a "formEnvironment" parameter in the above case.

This change is accompanied by corresponding API enhancements in ActionListPropertyDescriptor.

All "customizable screens" have been converted to form templates. The old customizable screens went back to the early days of install4j when form screens were not yet available. In install4j 7, the new form templates implement the same screens with form components. Each old customizable screen has been mapped to a form template and is migrated without any significant change in behavior.

The "Banner with header at the top" form template replaces the "Banner form" screen. Style is now a separate configuration option and is not coupled to the screen implementation anymore.

The important parameters are exported to the screen configuration, so that these forms are used just like the old customizable screens. The main difference is that the new form templates can be used as starting points and can be changed in arbitrary ways.

Most standard screens are now built with form components. This means that you can add your own elements to these screens.

Also, the standard screens with form components get full preview functionality so that you can see what they look like at design-time.

Native alert boxes and file choosers have been implemented on Windows and macOS. Previously, cross-platform file choosers and alerts were shown.

Native looking UI elements are important to make the end user feel comfortable with the installer.

The single instance mode for launchers has been implemented for Linux/Unix launchers. Previously, single instance mode was only available for Windows and macOS. This feature is now fully cross-platform.

Improved support for installing without admin privileges. installers now automatically handle the case where there is no "Request privileges" action in the project or where the "Request privileges" action fails and suggest an installation directory in the user home directory.

If you want to disable this new behavior for a failure of the "Request privileges" action, there is a new "Fall back to user specific installation directory" property for that case.

New actions for extracting archives have been added.

On macOS, the "Extract a DMG file" action is useful for obtaining the contents of a DMG file without manually mounting it.

The "Extract a TAR file" action works on .tar and .tar.gz files, similarly to the "Extract a ZIP file" action.