ej-technologies blog

Welcome!

Ingo Kegel — Tue, 21 Apr 2009 07:00:57 GMT

Categories: General

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

Object counts in dynamic memory views and the heap walker

Ingo Kegel — Wed, 22 Apr 2009 07:00:57 GMT

Categories: JProfiler

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.

Signing launchers and installers

Hannes Kegel — Wed, 22 Apr 2009 07:00:57 GMT

Categories: install4j

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:

https://www.thawte.com/code-signing/index.html

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:

http://msdn.microsoft.com/de-de/library/9sh96ycy%28VS.80%29.aspx

Below is a good summary of how to use signtool:

http://www.curlybrace.com/words/2008/09/12/using-certificates-and-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

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.

Finding a memory leak with JProfiler (old)

Ingo Kegel — Thu, 23 Apr 2009 07:00:57 GMT

Categories: JProfiler Screencast Memory Leak

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

Evaluation of cross-platform installer builders

Ingo Kegel — Fri, 24 Apr 2009 07:00:57 GMT

Categories: install4j

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.

The different references views in the heap walker

Ingo Kegel — Wed, 13 May 2009 07:00:57 GMT

Categories: JProfiler Screencast Memory Leak

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.

Changing the visibility of form components at runtime

Ingo Kegel — Wed, 27 May 2009 07:00:57 GMT

Categories: install4j

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.

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

Ingo Kegel — Thu, 18 Jun 2009 07:00:57 GMT

Categories: install4j

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.

JProfiler's IDE integrations

Ingo Kegel — Tue, 30 Jun 2009 07:00:57 GMT

Categories: JProfiler Screencast

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.

Appending to redirection files

Ingo Kegel — Thu, 09 Jul 2009 07:00:57 GMT

Categories: install4j

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.

Thread states in the CPU profiling views

Ingo Kegel — Fri, 10 Jul 2009 07:00:57 GMT

Categories: JProfiler Screencast

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

Fine-tuning console installers

Ingo Kegel — Thu, 06 Aug 2009 07:00:57 GMT

Categories: install4j

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;

Allocation recording explained

Ingo Kegel — Fri, 14 Aug 2009 07:00:57 GMT

Categories: JProfiler Screencast

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

Locking graphs in JProfiler

Ingo Kegel — Fri, 27 Nov 2009 08:00:57 GMT

Categories: JProfiler Screencast

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

Monitor events versus locking situations

Ingo Kegel — Thu, 21 Jan 2010 08:00:57 GMT

Categories: JProfiler Screencast

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.

Cumulating and filtering monitor events

Ingo Kegel — Fri, 05 Feb 2010 08:00:57 GMT

Categories: JProfiler Screencast

In the screencast below, I explain how monitor events in the locking history graph can be cumulated and how you can select monitors and threads of interest.

Offline profiling and triggers

Ingo Kegel — Mon, 29 Mar 2010 07:00:57 GMT

Categories: JProfiler Screencast

In the screencast below, I explain how to automate profiling with offline profiling and triggers, so that you do not have to use the JProfiler GUI for profiling and can analyze profiling results later on.

Migrating to install4j 5

Ingo Kegel — Thu, 17 Jun 2010 07:00:57 GMT

Categories: install4j Migration

Those who made the move from install4j 3 to install4j 4 will remember that it was a lot of work to migrate custom code, because most core concepts had been changed.
Not so with install4j 5 : Your old project file will be transformed to the new format and most projects will work right away, without the need for any manual work. If you are interested in the changes in the project file structure, please see the file config/transforms/transform_3.xsl in your install4j installation directory.

However, there are a number of cases where old functionality has been replaced, behavior has been changed or the API has been fixed. In those cases backwards incompatibilities can arise. This post intends to present an exhaustive list of them:

We have removed support for Java 1.3. This allows us to use the standard XML beans decoder and XML parser in the JRE. Java 1.4 is still supported.
The "Require admin user" action and the "Request admin privileges on Windows Vista" option on the "Installer options" step of the Windows media wizard have been removed. They have been replaced with a much more capable "Request privileges" action. The "Request privileges" action is now added to all projects by default and will be inserted into the "Startup" sequence of old projects as well. If you had a "Require admin user" action in your project, the "failure" properties will all be selected (they are otherwise not selected by default). If you had a condition expression on the "Require admin user" action, it will be lost. Especially platform-dependent configuration is now possible directly in the "Request privileges" action.
On the Installer->Custom Code tab, the old "Use installed JAR files if possible" option has been removed. Previously, the installer performed a two-phase initialization of screens and actions, before and after the "Install Files" action, so you could use custom code from installed JAR files. The main reason for that option was to prevent double packaging of JAR files, once for the installer and once for the launcher. In install4j 5, if entries in the custom code are also present in the distribution tree, they will be moved to the final destination by the "Install Files" action, and the custom code will automatically include the installed files in custom installer applications and the uninstaller. This change significantly improves custom code handling, because double packaging is always prevented and you can use such custom code before the "Install Files" action is executed.
However, if your code depends on the location of the JAR file, this can be a breaking change and you have to change your custom code. In that case, the new Screen#isCreatedLazily() method and the optional Context#initializeLazilyCreatedScreens() method will help you to move the initialization of the custom screen after the "Install Files" action while the Context#addToClassPath(File) method allows you to add installed JAR files to the custom code for dependencies that only work in the installed location.
The compiler variable "sys.platform" now resolves to "windows-x64" for 64 bit media files. Previously, it always resolved to "windows". This variable is used in the standard media file name pattern on the General Settings->Media File Options tab, so your 64-bit Windows media files will now be named differently if you have not changed or overridden the media file name.
There was a typo in the system message key name "LocateBrowerExecutable". In the unlikely event that you used that key explicitly in your project before, it will lead to a runtime exception.
A few installer variable names have changed to make naming more consistent. The old names will be replaced automatically with the new names when you open your old project file for the first time. However, if you use them outside the install4j IDE, for example, in custom code, you will have to change them. The replacements are:
- sys.mediaDirectory -> sys.mediaDir
- sys.installerDirectory -> sys.installerDir
- sys.programGroup.name -> sys.programGroupName
- sys.programGroup.linkDir -> sys.symlinkDir
- sys.programGroup.allUsers -> sys.programGroupAllUsers
(Updated on 2010-07-15) The "Services" screen has been removed. The reason is that since the service actions now support arbitrary service executables (not only those generated by install4j), it would be difficult for us to present a list like in 4.x. Also, we feel that this is really a technical question that users should not have to answer. If needed, you can create a question with a configurable form. The "Hello world" project has such a screen.

Other breaking changes only concern the API:

The method ApplicationRegistry.ApplicationInfo#getProgramGroup() has been removed from the API. It has been obsolete since 4.2, when the "Load reponse file" action was added. In the GUI, the "Suggest previous program group" option on the Installer->Update Options tab has been removed as well.
Several typos in method names have been fixed. Fortunately, typos were only discovered for the rarely used methods Context#isErrorOccurred(), Context#setErrorOccurred(boolean) and
FormComponent#initialize(). If you are affected by the first two changes, the build will fail. If you derive a form component from AbstractFormComponent, the third change concerns a method that is overridden and would not cause a compilation error, so we have added a method for backward compatibility in that case.
Several methods in the Install4jBeanInfo and Install4JPropertyDescriptor classes had their return values changed from void to the class itself in order to facilitate usages in builder patterns. You just have to recompile your code against the new runtime library, no source code changes are required.
The Context#getWizardContext() does not return null in unattended or console mode anymore. Instead, a dummy wizard context is returned that does nothing when its methods are invoked. If you use Context#getWizardContext() to check for those installer modes, you have to change your code and use Context#isUnattended() and Context#isConsole() instead.
The "installerAndUninstaller" argument from ActionBeanInfo#setAssociatedStartupAction(String) was removed because the new ActionBeanInfo#setComplementaryStartupLink(boolean) makes more sense.

That's it! Most of these changes are only breaking changes for corner cases and even then it should be easy to fix them. If you notice any other breaking changes, please let us know, so we can add them to this list.

Market study for multicore software development tools featuring JProfiler

Ingo Kegel — Wed, 27 Oct 2010 07:00:57 GMT

Categories: JProfiler

The Fraunhofer IAO has published a study on multi-core software development tools that features JProfiler.

The study can be viewed free of charge, but requires a registration for download. The abstract of the study is as follows:

To unlock the performance potentials of current processors, software has to be adapted for execution on multiple cores; it has to be parallelized. This requires the identification of parts that can run concurrently, adaptation of these parts, testing of the changes for correctness and the coordination of the concurrently running parts with regard to performance and scalability.

In this study Fraunhofer IAO characterizes the challenges of software development for multicore processors and presents tools that assist in the process. Profilers reveal parallelizable parts, programming languages and libraries help with the correct introduction of parallelism, debuggers show errors during parallel execution and tuners help achieving maximum parallel performance.

JProfiler's extensive support for locking analysis introduced in 6.0 is an important tool for this kinds of analysis.

My first try with install4j

Emmanuel — Tue, 14 Dec 2010 08:00:57 GMT

Categories: install4j Tutorial

A tutorial for beginners

This tutorial shows the various features offered by install4j 5.0 through the step by step configuration of an installer for Sweet Home 3D, a free open source Java program (so you can reproduce these steps if you want to).

In its current version 3.0, Sweet Home 3D may be installed with Java Web Start or its own installer (built with Inno Setup and launch4j tools under Windows). But install4j is able to build much more powerful installers and Java launchers than these free products.

Downloading and installing install4j

install4j can be downloaded from this page. If you want to test it before buying a license you'll have to fill this form to receive an evaluation key.

install4j is available for various operating systems and is available in two versions for each operating system, depending on whether you have already installed a JRE 6 on your computer.

From the previous matrix, I download the Setup Executable (21 MB) for 64-bit Windows and double-click on the installer icon once the file was downloaded.

Installing install4j already gives an idea of its abilities because the installer was of course built with install4j itself. Once the installer launched, I'm surprised to get a screen telling that no JRE is installed on my computer:

But in fact the installer was right, I didn't have a 64-bit JRE but only a 32-bit JRE! Therefore I click on Download to get a 64-bit JRE.

From the license agreement, installation directory selection to license key entry and auto-update configuration, the 10 steps that following look familiar compared to other installers.

Launching install4j

At first launch, Windows Firewall asks me to let install4j use the network to check its license key. I accept to ensure all features of install4j will work.

Then the main screen of install4j appears and shows the various features offered to create an installer.

Now I'll try to create a first version of an installer and launcher for Sweet Home 3D.

General settings

First, I fill the Application Info tab with the software's name and version.

Then, in the Java Version tab, I require a minimum Java version 1.5.

In the Languages tab, I keep English as the principal language and add all the languages supported by Sweet Home 3D found in the list (just missing Bulgarian and Vietnamese).

In the Media Files Options, I choose an Installer directory on my desktop as output directory, change the name pattern to "${compiler:sys.shortName}-${compiler:sys.version}-${compiler:sys.platform} " in respect to the format previously used for older versions of Sweet Home 3D, and uncheck Convert dots to underscores option.

Note that this name pattern uses some variables between ${ and } symbols. There are all kind of variables available in install4j (you can even create your own if needed) and you can select them in many text fields by clicking on the Insert variable button (the arrow button) that appears behind them.
The "${compiler:sys.shortName}-${compiler:sys.version}-${compiler:sys.platform} " pattern will resolve to SweetHome3D-3.0-windows for a Windows installer.

As Sweet Home 3D's current distribution is around 30 MB, I prefer the smallest distribution possible and I also increase Compression level to 9 and check all the compression options

Once General Settings are done I save my Installer project in the Installer directory of my desktop.

Files

Now I choose files that should be included in the distribution by clicking on the Files icon below the General Setting one. These files could be assembled by invoking the appropriate Ant target in the build.xml file of Sweet Home 3D project, but as this tutorial isn't about Ant, I prefer to use the files installed by the existing setup program available here. I launch this program and install the files in C:Program Files (x86)Sweet Home 3D 3.0 directory.

Once the existing installer finished, I have to include the jar and license files in the distribution tree of install4j. These files are indicated in blue in the following list:

Clicking on the Insert button (the green plus button), I choose the Add Files and Directories option,

and choose the Directory entry type for the C:Program file (x86)Sweet Home 3D 3.0lib directory with the option Add to subdirectory selected, then Single files type for the licenses files.

I also have to include the javaws.jar file found in the jre6lib subdirectory and required by Sweet Home 3D to run. I insert this file as as a Single file type and to make it appear in the lib subdirectory among other jar files, I insert a new folder named lib where I drag and drop the javaws.jar line.

All these files and directory finally appear in the list of the Define Distribution Tree tab.

Launcher

As I don't need to set any File options or don't want to propose optional files at this moment, I now click on the Launchers icon below the Files one, and double click on the New launcher icon.

This will launch a wizard used to create a launcher. As I want to generate a new launcher to test install4j features, I keep the Generate launcher option selected.

Then I give application name and the directory where it should appear. The Executable info second step offers also an interesting option that allows only a single running instance, that I would check if I didn't program already such a feature in Sweet Home 3D.

In the Advanced Options list, I choose Windows version info and check the Generate version info resource to get correct values in the file properties dialog box of the future launcher. I let install4j replace Product name and File version fields and enter values in Internal name, File description and Legal copyright text fields, using some existing variables.

The Icon third step proposes to choose an icon for the program. I select Add icon to launcher option, and configure the program icons at 3 different sizes and add them to the Cross-Platform Image File list.

The Java invocation steps shows information required to run a Java application. In VM Parameters, I increase the maximum memory to 512 MB and specify where Java 3D DLLs are available with the parameters -Xmx512m -Djava.library.path=lib (DLLs directory can be set with Advanced Options > Native libraries too). I enter program main class com.eteks.sweethome3d.SweetHome3D and enter -open in Arguments text field because Sweet Home 3D expects this selector before any file passed as an argument.

Now I need to complete the Class path list, which accepts individual jar files, directories containing jar files, directories containing .class files or resources, and information from environment variables. As I keep all the jar files in the lib subdirectory, I click on the Insert button, select the Scan directory option and enter lib directory.

The VM options file step offers an interesting option to the end users who can change default VM parameters in case they need it. As Sweet Home 3D uses a few System properties and may require more memory to run, I keep the default Copy template file with explanations for user selected.

Finally, in the Splash screen step, I can choose the splash screen image that should be displayed during program launch. As Sweet Home 3D handles this feature itself, I don't change default settings but note that you can use install4j splash screen or Java 6 one if needed.

The Advanced options let you even write some texts over the image. Nice!

Once the Launcher wizard is finished, a new launcher icon is added to Launchers screen to let you change launcher settings later.

Installer

The Installer screen describes the various screens that will be displayed to the end user during program installation and uninstallation. It's a highly configurable tool with many options that you can even extend if needed. The screens in the default template will show six screens from Welcome screen to Finish screen.

In the Screens & Actions tab, these screens are represented with an icon showing a gear in a window and sometimes by custom icons like the one used for the Installation screen . The tree shown on the left contains also some actions represented with a gear icon window and by custom icons like the one for the Startup action . An action is simply one or more statements (either preprogrammed ones or custom ones programmed in Java) that the installer should run during the installation.

To ensure the installer created with install4j behaves as the existing one, I'll add two screens:

one displaying the GNU GPL license of the software,
one that will let the user accept file associations,

and I'll add also two types of actions:

some registering file extension associations,
one that will let the user launch Sweet Home 3D once the installation is finished.

To add the new screens, I click on the Insert button and choose Add Screen in the popup menu.

In the displayed Select an Installation Screen dialog box, I filter the shown list by entering the first letters of "license ". Once I select Display license agreement item, I definitively know that screen has some good chances to be the one I look for from its Description displayed below.

I click on OK and the new screen is automatically inserted after the Welcome screen, just at the right place I wanted it to appear!

I now enter missing values in the screen properties list displayed at the right. I edit the License file property and install4j lets me choose it either as a file packaged with the installer or coming from installed files.

I choose the first option and select the COPYING.TXT file that contains the GNU GPL license text. As the license wasn't translated to other languages, I leave the file empty for the other languages, so the default text in English will be displayed.

Then I select the User must scroll to bottom option in the hope it will get more users to read the GNU GPL license.

I click again on the Insert button to add a File associations screen and select File associations item in the Select an Installation Screen dialog box.

Once I click on OK, install4j warns me that the File associations screen requires one or more File association actions to work.

I close the warning message. The File associations screen is added between Create program group and Installation screens, and I check Show selection buttons property to speed up user choice. As Sweet Home 3D has 5 file associations, these buttons will let him or her to select or deselect them with one click.

As file associations should be made only after the executable that handles them is installed, I select the Installation screen in the tree, then I click on the Insert button to add the desired action. In the displayed Select an Installation Action dialog box, I filter the shown list by entering the first letters of "association " to quickly find the Create a file association action among the 60+ preprogrammed actions.

Once I click on OK, install4j appends the new action to the Installation screen, and in the properties list associated to the action, I enter "sh3d " File extension, describe it as "Sweet Home 3D document " and select the SweetHome3D launcher.

Then I add the file associations for sh3f, sh3t, sh3p and sh3l extensions in the same way.

For the action that should launch Sweet Home 3D at the end of the installation process, I select the Finish screen, click on the Insert button and select Add action. In the displayed Select an Installation Action dialog box, I filter the actions list with the first letters of "launcher " and select Execute launcher action.

Once I click on OK, install4j asks me whether I want to add a check box to the Finish screen that will will let the user choose to launch the program or not.

I accept and in the properties list of the Execute launcher action, I finally choose SweetHome3D as the launcher to run.

At the end, I get the following list of screens and actions for Sweet Home 3D installer.

Media

As I don't need Custom code or Update features at this time, I jump to the last part of the installer preparation by clicking on Media icon, then double-clicking on New media file icon.

This will launch a wizard to configure a Media file. As I prefer an executable installer, I choose Windows in the Installer type combo box.

In the Configure installer options step, I change installation directory to "Sweet Home 3D ".

The Installer data files step doesn't need any change since I want to create one installer file that will contain everything required.

I don't check the 64-bit executable option in the Select the architecture of the generated executables step since the Java 3D DLLs delivered with Sweet Home 3D are 32-bit only.

As I don't have any code certificate I must pass the Configure code signing for launchers and installer step too.

The Bundle a JRE with your application step is more interesting for my use case.

As I want to bundle a JRE with Sweet Home 3D to spare users the installation of a JRE, I select the Bundle the following JRE option and chose the most recent one after clicking on Download JREs.

Once the JRE is downloaded, I select it in the Bundle the following JRE combo box.

I'm not interested by any of the Customize project default settings last step, and I can finish the Media Wizard execution that will add an icon for the newly created media.

Build

The installer is now ready to be built. I click on Build icon and then on Start Build button.

After 60 seconds, the installer is generated, and my first surprise is than the generated SweetHome3D-3.0-windows.exe file is more than 4 MB smaller than the one generated by Inno Setup (26 MB instead of 30.6 MB)! This is probably due to Pack200 compression algorithm.

Test

I double-click on the new installer icon to launch it and get the expected installation screens sequence.

Once Sweet Home 3D is installed and launched, I check how it's listed in the Processes tab of the Windows Task Manager : it appears as SweetHome3D.exe which is much nicer than javaw.exe.

Conclusion

With install4j you can easily create an installer and launcher for your Java application. Even if there are many steps in this installer wizard, you really feel install4j takes you by the hand to the right target. But in fact, install4j offers much more features that I'll test in a second article.

I'll use install4j to download some optional files for Sweet Home 3D and configure some program parameters, like memory settings, system properties and default preferences files.

I'll also show how to use the different installation modes and how to update the program automatically.

More installation options with install4j

Emmanuel — Tue, 21 Dec 2010 08:00:57 GMT

Categories: install4j Tutorial

Last week, I explained how to build an installer with install4j for Sweet Home 3D, that would behave as the one distributed on the website of the program.

But Sweet Home 3D and install4j provide some options that could be nice to offer to end users at installation time like:

keeping the language chosen at installation as the default language of the program,
configuring the max memory amount used by the program from the RAM available in the computer,
offering to download and install an optional program like the Furniture Library Editor,
downloading some optional files like archives containing 3D models,
offering special options when the program is installed on a USB key,
offering to delete program and configuration files during uninstallation,
translating the text of the special options added to the installer,
installing the program in unattended mode to speed up its deployment in
schools.

Storing the chosen language

In Sweet Home 3D, the user may change the language used in the graphic interface with the preferences panel displayed when he selects the File > Preferences menu item. The persistence of his choice is managed with Java Preferences class which stores its values in the registry under Windows. install4j offers an action able to set the value of a Java preference and I'm going to use it to store the language used in the installer.

As I want this action to occur after files were installed, I select Installation node in install4j and choose Add Action in its contextual menu.

I type the the first letters of "preferences " in the Filter text field and select the Set a key in the Java preference store action among the 5 actions dealing with preferences.

Once I click on OK, I fill the Java preference properties of the action from the matching value read in Sweet Home 3D. I set Package name value to "com.eteks.sweethome3d.io " and Key value to "language ".
The value of the Value text field must be set according to the language currently used in the installer, something stored in one of the install4j variables. To find it out, I click on the button arrow at the right of the text field and select the Insert Installer Runtime Variable option.

