Attaching to Windows services for Java profiling

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!

Using the probe tracker

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.

Please enable Javascript to view the screen cast

Profiling JPA/Hibernate

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.

Please enable Javascript to view the screen cast

Default locale changes in Java 7

In the last Windows versions of install4j, we recently introduced some changes to improve how installers choose the default language and to mirror the new locale features in Java 7.

New language settings in Java 7

Until Java 7, a Java application retrieved the default locale from the Formats tab in the Region and Language Windows control panel, as shown below.

Even if this dialog box and other Windows dialogs are in English, a Java application running under Java 6 and previous versions will choose here German and Germany as default language and country, and this settings will end up in the user.language and user.country System properties, and thus in the default Locale object. This might seem surprising at first, but language settings are often used to set the default Java formats for numbers and dates, so this actually makes sense.

Java 7 introduced new Locale concepts that are initialized from the Display Language setting shown below.

In Java 7, the information coming from these two different settings ends up in the following new system properties:

user.language.format
user.language.display
user.country.format
user.country.display

These properties are used to initialize the default locales - plural, because there are now 3 default locales! The old one returned by Locale.getDefault(), and the two new ones returned by Locale.getDefault(Locale.Category.DISPLAY) and Locale.getDefault(Locale.Category.FORMAT). The two latter ones reflect the two Windows languages settings above and are used in different contexts. As you can guess, Locale.getDefault(Locale.Category.FORMAT) will be used now in default Java formats.
But the first time you'll run your program under Java 7, you will see that its user interface will use the language chosen in the Display Language Windows setting - a change from previous Java versions. Actually, the default language in Swing look and feel still depends on the locale returned by Locale.getDefault(), but this locale is derived from Locale.getDefault(Locale.Category.DISPLAY).
To help you understand these changes, let's run the following test application:

import java.text.DateFormat;
import java.util.*;

public class ShowLanguageAndLocale {
  public static void main(String [] args) {
    String [] messages = {
        // language and country System properties                          
        "user.language = "          + System.getProperty("user.language"),
        "user.country = "           + System.getProperty("user.country"),
        "user.language.display = "  + System.getProperty("user.language.display"),
        "user.country.display = "   + System.getProperty("user.country.display"),
        "user.language.format = "   + System.getProperty("user.language.format"),
        "user.country.format = "    + System.getProperty("user.country.format"),
        // default locales
        "default locale = "         + Locale.getDefault(),
        "default display locale = " + Locale.getDefault(Locale.Category.DISPLAY),
        "default format locale = "  + Locale.getDefault(Locale.Category.FORMAT),
        // date test
        "Date: " + DateFormat.getDateInstance(DateFormat.FULL).format(new Date())};
    javax.swing.JOptionPane.showMessageDialog(null, messages);
  }
}

Under a Windows system configured in German for the Formats settings and English for the Display language settings, this application will show this dialog:

As expected, the title of the dialog box and the display language are in English, whereas the date and the format language are in German.

If you don't want this behavior in your application with Java 7 (for backward compatibility reasons for example), you can still force the old language settings based on the format language, by setting the new sun.locale.formatasdefault property to true.
When run with the following command:


java -Dsun.locale.formatasdefault=true ShowLanguageAndLocale

the previous application will display the following dialog box where the default locale is initialized from the FORMAT locale (note that the value of the DISPLAY locale is not lost):

Default language choice in install4j

install4j has a native part that also performs a language auto-detection that must be in sync with the default locale of the JVM. Since install4j 5.0.11, we handle this in the following manner: As many of you are still running their installers with Java 6 or a previous version, and don't want an unintentional change of behavior the day you'll support Java 7, we set the sun.locale.formatasdefault System property to true by default. If you run your application with Java 6, this won't change its behavior at all; if you run it under Java 7, this means that your application select the same locale as with Java 6.

As some of you might prefer the new choice made by Java 7, we also added the ability to pass the new -Dsun.locale.formatasdefault=false parameter to installers and launchers. This parameter will make them initialize their language and country from the Display Language setting whatever Java version they run with.


For more information about the Locale changes in Java 7, please read the new section about Locale scope in the Java tutorial.

Profiling with IntelliJ IDEA 11

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.

Java profiling comes to Linux ARM

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.

Sampling vs. Instrumentation

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.