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

1 Introduction

This chapter explains how the different Java SE Desktop technologies interact with each other. In addition, the chapter helps you pinpoint the technology from which you might start troubleshooting your problem and provides general troubleshooting tips.

This chapter contains the following sections:

Java SE Desktop Overview

Java SE Desktop consists of several technologies used to create rich client applications and applets. The desktop tools and libraries provide an interface between the Java application and the core tools and libraries of the platform.

Figure 1-1 Overview of Java SE Desktop

Description of Figure 1-1 follows
Description of "Figure 1-1 Overview of Java SE Desktop"

For information on all desktop technologies available in Java SE, visit the Java SE Desktop Overview website at

http://www.oracle.com/technetwork/java/javase/tech/index-jsp-142216.html

This guide describes troubleshooting procedures for the following Java SE Desktop technologies:

The better you understand the relationships between these technologies, the more quickly you can pinpoint the area your problem falls into.

Troubleshooting an Issue

When you experience problems running your application, follow the steps below for troubleshooting the issue.

Step 1Identify the symptom.
Step 2Eliminate non-issues.
  • Make sure the correct patches, drivers, and operating systems are installed.

  • Try earlier releases (back-tracing).

  • Minimize the test. Restrict the test to as few issues at a time as possible.

  • Minimize the hardware and software configuration. Determine if the problem is reproducible on single and multiple systems. Determine if the problem changes with the browser version.

  • Determine if the problem depends on whether multiple VMs are installed.

Step 3Find the cause.
Step 4Find the fix.

The Java SE HotSpot VM Troubleshooting Guide provides information that can help in troubleshooting problems between the Java application and the Java HotSpot virtual machine. A lot of that information can also be applied to problems with applications that use the Java SE Desktop technologies.

Identifying 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.

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 "Fatal Error Log".

A line near the top of the header section indicates the library where the error occurred. The example below 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.

In the case of a VM crash, see the Java SE HotSpot VM Troubleshooting Guide.

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 Solaris OS and Linux.

  • 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 that 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?

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.

Basic Tools

This section simply lists a few tools that can help in troubleshooting certain types of issues. For more information on these and other tools, see the Java SE HotSpot VM Troubleshooting Guide.

You can also debug JDK builds from dev.java.net for various issues.

Using JDWP

The Java Debugging Wire Protocol (JDWP) is very useful for debugging applications as well as applets.

To debug an application using JDWP:

  1. Open the command line and set the PATH environment variable to jdk/bin where jdk is the installation directory of the JDK.

  2. Use the following command to run the application (called Test in this example) which you want to debug:

    • On Windows:

      java -Xdebug -Xrunjdwp:transport=dt_shmem,address=debug,server=y,suspend=y Test
      
    • On Solaris OS and Linux:

      java -Xdebug -Xrunjdwp:transport=dt_socket,address=8888,server=y,suspend=y Test
      

    The Test class will start in the debugging mode and wait for a debugger to attach to it at address debug (on Windows) or 8888 (on Solaris OS and Linux).

  3. Open another command line and use the following command to run jdb and attach it to the running debug server:

    • On Windows:

      jdb -attach 'debug'
      
    • On Solaris OS and Linux:

      jdb -attach 8888
      

    After jdb initializes and attaches to Test, you can perform Java-level debugging.

  4. Set your breakpoints and run the application. For example, to set the breakpoint at the beginning of the main method in Test, run the following command:

    stop in Test.main run
    

    When the jdb utility hits the breakpoint, you will be able to inspect the environment in which the application is running and see if it is functioning as expected.

  5. (Optional) To perform native-level debugging along with Java-level debugging, use native debuggers to attach to the Java process running with JDWP.

    On Solaris OS, you can use the dbx utility and on Linux you can use the gdb utility.

    In Windows, you can use Visual Studio for native-level debugging as follows:

    1. Open Visual Studio.

    2. On the Debug menu, select Attach to Process. Select the Java process that is running with JDWP.

    3. On the Project menu, select Settings, and open the Debug tab. In the Category drop-down list, select Additional DLLs and add the native DLL that you want to debug (for example, Test.dll).

    4. Open the source file (one or more) of Test.dll and set your breakpoints.

    5. Type cont in the jdb window. The process will hit the breakpoint in Visual Studio.

To debug an applet using JDWP:

  1. Launch the Java Control Panel, open the Java tab and click View. On the Java Runtime Environment Settings window, specify the following in the Runtime Parameters field for the necessary platform:

    • On Windows:

      Djavaplugin.trace=true -Xdebug -Xrunjdwp:transport=dt_shmem,address=debug,server=y,suspend=y
      
    • On Solaris OS and Linux:

      Djavaplugin.trace=true -Xdebug -Xrunjdwp:transport=dt_shmem,address=8888,server=y,suspend=y
      

    When you launch a web browser and load an applet, the Java Plug-in will start in the debugging mode and wait for a debugger to attach to it at the address debug (on Windows) or 8888 (on Solaris OS and Linux).

  2. Open the command line and use the following command to run jdb and attach it to the running debug server.

    • On Windows:

      jdb -attach 'debug'
      
    • On Solaris OS and Linux:

      jdb -attach 8888
      

    After jdb initializes and attaches to Test, you can perform Java-level debugging.

  3. Set your breakpoints and run the applet. For example, to set the breakpoint at the beginning of the func1 method in MyApplet, run the following command:

    stop in MyApplet.func1 run
    

    When the jdb utility hits the breakpoint, you will be able to inspect the environment in which the application is running and see if it is functioning as expected.

Contents    Previous    Next

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