Netbeans debug test file

In the window that appears, you can watch all the variables declared in main memory RAM and the value they contain during each step of execution. Until now, the only variable declared and assigned a value is the variable s as shown in Figure 6.

Figure 6 The current value of variable s is displayed in the Variables window of the debugger. The second statement is executed. The third Java statement is executed and the program waits for you to enter a value. The program counter moves to the fourth Java statement. Figure 8 The values of variables s and a are displayed in the Variables window of the debugger.

This action executes the fourth and fifth Java statements. The program counter moves to the sixth Java statement. Figure 9 The values of variables s , a and b are displayed in the Variables window. What you expected here was the sum of 5. Instead of this, a new variable S is declared in the main memory RAM and the value 7.

Figure 10 All declared variables are displayed in the Variables window of the debugger. Now it becomes more obvious to you! You mistakenly declared two variables in the main memory RAM , the variable s and the variable S with a capital S.

So, when the flow of execution goes to the last statement, System. You have just found the error! You just performed your first debugging! Re-execute the program and you will now see that it calculates and displays the sum correctly. Debugging step by step has a big disadvantage.

You can set the project's main class, runtime arguments, VM arguments, and working directory. This simplifies running the application outside the IDE. For more information, see Section 8. For free-form projects, the IDE uses an existing Ant script to run your class.

You can write a target that executes the currently selected file in the IDE and map it to the Run File command. Once you have created and built your project, you must perform the following operations to configure the run process for your project:.

Modify the runtime classpath, as needed, to include any special libraries, project dependencies, or specific JAR files. When you have the runtime configurations set, you can either run individual project files or run the entire the project. Each of these operations is discussed in more detail in the following sections. With standard projects, you typically have one project that contains the application main class and several projects containing class libraries.

You can run the project or run any individual project that contains an executable class. For information on setting the main class, see Section If Compile on Save is not selected, the project is run using the project's build script. If you run a project for which you have not specified a main class, the IDE prompts you for the main class. You can change this setting in the Run panel of the project's Project Properties dialog box. Each project can contain only one main class.

For information on setting the classpath, see Section You might have a file in your project that you want to test before running the entire project. You can run a single file in the IDE and see any warning or error messages that might occur during the run in the Output window. Each of these actions contains a context element that gets a reference to the currently selected files and stores it in a property of your choice.

You use this property in your Ant targets to specify which files to process. Let's demonstrate how this works when you run a class. A typical target for running a project looks something like the following:. The target runs the file specified by classname. To run the currently selected file in the IDE, you need to modify the above target to something like the following:.

Once you have an Ant target for running the selected file, you have to get a reference to that file in the IDE and store it in a property. For example, the run-selected-file target above looks for the currently selected file in the runclass property. You store this reference in the same place where you map the build target run-selected-file to the IDE action.

First we will look at how to do this and then we will explain it in detail:. The runclass property is a newly defined property that holds the file that you want to run and is referenced by the java task. In this case, it is the name of file that you want to run. You can choose any unique name for this property. This property must be set by the IDE before the target can be run. If you want the property to be able to hold more than one file such as for the Compile File target , you can use the following, where the comma , is the separator between file names:.

Other formatting options include the following:. In this case, you want the target be executed only with files that end in. The process is basically the same for writing targets to debug and run a single file. The debug-selected-files target looks something like this:. This is basically the same as the debug target.

Instead of passing the program main class to java , you pass the classname property, which is set by the IDE to the currently selected file. Then you map the debug-selected-files target to the debug. By default, the runtime classpath of each standard project contains the project's compiled classes and everything in the project's compilation classpath. For information on viewing the compilation classpath, see Section 6.

If your project uses special libraries dynamically at runtime through an indirect interface or reflection like JDBC drivers or JAXP implementations , you have to add these libraries to the runtime classpath.

You also have to adjust your runtime classpath if the runtime dependencies between your projects do not match the compilation dependencies between the projects. For example, imagine that project A compiles against project B, and project B compiles against project C, but project A does not compile against project C. This means that project A only has project B on its runtime classpath.

If project A requires both project B and project C during execution, you have to add project C to project A's runtime classpath. Right-click the project node in the Projects window and choose Properties. Add the necessary elements to the project's runtime classpath by clicking the appropriate button. You can add any of the following:. The build output, source files, and Javadoc files of another IDE project. Adding a project to the classpath makes it dependent on the present project.

Whenever you clean or build the project, all of its dependent projects are also cleaned or built. A collection of binary files, source files, and Javadoc files. By default, the IDE specifies neither a main class nor runtime arguments. The runtime classpath of each standard project contains the project's compiled classes and everything in the project's compilation classpath. Indicate which class in your project is the entry point for the application by setting a main class.

Right-click the project node in the Projects window and choose Project Properties. Select the Run node in the Categories pane of the dialog box.

Type the fully qualified name of the main class in the Main Class field for example, org. The main class must exist in the project or in one of the JAR files or libraries on the project's runtime classpath.

