Install4j is a powerful multi-platform Java installer builder that generates native installers and application launchers for Java applications.
What's new in Install4j
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.
"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
Join over 500,000 subscribers.
Subscribe for our newsletter with best Mac offers from MacUpdate.