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.

Migrating to install4j 7

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

Comparing install4j to other deployment solutions

Samuel Ruggieri from Voyager Games has written an interesting article comparing install4j against Java Web Start and other installer builders. His conclusion is this:

"At the end of this adventure, I have another experience that demonstrates the old adage that it’s cheaper to buy software than to build it. In this case, it’s cheaper and better. Software engineer hours are expensive, and for a non-trivial Java application, you’ll burn scores of them if you try to build a custom deployment and auto-update solution. At the end of that development, whatever you’ve built will almost certainly be inferior to what install4j can give you with a bare minimum of expense, both in terms of time and effort."

If you're thinking about comparing different deployment solutions for your Java application, maybe his article can provide some shortcuts.

Migrating to install4j 6

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