Locking graphs in JProfiler

Friday, November 27, 2009 | Posted by

In the screencast below, I present some of the features in the locking graphs that have been introduced in JProfiler 6.

The test class that is profiled in this screen cast is given below:

public class MonitorTest {

// The only monitor that all threads are blocking or waiting on
private static final MonitorTest monitor = new MonitorTest();

public static void main(String[] args) throws InterruptedException {

// All threads execute this runnable, each thread acquires the
// monitor, works for 3 seconds and then waits on the monitor
Runnable runnable = new Runnable() {
public void run() {
synchronized (monitor) {
try {
// Instead of doing any real work, the thread just
// sleeps for 3 second
} catch (InterruptedException e) {


// 3 threads are started with an offset of 500 ms
new Thread(runnable, "Test Thread 1").start();
new Thread(runnable, "Test Thread 2").start();
new Thread(runnable, "Test Thread 3").start();

// After 20 seconds, all threads are woken up and the test class
// terminates
synchronized (monitor) {

Allocation recording explained

Friday, August 14, 2009 | Posted by

In the screencast below, I explain allocation recording in the dynamic memory views in JProfiler.

Fine-tuning console installers

Thursday, August 06, 2009 | Posted by

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");
return true;

Thread states in the CPU profiling views

Friday, July 10, 2009 | Posted by

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

Appending to redirection files

Thursday, July 09, 2009 | Posted by

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

Tuesday, July 07, 2009 | Posted by

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.

JProfiler's IDE integrations

Tuesday, June 30, 2009 | Posted by

In the screencast below, I explain the benefits and the usage of JProfiler's IDE integrations.

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

Thursday, June 18, 2009 | Posted by

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

Wednesday, May 27, 2009 | Posted by

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();
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

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

The different references views in the heap walker

Wednesday, May 13, 2009 | Posted by

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

Evaluation of cross-platform installer builders

Friday, April 24, 2009 | Posted by

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.

Finding a memory leak with JProfiler (old)

Thursday, April 23, 2009 | Posted by

There is a newer version of this screen cast.

This version is outdated with respect to the heap walker, but it also shows useful features outside of the heap walker.

Object counts in dynamic memory views and the heap walker

Wednesday, April 22, 2009 | Posted by

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.

I will explain below what tools you can use to sign your executables, but first, you would need a Microsoft Authenticode Certificate from a certificate authority like Thawte:


In their order process, they will generate a private key (PVK) file and a certificate request. After Thawte verified your identify, they will provide you a SPC file that contains your certificate. There are a bunch of other certificate authorities, most notably verisign where the process is quite similar.

Code signing on Windows

On Windows, you can quite easily use Microsoft's tools like signcode or signtool which are contained in the freely available Platform and .Net SDKs. You can find the documentation in the MSDN:


Below is a good summary of how to use signtool:


It also explains how to convert different file formats that other certificate authorities might issue.

Code signing on other platforms with Mono's signcode

It is also possible to sign executables on other platforms. The $INSTALL4J_HOME/resource/signcode.exe executable is a mono executable modified by ej-technologies to support signing of 64-bit executables. This executable can only be executed if mono is installed. Mono is available for a number of platforms and can be downloaded free of charge.
The tool has the same syntax as the one from Microsoft. A typical entry would be mono /opt/install4j/resource/signcode.exe -spc mycert.spc -v mykey.pvk -vp password -t http://timestamp.verisign.com/scripts/timstamp.dll $EXECUTABLE
Some SPC files cannot be read directly by this tool. If this is the case for your certificate, you can export all CER files from the SPC file and generate a new SPC file with the cert2spc tool included with mono. You have to add the CER files in the order of the certificate chain (your own certificate is the last one on the command line).
Code signing on other platforms with openssl and osslsigncode
If you want to avoid installing mono or have problems with your SPC file, you can also use a different tool called osslsigncode in conjunction with openssl. Here is a download with a patch for signing PE32+ (Windows x64) executables. A short ./configure && make should be sufficient when you have curl and openssl installed.
This tool requires the private key in a different form, though. First, you would have to convert your PVK file to a PEM file with this tool on Windows. A typical command line would be simply pvk -in mykey.pvk -out mykey.pem. The upcoming openssl 1.0 will also be able to do this conversion.
The PEM file is still encrypted, but osslsigncode needs an unencrypted DER file. You might want to generate this DER file directly before your build process and delete it afterwards to avoid having your private key hanging around unencrypted longer than necessary. The conversion to a DER file is done with openssl rsa -passin pass:XXXXX -outform der -in mykey.pem -out mykey.der.
A typcial command line in install4j would then be osslsigncode -spc mycert.spc -key mykey.der -t http://timestamp.verisign.com/scripts/timstamp.dll -in $EXECUTABLE -out $OUTFILE. Remember that the spc and key files can be specified relatively to your install4j project file.
Update: As of install4j 5.1, code signing is implemented directly and the above mentioned tools are no longer required.


Tuesday, April 21, 2009 | Posted by

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