In the Select Installer Runtime Variable dialog box, I filter variables with the first letters of "language " and choose sys.languageId variable.

Finally, I choose User specific for Preference root field.

Configuring the max memory of the program

Sweet Home 3D may require a lot of memory in some circumstances, and the default amount of maximum memory used by a Java Virtual Machine is generally not enough to let the program work correctly for big layouts. At the opposite, if too much memory is required, the program may slow down too much because the operating system will have to manage the missing RAM with disk swapping. A nice option could be to fix the maximum memory used by the JVM by program according to the available physical memory. This amount of memory is passed to the JVM with the option -Xmaaaam where aaaa matches the maximum memory in MB.

I already set -Xmx to 512m during the configuration of a launcher by setting the VM parameters value at the fourth step of the launcher creation wizard.

To set this value according to the memory available on the end user computer, the easiest way is to remove the -Xmx512m option from VM parameters and add an action to update VM parameters when the installer is run. As this action should happen at the end of the installation, I select the Installation node, click on the Insert button (the button with a green plus) and select the Add Action menu item.

In the Select an Installation Action dialog box, I choose the Add VM Options action,

and once I click on OK, I edit the properties of the action to set SweetHome3D as Launcher value and enter the text "${installer:xmx} " in VM options text field.

This value references the installer:xmx variable that will be evaluated at installation time, when the installer will be run. As I need to create this variable and give it a value, I click again on the Insert button and select Add Action menu item. This time, I choose the Set a variable action in the Select an Installation Action dialog box.

Once I click on OK, I move the new action one row up before the Add VM options action by clicking on the blue up arrow, edit the properties of the action to set the "xmx " name of the new variable without its installer prefix, and click on the button with an ellipsis at the right of the Script text field to edit its value.

This opens a text editor where I have to enter a Java expression whose value will be saved to the xmx variable.

The comment displayed by the editor suggests I can use the two context and action parameters if required, and the classes of these two parameters are com.install4j.api.context.InstallerContext and com.install4j.api.actions.InstallAction shown as hyperlinks to their respective javadoc pages.

The great thing is that editor offers auto completion when I press Ctrl + space keys! For example, if I try to complete "co " I'll get "context " at the top of the suggested items and other items starting by "co ".

I choose context, type a dot to invoke a method of the InstallerContext class, but there are so many choices that it's quite difficult to find out the method that returns the memory available in the computer where the installer runs (this value isn't available in Java SE 6 too).

Therefore I explore the help file, which seems pretty complete, since I find the information I need with a search of the "memory " keyword which brings me to the method getPhysicalMemory in the com.install4j.api.SystemInfo class.

As this method is static, I finally enter the expression
"-Xmx" + (SystemInfo.getPhysicalMemory() / 2 / 1024 / 1024) + "m"
and as the green square drawn at the end of line confirms, the syntax of my expression is correct,

I click on OK, save my install4j project, build it and run the installer to check how it works.

As setting this option won't change anything at the screen, I run SweetHome3D.exe executable file in a command window with the option /create-i4j-log that will create a temporary log file. To help me to find this log file, install4j displays an information dialog box recalling where it can be found.

Reading this file I can see a vmoption line with -Xmx755m option stating the half of the 1.5 GB memory of my computer might be occupied by the Java program.

Downloading an optional program

A program called the Furniture Library Editor was recently added as a separate application. It allows the user to import and edit faster the attributes of a group of 3D models instead of importing them one by one in the program.

This program is a Jar executable application and I want to suggest it as an option in the installer. As it is around 5 MB large, it won't be bundled with the installer but downloaded if the user wants to install it.

To make it a downloadable file, I have to add it to the installer Files and then select it as a downloadable component in the Media wizard. Therefore, I download FurnitureLibraryEditor-1.2.jar in the Installer directory on my desktop, and add it to the Installation directory node in the Files screen as a single file with the Insert button (the button with a green plus).

Then I create a new launcher for the Furniture Library Editor as I did for Sweet Home 3D, by clicking on the New launcher icon in Launchers screen.

This time, I name the executable file as FurnitureLibraryEditor, select the Allow only a single running instance of the application option,

fill the Windows version info resource,

configure its icon in the Icon step,

configure program launch by adding FurnitureLibraryEditor-1.2.jar archive in class path and using com.eteks.furniturelibraryeditor.FurnitureLibraryEditorBootstrap as main class,

and no splash screen. I finally see the new laucher item in install4j.

To make FurnitureLibraryEditor-1.2.jar and its launcher optional files, I then click on the Installation Components tab to create components that group files by application. I click on the Insert button, enter first the name of the basic component that will contain the Sweet Home 3D application files and click on OK.

In the Files tab, I select all the files except FurnitureLibraryEditor-1.2.jar and its launcher,

Then I create a second component for the FurnitureLibraryEditor-1.2.jar file that will be downloaded.

In the Options tab of that component, I unselect Initially selected for installation option and select Downloadable component

As the launcher of the Furniture Library Editor won't be downloaded but will be bundled with the installer (launchers are small files of 250 KB), I create a third installation component named Furniture Library Editor launcher for it, select [Launcher] FurnitureLibraryEditor file and change the options to hide it to the end users, because it would be useless to ask them to check two options if they want to install the Furniture Library Editor.

Now that installation components are created, I go to the Installer screen and select the Installation components node, that will be displayed from now on since I created installation components.

As I need to select the Furniture Library Editor launcher component if the Furniture Library Editor component is selected by the user, I click on the ellipsis button beside Selection change script field and enter the matching Java statement

Each component, screen or action in install4j has a unique ID and I need to find the ID of the Furniture Library Editor launcher component to pass a correct value to getInstallationComponentById method call. The IDs of install4j items can be displayed by clicking on the Show IDs button found on many screens, but to avoid closing the editor window, I prefer here to click on the Insert ID button to find the desired ID. This will open a dialog box where I enter the first letters of "Furniture " and find the ID of the component is 376.

I click on OK to close the script window, and finally go to the Media screen to update the Windows media file

that requires to be completed with the URL http://ovh.dl.sourceforge.net/project/sweethome3d/FurnitureLibraryEditor/ where FurnitureLibraryEditor-1.2.jar can be downloaded from.

I build a new installer and test it. A new step is now displayed that will let me choose what I want to install.

I select the Furniture Library Editor option and check that the new application is available in Sweet Home 3D group.

Downloading other optional files

Sweet Home 3D lets the user import pieces of furniture one by one, but also by group of pieces from .sh3f files (that the Furniture Library Editor can edit). At this time, four .sh3f files are available to download 400 models separately, but I'm going to offer them as optional files during installation time.

The 4 files to download are these ones:

Once downloaded, these files should be unzipped in a private directory of Sweet Home 3D that depends on the target system. Under Windows 7 and Vista, it should be under the directory C:UsersuserAppDataRoamingeTeksSweet Home 3Dfurniture and under previous versions of Windows C:Documents and SettingsuserApplication DataeTeksSweet Home 3Dfurniture, where user is the user's login name.

This time, unlike during the previous part where I installed an optional program, I'll create an Installation Components associated with no files, then use the Download file and Extract a ZIP file actions.

Thus, I create four additional Installation components in the proper tab of the Files screen. To simplify the way to find them later, I create a custom ID for each of them with a value equal to its name.

Then I unselect the Initially selected for installation option and select the Downloadable component option for the 4 new components.

To manage the download of the optional files, I go to the Installer screen, select the Installation node and insert a Download file action.

In the properties of the Download file action, I set the URL to "http://ovh.dl.sourceforge.net/project/sweethome3d/SweetHome3D-models/3DModels-1.1.1/3DModels-Contributions-1.1.1.zip ", the Target file to "${installer:sys.workingDir}/3DModels-Contributions-1.1.1.zip " and select the Delete downloaded file on exit since it won't be needed once unzipped.

Then I click on the ellipsis button beside the Control Flow / Condition expression field to enter the condition when this action should be executed

To unzip the downloaded file to the right directory, I insert a Extract a ZIP file action after the Download action.

In the properties of the Extract a ZIP file action, I set the Zip file to "${installer:sys.workingDir}/3DModels-Contributions-1.1.1.zip " and enter a File filter script condition that will extract only files ending with .sh3f.

I enter "${installer:privateDir}furniture " in Destination directory field because the place where the application configuration data is stored varies from one operating system to the other, and set the value of the privateDir variable with a new Set a variable action, setting its script to the corresponding
method in Sweet Home 3D.

Finally, I move the Set a variable action two rows up and I create the same Download file / Extract a ZIP file actions for the 3 other optional downloads. Installation screen runs 20 actions now!

Once built, the new version of the installer displays the options to download the optional files,

and if I check some of them, it will download them.

Setting special options

From the previous parts, you understood that like many other applications, Sweet Home 3D stores its configuration data in private directories. But some users want to be able to move an application and its configuration around without bothering how to copy this data, and requested to make Sweet Home 3D portable (not across operating systems, but across different computers). This ended up by the new com.eteks.sweethome3d.preferencesFolder and com.eteks.sweethome3d.applicationFolders system properties that give the directories where Sweet Home 3D will store its configuration data.

To spare end users the difficulty to set these properties, I'm going to add a new screen shown after the Installation location screen where the user will be able to choose whether he wants to install Sweet Home 3D as a portable application or not, when he chose a removable drive as installation destination.

To create this customized screen in install4j, I select the Installation location node in Installer screen, click on the Insert button and choose Add screen option.

In the Select an Installation Screen dialog box, I choose the Configurable form item in the list of screens and check Insert after selection at the bottom of the dialog box.

Once I click on OK, the new screen is added in the Installer screen sequence.

I click first on the Configure Form Components button to add a checkbox to the empty form. In the dialog box that appears, I click on the Insert button and choose the Add Form Component option.

This will open another dialog box in which I can choose among more than 30 different components. I choose a Check box component,

and click on OK. In the properties list of the inserted checkbox, I enter "Install as a portable application " as the text check box, enter "portable " as the variable name associated to this check box and select the Initially selected and Request focus check boxes.

As this new option isn't so easy to understand, I click on the ellipsis button of the Help text field and enter a text that explains this option,

and click on OK. Then, I click on the Preview Form button at the top right of the dialog to check how the checkbox and its help text will be shown.

This looks nice but the screen title and subtitle are still missing! I close the Configure Form Components and click on the Properties tab of the Configurable form node,
where I enter "Removable drive option " in Screen title text field and "Should application installation be portable? " in Screen subtitle text field.

As this screen should be displayed only if the user chose a removable drive, I finally click on the ellipsis button of the Condition expression property to enter the condition.

As this condition can be checked only under Windows I check first if the installer is running under Windows with a call to Util.isWindows(), then I use the getDriveType method of the WinFileSytem class to check if the installation directory chosen by the user is removable or not.

The new screen is now configured, and I have to use the value of the portable variable bound to the checkbox to configure Sweet Home 3D accordingly on the installation screen. As this variable won't exist if the new screen isn't displayed, I predefine it by clicking on the Installer node, then on the Configure Predefined Installer Variables button in the Installer Variables tab.

In the Edit Installer Runtime Variables For "Installer" dialog box, I click on the Insert button and choose the Add New Predefined Installer Variable option.

I set the name of the new variable as "portable ", set its type to Boolean and its default value to false.

I click on OK and use the portable value in the Installation node to add new VM options that will set the desired system preferences: I select the Set a variable action that defines the privateDir variable to add this new action after it, click on the Insert button, select Add Action option and choose the Add VM options action.

I confirm my choice, select SweetHome3D launcher, enter the two lines
"-Dcom.eteks.sweethome3d.preferencesFolder=${installer:privateDir} " and
"-Dcom.eteks.sweethome3d.applicationFolders=${installer:privateDir} " in its VM options text field, and set its condition expression as "context.getBooleanVariable("portable") "

These options reference the variable privateDir whose value must take into account the value of the portable variable, too. Therefore, I select the Set a variable action that defines the privateDir variable and click on the ellipsis beside its Script field to update it.

While editing this script, I got the context.getVariable("sys.installationDir") Java expression that returns the value of the sys.installationDir install4j variable by clicking on the Insert Variable button, chosing Insert Installer Runtime Variable item and selecting the sys.installationDir variable.

I build this updated configuration and try the new version of the installer that displays the new screen if I choose to install it on a USB key.

Uninstalling a program and its configuration data

Sweet Home 3D stores user preferences and configuration data in private directories to help users to upgrade the installed version of the software without losing data. But sometimes some users want to really remove all information bound to the installed software. Installers built with install4j are highly configurable, and their uninstaller counterpart is as much configurable as the installer, so I'm going to add a screen that will ask the user whether he wants to delete Sweet Home 3D private files or not, and add some actions that will handle his answer.

I select the Uninstaller node in Installer screen, click on the Insert button, select the Add Screen option and choose the Additional confirmations screen.

Once I click on OK, I move the Additional confirmations screen after Uninstall Welcome screen with the blue arrow button, and click on the Configure Form Components buttons.

In this form, I'm going to add a checkbox to confirm the deletion of Sweet Home 3D private data:

I click on the Insert button, select the Add Form Component option and choose Check box among the list of components.

I enter "Sweet Home 3D private data " as the displayed Text,

and click on the ellipsis beside Help text field to detail what will be deleted.

Finally, I enter "privateData " in the Variable name text field associated with this check box.

I close the Configure Form Components dialog box and click on Unistallation node to add a new action to it.

I filter the actions list with "delete " and choose the Delete a node or key in the Java preference store action.

I enter the "com.eteks.sweethome3d " package in the properties list, unselect the Only if empty check box and let the Key field empty to delete all the preferences associated to this package node.

I click on the ellipsis beside the Condition expression field, insert the value of the privateData variable to check the condition, and confirm my choice.

To delete private files, I add a Delete files and directories action to Unistallation node with the same Condition expression and select the Recursive option.

The files to delete are in the directory referenced by the privateDir variable created at installation time, but I need it also at uninstallation time. Like privateData variable, the value of an installer variable is available in the uninstaller if it's predefined in the installer and marked as a response file variable. A response file is a properties file that contains key-value pairs for installer variables. This file is created during installation process and is reused during uninstallation.

All the variables bound to a form component like the portable variable bound to the Install as a portable application check box, are automatically saved in a response file. But the privateDir variable isn't bound to any component, and I have to define it as a predefined variable and register it as a response file variable.

Thus, I click on the Installer node, select Installer Variables and click on the Configure Predefined Installer Variables button.

I click on the Insert button, select the Add Predefined Installer Variable option and enter the name "privateDir ".

I confirm my choice and add a new Run script action to the Startup node

that will register the privateDir variable as a response file variable.

Finally, I select again the Delete files and directories action, and complete its Files and directories field by clicking on the ellipsis button beside it. In the Edit Files dialog box, I click on the Insert and edit the file name by clicking on the arrow button to select the installer privateDir variable.

Once done, I can build the media files to test the installer and uninstallers.

When I uninstall Sweet Home 3D, I'll get a new screen showing the additional option.

If I check the option, all the configuration data is deleted as expected.

Translating new options

Some texts in the screens and the options added during the two previous steps aren't predefined in install4j, and I'll have to translate them. Handling translation in install4j works similarly to Java with properties text files where each translated text is associated to a key. The differences in install4j are that it's not mandatory to add a language suffix to each translated properties file and these files can be saved in UTF-8 encoding if they use utf8 file extension (until Java 6, Java properties file supported only ISO-8859-1 encoding which forces you to write characters that don't exist in this encoding with uxxxx sequence).

The properties files used by the installer are defined in the Languages tab of the General Settings screen of the installer project, and after clicking on the New button beside Custom localization file field, I choose to name it "InstallerTranslation.utf8 ".

Once I click on the Create button, a text editor is opened to let me define some properties or override existing ones in the installer. I close the editor and prefer to add the properties one by one, by editing the texts to translate where they are defined in the project. In the Installer screen, I select the Configurable form node and in its Properties tab, copy to the clipboard the text of the Screen title field, click on the arrow button beside it and select the Insert I18N Message option (I18N means Internationalization, the 18 number matching the the number of letters between the first and the last letter of this long word).

In the Select I18N Message dialog box, I click on the Edit link to enter a new key/value pair in the InstallerTranslation.utf8 file.

I enter the text "portableScreenTitle=Removable drive option " in the editor,

click on OK, and select the new key that appears in the Custom messages list.

Once done, the text of the Screen title field is replaced by ${i18n:portableScreenTitle}.

I perform the same operation for the other 5 new texts that need to be translated.

The two Help texts are replaced by clicking in the Insert Variable button shown in their editor and choosing the Insert I18N Message option.

Once done with the InstallerTranslation.utf8 file, i just have to translate this file in each supported language and add them on the Languages tab of the General Settings screen. For example, I can translate the texts to French in a file InstallerTranslationFrench.utf8 and add it to project.

Installing a program in console or unattended mode

Installing a program with a graphic user interface is nice for most users, but many environments offer only a command line interface. install4j offers such a mode without any additional change to the installer:
instead of answering questions with buttons, text fields and check boxes, the end user just uses the keyboard to answer. The console mode is used when the argument -c is passed to the installer program. Under Windows XP / Vista / 7, Sweet Home 3D installer can be run with the following command:

start /wait SweetHome3D-3.0-windows.exe -c

which will give the following results.

install4j offers also an unattended mode, something that may be very handy when you have to install a program the same way on different computers. In that mode launched with a -q argument passed to the installer program, the installation runs by itself until the end without asking any questions. The directory where the program should be installed can be specified with the -dir argument and the answers to the installer questions that should be different from their default values can be specified in a response file by passing the -varfile argument.

The easiest way to generate such a response file is to run the program in another mode and retrieve the response.varfile file created by the installer in the .install4j subdirectory of the directory where program was installed. This file is a text file that contains installer variables and their values that may be edited with any text editor if needed. Under Windows XP / Vista / 7, Sweet Home 3D can be installed in unattended mode with the following command:

start /wait SweetHome3D-3.0-windows.exe -q -varfile response.varfile

Conclusion

install4j lets you customize your installer in many ways. You can configure it to install some optional items and perform some special operations. You can also use your Java skills to program customized conditions or any required piece of code, in an editor that supplies the great features of modern IDEs.

Beyond installing

Emmanuel — Fri, 31 Dec 2010 08:00:57 GMT

Categories: install4j Tutorial

In the two last articles, I showed how to build an installer with install4j for Sweet Home 3D, then improve it with various options. But a program lives, and more and more users are used to getting program updates automatically. As install4j includes an auto-update feature, I'm going to use it to update Sweet Home 3D when a new version is released. Finally, I'll provide all the nice options that install4j offers for Mac OS X and Linux users by creating a cross platform installer.

Auto-updating

install4j offers various ways to check whether updates are available and to manage the launching of the updater. As I want to provide auto-updating without modifying the Sweet Home 3D source code at this moment, I'm going to set options in install4j that will check if a new version of the program is available when the program is launched. The auto-update feature is informed about the availability of a new version thanks to an updates.xml file I'll have to host at a specified URL. Each time an installer is built, install4j creates a default updates.xml file in the output directory, and when a new version will be available, I'll just have to upload that file along with the new version of the installer. For the version 3.0 of the installer, this file looks like this:

<?xml version="1.0" encoding="UTF-8"?>
  <updateDescriptor baseUrl="">
  <entry targetMediaFileId="80" updatableVersionMin="" updatableVersionMax=""
    fileName="SweetHome3D-3.0-windows.exe" newVersion="3.0" newMediaFileId="80"
    fileSize="27361280" bundledJre="windows-x86-1.6.0_23" archive="false">
  <comment language="en" />
  <comment language="zh_CN" />
  <comment language="cs" />
  <comment language="fr" />
  <comment language="de" />
  <comment language="el" />
  <comment language="hu" />
  <comment language="it" />
  <comment language="ja" />
  <comment language="pl" />
  <comment language="pt_BR" />
  <comment language="ru" />
  <comment language="es" />
  <comment language="sv" />
  </entry>
  </updateDescriptor>

To prepare future updates, I have to decide in this version where I'll host the updates.xml file. Thus, I enter the URL "http://www.sweethome3d.com/download/updates.xml " in Auto-Update Options tab of the Installer screen.

Then, in the Screens & Actions tab, I click on the Insert button and select the Add Application menu item.

In the Select an Application Template dialog box, I select the Updater with silent version check template.

Once I click on OK, a new node is added to Installer screen for the updater application and I name its Executable as "SweetHome3DUpdater " in its Properties tab.

To run this updater automatically when Sweet Home 3D or Furniture Library Editor are launched, I click on the Launcher Integration tab, select the Start automatically when launcher is executed option and choose to Always run the updater.

Minimum auto-updating is now integrated and I just have to build a new installer to make it available for a future version of the program.

To test it, I immediately install version 3.0 of the program, generate an installer with a fake 3.0.1 higher version number,

and upload SweetHome3D-3.0.1-windows.exe and updates.xml to http://www.sweethome3d.com/download after adding a small comment in default language to updates.xml file.

<?xml version="1.0" encoding="UTF-8"?>
  <updateDescriptor baseUrl="">
  <entry targetMediaFileId="80" updatableVersionMin="" updatableVersionMax=""
    fileName="SweetHome3D-3.0.1-windows.exe" newVersion="3.0.1" newMediaFileId="80"
    fileSize="27427328" bundledJre="windows-x86-1.6.0_23" archive="false">
  <comment>Fixed minor bugs</comment/>
  </entry>
  </updateDescriptor>

