When a debug process is launched from BugSeeker, you have the option of specifying which Java runtime to use when launching the process to be debugged. BugSeeker supports debugging with any Java 1.2 and above runtimes that are currently available or with runtimes that will be available in the future. But before you can specify a runtime to use, you first need to create a runtime configuration which you can do here.
Debugging programs running under a Java 1.1 or older runtime is not supported because JPDA does not exist for these runtimes which BugSeeker for Java 2 needs in order to debug these programs. Please take a look at our BugSeeker for Java 1.1 product if you have a need to debug programs running in a Java 1.1 runtime as it is based on the older Debug API that works in Java 1.1.
Available Java Debug Runtimes
Lists all currently available Java debug runtimes. The special Current runtime will always appear in the list and if this configuration is used, any debug processes launched from BugSeeker will use the same runtime as the Java runtime BugSeeker itself is currently running on. This special Current runtime configuration cannot be removed nor edited.
Adding new runtimes
To add a new Java debug runtime configuration, click on the New button to display a New Java Runtime Configuration dialog that will let you enter in details about the runtime configuration you wish to create.
The first step in creating a Java runtime is to locate the Java executable program installed on your system. This Java executable is frequently named java.exe, java, javaw.exe or javaw; the precise naming depends on what platform your are using and who your JVM vendor is. There are no standard locations as to where the Java executable is placed as it depends a lot on the platform you are using and who your JVM vendor is. Usually, this executable is located in the bin/ subdirectory of your Java SDK installation home or in the bin/ subdirectory of the Java Runtime Environment (JRE) installation home. When you select the Java executable location using the browse icon, BugSeeker will try to verify the Java executable to see if it is supported or not. If the Java executable you entered is correct, a default configuration name will be assigned to it which consists of the Java version and the name of the vendor from that runtime. If you entered an executable that is not valid, such as a Java 1.1 runtime, you will be displayed an error message indicating this.
We recommend selecting the Java executable found within the Java SDK distribution rather than the Java executable that is part of the Java Runtime Environment (JRE) because the JRE is focused on running Java programs only and not for debugging Java programs. For instance, most JRE will not only strip out local variable debug information from the Java core libraries but will also take out all line number and source file name information from the class libraries in an effort to reduce the size of the JRE. Also, newer JRE's include only the HotSpot engine which as noted in many places in this manual is not a very good engine to use when debugging because it is slow and does not support many debugging features.
Configuration Name
Each Java debug runtime configuration will have a name assigned to it that you can then use to later identify the configuration. If this field is left blank, BugSeeker will automatically generate a name for the configuration. You may however assign a custom name to the configuration.
Java Executable Location
You must specify the full path name to the Java executable in order for BugSeeker to be able to use the configuration. Java executables are usually named java.exe or java; console-less Java executables javaw.exe or javaw may also be used. Only Java 1.2 runtimes and above are supported since JPDA is not available in Java 1.1 runtimes. If you use the browse button to locate the Java executable, the default configuration name will be generated replacing the previous name if any.
Bootclasspath
For each configuration there are times where it would be useful if BugSeeker would prepended certain class libraries to the bootclasspath each time this configuration is used to start up a process to be debugged. The bootclasspath is similar with the project's classpath except that the bootclasspath will always be search first before the project's classpath for classes that your program uses and the bootclasspath is initialized to refer to the Java runtime's standard libraries. By adding custom class libraries to this list you can potentially override classes found in the standard bootclasspath because all class libraries entered into the list are prepended to the bootclasspath.
The most frequent use of this feature is to include your custom, debug compiled Java standard class libraries in this list. This is useful because you will be able to view local variable debug information when tracing through the Java standard libraries.
Sourcepath
Like the bootclasspath, you are allowed to specify a list of java source file locations that will be used whenever this configuration is used. The list of Java source file locations will be prepended to the project's sourcepath meaning the locations entered for this Java runtime configuration will be searched first before the project's sourcepath.