Author: Ingo Kegel

Fine-tuning console installers

In the upcoming install4j 4.2.4 release, we’ll expand on the improvements that were introduced with the visibility script in install4j 4.2.3.

The GUI installer operates in a “one screen at a time” mode while the console installer does “one question at a time”. Due to this difference, the automatic translation of form screens from GUI to console mode will not always be optimal.

In 4.2.4 we will introduce a “Console handler” form component that allows you to fine-tune the console mode of your installers. The form component is invisible and has no effect in GUI mode. Its action is defined in the “Console script” property:

Besides the usual parameters for form components, the script is passed a “console” parameter, which is of type com.install4j.api.screens.Console and offers a number of methods for interacting with the user on the console. This has previously only been offered in the API for the development of custom screens and custom form components.

In the console script shown above, an error condition is handled in the middle of the form component sequence. In GUI mode, such error conditions are usually handled in the validation script of the screen, but due to the lack of “screens” in console mode, the validation might be more appropriate at an earlier time.

Another scenario for the use of console handler form components are form screens that do no require user input. In such a case, you could add a console handler form component and set its console script to


console.print("Please read the information above");
console.waitForEnter();
return true;

Thread states in the CPU profiling views

In the screencast below, I explain the thread status selector and the different threads states in the CPU profiling views.

Appending to redirection files

install4j has always offered the possibility to redirect stderr and stdout to files. The main purpose of this feature is to analyze uncaught exceptions and to get debug information when something goes wrong in a customer’s installation.

The redirection files are created lazily, meaning that as long as there is no output, the file will not be created or replaced. However, once output is detected, the redirection file is created or overwritten. This has been the only option so far and while it is often sufficient to retain the error or debug output of the last run, in some cases you might want to keep the entire output over multiple invocations of the launcher.

In the upcoming install4j 4.2.4, we have added this feature and in the redirection step of the launcher wizard, you can change the classic “Overwrite” behavior to “Append”.


The redirection file will still be created lazily, but it will be appended to if it already exists.

Overview of profiling views and profiling settings

We now have a list of screencasts for JProfiler on our web site that is generated from this blog. In order to include the older demos (without audio) into that list, I post them below:

  • Overview of profiling views in JProfiler See a brief overview of the most important profiling views in JProfiler. Some important functionality is shown to give you an idea on how JProfiler works.
  • Getting started and session settings See how easy it is to get started with profiling. Important aspects of the session configuration like profiling settings, triggers and method call recording filters are shown.

Both demos take about 7 minutes and open in a new window. The were recorded for JProfiler 5.0 but are still quite accurate for JProfiler 5.2.

install4j and Java for Mac OS X v10.5 Update 4

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.

Changing the visibility of form components at runtime

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.

Evaluation of cross-platform installer builders

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.