Then, a few seconds after I launch Sweet Home 3D version 3.0, the updater is launched and offers to download Sweet Home 3D version 3.0.1.

If I click on the Show comments link, I get the comments entered in the updates.xml file.

Otherwise the download of the new version is started.

Once downloaded, I choose to execute the downloaded installer.

Because the installer detects that a previous version is installed on my computer, it asks me whether to update or to install it in another location before performing the installation.

Managing cross platform installers

Since install4j is a Java program itself, it's easy to prepare installers for each operating system where JVMs are available. If an application shares the same list of files (which is generally the case), I would just have to create a different media for each targeted operating system with its dedicated JRE. It's a little more complicated for Sweet Home 3D since it requires different Java 3D DLLs for different platforms. Therefore, I download Java 3D zip binaries for Mac OS X, Linux 32 bits and Linux 64 bits at Java 3D release builds page. Each of these zipped files contains a j3d-jre.zip file, and each j3d-jre.zip file contains the three j3dcore.jar, vectmath.jar and j3dutils.jar files which are the same as the Windows ones I have already, plus some DLLs like libj3dcore-ogl.so under Linux that I have to keep. Under Mac OS X, Java 3D works thanks to JOGL library, that I download too.
Once I retrieve all these files, I copy the ones required by Java 3D in a lib subdirectory of Install directory and reorganize them to avoid any name conflict.

These files will have to be copied in the lib subdirectory of the destination directory where program will be installed. To copy only the Java 3D files required for a given operating system, I'm going to create one file set for each system in install4j. In the Files screen, I click first on the Insert button and choose the New File Set option.

I enter the general name "Windows ",

and renew the New File Set operation for Mac OS X, Linux 32 bits and Linux 64 bits.

Then, for each of these file sets, I create a new lib folder by clicking on the Insert button and choosing the New Folder option.

Once the lib subdirectories are ready, I select the one in Windows file set, click on the Insert button and choose Add Files and Directories option.

In the Add Files and Directories dialog box, I choose the Single files option,

click on the Next button, and select the four Java 3D DLLs for Windows in C:Program Files (x86)Sweet Home 3D 3.0lib directory.

I confirm my choice, and repeat the same operation to add the Java 3D files that depends on Mac OS X, Linux 32 bits and Linux 64 bits.

To get consistent file sets, I also have to remove the Java 3D DLLs from Default file set : I select the Content of C:Program Files (x86)Sweet Home 3D 3.0lib into subdirectory lib node, click on the Edit Entry button,

and in the Modify Entry in the Distribution Tree dialog box, I change the entry type to Single files and select all the files in C:Program Files (x86)Sweet Home 3D 3.0lib directory except the four DLLs.

Once I chose these JAR files, I move them to the lib subdirectory of the installation directory.

Finally, I click on the Installation Components tab, select the Sweet Home 3D component and include Windows, Mac OS X, Linux 32 bits and Linux 64 bits file sets.

Now that file sets are ready, I'm going to use them in the Windows existing media file and in the new media files for Mac OS X and Linux. I go to the Media screen,

and double-click on the Windows media file to exclude the file sets that are not needed for Windows.

Then, I click on New media file icon to create Linux 32 bits media file. In the Installer type combo box, I choose Unix/Linux GUI installer,

and click on the Next button until the Data files step where I enter the same download URL http://ovh.dl.sourceforge.net/project/sweethome3d/FurnitureLibraryEditor/ for the Furniture Library Editor as I did for Windows media.

In the Bundled JRE step, I click on the Download JREs button,

to download Linux (x86) 1.6.0_23 JRE.

Once downloaded, I choose this JRE,

customize the installer by setting the media file name to "${compiler:sys.shortName}-${compiler:sys.version}-linux-32bits "

and by excluding the file sets of the other operating systems.

Once the Media wizard is finished for Linux 32 bits, I create similarly the media file for Linux 64 bits, and rename them as Linux 32 bits and Linux 64 bits with the Rename Media File menu item available in their contextual menu, to be able to distinguish more easily.

Mac OS X installer is very similar to the other installers except it doesn't need to download a JRE and it requires an additional VM option to run: as Mac OS X provides its own JRE with the Java 3D 1.3.1 library in extension directory, I have to change the java.ext.dirs system property to ensure the Java 3D 1.5.2 library installed with Sweet Home 3D will have a higher priority. To set this VM option that should replace the -Djava.library.path=lib existing one, I create the java3dDllsVMOption compiler variable by clicking on the Insert button in the Compiler Variables tab of the General Settings screen and enter "-Djava.library.path=lib " as its default value.

Then in the Java invocation step of SweetHome3D launcher, I update the text of the VM Parameters field with ${compiler:java3dDllsVMOption}.

Finally, I click on New media file icon, choose Mac OS X folder Installer type,

update the download URL, exclude the file sets of the other operating systems and in Compiler variables step, override java3dDllsVMOption variable with the value

-Djava.ext.dirs=lib:/Library/Java/Extensions:/System/Library/Java/Extensions:

    /System/Library/Frameworks/JavaVM.framework/Versions/1.5/Home/lib/ext

I can now build the 4 installers and test them on each operating system.

Conclusion

install4j offers many options to help with auto-updating installed software and to deliver Java cross platform installers and uninstallers. install4j can create installers for all supported platforms on any supported platform, so on a Linux build server you can create installers for Windows and Mac OS X as well.

Methods statistics and exceptional method runs

Ingo Kegel — Sat, 12 Feb 2011 08:00:57 GMT

Categories: JProfiler Screencast

In the screencast below, I explain how to analyze exceptionally slow invocations of frequently invoked methods. By using the method statistics and exceptional method run features in JProfiler, the slowest invocations are shown separately in the call tree.

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

import java.util.Random;
  
public class MethodStatisticsTest {

    private static Random random = new Random(0);

    public static void main(String[] args) {
        while (true) {
            doCriticalTask();
        }
    }

    private static void doCriticalTask() {
        if (random.nextInt(1000) % 999 == 0) {
            implOne();
        } else {
            implTwo();
        }
    }

    private static void implOne() {
        for (int i = 0; i < 100000; i++) {
            Math.sqrt(i);
        }
    }

    private static void implTwo() {
        for (int i = 0; i < 1000; i++) {
            Math.sqrt(i);
        }
    }
}

CPU profiling: Sampling and instrumentation

Ingo Kegel — Mon, 29 Aug 2011 07:00:57 GMT

Categories: JProfiler Screencast

In this screencast, I explain the two modes of CPU profiling, sampling and instrumentation and how they are activated in the JProfiler GUI. Choosing and understanding these modes is important for getting good results.

Probes overview

Ingo Kegel — Tue, 30 Aug 2011 07:00:57 GMT

Categories: JProfiler Screencast

In the screen cast below, I give a short overview of the capabilities of probes and the built-in probes that are included in JProfiler 7.0.

Analyzing long-running AWT events with JProfiler

Ingo Kegel — Wed, 31 Aug 2011 07:00:57 GMT

Categories: JProfiler Screencast

In the screencast below, I show how exceptional method recording and request tracking are combined for analyzing long-running AWT events in JProfiler.

Request tracking

Ingo Kegel — Wed, 31 Aug 2011 07:00:57 GMT

Categories: JProfiler Screencast

In this screencast, I explain what request tracking is and how to use it taking the example of executors in the java.util.concurrent package.

Filtering in the reference view of the heap walker

Ingo Kegel — Thu, 01 Sep 2011 07:00:57 GMT

Categories: JProfiler Screencast

In the screencast below, I show the powerful filtering capabilities in the outgoing reference view of the heap walker that allow you to find objects based on primitive field values, outgoing references or code snippets.

Heap walker graph: Finding paths between selected instances

Ingo Kegel — Fri, 02 Sep 2011 07:00:57 GMT

Categories: JProfiler Screencast

In this screencast, I discuss the graph view of the heap walker (new in JProfiler 7.0) and how to search for reference paths between two selected objects. Also, I show how to resolve transitive references in the biggest objects view with the help of the graph view.

Inspections in the heap walker

Ingo Kegel — Sun, 04 Sep 2011 07:00:57 GMT

Categories: JProfiler Screencast

In this screencast, I show what inspections are available in in JProfiler's heap walker and what they are capable of. Also featured is the powerful custom grouping inspection that lets you group object sets with a code snippet that is directly entered in the JProfiler GUI.

Creating a custom probe

Ingo Kegel — Tue, 06 Sep 2011 07:00:57 GMT

Categories: JProfiler Screencast

This version is outdated. There is a newer version of this screen cast.

In this screen cast I show how to create a simple custom probe that measures how often the paint method of the "Animated Bezier Curve" demo is called together with clip bounds information. The example custom probe features events, telemetries and hot spots view.

Using the "Run interceptor script" trigger action

Ingo Kegel — Wed, 07 Sep 2011 07:00:57 GMT

Categories: JProfiler Screencast

In the screen cast below I show how to use the "Run interceptor script" trigger action in a method trigger to print out some internal state of the application for debugging purposes. This is done without recompiling or restarting the application.

Sampling vs. Instrumentation

Ingo Kegel — Sat, 08 Oct 2011 07:00:57 GMT

Categories: JProfiler

Fabian Lange from codecentric has written an excellent article on the differences between sampling and instrumentation.

Sampling and instrumentation are the two modes how methods are measured for CPU profiling. Both have advantages and disadvantages and it depends on the use case which is better for you.

This decision is already prominently featured in JProfiler when you start a new session for the first time, as shown in this screen cast.

Java profiling comes to Linux ARM

Ingo Kegel — Fri, 14 Oct 2011 07:00:57 GMT

Categories: JProfiler

Up to now, there was no good solution for profiling Java code on embedded systems. With the 7.0.1 release of JProfiler, we have introduced support for the Linux ARM platform. The native agent libraries in the bin/linux-arm directory work with the official Java SE for embedded from Oracle.

On the embedded device, you just add the VM parameter -agentpath:[path to libjprofilerti.dll] to the profiled JVM. In the JProfiler GUI on your development machine, you create a session of type "Attach to profiled JVM" to start profiling.

Profiling with IntelliJ IDEA 11

Ingo Kegel — Fri, 09 Dec 2011 08:00:57 GMT

Categories: JProfiler

As always, we try to provide an IntelliJ IDEA plugin immediately when a new major version of IDEA is released.

Most of the time, a release of IDEA does not coincide with a JProfiler release, so we release the plugin separately in the plugin manager. To install the JProfiler plugin in IDEA (both community and ultimate editions), click on "Browse repositories" in the plugin manager and look for "JProfiler".

The plugin will be bundled in the upcoming JProfiler 7.1 release.

Update (2012-01-16) : By mistake, the plugin version (different from the JProfiler version) decreased from 10.3 to 10.2, so many update problems were caused by this. Now the plugin version has been increased to 11.0 and the update should work if you had 10.2 or 10.3 installed previously.

Profiling JPA/Hibernate

Ingo Kegel — Thu, 26 Jan 2012 08:00:57 GMT

Categories: JProfiler Screencast

The screen cast below shows the capabilities of the JPA/Hibernate probe in JProfiler. It presents the events view of the probe that shows a chronological progression of persistence operations as well as the hot spots view that shows back traces and associated JDBC statements.

Using the probe tracker

Ingo Kegel — Fri, 27 Jan 2012 08:00:57 GMT

Categories: JProfiler Screencast

This screen cast shows how the probe tracker can be used to record fine-grained chronological information for selected hot spots and control objects, such as JDBC connections. The probe tracker is available for all probes in JProfiler.

Attaching to Windows services for Java profiling

Ingo Kegel — Wed, 15 Feb 2012 08:00:57 GMT

Categories: JProfiler

Several profilers can attach to running JVMs, but only JProfiler can attach to Windows services. It is very easy to do:

1.Start "Quick attach":

2. All JVMs are shown that run with your user account. Select the "Show services" button at the top:

3. Select your service:

4. Profile!

All screen casts now with HTML5 video

Ingo Kegel — Mon, 18 Jun 2012 07:00:57 GMT

Categories: General

We've just converted all our screen casts to HTML with MP4 and WebM codecs so you can enjoy them on mobile and other Flash-less devices.

There still is a Flash fallback for ancient browsers that do not support the "video" tag. Some older browsers (such as Firefox 3) that support the video-tag but do not support either the MP4 or the WebM video codec may show an error. In that case, please go to our youtube channel to watch the screen casts.

--- Update 2013-07-24

Since Firefox 21, MP4 is supported on Firefox if you're on Windows 7 or higher. There may be problems with colors that are resolved if you go to about:config and set

media.windows-media-foundation.use-dxva=false

Migrating to install4j 5.1

Ingo Kegel — Mon, 18 Jun 2012 07:00:57 GMT

Categories: install4j Migration

The following new features in the install4j 5.1 require consideration when migrating from 5.0:

New architecture for elevated privileges

install4j 5.1 introduces a new architecture for elevated privileges. Under some circumstances this can create backwards compatibility problems with your existing projects that are discussed below.

Prior to install4j 5.1, the the "Request privileges" action could restart the entire installer process and run the installer GUI and all the actions with elevated privileges. This was the default setting on Windows and also available on Mac OS X. The unelevated process was kept around only for starting launchers and other executables without privileges. On Mac OS X, the default mode for the "Request privileges" action was to start an elevated helper process that was used internally by some actions - such as the service actions. The strategy of running the GUI without elevated privileges is a lot better, but our helper process had very limited capabilities and so it could not be made the default on Windows.

Enter install4j 5.1: We have now removed the "restart" and beefed up the elevated helper process considerably. Single actions can now be executed in the elevated helper process. To this end, we have added an "Action elevation type" property to all actions in the install4j IDE. Unless the action declares a different default value, it is set to "Inherit from parent". The "Action elevation type" is also configurable on screens, installer applications, screen groups and action groups, and determines the default value for the contained actions.

If an action is set to be executed with maximum available privileges and an elevated helper process has been started by the "Request privileges" action, the action is serialized to the elevated helper process, executed there and then serialized back to the unelevated process. In the elevated helper process, it has access to all installer variables and it can interact with the GUI through the methods in the com.install4j.api.Util class. Elevated actions in console installers can use all methods in the provided com.install4j.api.screens.Console object to interact with the user.

If you are just using standard actions, migrating to install4j 5.1 should not break anything. If you use custom code, the two-process architecture and the changed default privileges might impact your installer. Here are the points that you should look at:

Using static state in elevated actions may have unintended consequences, since static state is not synchronized between the two processes. Only use installer variables for saving state.
Elevated actions must be serializable. The base interface for actions now extends java.io.Serializable, but all contained objects must be serializable as well, otherwise a fatal error will occur.
Installer variable values should be serializable. If you place a non-serializable value into an installer variable, you will not be able to use it in elevated actions.
If your action previously assumed that it would have full privileges, you have to set its "Action elevation type" to "Elevate to maximum available privileges" manually. For example, a "Run script" action that modifies a file with your own code may not work on a file in the installation directory unless you elevate the action. For custom actions, you can call setFullPrivilegesRequired or setDefaultActionElevationType in your action bean info in order to automatically set the correct elevation type in the install4j IDE when the action is inserted.
Some methods in the API do not work in the elevated helper process. They have been marked to throw NotSupportedInElevationException in the API javadoc. Mainly this concerns methods in the context that change the control flow (i.e. jump to another screen) or methods that modify the GUI. If your action needs to use these methods while at the same time requiring elevation, you can always use context.runElevated(...) to push a piece of code to the elevated helper process.

The key advantages of the new architecture are:

Unified privileges architecture for Windows and Mac OS X
No more problems due to user change on authentication
Privileges can reasonably be requested at any point in the installer, not only at the beginning
Better desktop integration of the installer GUI, for example for drag and drop

Support for OpenJDK on Mac OS X

OpenJDK is the way forward for Java applications on Mac OS X. However, the following points need your attention:

It is not possible to deliver an installer or a single bundle archive that support both the old Apple JRE as well as OpenJDK. The stubs are different and you choose either option in the media wizard. Old projects will keep the Apple JRE option, so nothing will change by default
JRE bundling on Mac OS X is only supported for Open JDK
The minimum Java version for OpenJDK is Java 7 and the minimum Mac OS X version is 10.7.3. So you can currently target only newer systems and only if your application supports Java 7.

Code signing for Windows and Mac OS X

Code signing on Windows and Mac OS X is now implemented in pure Java code which works on any supported platform. Previously, install4j only offered a hook for inserting an external code signing tool for Windows which would be executed for each launcher and installer application. This functionality is still available for Windows media files and is now called "Executable processing". So your existing solution for code signing will still work and there is no immediate need for action.

However, if you have .pvk and .spc files for your code signing certificate, you can enter them on the General Settings->Code Signing tab and enable Windows code signing there. You then have to remove the external code signing command on the "Executable processing" step of the media wizard.

Profiling class loaders and solving related memory leaks

Ingo Kegel — Wed, 24 Jul 2013 07:00:57 GMT

Categories: JProfiler Screencast Memory Leak

This screen cast shows how the class loaders probe can be used to debug class loading and to solve class loader memory leaks.

Profiling MongoDB

Ingo Kegel — Thu, 25 Jul 2013 07:00:57 GMT

Categories: JProfiler Screencast

This screen cast shows how to use the MongoDB probe in JProfiler that has been added in JProfiler 8.0. The profiled application is the vert.x web demo application that uses mongodb as a storage option. MongoDB events are correlated to the the activity in the web application and it is shown how the exclusion of primitive data leads to a useful definition of hots spots.

Java profiling across JVM boundaries

Ingo Kegel — Tue, 30 Jul 2013 07:00:57 GMT

Categories: JProfiler Screencast

This screen cast shows "Remote request tracking" in JProfiler. It makes it possible to profile business transactions that span multiple JVMs. Here, a web service call to another JVM is shown and profiled in isolation of other requests that are handled by the server. In addition, JProfiler supports remote request tracking for RMI and remote EJB calls.

Introducing perfino

Ingo Kegel — Tue, 03 Jun 2014 07:00:57 GMT

Categories: General

Today we're releasing a major new product: perfino is a JVM monitoring tool for in-production use. Over the years, we have lost count of the number of times that our customers have asked us on how to best deploy JProfiler in production. While our standard response was to recommend a monitoring tool, our customers were not so easily dissuaded. They wanted the power of JProfiler to solve their particular problems.

Out of this dilemma, the idea for perfino was born. Would it be possible to develop a monitoring tool that could be used in production, yet provide a way to escalate from monitoring to profiling if necessary? We are firmly convinced that perfino succeeds with respect to this original goal and provides you with a layered defence in depth. When a problem becomes more difficult to solve with monitoring techniques, perfino offers low-risk, low-overhead native JVMTI sampling to get a picture of the entire JVM. If even that is not enough, perfino offers an easy way to attach JProfiler to a problematic JVM. At that point, you have the full arsenal of a Java profiler at your disposal.

However, the much larger part of perfino is not its emergency handling, but its monitoring capabilities. Here, we wanted to make a difference as well. perfino uses a Java agent with ultra-low overhead and measures what is called "business transactions" in the APM space. Business transactions capture important method calls with specially constructed names that help you to interpret what is going on in your application.

For business transactions, we brought in successful concepts from the profiling space and integrated them into perfino. For example, transactions are shown in a call tree and you can see hot spots of transactions. With perfino, it is possible to define many transactions that are nested. This gives you more informational depth and correspondingly more insight than just the list of top-level business transactions that is common for APM tools.

The amount of useful information in an APM tool is directly related to the amount and quality of the recorded business transactions. This is why we expended a lot of energy on the business transaction engine and the configuration of business transactions in the perfino UI. Also, we wanted to make it really easy to define business transactions directly in your code. The DevOps annotations offered by perfino are a great way to achieve this. Rather than thinking about monitoring as external to the application, you just annotate methods of interest.

The features mentioned above rotate around measuring method calls. Of course, a monitoring tool needs to do a lot more and we’ve strived to make perfino great in all these aspects: Telemetries, policies, triggers, alerts, end user experience monitoring and lots more. Take a look at the feature list or - even better - try it out in our live demo or on your own machines. Tell us what you think and what you would like to see in future versions.

perfino is a powerful APM solution today, but our vision for perfino is not done yet. There are many more things to come and we hope you’ll bear with us.

The v2 signature scheme for application bundles on Mac OS X 10.9.5+

Ingo Kegel — Mon, 08 Sep 2014 07:00:57 GMT

Categories: install4j

Apple has decided to introduce a new signing scheme in the upcoming Mac OS X 10.9.5 maintenance release.

The good news is that the new signature is much better from a security point of view. The utility of the old signature was highly questionable, because it allowed unsigned and modifiable files in the application bundle. An attacker could change the JAR files in the application bundle and the signature of the application bundle would remain valid.

The bad news is that all existing signatures are going to break. Only applications with a v2 signature will be accepted by Gatekeeper starting with Mac OS X 10.9.5. On the upside, the v2 signature is backwards compatible with older versions of Mac OS X. The means that if your application bundle is signed with the new scheme it will work in Mac OS 10.8, 10.9 and 10.10 - and hopefully even with future versions of Mac OS X.

