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.

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.

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.

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.

This change is accompanied by corresponding API enhancements in ActionListPropertyDescriptor.

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.

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

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