ej-technologies blog Ingo Kegel Page 8

In the screencast below, I discuss cross-links between the various monitor views. The profiled test program is the same as in the screencast on Locking graphs in JProfiler.

https://www.youtube.com/watch?v=ChlPb-3E5Ko

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

https://www.youtube.com/watch?v=6w-utHPJVog

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
                        Thread.sleep(3000);
                        monitor.wait();
                    } catch (InterruptedException e) {
                        e.printStackTrace();
                    }
                }

            }
        };

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

        // After 20 seconds, all threads are woken up and the test class
        // terminates
        Thread.sleep(20000);
        synchronized (monitor) {
            monitor.notifyAll();
        }
    }
}

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

https://www.youtube.com/watch?v=6sj0dxHFr2E

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;

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

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

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.

For The IntelliJ IDEA integration, this screen cast is outdated, please watch the more recent version instead.

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

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

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