We have implemented v2 signatures in install4j 5.1.13, so you can already create application bundles that will work with the upcoming disruptive releases of Mac OS X.

However, this change may have consequences for your install4j projects:

The application bundle that is installed by a "Mac OS X single bundle" installer cannot be signed anymore. The installer installs variable files into the bundle and of course it cannot update the signature of the bundle. Previously all these files did not influence the signature (you can see that this was a bad idea), but now everything in the bundle must be signed. If you really need a signed launcher, you have to switch to the "Mac OS X single bundle" archive.
Info.plist files and .vmoptions files in signed bundles cannot be changed anymore without breaking the signature. If you rely on the validity of the signature of the application bundle, you have to ensure that these files remain untouched. This applies to single bundle and folder archives as well as to the folder installer with signed launchers enabled.

To make the correct decisions, you have to understand that a signature is only required for the file that user downloads from the internet. An installer can install application bundles that are unsigned, because those will not be checked by Gatekeeper.

A signature on an installed application bundle is only required if you need access to restricted services, such as iCloud storage or the notification center. In addition, signed application bundles are treated preferentially in some cases. For example, if the user enables the firewall, unsigned application bundles can only receive incoming connections after the user confirms a question from the firewall.

Migrating to install4j 6

Ingo Kegel — Mon, 03 Nov 2014 08:00:57 GMT

Categories: install4j Migration

In nearly all cases, migrating to install4j 6 usually just involves opening and saving your project with the install4j 6 IDE. Nevertheless, there are some considerations with respect to backward compatibility and some behavioral changes.

The minimum Java version for launchers is now Java 6. If your launchers must run with Java 1.4 or Java 5, you have to stick with install4j 5.
The minimum Java version for the install4j IDE and the compiler is now Java 7. If your build machine only has Java 6 installed, you have to install a Java 7 JRE. On Windows and Mac OS X, Java 7 JREs are bundled in the install4j downloads.
The install4j API has been generified and old-style enums have been converted to language enums. Theses changes are binary and source compatible. The only exception is that enums do no longer extend com.install4j.api.SerializableEnum. In the unlikely case that you use this class in your custom code, you will have to replace it with the actual enum class.
Installer variables loaded by the "Load response file" action or the -varfile command line parameter are now automatically registered as response file variables. The eliminates problems with fast-path upgrade installations where response file variables would be lost if their form components were not be shown. If this change impacts on your logic, the "Load response file" action now has a "Register variables for response file" property that you can deselect to revert to the old behavior.
By default, the "Load response file" action will no longer overwrite installer variables that have been set explicitly on the command line with the -Vvariable=value option. This is the intuitive behavior and makes installer variables more flexible. If this change impacts on your logic, the new "Overwrite strategy" property of the "Load response file" action can be set to "Do not overwrite existing".
Mac OS X archives are now generated in DMG format. This means that the generated media file name will change between install4j 5 and install4j 6 and you have to adjust download links on your website. If you would like to keep the .tgz format, you can change the corresponding option on the "Installer options" step of the media wizard.
Invisible form components are no longer validated. A validation error would leave the user with no clue what to do, so this was really a mistake in previous versions. However, bound installer variables are set during the validation phase and that will no longer happen for invisible components. If you rely on the installer variables to be defined, you should predefine them in the "Installer variables" section of the installer or custom installer application.
Several installer variables that were previously only defined on Windows are now defined on multiple platforms. New cross-platform installer variables are "sys.desktopDir" and "sys.docsDir". The installer variables "sys.appDataDir", "sys.localAppdataDir", "sys.docsDir", "sys.fontsDir" and "sys.programsDir" are now also defined on Mac OS X. If your code checks if any of these installer variables is null, it may no longer work correctly.
The "Reboot computer" action and Context#triggerReboot now work on Mac OS X as well. If you rely on the previous behavior of not doing anything on Mac OS X, this may not be what you want. In that case, you have to add platform-specific checks in your project.
The ICNS icon for Mac OS X launchers is now generated from cross-platform images. If you previously had no ICNS icon defined but the "Add icon to launcher" check box was selected, the maximum resolution of your icon files might be too low. You need at least a 128x128 image for the icon to look good on Mac OS X. The old default ICNS icon is still available under resource/macos/app.icns, so you can specify it explicitly to restore the old behavior.
The name of the uninstaller on Mac OS X has changed if your project is localized. Previously the file name of the uninstaller application bundle was set to the localized name. In install4j 6, the file name is always set in the principle language and the localization is provided by the application bundle. You will see the localized name in the Finder, but not in the terminal.

If you notice anything else, please let us know!

Tracking JavaScript calls into your Java backend

Ingo Kegel — Tue, 09 Jun 2015 07:00:57 GMT

Categories: JProfiler Screencast

This screen cast shows how to split your Java call tree for different JavaScript XHR calls. By installing the JProfiler Chrome plugin, a locally running JProfiler GUI will be notified of XHR calls in the browser and show an event description and a stack trace without further configuration. In this way, you can identify the sources of your CPU load beyond the granularity of your URLs and analyze the call tree in isolation for specific browser events.

Multi-level HTTP request splitting

Ingo Kegel — Wed, 10 Jun 2015 07:00:57 GMT

Categories: JProfiler Screencast

This screen cast shows how JProfiler can split HTTP requests by the return values of scripts into multiple levels. This functionality allows you to both get a better overview as well as a more fine-grained analysis that can be adapted to your particular problem-related use cases. All the information in the HttpServletRequest object can be used for that purpose. In the screen cast, splitting by different usernames is demonstrated.

Method splitting by parameter values

Ingo Kegel — Thu, 11 Jun 2015 07:00:57 GMT

Categories: JProfiler Screencast

This screen cast shows how to split selected methods in the call tree by their parameter values. Directly in the call tree, you can select methods and set up scripts whose return values are used for grouping. The splitting nodes in the call tree provide insight into the distribution of your parameter values and give you the possibility to analyze the recorded method calls separately for special cases.

JProfiler's MBean browser

Ingo Kegel — Fri, 12 Jun 2015 07:00:57 GMT

Categories: JProfiler Screencast

JProfiler has an MBean browser that shows you MBean attributes and operations. Many frameworks and libraries publish statistics and expose configuration interfaces via JMX. With JProfiler, no configuration of JMX connectors is required, the browser just works out of the box and is very easy to use.

Custom telemetries in JProfiler

Ingo Kegel — Tue, 16 Jun 2015 07:00:57 GMT

Categories: JProfiler Screencast

This screen cast shows how to quickly add new telemetries to JProfiler. MBean telemetries draw their data from numeric attributes of MBeans that are published in the profiled JVM. Script telemetries are built with a script that can call static methods in the profiled code to return a value of type long. Telemetries can have multiple data lines and are persistent for the profiled session.

Finding JDBC connection leaks

Ingo Kegel — Thu, 19 Nov 2015 08:00:57 GMT

Categories: JProfiler Screencast

This screen cast shows how to detect JDBC connection leaks and find out where they're coming from. JDBC connection leak analysis is integrated into JProfiler's JDBC probe and has its own view. If a connection leak is detected, the stack trace and other information will help you to pinpoint the origin of the leak.

Remote profiling through an SSH tunnel

Ingo Kegel — Fri, 20 Nov 2015 08:00:57 GMT

Categories: JProfiler Screencast

JProfiler has built-in SSH tunneling for direct and multi-hop SSH connections. This is useful for situations where you do not have a direct network connection to the machine where the profiled JVM is running. The screen cast shows how to configure the SSH tunnel and prepare the remote Java process for profiling.

Collapsing recursions in the call tree

Ingo Kegel — Tue, 24 Nov 2015 08:00:57 GMT

Categories: JProfiler Screencast

This screen cast shows how to use the "Collapse recursions" call tree analysis to better understand recursive call trees. Recursive calls are stitched back to the topmost call of a method. Recursive call counts, merged stack counts as well as moved parts of the call tree are marked in the analysis view.

Analyzing incoming and outgoing calls of a method

Ingo Kegel — Wed, 25 Nov 2015 08:00:57 GMT

Categories: JProfiler Screencast

This screen cast shows how to use the call tree analyses to analyze both the cumulated outgoing calls of all top-level invocations of a selected method as well as to calculate the back traces of all its invocations. The results of the analyses are compared with the call graph that shows a combined view of incoming and outgoing calls.

Analyzing specific parts of the call tree

Ingo Kegel — Thu, 26 Nov 2015 08:00:57 GMT

Categories: JProfiler Screencast

This screen cast shows how the "Set root" action is used to analyze a specific part of your code. The "Set root" action in the call tree view is used to select the call stack of interest. The hot spot view and the call graph then only show data for the selected part of the call tree.

Comparing install4j to other deployment solutions

Ingo Kegel — Thu, 06 Oct 2016 07:00:57 GMT

Categories: install4j

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.

Zero-configuration remote attach

Ingo Kegel — Mon, 20 Mar 2017 08:00:57 GMT

Categories: JProfiler Screencast

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.

Complexity analysis in JProfiler

Ingo Kegel — Tue, 21 Mar 2017 08:00:57 GMT

Categories: JProfiler Screencast

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.

Finding a memory leak with JProfiler

Ingo Kegel — Wed, 22 Mar 2017 08:00:57 GMT

Categories: JProfiler Screencast Memory Leak

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.

JProfiler's integration into IntelliJ IDEA

Ingo Kegel — Thu, 23 Mar 2017 08:00:57 GMT

Categories: JProfiler Screencast

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.

Migrating to install4j 7

Ingo Kegel — Thu, 13 Jul 2017 07:00:57 GMT

Categories: install4j Migration

In nearly all cases, migrating to install4j 7 usually just involves opening and saving your project with the install4j 7 IDE. Nevertheless, there are some considerations with respect to backward compatibility and some behavioral changes.

The minimum supported Java version is now Java 7 up from Java 6 for install4j 6. This also means that the old Java 6 Apple JRE is no longer available as a separate type on the Bundled "JRE" step of the macOS media wizard. The launcher runtime still supports Java 6 and you can set the compiler variable sys.ext.forceMinJavaVersion to true in order to allow "1.6" as a minimum version. Note that no classes in the API can be called from Java 6.
The "native splash screen" feature for Windows has been removed. This went back to the pre-Java 6 days when Java did not offer splash screen functionality and was missing several important features. If you had this feature selected for one of your launchers, it now uses the regular Java splash screen
When a rollback terminates at a rollback barrier, the exit code of an installer application is now 0. To restore the old exit code of 1, you can set the "Exit code" child property of the "Rollback barrier" property to 1
In the "Key validation expression" script property of text components, the "keyCode" parameter has been removed. It was always 0 before and did not serve a useful purpose.
If you develop your own screens with the API, the methods isShowIndex, hasTitlePanel, hasDefaultInsets and hasDefaultButtons have been removed from the interface com.install4j.api.screens.Screen and so your existing implementation of these methods will no longer be called by install4j. This functionality is now covered by styles which are much more flexible than the previous limited styling capabilities.
In the API, methods with Object[] arguments for variable parameter lists have been converted to varargs. This should not cause source or binary incompatibilities but may show warnings in your code if you call such methods.
The "Create a quick launch icon" action has been removed with no replacement. The last OS where it had any effect was Windows Vista.
If you have not set a maximum Java version, and do not use a bundled JRE, any installed Java 9 JRE will be used. Java 9 has backward compatibility issues that may prevent your application from working unless you explicitly support it. Consider limiting the maximum Java version to "1.8" in that case.
If the "Request privileges" action fails, an installation directory in the user home directory is set. To restore the old behavior of keeping the default installation directory deselect the "Fall back to user specific installation directory" property on the "Request privileges" action.
With install4j 7, you cannot use the deprecated com.apple.eawt.Application.Application.getApplication().addApplicationListener(...) in the macOS EAWT API anymore, you have to use the new API methods, for example
```
Application.getApplication().setQuitHandler((quitEvent, quitResponse) -> {
        quitResponse.cancelQuit();
// TODO add your code
});
```
for the quit handler.

If you notice anything else, please let us know!

Stricter time-stamp validation on macOS 10.14

Ingo Kegel — Mon, 11 Jun 2018 07:00:57 GMT

Categories: install4j

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.

Whenever code signatures are invalid, macOS does not report any specific errors, but just informs the user that the archive is damaged and suggests to move it to the trash, like this:

If you use install4j for deploying to macOS, you probably do use code-signing, so we highly recommend to update to install4j 7.0.6 to avoid problems for users on macOS 10.14.

As an added benefit, the new release can scale splash screens under fractional HiDPI on Windows, so they no longer appear to be to small.

Development Sneak Peek: Dark Mode and HiDPI

Ingo Kegel — Tue, 19 Jun 2018 07:00:57 GMT

Categories: JProfiler

A system-wide dark mode is coming to both macOS and Windows. That's why we're working on a dark mode for JProfiler as well. Based on the excellent Darcula Look and Feel from our friends at JetBrains, JProfiler will soon fit into this new world of dark background colors:

Moreover, support for fractional HiDPI is coming for Windows. If you are using a 4K monitor, you will be happy to hear that the blurry upscaled UI will be a thing of the past. This is not only true for dark mode: We will also be using the light look and feel from IntelliJ IDEA together with the JetBrains Runtime in order to provide the best experience for high screen resolutions. The light mode will be the new default look and feel for JProfiler.

Automation sandboxing in macOS 10.14

Ingo Kegel — Tue, 16 Oct 2018 07:00:57 GMT

Categories: install4j

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.

To solve this problem, nearly all affected operations have been re-implemented as native code in install4j 7.0.8. As part of this work we have fixed a long-standing issue on macOS: When requesting elevated privileges, the password dialog notified the user that "install4j" wants to make changes.

However, users most likely do not know the name "install4j" and could be tempted to cancel the dialog. Starting with install4j 7.0.8, the full name that is configured in your project is displayed instead:

Migrating to install4j 8

Ingo Kegel — Fri, 28 Jun 2019 07:00:57 GMT

Categories: install4j Migration

In nearly all cases, migrating to install4j 8 usually just involves opening and saving your project with the install4j 8 IDE. Nevertheless, there are some considerations with respect to backward compatibility and some behavioral changes.

The unattended installer does not ignore file installation failures anymore but fails at the first file installation failure. To get the old behavior, start the installer with the -nofilefailures argument. To permanently set this mode, add -Dinstall4j.noFileFailures=true to the "VM parameters" property of the installer.
When using the VM parameters -Dinstall4j.alternativeLogFile=<path> and its new alias -Dinstallj4.log=<path>
now imply -Dinstall4j.keepLog=true, meaning that the log file is no longer deleted in case of a successful execution of the installer application.
The default file name of the error log for Windows installers has changed from error.log to ${compiler:sys.mediaFileName}_error.log. You can restore the old file name with the new "Log file for stderr" property of the installer.
In bean properties with an array type, installer variables with collection values are expanded as separate array elements. Previously this was only implemented if the installer variables had array values. In the API, this new behavior affects the AbstractBean.replaceVariables(...) methods with array parameters. If you rely on the toString() replacement of collections, you have to change the types of the related installer variables.
Variable names for all built-in variable systems can no longer contain the character sequence ?: which is now used for specifying default values for missing variables.
FormEnvironment.getId(...) now returns the display ID of the form component rather than the automatic ID. If you were checking for an explicit automatic ID and also defined a custom ID for a form component, that code will now fail.
The "Read text from file" action will now fail if an error occurred. Previously it always succeeded.
The compiler variable sys.platform now contains the value windows-x32 for 32-bit Windows media files instead of windows. For 64-bit Windows media files it remains windows-x64.
The "Customize project defaults->Installer custom script" step of the Unix/Linux GUI installer media wizard has been removed. The custom script is now configured on the installer in the "Installer->Screens & Actions" step. The simple case where there is only one Unix/Linux GUI installer is migrated correctly. However, if you used different customizations for different Unix/Linux GUI installers, the migration will be incomplete and you have to solve it with compiler variables.
For Linux/Unix installers, the umask is now set to 0022 to allow execution by all users. This can be changed by setting the compiler variable sys.ext.installerUmask to another mask value or to false to prevent executing any umask command in the installer script.

Support for macOS Apple Silicon

Ingo Kegel — Thu, 26 Nov 2020 08:00:57 GMT

Categories: General

Please note: Several JDK providers now offer the macos-aarch64 architecture and there is no need anymore to create the bundle yourself, install4j can do this for you automatically.

(Edited on 2021-01-07 to include changes for install4j 8.0.10)

Apple machines with the new ARM architecture are now available. While you can run existing x64 binaries for on ARM machines through Rosetta, the performance may be impacted significantly. install4j 8.0.9 addresses this concern with support for native ARM binaries.

At the time of writing, the JRE port to macOS ARM has not landed in OpenJDK yet. Currently, only the JetBrains JDK provider includes a release with the macos-aarch64 architecture (11.0.9.1-b1244.2).

In addition, Azul provides distributions for macos ARM for several JDK versions. These JDKs can be processed with the "Project->Create a JRE bundle" command in the install4j IDE or the createbundle command line tool. This creates a "pre-created" JRE bundle that can be selected on the "Bundled JRE" step of the media wizard. An Azul JDK provider that would download these JDKs automatically and in a cross-platform way is planned for install4j 9.

After you have prepared a JRE bundle for macOS ARM, you can select the architecture in the macOS media wizard. You will still need an additional media file for Intel-based Macs, because ARM binaries do not run there.

Finally, select the pre-created bundle in the "Bundled JRE" step.

Migrating to install4j 9

Ingo Kegel — Fri, 19 Feb 2021 08:00:57 GMT

Categories: install4j Migration

In nearly all cases, migrating to install4j 9 usually just involves opening and saving your project with the install4j 9 IDE. Nevertheless, there are some considerations with respect to backward compatibility and some behavioral changes.

The minimum Java version for the install4j runtime is now Java 1.8. Java 1.7 is no longer supported.
The install4j compiler and IDE now require at least Java 11. This is only relevant on Linux and Unix where no JRE is bundled.
"Install files" action: The "Update bundled" JRE property has been removed. A bundled JREs is now always updated if the update installer also includes a bundled JRE. The ability to switch this off offers no benefit and has the potential to create severe problems during sequential upgrades. If you had this property selected, you can restore the previous behavior by defining the VM parameter -Dinstall4j.preventJreBundleUpdate=true in the installer.
"HTTP request" action: In previous versions, if an error occurred, the response code variable and the response header variables were not set. This error has been corrected in install4j 9, but it changes the semantics of the installer variables.
The installer variable sys.appdataDir was previously undefined on Unix, it now returns the value of the environment variable XDG_DATA_HOME (~/.local/share ) on Unix.
Shared JREs (Windows and Unix) now have a sharing ID. This has become necessary because there is no universal definition of a JRE anymore so the scope of sharing has to be restricted. Consequently, shared JREs are now installed in different locations than before. Also, the user-specific root directories have changed to ~/.local/share/i4j_jres on Unix and %APPDATA%\Local\Programs\Common\i4j_jres on Windows. Shared JREs are now preferred to public JREs on Unix.
The "Execute launcher" action always executed the selected launcher without elevation. This does not work for launchers that require privileges themselves. Since install4j 9, the action respects the "Action elevation type" property of the action. This changes the behavior of the action if you have changed the "Action elevation type" property from its default value of "Do not elevate" to another property value.
The auto-update integration for background update downloaders in the launcher wizard behaves differently if the "Unattended mode with progress dialog" mode is selected: It now shows errors and alerts in the update installer where previously any error would lead to a silent failure. If this change is not acceptable for you, you can add the VM parameter -Dinstall4j.noAlerts=true to the "VM parameters" property of the installer.
Installer applications that have not been started in-process by launchers now set the system property jdk.lang.Process.allowAmbiguousCommands=false to avoid cmd.exe injections. In unattended and console mode, installers applications already behaved that way because they use a security manager. Some quoting strategies or arguments that worked before might stop working in GUI mode because of that change. To revert to the previous behavior, set the VM parameter -Djdk.lang.Process.allowAmbiguousCommands=true for the installer application.
The JRE version cache on Linux/Unix is now located in .cache/install4j/jres instead of the file ~/.install4j.
Config files, cached files and pre-crated JRE bundles have new platform-specific locations instead of being stored in ~/.install4j<version>. On Windows, all directories are located below %LOCALAPPDATA%/install4j/v<version>. On macOS, ~/Library/Application Support/install4j/v<version> is used for config files as well as pre-created JRE bundles and ~/Library/Caches/install4j/v<version> is used for cached files. On Linux and Unix, .config/install4j/v<version> is used for config files, .caches/install4j/v<version> for caches and .local/share/install4j/v<version> for pre-created JRE bundles. The environment variables XDG_CONFIG_HOME, XDG_CACHE_HOME and XDG_DATA_HOME modify the roots of these directories, respectively.
In previous versions, Linux/Unix installers created the installation directory with the default umask. Since install4j 9, the default Unix directory mode configured in the "Files->File Options" view or the overridden mode configured for the "Installation directory" node in the distribution tree is used.

New web license service and improvements for the on-premises server

Ingo Kegel — Thu, 24 Jun 2021 07:00:57 GMT

Categories: General

Customers with floating licenses now have more flexibility: Starting with with the most recent releases of JProfiler and install4j, we now offer a web license service, so you do not have to install a license server yourself. If you choose that option, you will receive a license key that can be distributed to all developers and is entered just like a single license key. This option requires the ability to make an outgoing HTTP request to our license server.

