Caching auto-provisioned install4j distributions in CI pipelines

Starting with install4j 11.0, integrating install4j into your build system has become much easier: The Gradle, Maven, and Ant plugins can now auto-provision the install4j distribution. This means the plugins will download and cache the appropriate install4j version automatically, so you no longer need to install install4j manually.

Cross-platform JRE bundle creation under threat from JEP 493

One of the most valuable capabilities introduced with the Java module system in Java 9 is its support for creating custom runtime images with jlink. Developers can include only the modules they need, resulting in lightweight JRE bundles tailored to the requirements of their applications. Using the --module-path option, it has even been possible to generate those runtime images for different operating systems from a single host machine.

With Java 24, JEP 493 introduces a change that significantly impacts this workflow. JDK vendors can now configure builds without .jmod files, as jlink can optionally extract the required resources from the lib/modules jimage file. While this change reduces the size of the JDK by about 25%, it also removes critical support for cross-platform linking.

Improvements for macOS App Store submissions in install4j 11.0.2

install4j 11.0.2 introduces several new features to simplify macOS App Store submissions, including automated entitlement handling for TestFlight, improved support for local testing with development provisioning profiles, and dynamic bundle versioning for easier resubmission of builds.

Migrating to install4j 11.0

In most cases, migrating to install4j 11 involves simply opening and saving your project with the install4j 11 IDE. Nevertheless, there are some considerations with respect to backwards compatibility and a couple of behavioral changes.

Namespace awareness of XML actions in install4j

This post explains an exceptional backward-incompatibility in the install4j 10.0.9 release. This was necessary due to a change in install4j 10.0.8 that was intended to fix the corruption of namespaced XML documents by modifying XML actions.

Migrating to install4j 10.0

In nearly all cases, migrating to install4j 10 just means opening and saving your project with the install4j 10 IDE. Nevertheless, there are some considerations with respect to backwards compatibility and a couple of behavioral changes.

Migrating to install4j 9

In nearly all cases, migrating to install4j 9 just means opening and saving your project with the install4j 9 IDE. Nevertheless, there are some considerations with respect to backwards compatibility and a couple of behavioral changes.

Migrating to install4j 8

In nearly all cases, migrating to install4j 8 just means opening and saving your project with the install4j 8 IDE. Nevertheless, there are some considerations with respect to backwards compatibility and a couple of behavioral changes.

Automation sandboxing in macOS 10.14

macOS 10.14 introduces automation sandboxing as part of a new push for security. This change impacts installers generated with install4j prior to 7.0.8, because they use AppleScript to perform a variety of tasks. The authorization dialogs from the new sandboxing mechanims are undesirable for an installer and once a permission is denied it is difficult to reauthorize it.

Stricter time-stamp validation on macOS 10.14

Today we released an install4j emergency release for macOS 10.14 that fixes a problem with code signing. Previous versions of install4j used time stamp validation during code-signing in such a way that it's no longer recognized by macOS 10.14.