ej-technologies blog 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.

• The minimum Java version for the install4j runtime is now Java 1.8. Java 1.7 is no longer supported.
• The install4j compiler and IDE now require at least Java 11. This is only relevant on Linux and Unix where no JRE is bundled.
• “Install files” action: The “Update bundled” JRE property has been removed. A bundled JREs is now always updated if the update installer also includes a bundled JRE. The ability to switch this off offers no benefit and has the potential to create severe problems during sequential upgrades. If you had this property selected, you can restore the previous behavior by defining the VM parameter -Dinstall4j.preventJreBundleUpdate=true in the installer.
• “HTTP request” action: In previous versions, if an error occurred, the response code variable and the response header variables were not set. This error has been corrected in install4j 9, but it changes the semantics of the installer variables.
• The installer variable sys.appdataDir was previously undefined on Unix, it now returns the value of the environment variable XDG_DATA_HOME ( ~/.local/share ) on Unix.
• Shared JREs (Windows and Unix) now have a sharing ID. This has become necessary because there is no universal definition of a JRE anymore so the scope of sharing has to be restricted. Consequently, shared JREs are now installed in different locations than before. Also, the user-specific root directories have changed to ~/.local/share/i4j_jres on Unix and %APPDATA%\Local\Programs\Common\i4j_jres on Windows. Shared JREs are now preferred to public JREs on Unix.
• The “Execute launcher” action always executed the selected launcher without elevation. This does not work for launchers that require privileges themselves. Since install4j 9, the action respects the “Action elevation type” property of the action. This changes the behavior of the action if you have changed the “Action elevation type” property from its default value of “Do not elevate” to another property value.
• The auto-update integration for background update downloaders in the launcher wizard behaves differently if the “Unattended mode with progress dialog” mode is selected: It now shows errors and alerts in the update installer where previously any error would lead to a silent failure. If this change is not acceptable for you, you can add the VM parameter -Dinstall4j.noAlerts=true to the “VM parameters” property of the installer.
• Installer applications that have not been started in-process by launchers now set the system property jdk.lang.Process.allowAmbiguousCommands=false to avoid cmd.exe injections. In unattended and console mode, installers applications already behaved that way because they use a security manager. Some quoting strategies or arguments that worked before might stop working in GUI mode because of that change. To revert to the previous behavior, set the VM parameter -D jdk.lang.Process.allowAmbiguousCommands=true for the installer application.
• The JRE version cache on Linux/Unix is now located in .cache/install4j/jres instead of the file ~/.install4j .
• Config files, cached files and pre-crated JRE bundles have new platform-specific locations instead of being stored in ~/.install4j<version> . On Windows, all directories are located below %LOCALAPPDATA%/install4j/v<version> . On macOS, ~/Library/Application Support/install4j/v<version> is used for config files as well as pre-created JRE bundles and ~/Library/Caches/install4j/v<version> is used for cached files. On Linux and Unix, .config/install4j/v<version> is used for config files, .caches/install4j/v<version> for caches and .local/share/install4j/v<version> for pre-created JRE bundles. The environment variables XDG_CONFIG_HOME , XDG_CACHE_HOME and XDG_DATA_HOME modify the roots of these directories, respectively.
• In previous versions, Linux/Unix installers created the installation directory with the default umask. Since install4j 9, the default Unix directory mode configured in the “Files->File Options” view or the overridden mode configured for the “Installation directory” node in the distribution tree is used.