Migrating to install4j 6

In nearly all cases, migrating to install4j 6 just means opening and saving your project with the install4j 6 IDE. Nevertheless, there are some considerations with respect to backwards compatibility and a couple of 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 web site. 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!

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

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.

Introducing perfino

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.

Java profiling across JVM boundaries

This screen casts 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.

Profiling MongoDB

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.

Profiling class loaders and solving related memory leaks

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

All screen casts now with HTML5 video

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