Custom telemetries in JProfiler

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.

JProfiler's MBean browser

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.

Method splitting by parameter values

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.

Multi-level HTTP request splitting

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 user names is demonstrated.

Tracking JavaScript calls into your Java backend

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.

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.