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.
(more…)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.
(more…)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.
(more…)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.
(more…)This screencast shows the JProfiler plugin for IntelliJ IDEA. A run configuration is profiled, source code navigation is discussed and the call graph data display in the IDE is shown.
This screencast explains a basic strategy for solving memory leaks with JProfiler.
There is an older version of this screencast from 2009 that is not accurate for the heap walker anymore but that shows other useful features in JProfiler.
Complexity analysis in JProfiler is a tool for experimentally determining the Big-O behavior of algorithms based on the execution times of single selected methods. A bubble chart with curve fits of common complexities visualizes the results of the analysis.
This screen cast shows how to attach to a remote JVM with zero configuration on the remote side. The only requirement is an SSH connection to the remote machine. Remote JVMs are listed in the JProfiler UI and a JVM can be selected for profiling.
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.