Java debugging technology
Foreword
This material introduces Java debugging technology, which covers debugging of ordinary procedures and server-side programs.
Many programmers do not recognize the value of the exclusion of software. If you are a Java developer, it is worth reading this material. With the help of modern tools, developers become a good debugger and become the importance of a good programmer.
This material assumes that you already have basic Java programming, if you are proficient in Java, this material can also increase your many knowledge.
If you have a debugging experience in other languages, you can skip the basic knowledge part.
Even the small programs developed by advanced programmers may also contain errors. You only need to understand the concept of debugging and familiarize yourself with the right tools to become a good debugger. This material will explain the basic concepts of Java debugging and discuss advanced debug types. We will browse different technologies and provide some good recommendations to help avoid, track and finally correct the error.
We will pass a debug example to make you familiar with debugging technology. We will also use the Development Source Code Tool JIKES and JDB to demonstrate how to debug server-side and client programs. In order to compile and run sample code, you need to install a Java Development Kit (JDK), you can get the JIKES and JDB debugger references later.
About author
If you have any questions about this material, you can contact the author Laura Bennett, lbenn@us.ibm.com.
If you have any opinions and suggestions for the translation of the Chinese version, please contact Translator Cherami, Cherami @ 163.net.
Laura Bennett is a senior software engineer of IBM. She won a bachelor's degree in computer science in Pace University and a master's degree in computer science at Columbia University. She is the Java missionarian of DeveloperWorks, and is also the construction of the site. In his vacant time, she likes to play with her Lego Mindstorm robot and build an object with her four-year-old Tinkertoys.
Cherami is a software engineer, and there are some computer literature in the leisure time, in order to make a little meager contribution to China's computer software industry.
Basic knowledge of debugging
Beginning
In the early stage of the Java language, a typical developer uses a very old way to debug procedures: use the System.out.Println () method. The tracking information of the code is printed to the console, file or socket.
Few people can write a perfect (no error) code in the first time. Therefore, the market recognizes the need for tools like C programmers. Java developers now have a lot of debugging tools to choose, choose what kind of tools depend on your technology level. Usually newcomers use the GUI debugging tool and more experienced programmers tend to avoid more control over the tools you have obtained. No developer does not use any debugging tools. The debugger allows you to cross the code, freeze output, and check the variable. The more experienced developers, the more the debugging tools can help him locate the position of the program.
Type of Java debugger
There are several tools for Java debugging technology here:
IDE (integrated development environment) contains their own debuggers (such as IBM Visual, Symantec Visual Cafe, and Borland JBuilder)
Separate GUI tools (such as Javadt, Java platform debugger Javadt, and JPROBE)
Tools based on text and command lines (such as Sun JDB)
Barbarian editor (such as NOTEPAD or VI) check stack drawing (Stack Trace ")
The JDK, JSDI, JSP, and HTML you use have an impact on your choice.
Ide and independent GUI debuggers are the easiest to beginners and proven to be the most time. The debugger will guide you to the program crash. Inside the debugger, use the mouse to set the breakpoint and cross the code. Using these debuggers is not all Ide debuggers support the latest Java APIs and technologies (such as servlets and EJB components). Based on text and barbaric use editor provides more control but to find a longer time for programmers without too many experiences. We call them "poor" debugging methods.
If you don't meet your needs, the Java platform introduces Java Debugging API to create debuggers that meet your own specific needs.
Debug type
There are many debugging methods here, both in the client or server. We contain the following methods in this material:
Basic Java bytecode (that is, using system.out.println ())
Use annotation
Attached to a running program
Remote debugging
Demugging on Demand
Optimize code debugging
Servlet, JSP file, and debugging of EJB components
Each type of debugging will be described in detail later.
Common error type
In order to give you a prompt that you will encounter, we will list the developers' universal mistakes once again:
Editing or syntactic errors are your first and most prone to errors. They are usually caused by typing errors.
Logical errors are different from runtime errors because there is no exception thrown, but the output is not a desired thing. These errors range from the buffer overflow to memory leakage.
Runtime errors occur during execution and usually generate a Java exception.
Thread errors are the most difficult to repeat and track.
Java Debugging APIS
Sun has defined the debug structure, which is called JBUG. This is to respond to the needs of the real Java debugger. These APIS help programmers build debugger that meets themselves:
The interface should be object-oriented as the language style.
For example, the Java runtime feature such as threads and monitors should be supported by the previous support.
Remote debugging can be made.
Security under normal operation cannot be damaged.
Corrected Java Debugger (JDB) is only the concept of the Java Debugging API, but also a useful debug tool. It is rewritten with Java Debug Interface (JDI) and is part of the JDK. JDB will discuss in detail later.
Prepare a debugging program
The Java platform provides language support for the debugging process.
You can use the Compile Option to indicate symbol information in the target file when compiling your programs with a compiler. If you use other compilers instead of javac, refer to how your compiler's document gets how to generate target files with debugging information.
If you use the Javac compiler to create a debug code, use the -g compile option. This option allows you to check this instance and static variables when debugging. If you don't use this option to generate your class file, you can also set breakpoints and tracking code, but you will not check the variable. (The breakpoint is the point where manually specified program is running.)
Even if you use the -g option to compile your program, you cannot debug local variables of the core system class of the Java platform. If you need to list a list of local variables of certain system classes, you need to compile these classes using the -g option, which is to recompile the RT.jar class using the -g option or the file inside SRC.zip. Then specify your classpath to run your program with the newly compiled class for the correct class file. Under Java 2, use the Boot ClassPath option to make the new class are first loaded.
Remember if you use the -o option to optimize your code, you can't debug your class. Optimization will remove all debug information from the class.
Note: Check your ClassPath environment variable is correct to let debugger and java program know where to find your class library. You should also check your debugging tool to see if other or environment variables are required.
Set breakpoint
The first step in debug is to find the location of the code error. Breakpoint settings can help you finish this.
The breakpoint is the temporary tag you put in the program, which makes the debugger know where the program is executed. For example, if a problem in a program is triggered, you can set the breakpoint on the line containing that declaration and then run the program. At that statement, the pre-execution procedure stops execution. Then you can check the contents of the variables, registers, memory, and stacks, and then cross (or execute) that the problem is caused. Different debuggers support different breakpoints. Some generic types are:
The code is thrown before the code is executed before the code.
The method breakpoint is initiated when the method reaches the desired breakpoint.
The counter breakpoint is triggered when a counter is reached or exceeds a particular value.
The abnormal breakpoint is thrown when the code throws a specific exception.
Storage change breakpoints triggered when the content stored in a specific address range is modified
The address breakpoint is raised when the address set is set to breakpoint.
Note: Some debuggers support certain breakpoint types only on the Java code (code generated by Just-In-Time compiler) without supporting interpretation code (code generated using the Javac tool). An example is the address breakpoint. Each tool may be somewhat different in the way you can set a breakpoint. Check the documentation for your tool.
You may ask, how do I know where to place breakpoints?
If you don't feel at all, you can set breakpoints at the main () method
If your code generates stack reprittion, set breakpoints in the program generated it. You will see the line number of the problem in the source code in the stack.
If your output or graphic display is not properly displaying predetermined information (such as text domain display error text), you can set breakpoints in the component created. Then you can write your program to display the value related to the GUI object.
Experience will set breakpoints in the most suitable place. You can set multiple breakpoints in a class or program.
Typically, you will be prohibited, activate, add, and delete breakpoints when debugging the code. Tools will allow you to view the location of all breakpoints you set at the same time, give you an option to delete all breakpoints.
Single step executive
Single-step executives are finally solving those ways to debug issues. It allows you to track the entire execution process of the method in the class. Note that you don't need to set a breakpoint to stop an execution of a GUI program.
After setting the breakpoint, start executing the program in the debugger. When you encounter the first breakpoint, you can cross the procedure or type, or continue to run until the next breakpoint or program ends.
The terms that are often encountered when debugging procedures are:
Enter the execution of the current line. If the current row contains a method call, execute the first line of the called method. If the method in the class is compiled with options without debugging (not using the -g option), you will see the No Source Available message.
Crossing the current row without stopping a method or routine because the line calls.
Returns the row that is executed from the current execution point and returned to the call current method.
Check variable
Typically, the program will perform a core dump because the value of a variable is not properly set. The most common is to try to perform a calculation or comparison of NULL and in addition to zero. The easiest way to find this problem is to check the value of the variable at the wrong place. The most common situation is that the variable does not have a value that is expected to be allocated.
Visual debugger typically has a monitor window to display all local variables of the class you are currently being executed. Some debuggers do even display the address of the variable or further allow you to dynamically change the value of the variable to see if the programs can continue to be executed when the value is expected. Command line adjustile usually provides commands to provide corresponding features. Use the command line characteristics, you can even see the entire array by displaying each line of the array and each column.
Although most debuggers simply display local variables in the monitoring window, there are still some debuggers to continue to monitor it after the variable is out of the range.
Some debugger supports viewing registers. Note that this can only be a program that views a compiled Java and cannot be an explanation (bytecode program).
Stack reprittion (Stack Traces)
When the Java program performs kernel dumps, it generates what we calls Stack TRACE in the console. The stack is written to tell the developer program's exact path. It will explain the number and method names and the number of rows in the source code (if you compile using debug options). If you start debugging at the beginning of the stack copy, you can view your code backwards to see what is actually the declaration. This is a solution to the rapid discovery process. You can also use one of the following methods to manually enforce the stack.
Throwable (). PrintStackTrace () Generates stack repartitions in calling the point. Dressing will display the thread involved in the method.
Thread.currentthread.dumpstack () only generates a snapshot of the current thread.
When you need to understand what your program will generate a stack, use forced to write. The following program is an example of a forced stack. This program is filed for file copy. By comparing whether the length of the two files is equal to whether the copy is successful. If we don't wait, we write to the file and then force the print stack to write (see the declaration of the black body). Throwable () is a class in java.lang. PrintStackTrace () is a method of throwable (), which prints the program execution path.
Public Static Boolean CopyFile (String Sourcefile, String TargetFile)
{
........
........
// see if the copy succeeded.
IF (SUCCESS)
{
// see if the correct number of bytes a Copied Number of Bytes WERE COPIED
Long newfilelength = new file (targetfile) .length ();
IF (OldFileLength! = NewFileLength)
{
Debug.Trace (1, Sourcefile Constants.blank_string long.toString (OldFileLength));
Debug.Trace (1, TargetFile constants.blank_string long.toString (NewFileLength));
Throwable (). PrintStackTrace ();
Return False;
}
}
Else
{
Debug.Trace (1, Sourcefile);
Debug.Trace (1, TargetFile);
Return False;
}
........
........
Return True;
}
You may find that there is no line number in the stack. This can be simply referred to as "Compile Code". To generate a line number, use the NOJIT option or djava.compiler = none command line parameter to prohibit JIT compiler. If you know the names of the method and change, the line number is not that important.
diagnosis method
The Java language provides methods to track your JVM method in the Runtime () class. These tracking will generate a list of you call every method of the JVM byte code. Note that this list can generate a large number of outputs, so use it in a small section of your code.
Open tracking can be added to the code:
TracemethodCalls (True)
Close Using:
TracemethodCalls (False)
turn on
JVM
And observe the output of it output to the standard.
