ej-technologies blog tools and more Page 9

Unfortunately the latest release of Java 6 on Mac OS X a few days ago broke all installers on Mac OS X that require Java 6 as a minimum Java version.

This is why we have sped up our release schedule for 4.2.3 and we pushed out the release today.

The error message you get with installers that are generated by older versions of install4j is:

 
Java application launched from PPC or bad stub. Relaunching in 32-bit, and tagging sub-processes to prefer 32-bit with $JAVA_ARCH=i386.
[JavaAppLauncher Error] This process is [i386] and was re-exec'd from [i386], but for some reason we are trying re-exec to [].

How could this happen? The explanation goes like this: Installers on Mac OS X ship their own binary Java application stub. Prior to Java 6 this application stub only contained 32-bit executables for PPC and Intel architectures. So far, Java 6 is only available on 64-bit Intel machines. From the beginning, the 32-bit stub continued to work with Java 6. This behavior was changed in Java for Mac OS X v10.5 Update 4, so we had to add a 64-bit executable to the Java application stub.

If you’re on an older version of install4j and cannot update to the latest version for whatever reason, you can copy the file $INSTALL4J_HOME/resource/macos/JavaApplicationStub from a 4.2.3 installation to your older installation.

One of the strong points of form screens is that they are displayed by console installers without any further configuration. You don’t have to program the user interface twice, once for the GUI and once for the console.

However, it is often necessary to hide certain form components at runtime. For example, a certain form component might only make sense on a specific platform. Until now, you could use the initialization script of the form component to change the visibility like this:

 
  boolean visible = Util.isWindows();
  component.setVisible(visible);

This hides the form component unless the operating system is Windows.

However, the drawback of this method is that the console installer does not execute the initialization script of a form component – there is no GUI widget created and so the configurationObject parameter would be null. In the upcoming install4j 4.2.3, we have added a visibility script property that works for both the GUI and the console installer:

Even simpler than the previous initialization script, a simple visibility expression of

Util.isWindows()

(no semicolon at the end to make it an expression rather than a script) hides the form component on non-Windows platforms.

This screencast is outdated, please watch the more recent version instead.

In the screencast below, I explain the different reference views in the heap walker.

https://www.youtube.com/watch?v=VpyUiLdar2Q

On stackoverflow, there’s a question regarding the comparison of cross-platform installer builders. This answer is apparently the result of a very thorough evaluation and paints a very favorable picture of install4j.

This screencast is outdated, please watch the more recent version instead.

https://www.youtube.com/watch?v=FSJMSe8TvpI

Often the question comes up why there are larger object counts in the dynamic memory views than in the heap walker. The simple explanation is that the dynamic memory views show all objects on the heap – even those that are unreferenced, while the heap walker only shows objects that are strongly referenced.

Here, for example, in the “All objects” view, a particular class has an object count of 6741:

In the heap walker, the object count is only 6282:

The difference comes from objects that are not referenced anymore, but that are still on the heap because the garbage collector has not collected them yet. Clicking on the “Run GC” button in JProfiler might collect some, but not all of them, since the garbage collector does not do full collections in modern JVMs. However, when you take a heap snapshot, a full collection is done internally, so you only look at objects that you can actually do something about.

Ideally, we would exclude unreferenced objects from the dynamic memory views too, but this information requires an expensive calculation that can only be performed when taking a heap snapshot.

Since the release of Vista, code signing has been of growing interest for our users, mainly because a signed installer or launcher produces nicer and less UAC dialogs when it wants to elevate its privileges.

install4j provides a signing hook for all generated windows executables. On step 5 of the Windows Media Wizard, you can specify any external tool with the executable files as parameter. The signing tool will be called with the working directory set to the project file parent directory so you can specify keys and certificates relatively. You can use the $EXECTUABLE variable to refer to the launcher or installer and an $OUTFILE variable if the tool you use requires different in and out files. (more…)

In this blog we’ll show you tips and tricks around JProfiler and install4j. Comments and questions are always welcome. Enjoy!