Going forward, we will be offering both the web as well as the the on-premises solution. For the time being, the on-premises option remains the default and you can contact us if you would like to switch to the web option.

There is also good news for the on-premises license server with two great improvements that are available in the latest release:

Remote checkout

When you take your computer offsite where you don't have access to the license server, you can check out a license for a number of days in the license dialog (Help->Enter License Key):

The maximum allowed number of days is configurable in the license server configuration and is set to 1 by default. If you return early, you can give the license back to the license server so it becomes available for other team members:

Encryption and Authentication

Previously, you could either choose an unencrypted direct connection suitable for local networks or an SSH connection suitable for use over the internet. However, the latter required SSH server access to the license server machine.

With the latest releases, you can enable encryption in the license server configuration and connect directly over the internet with mutual authentication and TLS encryption. The license server creates a file encryption/client.ks at startup (if it does not exist) that must be distributed to users and entered in the license dialog:

Without that file, no connection to the license server is possible. To reset the authentication, simply delete the "encryption" folder in the license server installation and restart the license server. A new authentication file will then be generated.

Migrating to install4j 10

Ingo Kegel — Tue, 26 Jul 2022 07:00:57 GMT

Categories: install4j Migration

In nearly all cases, migrating to install4j 10 usually just involves opening and saving your project with the install4j 10 IDE. Nevertheless, there are some considerations with respect to backward compatibility and some behavioral changes.

Compile-time requirement for associations in archives on macOS

Starting with ARM-based macOS machines, the Info.plist files of launchers cannot be modified at runtime without breaking the signature, so all content must be generated at compile time. This means that it is not possible to conditionally add file associations or URL handlers at runtime anymore. In earlier versions of install4j, the related behavior was different for Intel and ARM-based macOS machines, which was inconsistent.

To provide a way of configuring this information, the "Executable info->macOS options" step of the launcher wizard now contains a list of file associations and URL handler definitions that are translated into the corresponding entries of the Info.plist file of the installer. Previously, archives would process the definitions of selected "Create a file association" and the "Register a URL handler" actions in the "Installer->Screens & actions" section.

You can either add a file association or a URL handler. A file association is defined by its extension, a description and an optional icon file. The role indicates whether the application just displays files or also edits their content.

The URL handler is defined by the URL scheme, so for a scheme of "hello" it handles requests in the browser that start with "hello://".

The "Create a file association" and the "Register a URL handler" actions now only work for Windows and Linux. If you open projects that were saved with previous versions of install4j, the information from these actions is migrated into the new settings for macOS in the launcher wizard.

In situations where file associations were added conditionally, this migration may fail to produce the correct results, so you should check the migrated associations on the "Executable info->macOS options" step of the launcher wizard after opening the project in install4j 10.

Retirement of user-selectable MSI scope

Creating MSI installers that can conditionally be installed for all users or for a selected user by passing ALLUSERS=1 on the command line are no longer supported in new projects. We have found that the interaction of install4j-specific features with the user-selectable mode raises a number of undesirable behaviors and pitfalls that cannot be fixed within the architecture underlying install4j installers.

If you have already configured this setting, it will continue to work in the same way in install4j 10. However, you should switch to the per-machine or the per-user MSI scope.

How to configure a script probe in JProfiler

Ingo Kegel — Mon, 01 Aug 2022 07:00:57 GMT

Categories: JProfiler Screencast

This screen cast shows how to configure a script probe for a Java profiling session in JProfiler.

Script probes are custom probes that intercept selected methods and construct payload strings with Java scripts that are entered directly in the JProfiler UI.

You then get a payload call tree, payload hot spots with back traces, telemetries for probe event counts and event durations as well as the ability to inspect single events with their threads and stack traces.

Working with merged reference trees in JProfiler

Ingo Kegel — Fri, 05 Aug 2022 07:00:57 GMT

Categories: JProfiler Screencast

This screen cast shows how to analyze memory leaks in Java applications or reduce memory consumption in general if the objects of interest are not all referenced in the same way.

Analyzing a single object and finding the path to a garbage collector root is not enough in that case and the merged incoming references view as well as the merged dominating reference view are helpful in finding out about the distribution of the actual incoming references and how to make a maximum of objects eligible for garbage collection.

Profiling HTTP calls and tracking them between JVMs

Ingo Kegel — Thu, 22 Sep 2022 07:00:57 GMT

Categories: JProfiler Screencast

This screen cast shows how to profile HTTP calls with the HTTP client probe and use the HTTP remote request tracking feature to follow HTTP calls from one JVM into another.

A simple Spring Boot project with two application is profiled: A gateway server that serves static files and proxies API request to a second server that handles REST calls.

You can see how JProfiler tracks calls from the browser including the JavaScript stack trace through the gateway server into the REST server. The HTTP client probe with its various views is shown and its profiling settings are discussed.

Inlining asynchronous executions in JProfiler's call tree

Ingo Kegel — Wed, 05 Oct 2022 07:00:57 GMT

Categories: JProfiler Screencast

This screencast shows how to use the "Inline async executions" call tree analysis to get a unified call tree across thread boundaries

This is made possible by JProfiler "request tracking" feature. In the screencast, a simple example with Spring WebFlux is profiled that creates permutations of a specified word.

Most reactive stream frameworks use the executor service JDK API for asynchronous execution. JProfiler can track tasks that are submitted to an executor service and stitch them back into a single call tree when the "Inline async executions" call tree analysis is invoked. This is essential when analyzing performance bottlenecks in asynchronous programming models.

Profiling a Netty server

Ingo Kegel — Wed, 02 Nov 2022 08:00:57 GMT

Categories: JProfiler Screencast

JProfiler's support for Netty covers many modern web frameworks that use Netty under hood, like Vert.x, Micronaut, Ktor or Spring WebFlux.

This screen cast shows how to profile a Netty server with customized URL splitting and gives an overview of the HTTP server probe.

Using flame graphs when profiling Java applications

Ingo Kegel — Wed, 09 Nov 2022 08:00:57 GMT

Categories: JProfiler Screencast

Flame graphs are a great way to get an overview of the entire call tree and to visualize performance characteristics. This screen cast shows how the jclasslib bytecode viewer is profiled. A class file is opened and the parsing of the class file is analyzed with the flame graph.

Using sunburst diagrams for understanding Java memory consumption

Ingo Kegel — Tue, 22 Nov 2022 08:00:57 GMT

Categories: JProfiler Screencast

This screencast shows how to use the sunburst diagram in the biggest objects view of JProfiler's heap walker to visualize memory consumption of your Java application.

The sunburst diagrams shows a ring with the biggest objects and multiple reference levels of dominated objects in successive outer rings. See the documentation to read about the dominator analysis and the biggest objects view.

In the screencast, a memory snapshot of the eclipse IDE is analyzed and the class loader and classes groupings of the biggest object view are shown.

Profiling Java applications in Docker containers

Ingo Kegel — Mon, 05 Dec 2022 08:00:57 GMT

Categories: JProfiler Screencast

This screencast shows how to use JProfiler to profile a JVM that is running in a Docker container. JProfiler has dedicated zero-configuration support for attaching to local and remote Docker containers and both cases are shown in the screencast.

Profiling Java applications in a Kubernetes cluster

Ingo Kegel — Wed, 21 Dec 2022 08:00:57 GMT

Categories: JProfiler Screencast

This screencast shows how you can profile JVMs running in Kubernetes cluster with JProfiler. A profiling session with a note taking demo application sessions is started from the IDE, which provides additional benefits, like source code navigation and the automatic detection of profiled packages. Also, a standalone session is started, where an additional SSH connection is required to reach the kubectl command that can connect to the cluster.

Profiling JEE/Spring applications

Ingo Kegel — Wed, 04 Jan 2023 08:00:57 GMT

Categories: JProfiler Screencast

This screencast showcases JProfiler's support for JEE and Spring, in particular the JEE/Spring component detection and the JEE/Spring aggregation level in the call tree and hot spot views.

Improved Kubernetes authentication handling in JProfiler

Ingo Kegel — Fri, 17 Mar 2023 08:00:57 GMT

Categories: General

Since version 13, JProfiler supports profiling on Kubernetes clusters with no extra configuration.

JProfiler 13.0.6 added an important improvement for profiling a JVM in Kubernetes clusters where authentication is set up in such a way that the authentication plugin prints instructions on stdout.

For example, when the Azure Kubernetes Service (AKS) is configured to authenticate with Active Directory (AD), users will be required to authenticate their identity using the kubelogin authentication plugin. The plugin will initiate a multi-factor authentication (MFA) process by prompting the user to open a URL and enter a one-time code. Previously, the information was not visible when JProfiler was making a connection to a Kubernetes cluster.

Since JProfiler 13.0.6, the progress dialog will be expanded if such output is detected. The command line output is then shown in a text area where text can be copied to the clipboard and links can be opened directly the system web browser:

After completing the instructions, the connection will be made and the pods in the cluster will be listed.

Customizing telemetries in JProfiler

Ingo Kegel — Tue, 12 Sep 2023 07:00:57 GMT

Categories: JProfiler Screencast

Telemetries are an essential feature for a profiler, they help you get an idea about when things happen in the profiled JVM, and how various subsystems are correlated.

This screencast shows how to customize the telemetries section in JProfiler by adding probe telemetries. It discusses bookmarks, recording actions and setting time range filters for probe events in probe telemetries.

Working with probe events in JProfiler

Ingo Kegel — Fri, 15 Sep 2023 07:00:57 GMT

Categories: JProfiler Screencast

Probe events are of great help in debugging specific performance problems. To find events of interest, JProfiler gives you a lot of tools to narrow down the set of displayed events.

This screencast shows the HTTP server and HTTP client probes, the JDBC and JPA/Hibernate probes as well as the socket probe when profiling a real-world application. The various ways of filtering probe events as well as duration and throughput histograms are explained.

The profiled application is the CommaFeed RSS reader.

Enhanced JFR snapshot analysis with JProfiler

Ingo Kegel — Mon, 18 Sep 2023 07:00:57 GMT

Categories: JProfiler Screencast

JProfiler has excellent support for viewing JFR snapshots. This screencast focuses on the event browser, which is specific to JFR snapshots, and also gives an overview of the other view sections that offer some of the same views as regular profiling sessions.

Recording JFR snapshots with JProfiler

Ingo Kegel — Wed, 20 Sep 2023 07:00:57 GMT

Categories: JProfiler Screencast

Recording JFR snapshots with JProfiler

This screencast shows JProfiler's versatile functionality as a JFR recording controller. As an example, a JFR recording on a Kubernetes cluster is recorded and the resulting snapshot is shown in JProfiler. In this context, you can see the wizard for configuring JFR recording settings. In addition, JFR recordings of terminated JVMs and the handling of externally started JFR recordings are demonstrated.

Garbage collector analysis in JProfiler

Ingo Kegel — Fri, 22 Sep 2023 07:00:57 GMT

Categories: JProfiler Screencast

This screencast shows how to use the garbage collector probe in JProfiler. Having access to detailed information about the overall activity of the GC, as well as the single garbage collections, is crucial for tuning the garbage collector and achieving an optimal performance for your application.

How invokedynamic makes lambdas fast

Ingo Kegel — Wed, 10 Jan 2024 08:00:57 GMT

Categories: General

Recently, we have been at work rewriting our website in Kotlin. Instead of a view technology that uses string templates with embedded logic, we now use the Kotlin HTML builder to develop views as pure Kotlin code. This has a number of advantages, like being able to easily refactor common code. Also, the performance of such views is much better than that of string templates, which contain interpreted code snippets.

When measuring the performance, we noticed that a lot of anonymous classes were created for our views and their loading time was significant. Code that uses the Kotlin HTML builder is very lambda-heavy and as of Kotlin 1.9, lambdas are implemented as anonymous classes. The JVM has a sophisticated mechanism to avoid creating classes at compile time that was introduced in Java 8 - the LambdaMetafactory and invokedynamic. The JVM developers also claimed that the performance would be better than anonymous classes. So why does Kotlin not use that?

As it turns out, Kotlin can optionally compile lambdas with invokedynamic in the same way that Java does, by passing -Xlambdas=indy to the Kotlin compiler. This has been supported since Kotlin 1.5 and will become the default in the upcoming Kotlin 2.0 release. The great thing about having both compilation strategies available, is that we can compare how anonymous classes and invokedynamic compare in a real-world example.

First of all, the number of classes for our entire website project was reduced by 60% (!) when compiling with -Xlambdas=indy. Here you can see the list of classes for our store view with both compilation modes:

For that particular view, the cold rendering time was improved by 20%. This was simply measured by wrapping the rendering with a measurement function. How about the warmed-up rendering time? The times there are much shorter, and we need to introduce some statistics by making many invocations. This is easily done with JProfiler and has the added benefit that we can also compare the internal call structure.

With the default compilation to anonymous classes, we recorded 50 invocations after warm-up and got 12.0 ms per rendering:

With invokedynamic compilation, the time per rendering was 10.6 ms:

This is an improvement of 12% which is surprisingly large. This test does not measure the difference between the invocation mechanisms in isolation, but it includes the actual work that is done to render the store view. Against that baseline duration, a speed-up of 12%, - just by changing the compilation mode for lambdas - is quite impressive. Many DSL-based libraries in Kotlin are lambda-heave, so other use cases may also produce similar numbers.

By looking at the call tree, we can see that the version with anonymous classes makes 3 calls, instead of one: First, it instantiates the anonymous class and passes all the captured parameters:

Then it calls a bridge method without the captured parameters, which in turn calls the actual implementation:

Looking at the bytecode, we can see that a number of instructions are required to store the captures parameters into fields, and the bridge method also contains instructions that add to the overhead.

With invokedynamic compilation, the generated lambda methods are in the same class:

This works because the lambda instances are created by invokedynamic calls to so-called bootstrap methods.

Bootstrap methods are structures in the class file that contain signature information for the lambda and a method handle reference to a static method. The LambdaMetafactory then efficiently creates an instance for the lambda.

This intricate mechanism makes lambda calls on the JVM as fast as they are - and from Kotlin 2.0 on this will be the default for Kotlin as well.

Why JVMTI sampling is better than async sampling on modern JVMs

Ingo Kegel — Thu, 01 Feb 2024 08:00:57 GMT

Categories: General JProfiler

In recent years, "async sampling" has been hyped as a better way of CPU profiling on the JVM. While this has been true for some time, it is no longer the case. This blog post explains the history of sampling and the current state of the art.

The problem

The fundamental operation of a CPU profiler is to associate time measurements with call stacks. To obtain call stacks from all live threads, most CPU profilers perform sampling. Sampling means that data is measured periodically rather than continuously. However, this measurement is not trivial because the JVM does not store call stack information for easy access via an API.

The JVM compiles Java bytecode to native code for hot execution paths. The stack traces now have a native part that needs to be retranslated to Java in order to be useful. Also, it is not possible to ask a running thread what it's currently doing, but you have to interrupt it to get a defined state. Depending on how you do it, this introduces an observer effect that can severely alter the execution of the program.

Historically, sampling could only be done at a global safepoint. Global safepoints are states where the JVM can pause all threads for operations that require a consistent view of memory. At a safepoint, all Java threads are paused, ensuring they are not in the middle of modifying shared data. While safepoints originated from the stop-the-world phase of garbage collectors, they could also be used for other purposes, such as code deoptimization, class redefinition, and finally to safely get all stack traces for the purposes of sampling.

In contrast to garbage collector activity, sampling is performed quite frequently, on the order of once per millisecond. Requesting a global safepoint so many times per second can cause substantial overhead and a severe distortion of the observed hot spots. The adverse effects of global safepoints are especially pronounced for heavily multithreaded applications, where safepoints can limit concurrency, reduce thread cooperation and increase contention and synchronization overhead. The observed hot spots will then be skewed towards the safepoints, an effect known as safepoint bias.

Async profiling to the rescue

Unhappy with this state of affairs, the HotSpot JVM developers added the experimental AsyncGetStackTrace API that allowed profilers to get the stack trace of threads without requiring a safepoint. On Unix systems, profilers can use various signal mechanisms to periodically interrupt the running thread and execute a handler on the interrupted thread and call this API.

While this adds minimal overhead, it unfortunately is not an ideal solution. The main problem is that the interrupted thread and the JVM in general are in an unsafe state. The handler must be very careful not to perform any operation which might crash the process. These restrictions, especially regarding memory access and allocations make some advanced features of a profiler unfeasible. Also, the retranslation of the stack traces back to the Java stack trace results in a lot of stack traces being truncated or otherwise invalid. In addition, async sampling is also sampling from the pool of all live threads, so rarely scheduled threads will sometimes be missed completely.

JProfiler supports JVMTI sampling as well as async sampling, and as part of our tests we perform a lot of data comparisons. While async sampling is near-zero overhead and eliminates safepoint bias, it introduces a certain "trashiness" to the data and places limits on which features are possible to implement. For a long time, it seemed like an unavoidable trade-off with only bad options. One could choose one or the other sampling method based on the type of application and accept the corresponding drawbacks.

ZGC and thread-local handshakes

In the quest for an ultra-low latency garbage collector, the JVM developers needed a way to perform operations on individual threads without requiring a global VM safepoint. In Java 10, JEP 312 was delivered with no concrete use cases. While intriguing at the time, we were unable to make any use of this feature because it was internal to the JVM and not available for profiling agents.

The only publicly mentioned purpose in JEP 312 was that it blocked JEP 333 for the Z Garbage Collector (ZGC). In Java 11, ZGC was delivered as one of the big-ticket items, and thread-local handshakes helped it push maximum GC pause times below 10ms.

ZGC continued to be improved, and JEP 376 aimed to evict its last major work item from global safepoints: The processing of thread-related GC roots was moved to a concurrent phase. That JEP included a goal to "provide a mechanism by which other HotSpot subsystems can lazily process stacks" and issues like https://bugs.openjdk.org/browse/JDK-8248362 added this capability to the JVMTI, the interface that is used by native profiling agents.

JVMTI sampling strikes back

With Java 16, JEP 376 was delivered, and it was possible for profiling agents to use the lazy stack processing based on thread-local handshakes and avoid global safepoints for sampling. JVMTI sampling (called "full sampling" in JProfiler), is now comparable in overhead with async sampling and, given the frequency of local safepoints, the remaining local safepoint bias is irrelevant for the vast majority of applications.

Let's compare a real-world use case. A multithreaded Maven compilation for a medium-sized project was recorded with both JVMTI sampling and async sampling. The overhead is not measurably different, and the hot spot distribution is very similar. See the "Hot spots" view in JProfiler below, first for JVMTI sampling:

… and then for async sampling:

Is the difference the remaining safepoint bias? Not necessarily so, and most probably not. There are two other important factors at play: First, async sampling measures threads that are actually running while JVMTI sampling measures if threads are scheduled for execution, that is if they are "runnable". The JProfiler UI reflects this in the labelling of the thread status.

Second, async sampling operations do not work all the time. The technical "outages" are summed up at the bottom of the call tree without contributing to the total percentage:

These are substantial times and they do contribute some skew. So while async sampling measures actual CPU times, they are only partial CPU times and not a more useful measure than the runnable time measured by JVMTI sampling.

As an example of a feature that async sampling cannot provide, try to change the thread state to "Waiting", "Blocking" or "Net I/O". With async sampling, these are not available, unlike with JVMTI sampling.

When working with databases or REST services, having access to the "Net I/O" state is an invaluable benefit, though, because these are the times waiting for the external service.

What remains for async sampling? Async sampling can profile native stack traces, so if you are interested in that, it remains a useful tool. Other than that, full sampling is now by far the better alternative, in terms of data quality and available features, without compromising on overhead.

We invite you to try it out in the latest JProfiler release. Happy profiling!

Namespace awareness of XML actions in install4j

Ingo Kegel — Wed, 21 Aug 2024 07:00:57 GMT

Categories: install4j

This post explains an exceptional backward-incompatibility in the install4j 10.0.9 release. This was necessary due to a change in install4j 10.0.8 that was intended to fix the corruption of namespaced XML documents by modifying XML actions.

install4j provides a number of actions that work with XML files, like reading values, inserting fragments or removing nodes.

Most of these actions require that you enter an XPath expression to select the parts of the document to operate on. In versions prior to install4j 10.0.9, the XML parser used by the actions was not namespace-aware, so the XPath expressions did not require any namespaces.

This typically works well for reading values from an XML file, and it continues to be the default for install4j 10.0.9+, where the "XPath expression" property now has a new "Namespace-aware" child property that is initially deselected.

However, when modifying XML documents, the XML file needs to be written again, and using a non-namespace-aware XML parser means that the namespaces would be lost. To fix this problem, we turned on namespace-awareness for all XML actions in install4j 10.0.8. However, this meant that there was no way of specifying XPath expressions that matched namespaced elements anymore.

This is why the "XPath expression" property of all modifying XML actions has an "XML namespaces" child property since install4j 10.0.9.

Here you can specify namespaces and their prefixes in a separate dialog and then use the namespace prefixes in your XPath expression.

If you used XML documents without namespaces, no changes are required if you have configured XML actions in earlier versions of install4j. While the "Read value from XML file" and the "Count nodes in XML file" actions continue to work with namespaced elements as before, the following actions require changes to the XPath expression if they match namespaced elements with their "XPath expression" properties:

