What's new in install4j 11.0

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:

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.