To map a debug target to the Debug Project command:. In the Projects window, right-click the project node and choose Properties.
Click Build and Run in the left panel of the Project Properties dialog box. Click Add , select your debug target, and type a label, such as "Debug Project. If you want to map the debug action to a target in a separate Ant script, open the project's project. Before you can use your debug target, you need to deploy your application. Therefore, start the server and run deploy the application.
Note that the first time that you run the application per session, the Tomcat Web Server asks you for a username and password. The only acceptable username and password is that of a user with a "manager" role. To identify the location of this directory, right-click the Tomcat Web Server instance node in the Services window and select Properties.
Once the application is deployed, stop the server and restart it in debug mode. The way this is done depends on the server:. The application is deployed and is attached to the debugger.
The debugger stops at the first breakpoint, after which you can Step into or Step over the code. To use a debug target in a free-form web project:.
Right-click the project node in the Projects window, choose Properties , click Java Sources in the Project Properties dialog box, and make sure that all the source files you want to debug are listed in the Source Package Folders list. Make sure that you have a debug target and that it is mapped to the Debug command, as described in the previous sections. For more information debugging features that you can use for web applications in the IDE, see Section Even though the IDE does its best to generate a complete debug target for you, with properties that are tailored to your specific environment, you should always analyze and fine tune the debug process.
In the Services window, expand the Servers node, start the server if not started , expand the server's instance node, and expand the Web Applications node. HTTP Proxy. Type the proxy host name in the Proxy Server Name field and the port number in the Port field. Click Finish. In the Services window, expand the Servers node and check that the server is running. Note that even if it is running, it may not be running in debug mode. If it is running, but you are not sure that it is running in debug mode, stop the server and restart it in debug mode.
Check that the jpda. Check the Debugging Port property for socket connections. Check the Name property for shared memory connections. If you change the server's Debugging Port property or Name property, make sure that it matches the related property in the debug. If you change the server's Debugging Type property, make sure that it matches the related property in the debug.
If you are unable to step from line to line in your code, but only from breakpoint to breakpoint, the IDE has not been able to find your sources. This is because you have not specified your sources correctly. The Sources window displays all the Java source folders that are available for debugging. If you want to debug a source folder that is not available in the Sources window, specify it in the Project Properties dialog box:.
If a servlet is compiled without debug info, the debugger will not stop on its breakpoints. JSP pages: Make sure that you have defined a context path for the project:. If you have set your breakpoints before specifying the context path, you must remove and reset the breakpoints after specifying the context path.
In other words, the context path must be set first. Also make sure that the sources are correctly specified in the debug. Note that if your nbproject folder is not housed within the folder that houses your sources folder, you should set the following properties for your src.
After you create a project you can start a debugging session, take a GUI snapshot of the application, and then work with the snapshot to locate source code, add listeners to events and view the event log of GUI components. Alternatively, right-click the project node in the Projects window and choose Debug. When you start the session, the IDE will launch your application and open the Debugging window. The source code for GUI components can sometimes be difficult to locate and the snapshot provides a way for you to locate the code based on the GUI instead of searching through the code.
You can select components in the snapshot and invoke tasks from the context menu to view the source code for the component, show the listeners and set breakpoints on components.
To locate the declaration and source code for the component:. When you select a component in the snapshot, the IDE displays details about the selected component in the Properties window.
The IDE also displays the location of the component in the form hierarchy in the Navigator window. Right-click the component in the snapshot and choose Go to Component Declaration from the context menu.
When you choose Go to Component Declaration, the IDE opens the source file in the editor and moves the cursor to the line in the code where the component is declared. Right-click the component in the snapshot again and choose Go to Component Source. When you choose Go to Component Source , the IDE opens the source file in the editor and moves the cursor to the line in the source code for the component. To locate the line in the source code where a component is added to its container:.
Click the Java Debugger tab in the Java category in the Options window. Select Visual Debugging in the list of categories and select Track locations of component hierarchy changes. Click OK. After you enable the command in the Options window you will need to restart your debugging session and take a new GUI snapshot before you can use the Go to Hierarchy Addition command.
To locate component listeners and the events that are triggered by the components:. Right-click a component in the snapshot and choose Show Listeners from the context menu. Right-click an item below the Custom Listeners node and choose Go to Component Source in the context menu. When you select another component, the items in the Events window will change automatically to display the listeners for the selected component. Alternatively, you can right-click the Event Log node and choose Set Logging Events from the context menu.
Select a required listener from the dialog for example, java. The event is recorded in the events log. For example, if you expand the Event Log node you can see that each keystroke is now logged. New events appear each time that you complete an event. If you expand an individual event, you can see the properties of that event in the log. If you expand the Called From node for an event you can see the stack trace for the event.
Select a category in the Java Debugger tab to configure the global settings for the behavior of the Java debugger. When you start a debugging session the IDE opens some debugging windows by default. In addition to the main Debugging window in the left pane of the IDE, other debugger windows open as tabs below the editor. Each debugger window displays a variety of icons to relay information about the object. For example, the Breakpoints window uses a small red square to indicate a breakpoint set on a line.
Some windows also include a node expansion control to the left of the icon. Clicking this control expands and collapses the object.
The Debugging window opens in the left pane of the IDE and uses a tree structure to display the threads and calls in the current debugging session.
The current thread and call are displayed in bold. You can expand the node for suspended threads to view the call stack. In the debugger tabs, information is organized into lists. Each list item represents a single object.
Each column represents a property of the object. Data displayed in blue underlined text is linked to the source code. Some elements of lists in the debugger tabs have editable properties, such as the value property of a variable in the Variables window. If you select a property and the property has a white background you can edit the property. A selected property with a gray background cannot be edited. You can rearrange elements of a debugger window or remove columns to display only the information of interest.
For all windows, you can sort the column in ascending or descending order. A triangle is displayed in the column header. The direction in which the triangle is pointing indicates whether the sort order is ascending or descending.
Some windows provide additional sort orders. The current context is the portion of your program on which the debugger is currently focusing. When multiple sessions are running, only one session is current. Within the current session, the thread from which the debugger regained control is the default current thread. Inside the current thread, the most recent call is the default current call.
You can make any session, thread, or call current by right-clicking its node in the appropriate debugger window and choosing Make Current. Most debugger windows depend on the current context. When you change the current context, the contents of these windows are updated to reflect the new context.
For example, the Debugging window shows the threads in the current session, while the Call Stack window shows the call stack for the current thread. The Variables window shows the variables that are local to the current call, and the Loaded Classes window shows the classes that have been loaded by the current session.
For more information on viewing classes and class instances, see Section 9. The exceptions are the Breakpoints and Watches windows. These windows list all breakpoints and watches set in the IDE. While the set of watches is shared by all sessions, an individual watch expression is evaluated and displayed based on the current context. For information on setting breakpoints, Section 9.
For information on debugging threads, see Section 9. For information on examining the call stack for the current thread, see Section 9. When a variable is active in the current context, the Source Editor displays the value of the variable when you move the pointer over it.
In cases where a program includes different variables with the same name, the Source Editor displays the value based on the current context, and not on the instance of the variable in the source code. When you add a JAR file or folder of compiled classes to a project's classpath, it is often useful to add the source files for those classes so that you can view their contents when working with them.
Attaching source code to a JAR file or compiled classes folder lets the IDE know where to find the source code for those classes. You can then step into the source files when debugging and open the source files with the Go To Source command. For code completion to work properly in the IDE, you must either attach a complete set of source files as a folder or add the available source files as a Zip archive. To attach source code to a JAR file or compiled classes folder:.
In the left pane of the Ant Library Manager, select the project library within which the JAR file you want to add the source code to is located. If the JAR file or classes folder for which you want to add the source code has not already been added to a registered library, create a new empty library using the New Library button.
A class library can contain multiple JAR files as well as their Javadoc documentation and source code. The IDE adds the selected JAR files and source code to the specified library and automatically registers the source code in every project that has that JAR file on its classpath. When you create a Java class library for a single JAR file, you can simply add the JAR file to the project's classpath to make the associated Javadoc and source code available.
If your Java library contains multiple JAR files, however, you must add the library itself to the classpath. Adding the library to the classpath also makes it easier to share the project with other developers.
For information on setting the classpath, see Section 5. However, doing so creates the association only for that project. Open the Project Properties dialog box by right-clicking the project node and choosing Properties.
Select the JAR with which you want to associate the sources and click Edit. In the Sources tab, add the folders or archive files containing the source code. For free-form projects, set the target JDK in your Ant script and specify the source level in the Project Properties dialog box for more information, see Section 5. A breakpoint is a flag in the source code that tells the debugger to stop execution of the program. When your program stops on a breakpoint, you can perform actions like examining the value of variables and single-stepping through your program.
You can also set line breakpoints directly in the Source Editor. Breakpoints can be set for the following types of source elements:. You can break when the class is loaded into the virtual machine, unloaded from the virtual machine, or both. You can break whenever a specific exception is caught, whenever a specific exception is not handled in the source code, or whenever any exception is encountered regardless of whether the program handles the error or not.
You can stop execution of your program whenever a field in a specific class is accessed for example, the method was called with the variable as an argument , modified or both. Program execution stops every time the method is entered, exited or both.
You can break program execution whenever a thread starts, stops, or both. The Source Editor indicates a breakpoint by highlighting the line at which the breakpoint is set in red and placing an annotation in the left margin.
The following table describes the debugging annotations:. Table Debugging Annotations. All Java breakpoints are defined globally and, therefore, affect all IDE projects that include the source on which a breakpoint is set. For example, if you set a class breakpoint on com. MyClass in one project, the IDE stops execution every time it encounters that class during a debugging session for other projects that include the class. If you open the Breakpoints window when a debugging session is running, it closes automatically when you end the debugging session.
If you open the window when no debugging session is running, it stays open until you close it. By default, each entry contains a short text description of the breakpoint and a checkbox indicating whether the breakpoint is enabled or disabled. You can enable or disable a breakpoint directly in the Breakpoints window by selecting or deselecting the checkbox.
All Java breakpoints are defined globally and therefore affect all IDE projects that include the source on which a breakpoint is set. To set a line, field or method breakpoint in the Source Editor:. A field, method or line breakpoint is created depending on if the line contains a field declaration, method declaration or other code.
The corresponding breakpoint annotation is visible in the left margin next to the line of source code. The IDE tests the validity of set breakpoints when the debugger session is starting or when a debugger session is already running. If a breakpoint is invalid the IDE uses a broken annotation to indicate the invalid breakpoint and displays an error message in the Debugger Console. For example, if you want to set a class breakpoint on the class BeanCounter , select the class name in the class declaration.
Set any additional options you require in the New Breakpoint dialog and click OK. Right-click any breakpoint and choose Properties to open the Breakpoint Properties dialog box.
Right-click the breakpoint in the Breakpoints window and choose Enable or Disable. You can modify and enable line, field and method breakpoints by right-clicking the breakpoint icon in the left margin of the Source Editor and choosing from the Breakpoint submenu.
You can set conditions on a breakpoint so that execution only breaks if the condition is true. Set conditions on any breakpoint except thread breakpoints by selecting the Conditions checkbox and entering the condition.
For all breakpoints you can specify how often the breakpoint is triggered by selecting the Break When Hit Count checkbox and choosing a criteria from the drop-down list and specifying a numerical value. For class breakpoints, you can exclude classes triggering the breakpoint by selecting the Exclude classes checkbox and specifying the classes to exclude.
For exception breakpoints, you can filter the classes triggering the breakpoint by selecting the Filter on Classes Throwing the Exception checkbox and specifying the names of classes to match or exclude.
Create a new breakpoint or open an existing breakpoint's customizer by right-clicking its name in the Breakpoints window and choosing Customize.
Select the Condition checkbox and type the condition in the Condition field. The condition must follow the Java syntax rules. The condition can also include variables and methods that are within the current context.
The following are exceptions:. Imports are ignored. You must use fully qualified names, such as obj instanceof java. You cannot access outerclass methods and variables directly. Use this. Optional Select the Break When Hit Count checkbox and choose a criteria from the drop-down list and specify a numerical value. Conditional line breakpoints have a icon in the left margin of the Source Editor. The Breakpoints window lists all of the breakpoints defined for all of your IDE projects.
If you have numerous breakpoints set in the IDE, it is useful to organize these breakpoints into groups. Once your breakpoints are placed into groups, you can enable, disable, and delete them as a single unit. Right-click the breakpoint and choose Move Into Group and select a custom group from the list. To remove a breakpoint from a custom group:.
Alternatively, you can modify how breakpoints are organized from the Breakpoints window by clicking Breakpoint Groups and selecting a grouping strategy from the context window. If you choose Nested you can specify the specific groups and the order of the groups that are displayed. Local debugging is the process of debugging a program that is running on the same computer as the IDE.
The IDE starts the debugger, then runs the application inside the debugger. When you start a debugging session, the IDE automatically opens the debugger windows and prints debugger output to the Output window. Debugging commands in the Debug menu are generally run on the main project, and when debugging a project it is recommended that you set the project as the main project.
If no project is set as the main project the Debug Project command is run on the project that is selected in the Projects window and the commands begin the debugging session in the main class of the selected project. For information on how to set a main project, see Section 5. Table displays the commands in the Debug menu and the corresponding toolbar icons for starting and stopping the debugger. Table Basic Debugging Commands and Icons. Starts the debugger and runs the program until it reaches a breakpoint or exception or until the program terminates normally.
Remote debugging is the process of debugging an application that is running on a different computer. This technique is useful when you are developing an application that runs on a web server or in a different environment than the computer on which you are developing the application.
On the computer where the IDE is running, open the projects that contain the source for the application. Select the appropriate Connector from the drop-down list, enter any required process information, and click OK. The instructions for starting an application in debugging mode and the method for connecting to the VM depends on your VM.
See your VM documentation for further details. You can view and select from the four most recent Attach configurations by expanding the menu under the Debug button in the toolbar.
After execution of your program is halted, step through your lines of code using the commands listed in Table in the Debug menu or the corresponding icons in the toolbar:. Table Debugging Step Commands and Icons. Executes one source line. If the source line contains a call, executes the entire routine without stepping through the individual instructions.
Executes one method call in an expression. If an expression has multiple method calls, you can use Step Over Expression to step through an expression and view the value of each method call in the expression in the Variables window. Each time you use the Step Over Expression command, the debugger advances to the next method call in the expression and the completed method call is underlined.
Step Over Expression behaves like Step Over when there are no additional method calls. Executes one method call in a source line. If the line has more than one method call you can choose which method call to step into by using the arrow keys or mouse in the source editor to select the method call.
The selected method call to step into is indicated by a box around the method call in the source editor. The most likely method call in the line is selected by default. If the source line contains a call, the IDE stops just before executing the first statement of the routine. You can also start a debugging session with the Step Into command. To use this feature, select a level in your stack and press the Drop to Frame button in the toolbar of the Debug view. The following screenshot depicts such a reset.
If you restart your for loop, the field result is not set to its initial value and therefore the loop is not executed as without resetting the execution to a previous point. To practice debugging create a new Java project called de. Also create the package de. Set a breakpoint in the Counter class.
Debug your program and follow the execution of the count method. Define a Detailed Formatter for your Counter which uses the getResult method.
Debug your program again and verify that your new formatter is used. Delete your breakpoint and add a breakpoint for class loading. Debug your program again and verify that the debugger stops when your class is loaded.
How to develop your own debugger. If you need more assistance we offer Online Training and Onsite training as well as consulting. Eclipse Debugging. This article describes how to debug a Java application in Eclipse. This article is based on Eclipse 4.
Overview 1. What is debugging? To stop the execution, if a field is read or modified, you can specify watchpoints. Breakpoints and watchpoints are sometimes called stop points. Debugging support in Eclipse Eclipse allows you to start a Java program in Debug mode. Setting Breakpoints To define a breakpoint in your source code, right-click in the left margin in the Java editor and select Toggle Breakpoint.
Starting the Debugger To debug your application, select a Java file with a main method. Controlling the program execution Eclipse provides buttons in the toolbar for controlling the execution of the program you are debugging.
The following picture displays the buttons and their related keyboard shortcuts. Breakpoints view and deactivating breakpoints The Breakpoints view allows you to delete and deactivate breakpoints and watchpoints. Evaluating variables in the debugger The Variables view displays fields and local variables from the current executing stack. As of Eclipse 4. Via the drop-down menu of the Variables view you can customize the displayed columns. Changing variable assignments in the debugger The Variables view allows you to change the values assigned to your variable at runtime.
Controlling the display of the variables with Detail Formatter By default the Variables view uses the toString method to determine how to display the variable.
Advanced Debugging The following section shows more options you have for debugging. Breakpoint properties After setting a breakpoint you can select the properties of the breakpoint, via right-click Breakpoint Properties. Watchpoint A watchpoint is a breakpoint set on a field. Exception breakpoints You can set breakpoints for thrown exceptions.
You can configure, if the debugger should stop at caught or uncaught exceptions. Method breakpoint A method breakpoint is defined by double-clicking in the left margin of the editor next to the method header. You can configure if you want to stop the program before entering or after leaving the method. Breakpoints for loading classes A class load breakpoint stops when the class is loaded.
Step Filter You can define that certain packages should be skipped in debugging. JDI Java Debug Interface , defines a high-level Java language interface which tool developers can easily use to write remote debugger applications. A detailed description about JPDA can be found here. Before we start understanding how debug works in Eclipse, lets us understand the JVM execution environment.
The JVM runs in a single process, but it can execute several threads concurrently. Each of the threads are running their own tasks.
For example, when we start executing a Java program, JVM process starts a main thread at the entry point i. It also starts one more thread for Garbage Collection.
0コメント