"Insert XML fragment into XML files" action
"Remove nodes from XML files" action
"Replace text in XML files" action

Each node test in the XPath expression that required a qualified name (QName) must now include the appropriate namespace prefix that matches an entry in the "XML namespaces" child property. For example, in the XML document

<?xml version="1.0" encoding="utf-8" ?>
<config xmlns="http://mycorp/cluster" xmlns:ext="http://mycorp/server">
  <cluster>
    <ext:server name="production" port="8000"/>
    <ext:server name="staging" port="7000"/>
  </cluster>
</config>

the non-namespaced XPath expression to match the server port of the production server is

//cluster/server[name='production']/@port

For the modifying XML actions, this XPath has to be changed to

/c:cluster/ext:server[name='production']/@port

with the namespace definitions

c=http://mycorp/cluster
ext:http://mycorp/server

in the "XML namespaces" child property.

While the "cluster" element in the source document is not written with a prefix, it is in a default namespace that must be specified just like the explicit namespaces to ensure the XPath expression matches it correctly.

Migrating to install4j 11

Ingo Kegel — Mon, 02 Sep 2024 07:00:57 GMT

Categories: install4j Migration

In most cases, migrating to install4j 11 usually just involves opening and saving your project with the install4j 11 IDE. Nevertheless, there are some considerations with respect to backward compatibility and some behavioral changes.

Notarization now uses the App Store Connect API. Previously, install4j could only perform notarization when building on macOS using the notarytool command line tool for which an Apple ID was required in the configuration. That mode is no longer supported in install4j 11. For the App Store Connect API, you need to specify issuer ID, key ID and the downloaded private key file.
The install4j IDE and command line compiler now require Java 21. The runtime requirement for the generated installers and launchers remains Java 8. The install4j downloads for Windows, macOS and Linux x64 contain a suitable JRE. If you download the Unix media files, you have to make sure to install Java 21 on your build server first.
The list of releases from JDK providers is now requested from URLs below https://www.ej-technologies.com/jreprovider/. This allows us to respond to API changes without breaking older versions of install4j and to introduce fixups for erroneous releases from JDK providers. The actual downloads are still performed from the URLs that are published by the JDK providers. If you have added exceptions to your firewalls, you need to take this into account.
As announced in the 10.x series, the macOS single bundle installer has been removed. The macOS single bundle archive should be used as a replacement. However, the macOS single bundle installer media files are not migrated automatically because it may take some consideration as to which actions you would like to run when the launcher is started for the first time.

On the "Launcher" tab of the media file wizard, you can select a "setup application" from the list of custom installer applications that are defined in the "Installer->Screens & Actions" step. In that custom installer application you can link to screens and actions, or screen groups and action groups to avoid duplicating configuration.

This removal was necessary due to signature and notarization requirements, which made the bundle directory unmodifiable at runtime. This installer type has been non-functional in recent macOS releases.
The "Sign all launchers" option for macOS media files has been removed as launchers are now always signed to comply with notarization requirements.
For the "Add VM options" and the "Modify classpath" actions, the property "Target file on macOS" was removed. It offered an option to write the .vmoptions file into the application bundle, which is no longer possible due to current notarization requirements. These files are now always created next to the application bundle.
install4j 11 has removed support for dynamic JRE downloads and shared JRE installations. Modern JREs that are linked to a minimum required module set do not match with these features and lead to various problems at runtime. Also, the concept of pre-installed JREs that could be found is no longer a mainstream concept.

Instead, we have expanded support for the use case where the initial download contains the JRE and updates should not include a JRE for small downloads and fast installations:
1. The new "Previous installations" search sequence entry type on the "General Settings->JRE Bundles->Search Sequence" step helps you to reuse the installed JRE in update installers. Only installations with the same application ID are considered for the search sequence entry type.
2. The "Install files" action now copies a JDK from a different installation directory if it was found by the "Previous installations" search sequence entry. This prevents issues that would arise if the other installation is uninstalled.
3. Update downloaders can now make decisions based on the JRE version of the update installer by inspecting com.install4j.api.update.UpdateDescriptorEntry#getJreMinVersion and #getJreMaxVersion. If the JRE version matches the currently used JRE, you can download a media file without a bundled JRE, otherwise a media file with a JRE should be downloaded.
The "Open PDF viewer" action and the "PDF display" form component now require at least Java 11.
Custom names of screens, actions and form components are no longer written to the runtime configuration, and only bean IDs are annotated into stack traces. These names were not usable programmatically and could expose unintended text. When inspecting stack traces, use the "Search ID" feature on the "Installer->Screens & actions" step to locate the corresponding beans.
There are breaking changes in the Gradle plugin configuration. All properties are now typed correctly and use the Gradle provider mechanism. This was necessary to enable compatibility with the configuration cache where extensions and projects cannot be accessed at execution time. Also, the deprecated variableFile property was removed.
Keyboard shortcut changes in generated installers on macOS: To move to the previous or next installer screen, use Ctrl+Option+Left Arrow and Ctrl+Option+Right Arrow. The previous keyboard shortcuts did not work in text fields. On Windows and Linux, the shortcuts remain Ctrl+Left Arrow and Ctrl-Right Arrow respectively.
The "Installation type" screen now behaves differently if the selected installation type is user-configurable and the user does not change the installation type in an upgrade installer. In this case, the selected components retain their previous installation state, and are not reset to the default set of the installation type.
For generated GUI launchers for which the "Uses SWT or QT" option has been selected on the "Executable info" step of the launcher wizard, installer applications - such as the update downloader - can only be started in a new process. This is necessary to avoid deadlocks. For automatic launcher integrations this is enforced automatically regardless of the settings on the "Launcher Integrations" tab of the custom installer application. Programmatic invocation through ApplicationLauncher.launchApplicationInProcess will throw a IllegalStateException in this case. Use ApplicationLauncher.launchApplication instead.

Refreshed JProfiler IDEA plugin for the new UI

Ingo Kegel — Mon, 23 Sep 2024 07:00:57 GMT

Categories: JProfiler

Kotlin 2.0 features a total rewrite of the Kotlin compiler known as "Kotlin K2". IntelliJ IDEA will remove support for the old compiler in version 2024.3 impacting all plugins that depend on the Kotlin plugin, such as the JProfiler IDEA plugin.

The newest version of the JProfiler IDEA plugin for IntelliJ IDEA now includes support for Kotlin K2 mode. This means that the JProfiler plugin no longer prevents switching to K2 mode in IntelliJ IDEA 2024.2 and is now ready for IntelliJ IDEA 2024.3 where K2 mode will be the default and plugins depending on the old API will no longer be loaded.

We took this opportunity to align the JProfiler plugin with another recent major change in IntelliJ IDEA: The new UI, which became the default in IntelliJ IDEA 2024.2. It is impractical for IDEA plugins to support both the old and the new UI, so we decided to change the UI once the new UI became widely used.

Plugin icons have been adjusted to the style of the new UI in IDEA. The action to profile the selected run configuration with JProfiler continues to be available in the dropdown menu of the run widget:

The JProfiler plugin adds additional settings to run configurations which are not immediately visible. To access these settings, select the "Profile" option in the "Modify options" dropdown. All other profiling settings can be configured in the startup dialog of the JProfiler window.

Once the profiling session is started, the output appears in a separate JProfiler tool window. That tool window displays the console output like the regular run tool window, along with a "JProfiler" tab that can be used after you connect with the JProfiler UI:

The "JProfiler" tab contains actions to start and stop data recording for CPU data, allocation data and probe events. Additionally, an action allows you to switch to the JProfiler window. The JProfiler window includes a similar action for switching back to the IDEA window, so that it becomes convenient to work with the two separate windows.

Profiling information is typically displayed in the JProfiler window, but the CPU graph data is also integrated in the IntelliJ IDEA UI because it makes sense to show this data directly in the source code. Use the "Apply graph" action in IntelliJ IDEA or generate a CPU graph in JProfiler to display CPU data within IntelliJ IDEA.

Once the CPU data has been applied, the "JProfiler" tab displays a list of recorded methods. Double-clicking on a method will take you to the source code. In the gutter of the source code editor, arrows for incoming and outgoing calls are added.

Clicking on a gutter icon displays the incoming or outgoing methods in a popup window, along with a bar chart showing the recorded times. Clicking on rows in the popup will navigate to the corresponding methods.

Also, the total recorded time and the invocation count for the target method will be shown at the bottom of the popup. The "Show in JProfiler" drop down in the bottom-right corner of the popup provides context-dependent navigation actions into the JProfiler UI.

The same navigation actions are also available in the context menu of the method table in the "JProfiler" tab:

One major change in the new IntelliJ IDEA UI is that plugins no longer add actions to the main toolbar. Instead, plugins can provide "toolbar quick actions" that are shown when you choose the "Add to Main Toolbar" action in the context menu of the main toolbar.

In the new JProfiler plugin there is now a toolbar quick action for the "Attach to JVM with JProfiler" action. With that action you can attach to a process that is already running and still get source code navigation from the JProfiler UI into IntelliJ IDEA as well as inline CPU graph data in source code editors:

This is how the action button looks like once it has been added:

The key bindings for all actions in JProfiler can be customized in the "Keymap" settings in IntelliJ IDEA. Given the limited availability of non-conflicting keyboard shortcuts, the navigation actions from the source code editor to the JProfiler UI are chained shortcuts where you first hit Ctrl-Alt-Shift-O and then another key to select the navigation action. If you frequently use this functionality, you may want to assign simpler keyboard shortcuts.

Improvements for macOS App Store submissions in install4j 11.0.2

Ingo Kegel — Tue, 14 Jan 2025 08:00:57 GMT

Categories: install4j

install4j 11.0.2 introduces several new features to simplify macOS App Store submissions, including automated entitlement handling for TestFlight, improved support for local testing with development provisioning profiles, and dynamic bundle versioning for easier resubmission of builds.

Background

Submitting a Java app to the Mac App Store can be a daunting task. Understanding the involved concepts and fulfilling the many requirements set by Apple is much easier when you have install4j to help you reach the finish line.

Since install4j 10.0, "the single bundle archive" media file type in install4j has an App Store submission mode that generates a .pkg installer that supports an optional "provisioning profile".

In addition, the launcher has several settings that are relevant for a successful App Store submission.

To be able to submit an application, the bundle identifier for the launcher must match the configured ID in App Store Connect. Since apps in the App Store run in a sandbox, they cannot even open a file without requesting the appropriate "entitlement". These fine-grained permissions can be requested in the entitlements file. Finally, the application category is a required attribute for an App Store submission.

Provisioning profiles

To complicate things, Apple has two different sets of entitlements. Some entitlements such as "com.apple.developer.applesignin" and "com.apple.developer.icloud-service" require a provisioning profile. This is an artifact that you create in your Apple Developer Account under "Certificates, Identifiers & Profiles".

In addition, using TestFlight is only possible when a provisioning profile is specified and the same "com.apple.application-identifier" and "com.apple.developer.team-identifier" attributes are also present in the entitlements file. Starting with install4j 11.0.2, these values are automatically copied to the entitlements by install4j, so using TestFlight is enabled as long as you use a provisioning profile.

Code signing certificates

Code signing for the App Store is further complicated by the fact that you need certificates of the types "Mac App Distribution" (for the app) and "Mac Installer Distribution" (for the .pkg installer). For each certificate, you have to generate a certificate signing request in the Keychain app, create the appropriate certificate in the Apple Developer Account, and import the certificate in Keychain.

When exporting from your Keychain, you have to add these certificates together with their private keys and specify the PKCS#12 file in install4j. If you also distribute non-App Store builds, you will also need to include an "Apple Developer ID" certificate. install4j automatically chooses the correct certificate from the specified PKCS#12 keystore.

Local testing

If you want to test the sandboxed environment of your app, you may want to install the generated .pkg file before submitting it to the App Store. However, if you use an App Store provisioning profile, such an installation will fail.

Instead, you have to use a "macOS App Development" provisioning profile and install it on your local machine. A development provisioning profile is associated with certificates of the type "Apple Development" or "Mac Development". This means that you have to change both the provisioning profile and the code signing certificate to create a development build.

Before install4j 11.0.2, using certificate types other than "Mac App Distribution" or "Mac Installer Distribution" for App Store code signing was not supported, so using development provisioning profiles was not possible.

If you do not require the special entitlements that are only available via provisioning profiles and you do not need to use TestFlight for testing, you can opt to not use a provisioning profile at all. In that case, the generated .pkg will be installable on your local machine even when signed with the distribution certificates.

Resubmitting builds

Another App Store-related improvement in install4j 11.0.2 is that the CFBundleVersion attribute is now set to a timestamp to allow submitting multiple builds with the same version to the App Store. Previously, you would have to change the user-facing version if a build was rejected by the App Store.

Ready to simplify your macOS App Store submissions? Download the current version of install4j and try it yourself.

Cross-platform JRE bundle creation under threat from JEP 493

Ingo Kegel — Tue, 08 Apr 2025 07:00:57 GMT

Categories: install4j

One of the most valuable capabilities introduced with the Java module system in Java 9 is its support for creating custom runtime images with jlink. Developers can include only the modules they need, resulting in lightweight JRE bundles tailored to the requirements of their applications. Using the --module-path option, it has even been possible to generate those runtime images for different operating systems from a single host machine.

With Java 24, JEP 493 introduces a change that significantly impacts this workflow. JDK vendors can now configure builds without .jmod files, as jlink can optionally extract the required resources from the lib/modules jimage file. While this change reduces the size of the JDK by about 25%, it also removes critical support for cross-platform linking.

The impact on deployment workflows

Cross-platform linking is essential for developers who build installation packages or runtime bundles targeting multiple operating systems. Without .jmod files in the JDK, the --module-path option of the jlink tool can no longer be used to link bundles for another target platform. This is because binary resources like executables and native libraries are extracted from .jmod files. In the jmod-less mode, these resources can only be extracted from the current JDK.

This change affects tools such as install4j, the Badass Runtime Plugin, and Moditect, which rely on the availability of .jmod files to build minimal, cross-platform runtime images. Their functionality is either limited or entirely blocked when .jmod files are not available.

For example, in install4j, users can select a JDK provider to build platform-specific runtime bundles directly within the project configuration:

Later in the process, the media wizard allows developers to bundle additional modules that are needed for the target platform:

Current state across JDK distributions

Adoptium has adopted JEP 493 for Eclipse Temurin in full, and its Java 24 builds no longer include .jmod files. This decision aligns with the goals of the JEP. To their credit, the Adoptium team has been very transparent and responsive in community discussions, and a solution to provide .jmod files as a separate download is currently being discussed.

As of Java 24.0, JDK distributions such as Azul Zulu, Amazon Corretto, and BellSoft Liberica continue to provide .jmod files in their Java 24 builds, maintaining compatibility with existing tools and workflows. It is hoped that other JDK vendors adopting JEP 493 will also recognize that .jmod files still need to be provided one way or another.

Proposed solution

The simplest and most practical solution is to publish .jmod files as an optional artifact alongside the standard jmod-less builds. This would preserve support for deployment tooling without compromising the goals of JEP 493.

Maintaining .jmod builds ensures that developers have the flexibility to choose between minimized JDK distributions and full-featured ones that support cross-platform deployment.

Community feedback matters

If your build is affected by this change, it is important to share your experience. The Adoptium issue is open, and the maintainers are actively listening to feedback.

The ability to build platform-specific runtime images remains a crucial requirement for many real-world Java projects. Let’s ensure that continues to be possible.

Caching auto-provisioned install4j distributions in CI pipelines

Ingo Kegel — Mon, 14 Apr 2025 07:00:57 GMT

Categories: install4j

Starting with install4j 11.0, integrating install4j into your build system has become much easier: The Gradle, Maven, and Ant plugins can now auto-provision the install4j distribution. This means the plugins will download and cache the appropriate install4j version automatically, so you no longer need to install install4j manually.

Since 11.0.3, the distribution is cached in OS-specific locations using sensible defaults for each build system:

Gradle caches to the Gradle user home (e.g. ~/.gradle)
Maven and Ant cache to OS-specific locations: %LOCALAPPDATA%/install4jDist on Windows, $HOME/Library/Caches/install4jDist on macOS, and either $XDG_CACHE_HOME/install4jDist or $HOME/.cache/install4jDist on Linux.

While this works well for local development, it’s less ideal for CI environments where you often want full control over the caching location to speed up builds and avoid redundant downloads. That’s why in the upcoming install4j 11.0.4 release, we're introducing the optional autoProvisioningCacheDir property.

Quick plugin usage examples

Gradle (Kotlin DSL)

plugins {
  id("com.install4j.gradle") version "11.0.4"
}

install4j {
    // New optional global and task-level property in 11.0.4+
    autoProvisioningCacheDir = layout.buildDirectory.dir("custom-install4j-dist-cache").get().asFile
}

register<Install4jTask>("install4j") {
    projectFile = file("resources/main/installer/myProject.install4j")
}

Maven

<plugin>
  <groupId>com.install4j</groupId>
  <artifactId>install4j-maven-plugin</artifactId>
  <version>11.0.4</version>
  <executions>
      <execution>
        <id>compile-installers</id>
        <phase>package</phase>
        <goals>
          <goal>compile</goal>
        </goals>
        <configuration>
          <!-- New optional property in 11.0.4+ -->
          <autoProvisioningCacheDir>${project.build.directory}/custom-install4j-dist-cache</autoProvisioningCacheDir>
          <projectFile>${project.basedir}/resources/main/installer/myProject.install4j</projectFile>
        </configuration>
      </execution>
  </executions>
</plugin>

Ant

<taskdef name="install4j"
         classname="com.install4j.Install4JTask"
         classpath="ant.jar"/>

<target name="media">
  <!-- New optional task property in 11.0.4+ -->
  <install4j projectFile="myProject.install4j"
         autoProvisioningCacheDir="${basedir}/custom-install4j-dist-cache"/>
</target>

Caching in GitHub Actions

If you're using GitHub Actions for CI, you can ensure that the downloaded install4j distribution is cached across runs. Here's a simple example with a Gradle build using the default cache location:

name: Build with install4j

on:
  push:
    branches: [ main ]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Set up JDK
        uses: actions/setup-java@v4
        with:
          java-version: '21'
          distribution: 'temurin'

      - name: Cache install4j distribution
        uses: actions/cache@v4
        with:
          path: ~/.gradle/install4jDist
          key: install4j-${{ runner.os }}-${{ hashFiles('**/build.gradle.kts') }}

      - name: Build
        run: ./gradlew build

To use a custom cache directory, define it as an environment variable:

env:
  INSTALL4J_CACHE_DIR: ${{ runner.temp }}/install4j-cache

...

- name: Cache install4j distribution
  uses: actions/cache@v4
  with:
    path: ${{ env.INSTALL4J_CACHE_DIR }}
    key: install4j-${{ runner.os }}-${{ hashFiles('**/build.gradle.kts') }}

And reference it in your Gradle build script:

install4j {
  autoProvisioningCacheDir = file(System.getenv("INSTALL4J_CACHE_DIR"))
}

This setup not only speeds up GitHub Actions builds, but also applies to any CI system where you can persist directories between runs, such as GitLab CI, Jenkins, or CircleCI.

Summary

While the auto-provisioning feature simplifies local development, the new autoProvisioningCacheDir option gives you full control in CI pipelines. With the 11.0.4 release, you’ll be able to manage where your install4j distributions are cached across all three supported build systems. This provides consistent and efficient builds across both developer and CI environments.

Bringing JProfiler to VS Code with Kotlin Multi-Platform

Ingo Kegel — Wed, 16 Apr 2025 07:00:57 GMT

Categories: JProfiler

At ej-technologies, we've long provided JProfiler integrations for Java IDEs like IntelliJ, Eclipse, and NetBeans. These plugins share a significant amount of logic: profiler configuration, session management, and communication with the JProfiler backend, all written in Kotlin.

When we decided to add support for VS Code, we faced a problem: VS Code extensions run on Node.js, not the JVM. Rewriting the plugin from scratch in TypeScript would have been inefficient. Instead, we turned to Kotlin Multi-Platform (KMP), allowing us to reuse our existing Kotlin code while adapting to the JavaScript ecosystem.

The Challenge of Cross-Platform Code

To support platform-specific functionality in shared code, Kotlin Multi-Platform uses the expect/actual mechanism. In the common source set, an expect declaration defines a function, class, or property without an implementation. Then, in each platform-specific source set (JVM, JS, etc.), an actual declaration provides the corresponding implementation. This lets the shared code call into platform-specific functionality without relying on reflection or dynamic dispatch.

The core of our plugin was already in Kotlin but moving it to common Kotlin code meant replacing all JVM-specific dependencies.

Replacing the JRE

For example, Kotlin common code can't rely on java.io for file access or java.lang.ProcessBuilder for OS processes. To migrate these two APIs, we used:

kotlinx-io for file operations and I/O
kmp-process for process management (a critical piece, since JProfiler launches external processes)

For example, consider the following JVM code that writes some text to a file:

java.io.File("file.txt").writeText("Hello")

With kotlinx-io, we defined the following extension function to achieve the same effect:

