Install4j

New features:

• In development environments, the API runtime dependency now automatically provides the native libraries that are required by some API calls
• In development environments, the .install4j runtime directory can now be specified with the system property -Dinstall4j.runtimeDir. This allows all API calls to work, including those that require access to the config file, such as Variables.getCompilerVariable(...).
• Multiple timestamp signing services are now tried in the case of a failure. The default is now DigiCert with a fallback to GlobalSign. This can be changed on a per-project basis as explained in the documentation.
• Bugs fixed:
• "Download file" action: If the digest file was created with an external tool that produces upper case letters, the check would fail
• "Execute SQL script" action: Regexp delimiters and compound delimiters with a line break like ";n" did not work
• "Check for running processes" action: Prevent closing the process dialog with the window close button
• "Set the owner of files and directories" action: Leading and trailing spaces in the "owner" property were not trimmed and lead to an unhelpful error message
• The native log files of Windows installers was not deleted
• Fixed deadlock during auto-save or while saving the project when the floating license server connection was lost
• Fixed memory leak when running in-process installer applications multiple times
• When using the filter text field in the certificate selection dialogs, the wrong certificate was selected
• The check whether modules are used by launchers was not made for merged projects, so a non-modular runtime library could be generated leading to a runtime failure in a merged launcher
• Text mode overrides for bean properties did not work for elevated actions
• Installers could throw an LzmaException for large data files
• Arguments in .vmoptions files were not trimmed on macOS
• API: If a scheduled version has already been installed manually, return false for UpdateChecker.isUpdateScheduled()
• macOS: Command line executables could not use bundled JRE in macos folder archives due to notarization requirements
• macOS: The reported file sizes of notarized media files in updates.xml was wrong
• macOS: Fixed signing Java 9+ JRE bundles for macOS folder archives when the build runs on macOS or Linux