Documentation Contents
Java Platform, Standard Edition Troubleshooting Guide
Contents    Previous    Next

9.3 Identify the Type of Issue

First of all, take a moment to categorize the problem you are experiencing. This will help you identify the specific area of the problem, find the cause, and ultimately determine a solution or a workaround.

The subsections below provide information about common issue types:

Some of these might seem obvious, but it is always helpful to consider every possibility and to eliminate what is not an issue.

9.3.1 Java Client Crashes

When a crash occurs, an error log is created with information and the state obtained at the time of the fatal error. The default name of the error log file is hs_err_pid.log where pid is the process identifier (PID) of the process that crashed. For a standalone Java application this file is created in the current directory, while for Java Applets it is created in the browser binaries directory or user client folder.

For a detailed description of the fatal error log, see Appendix A.

A line near the top of the header section indicates the library where the error occurred. Example 9-1 shows that the crash was related to the AWT library.

# Java VM: Java HotSpot(TM) Client VM (1.6.0-beta2-b76 mixed mode, sharing)
# Problematic frame:
# C  [awt.dll+0x123456]

If the crash occurred in the Java Native Interface (JNI), it was likely to have been caused by the desktop libraries. A crash in a native library typically means a problem in Java 2D or AWT, because Swing does not have much native code. The small amount of native code in Swing is mostly concerned with native look and feel, and if your application is using native look and feel, the crash may be related to this area.

The error log usually shows the exact library where the crash occurred, and this can give you a good idea of the cause. Crashes in libraries which are not part of the Java Development Kit (JDK) usually indicate problems with the environment, for example, bad video drivers or desktop managers.

9.3.2 Performance Problems

Performance problems are harder to diagnose because you generally do not have as much information.

First, you must determine which technology has the problem. For example, rendering performance problems are probably in Java 2D, and responsiveness issues can be Swing-related.

Performance-related problems can be divided into the following categories:

  • Startup

    How long does the application take to start up and become useful to the user?

  • Footprint

    How much memory does the application take? This can be measured by tools such as Task Manager on Windows or top and prstat on Oracle Solaris and Linux operating systems.

  • Runtime

    How fast does the application complete the task it is designed to perform? For example, if the application computes something, how long does it take to finish the computations? In the case of a game, is the frame rate acceptable and does the animation look smooth?

    Note: This is not the same as responsiveness, which is the next topic.

  • Responsiveness

    How fast does the application respond to user interaction? If the user clicks a menu, how long does it take for the menu to appear? Can a long-running task be interrupted? Does the application repaint fast enough so that the it does not appear to be slow?

9.3.3 Behavior Problems

In addition to crashes, various behavior-related problems can occur. Some of these problems are listed below. Their descriptions can guide you to the Java SE Desktop technology to troubleshoot.

Contents    Previous    Next

Oracle and/or its affiliates Copyright © 1993, 2015, Oracle and/or its affiliates. All rights reserved.
Contact Us