// Multi-platform file write using kotlinx-io
fun kotlinx.io.files.Path.writeText(text: String) {
    kotlinx.io.files.SystemFileSystem.sink(this).buffered().use { it.writeText(text) }
}

For anyone migrating JVM code to Kotlin common code, JetBrains offers a useful site for finding Kotlin Multi-Platform libraries: https://klibs.io.

These libraries worked as expected but required careful adjustments, especially around error handling and platform-specific quirks.

Serialization: From Kryo to kotlinx.serialization

Our existing plugins used Kryo for communication between the IDE and JProfiler. Kryo relies on JVM functionality. To support Kotlin/JS, we migrated to kotlinx.serialization.

This wasn't just a drop-in replacement. Kryo's runtime reflection and kotlinx.serialization's compile-time approach demanded changes to our data classes. However, we managed to annotate them in a way that both frameworks could serialize the same objects, ensuring backward compatibility with older JProfiler versions.

Coroutines Instead of Threads

The original plugin used multithreading for tasks like background communication with the profiler. In KMP, we replaced this with Kotlin coroutines, which work seamlessly across JVM and JavaScript.

This shift wasn't trivial. Coroutines require a different mindset, but the result is clean and maintainable.

Adapting jclasslib for Multi-Platform

In our plugin code, we need to read class files to resolve line numbers and other debug information. We use the jclasslib library for this purpose, which we maintain in-house. As part of the KMP migration, we adapted jclasslib's data structures module into a Kotlin Multi-Platform library. This allowed us to keep the same class file parsing logic while making it available to both our JVM and Node.js platforms.

That migration can be seen in this single commit and mostly involves getting rid of Java-specific class references and migrating I/O to kotlinx-io. Note that we only migrated the data structures module. Migrating the bytecode viewer would be more challenging, but with Compose Multiplatform, it looks feasible.

As an upside, jclasslib is now also listed on klibs.io, so you can use it in your own Kotlin Multi-Platform projects.

Bridging Kotlin and TypeScript

While most of our logic could live in Kotlin, the VS Code extension still needed a TypeScript layer to interact with VS Code's APIs.

The Limits of Kotlin/JS Interop

Ideally, Kotlin Multi-Platform should generate bindings for JavaScript libraries, but TypeScript integration isn't yet available. JetBrains started developing Dukat, a tool for generating Kotlin declarations from TypeScript, but it currently remains stalled and non-functional for non-trivial use cases.

Since this means that the VS Code API is not discoverable in Kotlin MP, using it would require a lot of manual work. Fortunately, TypeScript feels familiar to Kotlin developers, so this wasn't a major hurdle.

Another issue was the blurred line between Node.js and browser targets in Kotlin/JS. This is something we hope will improve with future KMP updates.

Sharing Interface Definitions

One pleasant surprise was how well Kotlin's interface definitions translated to TypeScript. We could define contracts (like RPC messages) in Kotlin and consume them in TypeScript with minimal friction. The reverse (using TypeScript types in Kotlin) was a lot harder, requiring manual type mappings.

The Result

Today, JProfiler's VS Code extension offers the same core features as our other IDE plugins, thanks to Kotlin Multi-Platform. Developers can profile their applications directly from VS Code, with most of the logic shared across all supported platforms.

Along the way, we have learned the following lessons:

KMP is powerful but demands adaptation. Replacing JVM APIs requires research and testing.
Coroutines simplify cross-platform concurrency, but migrating from threads takes effort.
TypeScript interop works best one-way (Kotlin → TypeScript). For now, manual bridging is still necessary.

If you're a Kotlin developer exploring multi-platform possibilities to prevent a full rewrite, our experience shows that even niche use cases like IDE plugins can benefit from KMP.

Profiling Kafka #1 – Message Flow & Hot Spots

Ingo Kegel — Tue, 22 Apr 2025 07:00:57 GMT

Categories: JProfiler Screencast

Kafka-based applications are notoriously hard to profile. Message flow happens in background threads, stack traces don’t reveal the full picture, and it’s hard to know which topic contributes to which hot spot.

JProfiler’s Kafka probes give you deep insight: producers, consumers, and message-level details are all captured and correlated with performance data.

This screencast walks through profiling a Spring Kafka application, showing how:

consumer call trees are split by topic
producers link directly into probe views
you can correlate CPU hot spots with Kafka topics
Kafka events are filterable, inspectable, and aggregatable

Advanced Kafka probe configuration in JProfiler

Ingo Kegel — Wed, 23 Apr 2025 07:00:57 GMT

Categories: JProfiler Screencast

In our first Kafka screencast, we looked at how JProfiler correlates message flow and CPU usage through producers, consumers, and topic-level call trees.

In this follow-up, we go deeper, showing how to configure custom naming for Kafka messages based on their content.

This enables you to:

split call trees by semantic message types
track specific event types in probe views
add value-level details to single event descriptions
visualize outliers in event duration histograms

We also trigger a Kafka message spike via an API call and analyze its impact, all without changing the application code.

Profiling Java applications in VS Code with JProfiler

Ingo Kegel — Fri, 25 Apr 2025 07:00:57 GMT

Categories: JProfiler Screencast

JProfiler now integrates directly into VS Code, bringing the powerful profiling tool into your everyday development workflow.

In this screencast, we profile the Spring Pet Clinic demo and walk through the features of the JProfiler extension for VS Code, including:

Toggling profiling mode
Automatic setup of profiled packages
Source code navigation from profiling views
Attach mode for unsupported launch methods (like Maven)
Built-in Gradle integration

If you're using a launch method in VS Code that isn't currently supported, let us know, we’re always looking to expand support.

Advanced SSH remote profiling with JProfiler

Ingo Kegel — Mon, 28 Apr 2025 07:00:57 GMT

Categories: JProfiler Screencast

Remote profiling can be challenging when SSH access involves custom setups, proxies, or cloud authentication plugins. JProfiler 15 introduces advanced SSH connection features that remove these obstacles, enabling profiling in complex environments without manual setup.

This screen cast shows how to profile remote JVMs even in situations where the built-in SSH client is insufficient, using AWS Session Manager as an example.

Along the way, you will see how to:

Use OpenSSH mode for remote profiling
Connect with ProxyCommand and the AWS CLI
Handle SSH port forwarding restrictions with netcat mode

Capturing and comparing MBean states with JProfiler

Ingo Kegel — Wed, 30 Apr 2025 07:00:57 GMT

Categories: JProfiler Screencast

MBeans expose a wide range of runtime metrics and management operations that are essential for understanding the internal state of Java applications. Traditionally, JProfiler has supported live inspection of MBeans during a profiling session.

With the new MBean snapshot feature in JProfiler 15, it is now possible to capture the complete MBean state, compare snapshots, and analyze metrics offline, even after the application has shut down.

This screencast demonstrates the new functionality with a small Hazelcast application that performs random map operations and registers a custom MBean for triggering cleanup operations.

Along the way, you will see how to:

Capture and compare MBean snapshots manually
Trigger MBean snapshots programmatically with method triggers
Restrict the snapshot scope to specific MBeans

Heap Walker scripting for snapshot analysis

Ingo Kegel — Fri, 02 May 2025 07:00:57 GMT

Categories: JProfiler Screencast

Previously, JProfiler's heap walker only offered advanced filtering and grouping features in live sessions. With JProfiler 15, the heap walker introduces full support for filtering and grouping in snapshots. A new API lets you write scripts to filter objects or define custom grouping logic based on dumped object data.

This screencast demonstrates the new functionality with a small Hibernate-based demo that creates different types of query cache entries. Hibernate’s second-level cache can quickly fill up with unexpected entries, and identifying what’s taking up space is key to resolving memory issues. JProfiler now makes it possible to answer such questions with snapshots.

The screencast shows how you can:

Group cache keys by query structure to compare memory impact
Use object set filter scripts to isolate problematic cache entries
Use merged dominating references to understand why objects are retained

JVM performance watch roundup April 2025

Ingo Kegel — Tue, 06 May 2025 07:00:57 GMT

Categories: Roundup

I post notes on JVM performance-related news on social media whenever a patch, JEP, or benchmark catches my eye. This blog post collects everything shared in April 2025. Each section rewrites the original thread in plain text.

Follow me on to get these updates as soon as they go out.

1. JFR to gain CPU-time-aware sampling

A new JEP draft proposes CPU-time profiling in JFR via a new jdk.CPUTimeSample event. Unlike today’s JFR sampling, which can’t distinguish between running and waiting threads, this upgrade measures actual CPU time consumed between timestamps.

Samples will include thread ID, timing, and CPU delta, and can be configured by interval or frequency. This allows more accurate attribution of CPU usage in profiling tools.

JProfiler will use this to highlight real CPU hot spots in JFR snapshots by identifying code that was actually executing rather than just present in stack traces.

2. Scoped values finalized in Java 25

Scoped values are replacing ThreadLocal as a safer and faster way to pass context, especially in structured concurrency and virtual threads. Finalized by JEP 506 after five previews, they arrive in Java 25.

Unlike ThreadLocal, scoped values are immutable and don’t require copying to child threads. This eliminates overhead in virtual thread hierarchies and prevents bugs caused by unintended sharing of mutable state.

They also reduce the risk of memory leaks. ThreadLocal often leads to memory leaks when large objects or class loaders are accidentally retained. Scoped values avoid this pattern by enforcing scoped, immutable context.

JProfiler’s heap walker already includes an inspection for thread-local leaks. Scoped value support is planned for a future version.

3. Compact Object Headers proposed as production feature

JEP 450 introduced Compact Object Headers in Java 24 as an experimental feature: shrinking object headers to 64 bits on 64‑bit systems. A new JEP draft now proposes promoting it to a product feature.

This change cuts live heap usage by 10–20%, improves cache locality, and reduces GC frequency and duration. In production tests (for example at Amazon), it led to:

20%+ heap reduction (SPECjbb2015)
8–10% lower CPU usage
15% fewer GCs

The mechanism packs class metadata and hash code into a compact field. The trade-off is more complex GC and locking logic in exchange for memory savings in large heaps.

JProfiler tips roundup April 2025

Ingo Kegel — Thu, 08 May 2025 07:00:57 GMT

Categories: Roundup

I regularly share practical advice and insights on JProfiler and install4j on social media, covering features, shortcuts, and use cases. This blog post collects everything shared in April 2025. Each section rewrites the original thread in plain text.

Follow me on to catch future tips as they’re posted.

1. Comparing snapshots to explain performance changes

Snapshot comparisons in JProfiler help you answer questions like whether memory usage increased, I/O operations became more frequent, or a specific method slowed down.

JProfiler provides four dedicated comparison views: CPU, memory, probe, and telemetry. These views let you analyze performance regressions or behavior differences between snapshots.

Each comparison type has its own wizard to help configure the baseline and target snapshots. Once set up, JProfiler presents a tailored UI for each case. For example, telemetry comparisons graph time series data such as heap usage across snapshots, making it easy to correlate metric shifts with changes in application behavior.

2. Visualizing Java locking behavior in real time

JProfiler offers a real-time view into Java synchronization by recording and analyzing both intrinsic locks (synchronized) and java.util.concurrent locks. Locking events include blocking durations, involved threads, and the specific monitor or lock objects, making it easier to debug deadlocks or optimize concurrency.

To reduce noise, JProfiler applies configurable thresholds so that only events above a certain duration are recorded.

The monitor history view provides a searchable table with durations and stack traces for both the waiting and owning threads.

The locking graph is a visual representation of thread interactions via monitors and locks. Nodes represent threads or locks, and edges show the interactions. You can mark specific threads or locks to restrict navigation to relevant events using the event switcher.

3. Detecting runtime spikes with the outlier view

JProfiler’s outlier detection view highlights methods with rare but significant runtime spikes, cases that can be missed when focusing only on total or average execution time. Instead of just aggregating performance data, it computes an outlier coefficient:

(max time - avg time) / avg time

This lets you find methods that usually behave well but occasionally take much longer. Typical examples include intermittent network latency, caching failures, or blocking I/O in rarely used code paths.

The view filters out low-impact cases by default, showing only methods with more than 10 invocations and a maximum duration above 10 ms. These thresholds are configurable.

Start CPU recording, open the outlier detection view, and sort by the outlier coefficient to pinpoint erratic behavior.

JVM performance watch roundup May 2025

Ingo Kegel — Tue, 03 Jun 2025 07:00:57 GMT

Categories: Roundup

I post notes on JVM performance-related news on social media whenever a patch, JEP, or benchmark catches my eye. This blog post collects everything shared in May 2025. Each section rewrites the original thread in plain text.

Follow me on to get these updates as soon as they go out.

1. Streamlined ahead-of-time caching with single-step command-line option

JEP 514 proposes a streamlined command-line interface for generating ahead-of-time (AOT) caches in the JVM. Until now, AOT cache creation requires a two-step process: first recording with -XX:AOTMode=record, then generating the cache using -XX:AOTMode=create. The new -XX:AOTCacheOutput=<file> option simplifies this by combining both steps into a single JVM invocation.

This integrated approach automatically manages a temporary config file for the training phase. Additionally, the new JDK_AOT_VM_OPTIONS environment variable will allow developers to customize the cache creation phase independently of the training phase. This is useful for scenarios where cache generation might benefit from different hardware or memory configurations.

The existing two-step workflow remains supported, making it possible to record on a small instance and then create the cache on a more powerful machine.

2. JFR stack sampling overhaul with cooperative safepoint sampling

JFR stack sampling is undergoing a significant rewrite aimed at improving safety, reliability, and scalability in production environments. JEP 518 introduces a cooperative stack sampling mechanism that eliminates the old crash-prone asynchronous heuristics in favor of sampling at safepoints.

In the current implementation, JFR forcibly stops threads at arbitrary points and guesses the call stack. This approach often resulted in invalid traces and occasional JVM crashes, particularly when classes were unloaded during sampling. The new design instead marks threads and lets them stop at the next safepoint. At that point, JFR records just the program counter and stack pointer, deferring the actual stack reconstruction to the thread itself at a safe location.

This change allows JFR to allocate memory safely during stack parsing. While some limitations such as incomplete traces for intrinsics or native methods remain, the risk of JVM crashes is effectively removed.

For JProfiler, this improvement means JFR recordings will become a more interesting data source, which is especially useful in environments where native agents are restricted.

3. Generational Shenandoah GC is graduating from experimental to production

Generational Shenandoah is moving from experimental to production status. Initially introduced as an experimental feature in JEP 404 (JDK 24), generational Shenandoah aims to improve throughput and pause times for allocation-heavy workloads by dividing the heap into young and old generations.

Currently, enabling generational mode required using experimental flags:

-XX:+UseShenandoahGC
-XX:+UnlockExperimentalVMOptions
-XX:ShenandoahGCMode=generational

According to JEP 521, generational Shenandoah is now considered stable enough to drop the +UnlockExperimentalVMOptions flag requirement, thereby simplifying its activation. However, single-generation Shenandoah remains the default.

Benchmarks like DaCapo, SPECjbb2015, and Heapothesys have reported encouraging results. For memory-sensitive or low-latency workloads, generational mode is worth evaluating.

4. JFR method-level timing and tracing

JEP 520 introduces method-level timing and tracing to JDK Flight Recorder (JFR) via JVM-managed bytecode instrumentation, starting with Java 25. With the jdk.MethodTiming and jdk.MethodTrace events, developers can now record exact invocation counts, execution times, and stack traces for targeted methods. Targets are configured using class names, method references, or annotations.

This feature is particularly useful for pinpointing performance bottlenecks in critical or infrequently called code such as startup logic, connection pools, or custom endpoints. Filters allow multiple selection types: class, method, or annotation. For example, ::<clinit> targets all static initializers, and annotations like @RequestMapping can be used to track selected methods.

JProfiler users benefit from JEP 520 by gaining some high-resolution CPU data when analyzing JFR snapshots. This aligns with JProfiler’s existing support for both agent-based instrumentation and JVMTI sampling.

JProfiler tips roundup May 2025

Ingo Kegel — Wed, 04 Jun 2025 07:00:57 GMT

Categories: Roundup

I regularly share practical advice and insights on JProfiler and install4j on social media, covering features, shortcuts, and use cases. This blog post collects everything shared in May 2025. Each section rewrites the original thread in plain text.

Follow me on to catch future tips as they’re posted.

1. Correlating XHR calls with backend activity in JProfiler

JProfiler supports correlating JavaScript XMLHttpRequest and fetch() calls with backend server activity through XHR origin tracking. This feature helps identify which user interaction triggered a particular backend request.

To enable this functionality, install the JProfiler origin tracker Chrome extension. When active, it intercepts XHR calls in the browser and links them to the running JProfiler session. In JProfiler’s JavaScript XHR view, you’ll find a combined call tree of all tracked XHR calls handled by the profiled JVM.

This view shows JavaScript stack traces with source files and line numbers and hyperlinks to the corresponding server-side call tree.

In the call tree, XHR nodes are grouped by the triggering browser event (e.g., click, submit), the DOM element, and the JavaScript call stack.

For projects using popular JavaScript frameworks, the extension traverses the DOM tree to locate meaningful splitting attributes. You can also manually specify an attribute by adding data-jprofiler="..." to any DOM element.

2. JProfiler’s integrated MBean browser

JProfiler includes a built-in MBean browser that allows you to explore, edit, and visualize JMX data directly, without needing remote JMX access.

MBeans provide a standard way to expose runtime data and modify configuration in Java applications. They are published by app servers like Tomcat, frameworks like Apache Kafka, or by internal JVM metrics. JProfiler’s MBean browser automatically discovers all MBeans registered in the JVM being profiled.

If an attribute is editable, an edit icon allows direct modification of arrays or simple types.

JProfiler also supports defining custom telemetries from numeric MBean attributes. A custom telemetry can be created for any numeric value via the context menu, including nested fields in composite or tabular data.

MBean operations are available too. You can invoke operations with parameters and see the structured return value.

3. Analyzing native HPROF and PHD heap snapshots in JProfiler

JProfiler can open native HPROF and PHD heap snapshots from any JVM, including HotSpot, Android, and IBM J9.

Use Session -> Open Snapshot in JProfiler to analyze HPROF or PHD files. The heap walker is fully available for in-depth memory analysis.

These native heap snapshots are saved directly by the JVM or command-line tools, allowing you to capture the heap state without attaching the JProfiler agent. This is helpful in production environments where agents are not allowed.

Note that native heap snapshots support fewer features than JProfiler snapshots. Allocation call stacks are not available, and only the heap walker is enabled. All other sections are grayed out.

You can also create HPROF or PHD heap snapshots from a live session in JProfiler, either through the menu or by setting up trigger actions. A common use case is saving a heap snapshot automatically on OutOfMemoryError.

JProfiler supports taking HPROF snapshots without loading the profiling agent, both locally and remotely, directly from the attach dialog.

For command-line workflows, JProfiler ships with bin/jpdump, an alternative to jmap that handles process selection, Windows services, mixed 32/64-bit JVMs, and auto-numbers files.

HPROF snapshots can include thread dumps. If the dump was triggered by an OutOfMemoryError, JProfiler highlights the responsible thread, making it easier to identify what was happening at the time.

JEP 493 follow-up: install4j 11.0.4 is ready for separate JMOD bundles in Eclipse Temurin 24.0.2

Ingo Kegel — Thu, 05 Jun 2025 07:00:57 GMT

Categories: install4j

Two months ago, I wrote about how JEP 493 threatened cross-platform JRE bundle creation by allowing JDK vendors to omit JMOD files from their distributions. Without JMOD files, tools like install4j cannot build cross-platform runtime images. This had the potential to seriously disrupt functionality for our users.

The first JDK vendor to implement this change was Adoptium, which started releasing without JMOD files starting with their 24.0.0 release.

Now the problem is about to be solved: The Eclipse Temurin project plans to publish separate JMOD downloads starting with version 24.0.2. This means that developers using install4j will again be able to build modularized JRE bundles for recent releases of Eclipse Temurin.

install4j 11.0.4 is already prepared for this change. It fully supports the upcoming separate JMOD archive downloads in Eclipse Temurin 24.0.2. With these minimum versions of install4j and Eclipse Temurin, developers can build modularized JRE bundles again. With Eclipse Temurin 24.0.0 and 24.0.1, the only option was to include everything, resulting in unnecessarily large runtime bundles.

🙏 Thanks to the team at Adoptium for listening and making this happen so quickly!

All our artifacts are now published on Maven Central

Ingo Kegel — Fri, 06 Jun 2025 07:00:57 GMT

Categories: General

We have migrated all of our public Maven artifacts to Maven Central. Previously, these artifacts were available from our own Maven repository, which will remain online for older releases. New releases will be published exclusively on Maven Central.

Maven Central is the default repository for Maven and also present in most Gradle builds. Not having to add a custom repository makes using our libraries a lot more straightforward.

Here’s a list of the published artifacts in the format groupId:artifactId:

JProfiler

com.jprofiler:jprofiler-controller
Controller API for managing profiling recordings in-process.
com.jprofiler:jprofiler-mbean
MBean API for managing profiling recordings via JMX.
com.jprofiler:jprofiler-injected
API for developing probes by injecting measurement calls into third-party libraries and frameworks.
com.jprofiler:jprofiler-embedded
API for developing probes by embedding measurement calls directly in the application code.

perfino

com.jprofiler:perfino-api
The API library for integrating with perfino.

install4j