If you use the Browse button to choose the project main class, the file chooser only shows classes in your project source directory. If you want to specify a class in one the libraries on the classpath, you have to type the fully-qualified name of the class in the Main Class field. In the Project Properties dialog box, select the Libraries node in the Categories pane. JVM arguments and system properties can be set through the project's properties file through the IDE.

Debugging is the process of examining your application for errors. The process of debugging is accomplished by setting breakpoints and watches in your code and running it in the debugger. This enables you to execute your code one line at a time and examine the state of your application to discover any problems. When you start a debugging session the Debugging window opens in the left pane of the IDE.

Additional debugger windows also appear automatically at the bottom of your screen. You can also debug applications that are running on a remote machine by attaching the debugger to the application process. From this tab you can perform the following:. Similar to commands for compiling and running, debugging commands rely on various information, such as the location of your sources, the location of the compiled classes and other items on the classpath, and name of the project's main class for more information, see Section In free-form projects, the IDE does not "know" about any of these things.

When you run a command in the IDE such as Build , the IDE simply calls a target in your build script and lets the script handle the command. Therefore, for debugging to work, you also have to have a build script target for debugging. The IDE provides some custom Ant tasks to work with the debugger and also can generate a basic debug target, which attempts to fill in important details based on other targets in your script. Make sure that your classes are compiled with debugging information included.

Set the output of the free-form project. If the output of a free-form project is on the classpath of another project, map the free-form project's source packages to their outputs.

This ensures that you can use the debugger to step into the project's sources when you start a debugging session in a project that has a dependency on the free-form project. To declare the output files, right-click the free-form project node and choose Properties. Then click the Output category in the Properties window and specify the output file for each source folder. Confirm that the target JDK is set in your Ant script and the source level is specified in the Project Properties dialog box.

Create a target in your build script for debugging and map that target to the IDE's Debug Project command. The IDE can assist you by generating a basic target and mapping, but you might have to modify the target.

For more information, see Section For information on mapping an Ant target to a debugging command, see Section 6. To run a free-form project in the IDE's debugger, you have to have a special target in your project's build script. If you do not have a debug target written for your project, the IDE offers to generate a basic target for you when you first try to debug the project. You can then inspect the target and customize it for the project's specific requirements. When you click Generate , a target named debug-nb is created in a file named ide-targets.

The generated ide-targets. In addition, a mapping for this target is created in the project. If you write the target from scratch, you must also create this mapping yourself. Verify that the generated debug-nb target properly takes into account all of the elements of your project.

Set a breakpoint in your main class by clicking in the left margin of the line where you want to set the breakpoint. The target should run and start execution of the program. Progress of the running target is shown in the Output window and the status of the debugger is shown in the status bar at the bottom of the Output window.

Stores the address at which the debugger listens for the application in the jpda. You do not have to define the jpda. It is defined by the IDE. Establishes the runtime classpath. If the IDE is not able to determine your runtime classpath, placeholders are put in the script, which you must fill in yourself. Runs the application in debug mode, passing the jpda. For example, if the IDE is able to guess the runtime classpath, the debug-nb target that the IDE generates in ide-targets.

If you do not have a run target mapped or the IDE otherwise cannot determine the project's classpath or main class, the generated debug target includes "TODO" placeholders for you to fill in these values as shown in Example To specify the runtime classpath, insert pathelement elements within the path element and point them to the directories that contain the items in your classpath. For example, you can use the location attribute of pathelement to specify the location of the classpath items relative to your project directory as shown in Example The project directory is usually the one that contains the project's build.

Example Specifying location of classpath items relative to a project directory. However, if you have created the target manually, you must also create the mapping manually. To map the Debug Project command to a target in an external Ant script:. Open the project's project. For information on how to map a target to a debugging command, see Section 6.

If you have successfully created a debug target and started the debugger, but the debugger does not stop at breakpoints, the IDE is probably lacking debugging information or knowledge of where your sources are. In a free-form project, you must set up your own Ant target to run a project in the debugger.

However, you can use the IDE to generate a debug target for you. Alternatively, if you have your own debug target, you must map it to the Debug Project command yourself.

Generates a target named debug-nb. These targets do the following:. Connects the debugger to the application to be debugged at the specified host jpda. There's no need for you to customize the generated targets. All you have to do is set the properties that the IDE requires to use the targets it generated. For example, you need to tell the IDE where your application's sources are.

Using the -load-props target above, the IDE will load the properties when you run the debug-nb target. Generates and defines debug properties. The properties define the following:. Maps the debug-nb target to the Debug Project command. Example Adding properties to a new debug.

If you use the IDE to generate the debug target, as described in the previous section, the target is automatically mapped to the Debug Project command. However, if your debug target was not generated by the IDE, you must map it to the Debug Project command manually. 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. 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:. JSP pages: Make sure that you have defined a context path for the project:. 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. 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. In my opinion the Netbeans 6. Also via: meetup. Which results in all tests beeing run It might well be that I have overlooked some trick. But I have to say that both Eclipse and IntelliJ just work out of the box for the above scenarios.

I have tried it on exactly the same projects. Hi Adam, thanks for this post. It seems i have not been the only one with this issue. I am also of the opinion that it was more intuitive in 6.