Compiling with Debug Information

Before you start debugging your program, you should ensure that the classes you wish to debug have been compiled with the -g option (ie. javac -g MySource.java). The -g option tells the java compiler to include debugging information that is need by BugSeeker to allow you to set breakpoints in these classes and to be able to show you local variables and their values.

If you are tracing through sources whose classes do not contain any debugging information (such as the Java core libraries), you will notice that there will not be any local variable information shown in the Variables debug tab. Furthermore, for classes that have been optimized (compiled with the -O option), you will also not be able to set any breakpoints in those classes because the optimizations strips away all line number information from the resulting class files.

Viewing local variables in Java core libraries

To be able to see the local variables information for the Java core libraries (java.lang, java.awt, etc. packages), you will need to separately compiled the source files that often come bundled with the Java SDK with the -g compiler option and ensure the resulting class files are found in the classpath before the bootclasspath libraries that do not have the debug information. The easiest way to achieve this is to define your own custom Java Runtime (Tools | Options | Java Runtime category) and add the location of your custom compiled java class libraries with debug information to the bootclasspath tab which will tell BugSeeker to prepend these locations to the bootclasspath when starting a new process from within BugSeeker. When you then configure your project, you should then ensure this custom Java runtime configuration you just created is the configuration the Project is to use (see the Runtime tab of the Project Properties dialog).

Note that if you start your program separately from BugSeeker and then use BugSeeker's remote debugging capabilities to connect to this running process you again will not be able to view local variables when tracing through the Java core libraries unless you take special steps to manually request that the debug versions of the core libraries you separately compiled are to be prepended to the bootclasspath when you manually start your program outside of BugSeeker. For example, when using Sun's java executable, you will need to supply a -bootclasspath\p:path_to_debug_core_libraries JVM option when starting your program externally.

Javac versus other Java compilers

We highly recommend that you compile all your source files that you intend to trace through within BugSeeker using Sun's standard Javac compiler. This is because the JPDA libraries that BugSeeker uses may encounter difficulties when tracing through classes that were not compiled with Javac. Problems such as the debug JVM or BugSeeker itself crashing and strange stepping behaviors have been attributed to class files that have been produced by non-Javac compilers such as IBM's fast jikes compiler.

Furthermore, because the way anonymous classes are named is not standardized you may have problems setting breakpoints in anonymous classes if your non-Javac compiler produces .class files for these anonymous classes whose names that do not correspond to the names produced when the same files are compiled using Javac. BugSeeker follows the anonymous class naming convention used by Javac because it is the most common Java compiler so it's a good idea to use Javac if you need to set breakpoints in anonymous classes.