com.install4j:install4j-runtime
API classes for install4j.
com.install4j:install4j-jdk-provider
API for developing a custom JDK provider for install4j.
com.install4j:install4j-maven
The Maven plugin for invoking the install4j compiler.

If you’re currently using our custom Maven repository, simply remove that entry from your build files. The group and artifact coordinates remain the same, so no other changes are necessary.

If you are using a Gradle build without direct or proxied access to Maven Central, you can add it to your build script:

repositories {
    mavenCentral()
}

Website refresh: Visual updates, dark mode, and semantic search for docs

Ingo Kegel — Mon, 07 Jul 2025 07:00:57 GMT

Categories: General

We have just rolled out significant changes to our website. They include many visual updates and important infrastructure updates that speed up loading times in many locations across the globe.

In addition, there are three functional changes that we would like to highlight:

Dark/Light mode is now available for the entire website. It detects your OS setting automatically and can be toggled manually in the top-right corner.

The documentation for all our products (JProfiler, install4j and perfino) is now served directly from the website. The rendering is improved considerably and the dark/light mode setting of the website uniformly applies to the documentation as well.

The documentation now features semantic search. Using the search box in the header, you can search for concepts and terms. The search results directly link to the relevant sections in the documentation.

Search is also available for localized variants of the JProfiler documentation (Chinese, Japanese and Korean).

The power of async tracking in JVM profiling

Ingo Kegel — Fri, 25 Jul 2025 07:00:57 GMT

Categories: JProfiler

Async operations can speed up applications and improve responsiveness, but they also introduce complexity. Especially in the context of profiling, understanding what really happened and why can be surprisingly tricky. This post shows how JProfiler's async tracking feature helps fix hard performance problems in your application.

Why are async calls important?

Unless you are fortunate enough to have virtual threads at your disposal, making async calls is the only way to stop blocking the current thread while a task is being executed. Many systems and frameworks have a canonical way of doing this, such as submitting a CompletableFuture to an ExecutorService. In an async call, the task is executed by a different thread, and the result (if one is even needed) can be processed by a callback.

UI systems are typically built in such a way that there is a single event dispatch thread that can modify and repaint UI components. Web browsers are built this way, but also all common JVM UI toolkits, like Swing, SWT and JavaFX.

The problem

A common problem with async calls is that a stack trace from the deferred task has no connection to the thread that initiated the task. This makes debugging notoriously difficult ("callback hell"), and it's an even greater problem for profiling. In most cases, you don't look at methods in isolation, but you always want to attribute the cumulative measured time of any method to the parents in the call stack. In this way, you find out who is responsible for a performance problem which helps you to fix it.

Let's look at an example. The call tree below shows the install4j UI while the user hovers over a single item in the view selector without any visual change. The consumed times are quite a bit more than we would expect. The root node in the call tree is the event dispatch thread and contains unprofiled classes in its internal machinery. Below it, we directly see the NavigationTree.paintComponent method that runs on the event dispatch thread. There is no indication of who triggered this method, either via an EventQueue.invokeLater or an EventQueue.invokeAndWait call.

Enter async tracking

With JProfiler, you have a tool at your disposal that can stitch together async call sites with async execution sites. In the profiled example, async tracking for AWT was active. This is off by default, so you need to switch on the particular kind of tracking that's useful for your application by clicking on the tracking icon in the status bar or showing it in the "Profiling" menu.

When async tracking is enabled, a hyperlink label is shown above the call tree. When you click on it, JProfiler calculates a call tree where all tracked async calls are inlined.

The "Add async execution time to tree" checkbox above the call tree is important. If you select it, the time spent in the async execution is added to the parent node in the call tree. It then effectively treats async calls as if they were blocking calls. This is very useful to find hot paths in the async execution sites by starting from the top of the tree.

Fixing the problem

In the async call tree, we see that the mouseMoved method of the MouseMotionListener in NavigationComponentHelper issues a lot of repaints. We can now check the source code of that method and prevent unneeded repaints where the visual representation of the view selector does not change.

This example translates to many real-world scenarios with the other supported tracking types. Async support in your profiling tool is a crucial feature that enables you to productively fix performance problems in your application. Try it out with the latest JProfiler version and convince yourself of the power of async tracking!

With Temurin 24.0.2, Adoptium JDKs can again be modularized by install4j

Ingo Kegel — Mon, 04 Aug 2025 07:00:57 GMT

Categories: install4j

This year we had some dramatic moments starting in April with the release of Temurin 24.0.0 from Adoptium, our default JDK bundle provider. In this blog post we celebrate the happy conclusion of this incident.

The problem began when Adoptium started to take advantage of the new flexibility in JEP 493 to remove JMOD files from their JDK distributions. However, without those JMOD files, install4j could no longer use jlink to modularize JDK bundles for other platforms. There was no build failure with Temurin 24.0.0 and Temurin 24.0.1, and these versions were treated like pre-Java 9 JDKs, which could not be modularized. This means that the entire JDK was included in a JDK bundle with your installer if you configured one of those JDK versions. Consequently, media file sizes increased by 100 MB and more.

We do offer several other JDK bundle providers and could have removed Adoptium as a last resort. However, this was very undesirable: What if the other JDK providers went the same way?

Fortunately, the Adoptium team was very responsive to our use case, and by June they had an alternative solution in place, providing JMOD files as a separate artifact.

On the 23rd of July 2025, Temurin 24.0.2 was released as the first version with this additional artifact. With install4j 11.0.4+, Temurin 24.0.2+ can now be modularized again.

Non-LTS Java versions are used less frequently, but Java 25 LTS is around the corner, so we are glad that this situation was resolved in time. If you are using an older version of install4j and want to bundle Temurin 24+, upgrade now.

Migrating to install4j 12

Ingo Kegel — Fri, 31 Oct 2025 08:00:57 GMT

Categories: install4j Migration

In most cases, migrating to install4j 12 usually just involves opening and saving your project with the install4j 12 IDE. Nevertheless, there are some considerations with respect to backward compatibility and some behavioral changes.

As part of the evolution of the "Update alert" form component into the "Streamlined installation" chooser form component, the installer variable sys.confirmedUpdateInstallation has been renamed to sys.streamlinedInstallation. When the project is migrated, it is replaced in the entire project file.

However, if you use this variable in custom code, you need to update it accordingly.
The way that install4j determines the previous installation directory has been redesigned. See the What's new page for more details. Project migration to install4j 12 involves the following automatic changes to the project so that the resulting behavior closely corresponds to what happened in previous versions of install4j:
- A "Set installation directory" action is added to the startup node, either after an existing "Request privileges" action or as first action. Its "Search for previous installation" property is selected if the "Detect previous installation directory" setting on the "Installer->Update options" was previously selected. That setting has been removed. By default, the scope is set to "For all users if directory is writable". If a "Request privileges" action is used in the installer, but not in the startup node, the scope is set to "Installation directory for all users" instead.
- A "Set installation directory" action is added after each "Request privileges" action used in screens. The "Installation scope" of the action is set to "For all users if directory is writable" and the search for update installations is disabled.
However, the previous way the installation directory was set involved hidden logic and some heuristics that are not replicated by the new setup. In certain edge cases, the result can now be different. With the flexibility of the "Set installation directory" action you can achieve any desired behavior, but you will have to make it explicit in your project.
The non-public installer variable sys.resolveUserSpecificInstallationDir has been removed. It was previously set by the "Request privileges" action if a fallback to a user-specific installation directory was necessary. In install4j 12, this functionality has been moved to the new "Set installation directory" action which sets the boolean sys.installForAllUsers installer variable.

In the unlikely case that you use sys.resolveUserSpecificInstallationDir, you have to migrate it to the negated sys.installForAllUsers installer variable.
The "AdoptOpenJDK" and "AdoptOpenJDK (OpenJ9)" JDK providers have been deprecated. The associated API has been deprecated for a long time. Migrate to Adoptium for Temurin JDKs and the new Semeru provider for OpenJ9 JDKs instead.

If your project is configured to use a deprecated JDK provider, it is still shown in the JDK provider chooser. However, it cannot be selected for new projects anymore.
install4j now requires a POSIX-compatible shell for Unix/Linux media files. The only case where this is a problem is Solaris 10. Solaris 10 has been EOL since early 2024.

If you still need support for Solaris 10, define the compiler variable sys.ext.solaris10Compatible to add a workaround that executes /usr/xpg4/bin/sh on Solaris 10.
For macOS single bundle media files with the archive format set to ".pkg for App Store submission", additional top-level files are now added to the .pkg file. Previously, any configured additional top-level files were ignored in that case.

JProfiler 16: Profiling Agentic Java Applications

Ingo Kegel — Fri, 27 Feb 2026 08:00:57 GMT

Categories: JProfiler

Why AI Needs Profiling

Traditional profiling focuses on the JVM's internal execution, like method durations, memory allocation, and thread synchronization issues. One of JProfiler's main innovations of the past is grounded in its probes: Measurements of higher-level systems, like HTTP, JDBC, and RPC calls. With LLM frameworks like LangChain4j and Spring AI, a new performance challenge has emerged. LLM interactions introduce highly non-deterministic latency and substantial resource costs that standard CPU profiling cannot put into context. JProfiler is in a unique position to bridge this gap by treating AI interactions as a data source for a new probe.

The AI Probe: Observability for LLM Workflows

The centerpiece of JProfiler 16 is the new AI Probe. It provides a way to observe how your application interacts with LLMs, and delivers context-aware metrics that help you optimize two important problems: performance and cost.

While probes have previously only focused on duration of events, JProfiler 16 introduces switchable primary metrics. With the AI probe, these include input tokens and output tokens. This allows you to identify which prompts are driving up costs or causing latency spikes.

In the probe events view, you can inspect the entire contents of each prompt. This is potentially a massive amount of data. We've used this opportunity to advance JProfiler's event system from the original role as a debugging helper to a file-backed high-performance data store in this release. This enables event-centric views such as the AI probe and benefits all other existing probes.

The events view can now be the control center when working with a probe: With its advanced filtering capabilities you can trim the set of events across multiple dimensions and use the secondary views at the bottom to inspect hot spots, call trees, distribution histograms and timelines.

Scripting and Custom Hot Spots

For many probes, the most useful perspective is to look at its hot spots. For example, the JDBC probe shows you cumulative data for all measured prepared statements. With the AI probe, it is less obvious how to extract a "hot spot" string for multiple concurrent requests and how to name them.

By default, JProfiler shows the model name. This is a valid hot spot perspective, especially if you work with multiple models, but falls short for many other use cases and problem scenarios.

Once again, JProfiler's extensive support for scripting comes to the rescue: In a modern Java editor with code completion, inspections, quick fixes and refactorings, you can enter a script to extract a string that classifies the LLM request. To help you extract the required data, JProfiler includes an API that models the request.

JProfiler will compile the script and transfer it to the profiled JVM. Each time a call is made, the script will be run and data for the cumulative hot spots view will be calculated.

Practical Exploration: The LLM Demo

For developers who are considering working on agentic applications, we have included a demo app in this release. It allows you to explore the features of the AI probe without access to a real-world application.

Matching the theme of the AI probe, it downloads article summaries from the arXiv pre-print server and extracts keywords from them. After processing a batch of articles, it consolidates similar keywords.

With this demo, you can also see how to use the HTTP Client probe in tandem with the AI probe to inspect a workflow at different processing stages.

Foundations for the Future

The three main topics of this release are AI observability, massive scalability for probe events, and deep support for modern JVMs.

But we don't stop here. With JProfiler 16, our innovation has accelerated and it will continue to do so. Today, JProfiler provides the raw visibility needed to interpret the interactions between deterministic code and probabilistic models. Behind the scenes, we are laying the groundwork for future versions to move from pure observation to automated, AI-assisted performance heuristics. Stay tuned!

Profiling AI: LangChain4j and Spring AI

Ingo Kegel — Wed, 04 Mar 2026 08:00:57 GMT

Categories: JProfiler Screencast

Agentic applications introduce unique profiling challenges. Beyond standard CPU usage, performance and costs are determined by the complex structure of prompts, RAG retrievers, and tool calls that remain hidden behind framework abstractions.

To avoid vendor lock-in, most developers use frameworks like LangChain4j or Spring AI. JProfiler’s AI probe provides deep visibility into these frameworks.

This screencast walks through profiling a LangChain4j customer support agent, showing how the AI probe visualizes prompt compositions, isolates token-heavy outliers, and projects resource costs directly onto the recorded call tree.

Breaking the LLM Black Box: Custom Categorization in JProfiler

Ingo Kegel — Fri, 06 Mar 2026 08:00:57 GMT

Categories: JProfiler Screencast

Modern agentic applications often perform a wide range of logical tasks through a single interface. While these operations have vastly different performance and cost profiles, they appear as an undifferentiated call tree in traditional profilers.

By default, JProfiler groups these requests by model name, which provides a high-level overview but lacks the granularity needed to distinguish between different functional workloads.

This screencast shows how to move beyond this predefined perspective with scripts that define your own categorization rules based on internal metadata, instruction structure, or application state.

JProfiler 16.1: AI Agents Can Now Profile Your Java Applications

Ingo Kegel — Thu, 09 Apr 2026 07:00:57 GMT

Categories: JProfiler

Since JProfiler 1.0, profiling has been something a developer does with a GUI. You start a session, navigate views, and interpret data. In practice, this means that performance analysis only happens when a problem is serious enough to justify the context switch, and many issues ship to production without ever being profiled.

With JProfiler 16.1, we are changing how profiling works: AI coding agents can now profile your Java applications, analyze the results, and act on them. This is the biggest change in how developers use profiling since we started.

The new JProfiler MCP server, available as the @ej-technologies/jprofiler-mcp npm package, exposes JProfiler's profiling and heap analysis capabilities through the Model Context Protocol. It works with Claude Code, Cursor, Codex, Gemini CLI and any other MCP-compatible AI coding tool.

The Problem: AI Agents Are Blind to Runtime Behavior

AI coding agents excel at reading code, generating implementations, and running tests. But they cannot see what happens at runtime. When you ask an agent to fix a performance problem, it can only guess based on code patterns. It cannot see which methods are actually slow, which database queries dominate execution time, or where memory is being consumed.

JProfiler 16.1 closes this gap by exposing profiling data through MCP, giving AI agents the same performance visibility that JProfiler has always provided to human developers.

From Hotspots to Root Causes

Agents can close the loop: an agent profiles an application, discovers that JDBC queries dominate execution time, and identifies the specific queries responsible. It then modifies the code to eliminate redundant database calls, re-profiles to verify the improvement, and presents a before-and-after comparison with concrete numbers. A complete performance engineering cycle, from diagnosis to verified fix, without the developer having to open the JProfiler GUI.

The agent works with actual runtime data and not by guessing. And because it can compare snapshots, it can prove that its fix actually worked.

A Guided Workflow That Agents Actually Follow

Building an MCP server that agents use correctly is harder than it looks. We have carefully crafted and tested the tools so that agents reliably follow a profiling workflow that mirrors how an expert would use JProfiler. The agent first sets up profiling for the target application. After the test run completes, it checks for data availability. Then it retrieves the initial aggregated hotspot view to understand where time is being spent. From there, it drills into specific hotspots, following the call chain to the root cause. Each step naturally leads to the next.

The data at each step is carefully filtered so agents see what matters without being overwhelmed, whether they are analyzing CPU hotspots, JDBC and JPA queries, HTTP calls, MongoDB operations, or heap dumps. Beyond live profiling of local and containerized JVMs, agents can also load existing JProfiler, HPROF, or JFR snapshots for analysis.

Getting Started

The setup is zero-friction: the MCP server auto-installs the JProfiler binary on first use and handles licensing through the MCP protocol. For Claude Code, it takes a single command:

claude mcp add jprofiler -- npx -y @ej-technologies/jprofiler-mcp@latest

The MCP setup page has instructions for Codex, Gemini CLI, Junie and other MCP-compatible tools.

Performance problems have always demanded that developers leave their flow, switch tools, and build up context from scratch. With JProfiler 16.1, your AI agent does this for you. It profiles, diagnoses, fixes, and verifies, in the same conversation where you described the problem. We will be publishing detailed walkthroughs of real profiling sessions in upcoming posts.

The Hotspot Claude Would Never Have Found by Reading the Code

Ingo Kegel — Fri, 17 Apr 2026 07:00:57 GMT

Categories: JProfiler

CommaFeed is my daily RSS reader. It is open source, and its creator runs a free public instance at commafeed.com. Every time I refresh my feeds, someone else's server does the work. So when I wondered where all that work actually goes, I pointed Claude Code and the JProfiler MCP at it.

As a result, a database optimization was merged into CommaFeed. The fix itself was not complicated, but Claude would never have come up with it from the source code alone. I asked afterward, and it confirmed as much: its natural first attempt would have fixed the wrong thing. Read on for how Claude Code, connected to the JProfiler MCP server, took me from curiosity to a merged PR.

Finding the Hotspot

I started CommaFeed locally and pointed Claude Code at the running process. Then I ran a unit test to set up feeds and refresh them. The first thing the agent did was ask for the JDBC hotspots. One query dominated the ranking: a per-entry guidHash existence check inside FeedEntryDAO.findExisting.

The cumulative time was 141 ms. That is not alarming by itself. What stood out was the count: 580 JDBC queries for 400 checks. Something was being checked again. The caller was FeedRefreshUpdater.addEntry, which runs once per entry during every feed refresh.

No static analyzer flags "400 checks but 580 JDBC queries" because the ratio only exists at runtime. An agent reading FeedRefreshUpdater sees a reasonable-looking loop calling a reasonable-looking DAO method. Reading the source, there is nothing obviously wrong.

The Fix

The agent diagnosed a classic N+1 query pattern. Every entry in the parsed feed triggered its own database round trip to check existence. The proposed fix was to fetch the existing GUIDs for a feed upfront in a single query, filter new entries in memory, and only enter the per-entry loop for new entries. The original per-entry check stayed in place as a concurrency safety net.

The agent then re-profiled to verify. The guidHash check dropped from 580 to 400 calls (-31%) and from 141 ms to 93 ms (-34%). The remaining 400 calls are the unavoidable safety-net invocations for genuinely new entries during the initial refresh. I submitted the change as a pull request.

The Review

The maintainer, Athou, raised a concern. CommaFeed lets users disable entry cleanup entirely by setting commafeed.database.cleanup.entries-max-age and max-feed-capacity to zero. For those users, a single feed can accumulate millions of entries over the years. Fetching all of them upfront on every refresh would cause a memory spike.

His suggestion was to not fetch all existing GUIDs, but only the GUIDs that are actually present in the current feed XML, using a SQL IN clause, and batch it with 1000 entries per batch.

The profiling data mattered here too. The fix was based on measurements and not on speculation about code, so the review was about how to scale the approach safely, not about whether the diagnosis was correct. The memory-spike concern was a constraint that required the maintainer's domain-specific knowledge, and so the PR process worked as intended.

Round Two

I fed the maintainer's review back to Claude Code. The agent changed the method signature from findExistingGuids(Feed feed) to findExistingGuids(Feed feed, Set<String> guidHashes), added the IN clause with Lists.partition batching, and updated the caller to pass in the hashes of the entries currently being processed. It also added an integration test that refreshes an already-populated feed and verifies that no duplicate entries are created.

public Set<String> findExistingGuids(Feed feed, Set<String> guidHashes) {
    if (guidHashes.isEmpty()) {
        return Set.of();
    }
    Set<String> result = new HashSet<>();
    for (List<String> batch : Lists.partition(new ArrayList<>(guidHashes), IN_CLAUSE_BATCH_SIZE)) {
        result.addAll(query().select(ENTRY.guidHash)
            .from(ENTRY)
            .where(ENTRY.feed.eq(feed), ENTRY.guidHash.in(batch))
            .fetch());
    }
    return result;
}

Before pushing the update, the agent re-profiled the test. Splitting a single query into batched IN lookups could have reintroduced overhead that would have reverted the original gain. The measurement showed it did not: the batched version stayed within a few percent of the original one-query approach on the feeds I tested, and the per-entry check count stayed at the new lower baseline. Only runtime data could confirm that.

The PR was merged the same day.

What Would Have Happened Without the MCP

After the PR was merged, I asked the agent what it would have tried if it only had the source code to work with. Its answer: the natural attempt would have been enabling Hibernate batch inserts, a setting that speeds up individual inserts. That would have had zero effect on this problem. The bottleneck was query count, not query speed. The agent would have recommended the wrong fix.

I then asked for a short testimonial. In the agent's own words:

JProfiler's JDBC and persistence probes revealed a pattern that timing alone would never surface: redundant per-entry database checks firing on every refresh cycle, even when nothing had changed. Without that probe data, I would have optimized the wrong thing entirely.

Every feed refresh on commafeed.com costs its creator resources. A substantial reduction in the most expensive query during refresh allows more users on the same hardware.

Try It on Your Own Code

The same approach works on any Java application. Every codebase has hotspots you cannot see by reading the source. An N+1 query that hides behind a DAO, a serializer that allocates millions of short-lived objects, a retry policy buried in an HTTP client that silently triples your outbound calls. Reading the code will not find them, runtime data will.

Setup takes a single command. Point your AI agent at your application and ask it where the time is spent. The JProfiler MCP page has instructions for Claude Code, Cursor, Codex, and any other MCP-compatible tool.