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
topandprstaton 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.
-
Hangs occur when the application stops responding to user input. For more information about dealing with such issues, see Troubleshoot Process Hangs and Loops.
-
Exceptions in Java code are visibly thrown to the console or the application log files. An examination of this output will guide you to the problem area.
-
Rendering and repainting issues indicate a problem in Java 2D, or perhaps in Swing. For example, the application has an incorrect appearance after a repaint that was caused by another application being dragged over. Other examples are incorrect font, wrong colors, scrolling, damaging the application's frame by dragging another window over it, and updating a damaged area.
A quick test is the following: if the problem is reproducible on a different platform (for example, the problem was originally seen on Windows, and it is also present on Oracle Solaris or Linux), it is very likely to be a Swing
PaintManagerproblem.For ways of changing Java 2D rendering pipelines with some flags, see Java 2D. This can also help in determining if the problem is related to Java 2D or to Swing.
Multiscreen-related repainting issues belong to Java 2D (for example, repainting problems when moving a window from one screen to another, or other unusual behavior caused by interaction with a non-default screen device).
-
Issues related to desktop interaction indicate a problem in AWT. Some examples of such issues occur when moving, resizing, minimizing and maximizing windows, handling focus, enumerating multiple screens, using modality, interacting with the notification area (system tray), and viewing splash screens.
-
Drag-and-drop problems are related to AWT.
-
Printing problems could be related either to Java 2D or AWT depending on the API that is used.
-
Text-rendering issues in AWT applications might be a problem in font properties or in internationalization.
However, if your application is purely AWT, text rendering problems might also be caused by Java 2D. On Oracle Solaris or Linux text rendering is performed by Java 2D.
Text rendering in Swing is performed by Java 2D. Therefore, if your application uses Swing and you have text rendering problems (such as missing glyphs, incorrect rendering of glyphs, incorrect spacing between lines or characters, bad quality of font rendering), the problem is likely to be in Java 2D.
-
Painting problems are most likely a Swing issue.
-
Full-screen issues are related to the Java 2D API.
-
Encoding and locales issues (for example, no locale-specific characters displayed) indicate internalization problems.