A new project has a default run configuration created for it, but you can create a custom run configuration. Use the procedure to select a run configuration.

1. From the main menu choose Application > Project Properties.
2. Select Run/Debug.

   Note:

   If you have not previously accessed the Run/Debug/Profile page, a button labelled Launch displays. Click the button to access the Run/Debug/Profile page.

3. In the Run Configurations list, choose a run configuration.

   Note:

   The last edited run configuration is the active run configuration.

Use the procedure to create a run configuration. Copy an existing configuration to create a new run configuration, and modify its settings.

1. Select a run configuration as described in How to Choose a Run Configuration.
2. Click New.
3. In the Name box, enter a name for the new run configuration.
4. In the Copy Settings From dropdown box, choose an existing run configuration to copy from.
5. To create a new run configuration having the same settings as the one it was copied from, click OK.
6. To create a new run configuration having different settings, choose the new settings and click OK

A project can be run from the operating system command line if it is a standalone executable, and the class file containing the application main() method is selected.

java -cp <jdev_install>\jdeveloper\jdev\mywork\Workspace1\Project1\classes package1.Application1

java -jar <application>.jar 

The Java Virtual Machine may need changes according to operating systems: client-side applications need the HotSpot Client VM, whereas executing long-running server applications need the Server VM. Use the procedure to change the Java Virtual Machine.

1. Right-click a project in the Applications window and choose Project Properties from the context menu.
2. Open the Run/Debug/Profile page.
3. Select a run configuration and click Edit.

   The Edit Run Configuration dialog displays.

4. On the Launch Settings page, in the Virtual Machine list box, select an available option.

   The selected JVM is used when running and debugging the project.

5. Click Help for additional information.

The Java2 Standard Edition includes the java.exe file is a development tool that can be used to test a Java application from the CLI.

The java.exe file is included as part of the Java2 Standard Edition (J2SE). It is intended to be used as a development tool, and is not licensed for distribution with your Java programs. It is used to test your Java applications from the command prompt.

In order to run a Java application from the command prompt, the system environment variable CLASSPATH must be defined to include all of the classes necessary to run your program. This includes any library classes provided with Jdeveloper that your program uses.

JDeveloper ships hundreds of library classes from J2SE, third-party developers, and Oracle Corporation to help you generate your Java programs.

Jdeveloper ships hundreds of library classes to help you generate your Java programs. The classes come from J2SE, third-party developers, and Oracle Corporation. Each of the libraries is kept separate for easy upgrade. As a result, many archive files may need to be included in your classpath to ensure that any program you create in Jdeveloper can be run from the command prompt.

Oracle recommends that you list only the paths to each of the libraries that your project uses. If you list paths that your project does not use, your program will still run, but for performance reasons, you will want to eliminate any unnecessary libraries.

If the output path is set to the default directory, test the Java application using java.exe by appending the classes directory to your classpath.

If you have used the default directory for your output path, you can test your Java application using java.exe by appending the following directory to your classpath:

C:\<jdev_install>\jdeveloper\jdev\mywork\Workspace1\Project1\classes

Having set this variable, you can use java.exe to run your application from the output directory mywork.

If you have deployed your Java program to any other directory, you need to add the path to the parent directory of the application package.

The CLASSPATH variable is a long string that can be difficult to type accurately. To save time and reduce errors, you can set the CLASSPATH as a system environment variable.

The Java Runtime Engine (java.exe) does not use the CLASSPATH environment variable, so the complete CLASSPATH to your Java program, or classpath, must be included as a parameter to the java.exe command.

The Java Runtime Engine (java.exe) doesn't use the CLASSPATH environment variable. The CLASSPATH must be included as a parameter to the java.exe command. The format for the command is:

java -cp <classpath> package.Application

Where classpath is the complete CLASSPATH to your Java program and the dependency classes it uses. Quotation marks are optional if there are no spaces in any of the CLASSPATH directory names.

The JDeveloper user interface, including the Debugger window and the Log window, provides several debugger and runner features.

When debugging an application deployed to an integrated WebLogic Server, the changes you make to files are reflected in the running application without having to stop and redeploy the application.

When debugging an application deployed to an integrated WebLogic Server, you can make changes to files and they will be reflected in the running application without you having to stop and redeploy the application. To debug the application, start the server in debug mode. Go to ORACLE_HOME/jdeveloper/jdev/bin and run java -? to see the run configuration options available for the version of the JDK you are running.

• Modify JSF files

  Save and refresh the browser if you are currently viewing the page that you modified, or navigate to the page if you were not on it. The page will reflect the changes you just made.

• Save and recompile them. You can see the changes the next time the altered code is executed without having to re-start the application.

If you are stopped at a break point, you can:

• Modify the class you are currently stopped in including the method that you are currently stopped in.

• Right-click in the editor and rebuild the individual class.

• Select the Stack tab (by default grouped with the Structure tab under the Applications window). At the top of the stack you will see that the method you are stopped in is obsoleted.

• Right click on the previous method and select the Pop back to here menu item. JDev will re-position the cursor to the code that invoked the obsolete method.

When you restart execution, the changes you made to the class or method will be reflected.

Compile code with debugging information, and use debugger features such as viewing arguments and local variables in the Data window. Use the procedure to set breakpoints and step through the code.

1. In a source editor, set a breakpoint on an executable statement by clicking in the margin to the left of the statement.

   The unverified breakpoints icon appears in the left margin.

2. Select Run > Debug filename.jpr.

   The class runs and stops at the first breakpoint.

3. From the toolbar, click Step Into to trace into a method call or click Step Over to step over a method call.
4. Look in the Stack window to examine the sequence of method calls that brought your program to its current state.
5. Double-click a method to display the associated source code in the source editor.
6. In the Smart Data and Data windows, examine the arguments and variables.
7. Display the Threads window to see the status of other threads in your program.

While debugging, use the HotSwap feature to fix errors and replace class definitions, without stopping and restarting the application. HotSwap is an enhancement to the Java Platform Debugger Architecture that is implemented in the JVM in JDeveloper.

While debugging, use the HotSwap feature to fix errors and substitute corrected class definitions, without stopping and restarting your application. HotSwap is an enhancement to the Java Platform Debugger Architecture (JPDA) in Java 2 SDK v1.4, and has been implemented in JDeveloper's Java virtual machine, OJVM.

When the debugger is paused you can recompile classes. When the debugger resumes after code has been HotSwapped, threads that are currently executing old method definitions will continue to do so until those methods return. For subsequent method calls, the class definition will be used. However, existing instances of the class will not be modified, and class variables will not be reset. Use HotSwap to modify the logic of class methods. In most cases you cannot use HotSwap to make more substantial changes, such as adding or removing fields or methods.

Changes made to a deployed Web application are expected to be displayed when a browser is refreshed. IDEs provide incremental compilation support for editing and build steps. On the server side, the WebLogic Server FastSwap deployment feature in JDeveloper makes for smooth deployment and test cycles.

Today's Web application developers expect to make changes to a deployed application and see those changes immediately by refreshing the browser. On the Java EE side, developers typically have to go through the following cycle to see their changes in action.

Edit -> Build -> Deploy -> Test

These steps, along with the many required descriptor elements, makes developing applications with Java EE seem complex and top-heavy. Among these steps, the build and deploy cycles are necessitated by Java and by the application server being employed. IDEs are trying to make the edit and build steps seamless by providing incremental compilation support. On the server side, the WebLogic Server FastSwap deployment feature, available in JDeveloper, makes the deploy and test cycles just as seamless.

JDeveloper supports ADF Declarative Debugger so that applications can be debugged with breakpoints, and breakpoint types decide how the application moves from one breakpoint to another. An application execution pauses to facilitate the comparison of the data that is available, and the expected data for the functioning of the binding container.

Manage the way a program is debugged, how it enables and disables packages and classes, and configures remote debugging options. Use the procedure to configure debugger and remote debugger options in JDeveloper.

1. Choose Application > Default Project Properties (to set preferences that apply to all projects)
2. Choose Application > Project Properties (to set preferences that apply only to the current project).
3. Select the Run/Debug node.
4. Select a run configuration.
5. Click Edit.
6. Select Tool Settings > Debugger.
7. Set the options on the Debugger and Remote pages.
8. Click OK when finished.

Set the debugger start option to specify how the debugger functions at the start of a new debugging session. Use the procedure to set the debugger start options.

1. From the main menu choose Tools > Preferences > Debugger.
2. Select a Start Debugging option.

   Table 12-5 Start Debugging Options

   Option	Description
   Run Until a Breakpoint Occurs	When you start debugging, the debugger will let the program you are debugging execute until a breakpoint is reached.
   Step Over	When you start debugging, the debugger will let the program you are debugging execute until a method in a tracing-enabled class is reached, but it will not stop in a class static initializer method.
   Step Into	When you start debugging, the debugger will let the program you are debugging execute until any method, including a class static initializer method, is reached.

Specify build options on the Compiler page of the Project Properties, and build the project because the debugger starts if the project builds successfully. Use the procedure to build a project and start the debugger.

1. In the Applications window, select the project.
2. Right-click and choose Project Properties > Compiler.
3. If not already enabled, select Full Debug Info.
4. Click OK to close the dialog.
5. Use one of the following methods to start the debugger:

   • To start the debugger using the current run configuration, from the main menu choose Run > Debug <target>.

   • To start the debugger using your choice of run configuration, select the dropdown menu beside the Debug icon on the toolbar and click the required run configuration name.

From a debugger window, export the debug information that the JDeveloper debugger generates to a text or HTML output file. Use the procedure to export debug information to a file.

1. Start debugging by clicking Debug from the toolbar.
2. Once the debugger has stopped at a breakpoint, locate the debugger window containing the information you would like to export.
3. Right-click in a debugger window and choose Preferences from the context menu.
4. In the appropriate Preferences - Debugger page below Columns, select which columns you want to show or hide in the debugger window and output file.
5. Click OK to close the Preferences dialog.
6. In the debugger window, right-click and choose Export.
7. In the Export dialog, enter the name of the file. The output file is saved as a text file with tabs between columns and new lines between rows. To export to an HTML file, add the extension as.html or .htm (case-insensitive).

When the debugger stops, the source editor displays the source file for the current open class marked by an icon for execution.

When the debugger stops (for example, at a breakpoint after completing a step command, or when paused), the source file for the current class will open in the source editor and will be marked with the execution point, as shown in the figure.

Figure 12-1 Execution Point Icon

If Jdeveloper cannot locate the source file for the class while debugging, the Source Not Found dialog is displayed prompting you for the source file location.

You can use the source editor to debug to:

• Hover over a variable name to see its value.

• Set a breakpoint, click in the source editor's margin.

• Remove a breakpoint, click the breakpoint in the source editor's margin.

  Figure 12-2 Breakpoint Icon

  

The debugger adds the Run to Cursor, Watch, Inspect, and Step Into Method at Cursor menu items to the context menu of the source editor.

The debugger displays tooltips in the source editor if you hover the mouse over the name of a data item. By default, the tooltip will show the name, value, and type of the data item; providing an easy way to quickly inspect a data item without adding it in Data window or Watches window. If the data item is an array or object, you can inspect children of the selected item deep in the object hierarchy. The tooltip displays 20 children data items, use the navigation buttons to view remaining data items.

The columns that display in the tooltip depend on the column settings that were enabled in the Tools > Preferences – Debugger – Tooltip page.

If the project builds successfully, the debugger starts.

Specify the legal Java expressions that are used in the Watches window, Inspector window, Breakpoint Conditions, and Breakpoint Log Expressions for the debugger to monitor and evaluate.

Use the debugger to manage how JDeveloper executes a single line of code, a method, or a code block in a program. Use the Step Into and Step Over commands to traverse program code.

The Jdeveloper debugger lets you control the execution of your program; you can control whether your program executes a single line of code, an entire method, or an entire program block. By manually controlling when the program should run and when it should pause, you can quickly move over the sections that you know work correctly and concentrate on the sections that are causing problems. See How to Set the Debugger Start Options.

The debugger lets you control the execution of your program by:

• Stepping into a method

• Stepping over a method

• Controlling which classes are traced into

• Locating the execution point for a thread

• Running to the cursor location

• Pausing and resuming the debugger

• Terminating a debugging session

The Step Into and Step Over commands offer the simplest way of moving through your program code. While the two commands are very similar, they each offer a different way to control code execution.

The smallest increment by which you step through a program is a single line of code. Multiple program statements on one line of text are treated as a single line of code – you cannot individually debug multiple statements contained on a single line of text. The easiest approach is to put each statement on its own line. This also makes your code more readable and easier to maintain.

Set the debugger to start by stepping into code using the Step Into command, so that the program that is being debugged executes until a method in a tracing-enabled class is reached. Use any of the listed methods to step into a method.

Set the debugger to start by using the Step Over command so that the program being debugged executes until a method in a tracing-enabled class is reached, but does not stop in the class static initializer method. Use any of the listed methods to step over a method.

Set the tracing include and exclude lists in Project Properties or Classes before debugging. The descending classes within the specified package are included or excluded.

Normally, you should set the tracing include and exclude lists in the project properties before you start debugging. However, if you need to change the tracing include and exclude lists, you can do so from the Classes window. Right-click in the Classes window and choose Tracing from the context menu. The Tracing dialog appears in which you can adjust the tracing include and exclude lists.

When you specify a package to be included or excluded from tracing, all descending classes within that package are included or excluded as well unless you've specified them individually.

To closely examine part of your program, you can enable tracing on only the files you want to step through in the debugger. For example, you usually don't want to step through classes that are in the J2SE library because you're not going to troubleshoot on them; you usually only want to trace into your own classes.

If a class or package is excluded, the debugger that is set to step into a class runs through that code without pauses. Use the procedure to adjust the tracing include or exclude list.

1. Right-click a project in the Applications window and choose Project Properties from the context menu.
2. Select the Run/Debug node.
3. Choose a run configuration and click Edit.
4. In the Edit Run Configuration dialog select Tools Settings > Debugger.
5. In the Tracing Classes and Packages to Include and Tracing Classes and Packages to Exclude fields, enter the name of the packages or classes you want to include or exclude in the appropriate field, separated by a semicolon (;). For example:

   oracle.xml;org.apache;org.omg;org.w3c;org.xml
   

   You can also click Edit to open the Tracing Classes and Packages to Include/Exclude dialog, then click Add or Remove. If you click Add, the Class and Package Browser dialog appears. If you click Remove, the selected class or package is removed from the appropriate tracing List. Navigate to the class or package you want to add and click OK. The class or package is added to the appropriate tracing list.

include:
exclude:java;javax

During the debugging process, the line of code that is the current execution point for the thread is highlighted and the left margin of the source editor displays the icon for the execution point. Use the procedure to find the current execution point.

1. Choose Run > Find Execution Point from the main menu.
2. Right-click a thread in the Threads window and choose Go To Source of Thread.

   The debugger displays the block of code containing the execution point in the source editor.

Step through application code in the debugger to a particular location without single stepping or setting a breakpoint. Use the procedure to run to a specific program location.

1. In a source editor, position your text cursor on the line of code where you want the debugger to stop.
2. Run to the cursor location in any of the following ways:

   • In the source editor, right-click and choose Run to Cursor.

   • Choose the Run > Run to Cursor option from the main menu.

   • Press the F4 key. The F4 key works unless you Operating System (OS) intercepts that key.

     Note:

     On ADC or SLC machines, F4 key is intercepted and never reaches the debugger.

Pause debugger running at a point in the program so that the debugger can evaluate the code at the location, and then resume debugging. Use the Pause option for Run, or use Pause on the debugger toolbar to pause the debugger.

Terminate a debugging session using Terminate in the Run menu if the debugger has run past a bug location, and needs a restart. Termination of a session closes all debugger windows without deleting breakpoints or watches that had been set.

Select Log for Debugger in the Window menu to view the Debugger log for an active debugger session.

Set a breakpoint to start a debugging session and at a breakpoint, select a specific window from the Debugger menu for Window. You can open and use Debugger windows for classes, Heap, Data, Log, Monitors, Stack, Smart Data, Threads, and Watches depending on requirements.

Select Breakpoints from the Window menu to open a window to display a list of set breakpoints. The Breakpoints window displays information about set breakpoints.

The Data window displays information about variables in a program. It also displays the current return value of a non-void method when a breakpoint in the method is set, and the Step to End of Method command or Step Out command is run.

The Smart Data window displays data that is relevant to the source code that is being stepped through. Set the options for smart data on the Smart Data page, selecting Debugger for Preferences for Tools.

Unlike the Data window which displays all arguments, local variables, and static fields for the current method, the Smart Data window displays only the data that appears to be relevant to the source code that you are stepping through. Specifically, the debugger analyzes the source code near the execution point and finds the variables, fields, and expressions, that are used in the lines of code that you are stepping through. See How to Locate the Execution Point for a Thread.

The Smart Data window also displays the current return value of a non-void method when you set a breakpoint in the method and issue a Step to End of Method command or Step Out command. The return value is not displayed for Step Over or Step Into commands.

By default, the debugger analyzes only one line of code for each location and analyzes up to two locations. You can adjust these settings in the Tools > Preferences - Debugger - Smart Data page which you can also access by right-clicking in the Smart Data window and choosing Preferences from the context menu.

A watch monitors the changing values of variables or expressions as a program runs. The values of the variables in the watch expression change to reflect program updates and changing contexts.

A watch enables you to monitor the changing values of variables or expressions as your program runs. After you enter a watch expression, the Watches window displays the current value of the expression. As your program runs, the value of the watch changes as your program updates the values of the variables in the watch expression.

A watch evaluates an expression according to the current context which is controlled by the selection in the Stack window. If you move to a new context, the expression is reevaluated for the new context. If the execution point moves to a location where any of the variables in the watch expression are undefined, the entire watch expression becomes undefined. If the execution point returns to a location where the watch expression can be evaluated, the Watches window again displays the value of the watch expression.

In the Inspector window, select a variable, field, or object, and get the information from the Watch or Data windows displayed. Use the procedure to open the Inspector Window.

1. Set at least one breakpoint in the Source Editor.
2. Click Debug from the toolbar.
3. When the debugger reaches a breakpoint, select a variable in the Source Editor, right-click, and choose Inspect.

   The floating Inspect window appears and contains the variable you selected. If you want to inspect something else, enter a new expression or variable in the text field, or select a previous one from the dropdown list.

   If no variable or expression is selected, the Inspect dialog appears pre-populated with the text under the cursor in the editor as the expression to inspect. Click OK to open the Inspector window.

The Heap window displays information about the heap in the program that is being debugged, and helps identify memory leaks in a program. The heap window holds the Class Folder and the Reference Path Folder.

The Stack window displays the call stack for the current thread.

The Stack window displays the call stack for the current thread. When you highlight a line in the Stack window, the Data window, Watches window, and all Inspector windows are updated to show data for the highlighted method.

The Classes window displays the classes that have been loaded and information such as the number of instances of a class and the memory needed. The window also shows garbage collector runs.

The Classes window displays which classes have been loaded and may also include useful information, such as the number of instances of a class and how much memory that number of instances requires. In conjunction with the Classes window, the debugger also includes a garbage collection tool when you want to force a run of the Java garbage collector. When you run the garbage collector, the impact is shown immediately in the Classes window. You can only force a run of the garbage collector when you are using a virtual machine that allows the debugger to do so.

Java uses the synchronization mechanism to coordinate activities and data access among multiple threads. The Monitors window displays status and control information for active monitors.

Java supports multithreading at the language level through the use of synchronization. Synchronization is the coordinating of activities and data access among multiple threads. The mechanism that Java uses to support synchronization is the monitor. The Monitors window displays status and control information for active monitors.

The Monitors window will also open automatically if the debugger is in a deadlock state.

The Threads window displays the names, status, and thread groups of all the threads in a program. Use Threads for Debugger in the Preferences for Tools to set the columns that get displayed in the window.

You can customize the settings for the Debugger window. Use the procedure to set preferences for the Debugger window.

1. Choose Tools > Preferences > Debugger.

   The debugging panel appears with customizable fields.

2. Make your selections from the fields and options provided.
3. To set any options for a specific debugger window, expand the Debugger node and click the appropriate window node. For example, if you want to change the columns displayed in the Smart Data window, click Smart Data.
4. Edit any of the available options as desired.
5. Click OK when you are done.

The debugger windows only displays the columns that you select. Right-click in the window and select Preferences from the context menu, or right-click a column heading to specify which columns get displayed in the window.

During debugging, the debugger verifies all breakpoints by checking if they have been set in executable lines of code, and displays an icon to indicate that they have been validated.

While debugging, you can place a breakpoint to the left of any line of code in the source editor. However, for a breakpoint to be valid, it must be set on an executable line of code. Before a method is first executed, the debugger verifies all valid breakpoints in the method. Breakpoints set on comment lines, blank lines, declarations, and other non-executable lines of code are invalid and will not be verified by the debugger.

When a breakpoint has been verified as valid, the icon displayed in the source editor margin and in the Breakpoints window changes to the icon shown in the figure.

Figure 12-8 Verified Breakpoint Icon

A deadlock, such as the common monitor block cycle deadlock, blocks one or more threads in a program from gaining access to a resource, or waits on a condition that cannot be satisfied. To debug, pause your program by clicking Pause in the debugger, and open the Monitors window.

A deadlock occurs when one or more threads in your program are blocked from gaining access to a resource or waiting on a condition that cannot be satisfied. A common deadlock in Java is a monitor block cycle deadlock.

A monitor block cycle deadlock occurs when two or more threads are unable to proceed because each is waiting to enter synchronized code that one of the others has already entered.

The following example shows a typical Java synchronization deadlock:

synchronized (a) 
 {
 ...
 synchronized (b)  {
 ...
  }
  ...
 }

At the same time, thread 2 is executing the following code:

synchronized (b) 
{
...
  synchronized (a) 
  {
  ...
   }
   ...
 }  

A deadlock will occur if thread 1 enters the synchronized (a) as thread 2 enters the synchronized (b). Thread 1 will be blocked from entering synchronized (b) until thread 2 finishes the synchronized (b) and thread 2 will be blocked from entering synchronized (a) until thread 1 finishes the synchronized (a). A deadlock is also called a "deadly embrace." This example is for two threads but the same situation could occur for 3, 4, 5, and so on threads. The deadlock breakpoint can detect this type of deadlock.

Another kind of deadlock is where one thread calls the wait method on a particular object and no other threads call the notify method on that object. The most common cause of this kind of deadlock is timing. The notifying thread may have called notify before the waiting thread called wait. The important thing to know about calling wait is that even if notify was already called many times before, the wait method waits until notify is called again. Also, notify doesn't return any kind of error if there was no thread waiting. The deadlock breakpoint cannot detect this type of deadlock.

If you think your program is hanging, click Pause to pause your program in the debugger, and open the Monitors window. Perhaps you can see that one thread is waiting, investigate the code. If you can see that another thread probably called notify before the first thread called wait, there is a deadlock. This kind of deadlock is very hard to detect. You must know your code well in order to figure out which other thread should have called notify.

You can disable the persistent deadlock breakpoint that the debugger automatically sets when JDeveloper starts. The debugger pauses program running when it encounters a monitor block cycle deadlock.

The Jdeveloper debugger sets a persistent deadlock breakpoint when it starts running. A deadlock breakpoint is useful in situations when you find it difficult to locate the source of the deadlock. When the debugger encounters a deadlock breakpoint, the debugger halts. It can detect a monitor block cycle deadlock as described above. The Monitors window can be useful when working with deadlocks.

The deadlock breakpoint has the following characteristics:

• It is a persistent breakpoint that is created automatically when you use Jdeveloper.

• It cannot be deleted, but it can be disabled.

• It pauses the debugger if a monitor block cycle deadlock is detected. A monitor block cycle deadlock occurs when two or more threads are unable to proceed because each is waiting to enter synchronized code that one of the others has already entered.

The Jdeveloper debugger automatically creates a persistent deadlock breakpoint; this breakpoint will occur whenever a monitor block cycle is detected. You cannot delete a persistent breakpoint. You cannot create a new deadlock breakpoint, but you can edit the existing persistent deadlock breakpoint.

Not all Java Virtual Machines support deadlock detection; for example, the HotSpot VM does not support deadlock detection.

JDeveloper supports Grouped breakpoints that allow you to use multiple breakpoints as a set. Enable breakpoints that are disabled when the debugger encounters the set points for program pauses, or set source breakpoints so that the debugger automatically enables the breakpoint group which contains the exception breakpoint.

Grouped breakpoints let you enable a set of breakpoints. When the debugger reaches a certain point in your code, you can instruct the debugger to enable a breakpoint or a group of breakpoints that was previously disabled.

For example, even though your code might be catching a NullPointerException, it may not be behaving correctly. In some cases, NullPointerExceptions occur more frequently than expected which causes the debugger to stop repeatedly for NullPointerExceptions, including those that are of no consequence to your code. This situation can be resolved by creating a breakpoint group, adding this breakpoint to the group, and disabling the breakpoint group so that the debugger does not stop at this breakpoint when debugging.

Next, you can create a source breakpoint in some code that you know is executed just before the problematic NullPointerException is thrown. You can set the actions for this source breakpoint so that when the source breakpoint occurs, it will automatically enable the breakpoint group which contains the exception breakpoint.

Using the Edit Breakpoint dialog, edit the options for a breakpoint after it has been added in the source code. Use the procedure to view and modify the options of a breakpoint.

1. If the Breakpoints window is not open, select View > Breakpoints from the main menu.
2. In the Breakpoints window, select a breakpoint.
3. Right-click and choose Edit, or click the Edit icon on the Breakpoint toolbar.

   The Edit Breakpoint dialog appears with a Definition tab, a Conditions tab, and an Actions tab.

4. Make any necessary changes to the breakpoint options.
5. To accept the changes, click OK.

Right-click a breakpoint located in the source editor to edit its attributes, such as enabled, disabled, or condition, in the Edit Breakpoint dialog.

A source breakpoint that is set on a line of executable code in the source pauses program execution. Set a source breakpoint by using Breakpoints in Window, or Toggle Breakpoint after right-clicking in the left margin next to a line of code.

Manage debugger functioning at a breakpoint by setting halt execution, beep, the enabling or disabling of a group of breakpoints. Use the procedure to control how the debugger behaves when a breakpoint occurs.

1. In the Breakpoints window toolbar, click Add Breakpoint. Or, select a breakpoint and click Edit.
2. Click the Actions tab in the New/Edit Breakpoint dialog. The Actions tab allows you to change these behaviors:

   • Halt execution (default)

   • Beep

   • Log breakpoint occurrence (enter a tag or an expression)

   • Enable a group of breakpoints

   • Disable a group of breakpoints

Delete a breakpoint when it is not required using either the source editor or the Breakpoints window. Use the detailed options to delete a breakpoint.

Instance filters that are displayed in the Instance Filters column of the Breakpoints window are source breakpoints with instance filters that identify selected instances. Use the procedure to set an instance breakpoint.

1. Set the source breakpoint that you will convert to an instance breakpoint. It must be in a method of the instance's class.
2. Set a second breakpoint at some point where the desired instance will be accessible.
3. Define the instance filter:

   • Start or resume the debugger.

   • When the debugger stops at the second breakpoint, find the desired instance in the Data window, Smart Data window, or Watches window.

   • Right-click the instance, choose Instance Filters, and choose the source breakpoint that is to become an instance breakpoint.

     Repeat for other instances you want to track.

4. Resume the debugger.

   The debugger will stop at the instance breakpoint only for the selected instances.

Set exception breakpoints that are activated when a certain type of exception is thrown during the running of a program. Use the procedure to set an exception breakpoint.

1. In the Breakpoints window, click Add Breakpoint on the Breakpoint toolbar. From the submenu, choose Exception Breakpoint.

   The Create Exception Breakpoint dialog appears.

2. In the Definition tab, enter or choose the name of an exception class.
3. If desired, select or clear the Break for Caught Exceptions or Break for Uncaught Exceptions checkboxes. Both checkboxes are selected by default.
4. Click OK.

The debugger pauses program execution every time a breakpoint is encountered, and by setting a condition using the Edit Breakpoints dialog, you can customize breakpoints so that they are activated only in certain conditions. Use the procedure to set a breakpoint condition.

1. Set a breakpoint on a line of code by clicking to the left of the line in the source editor.
2. Open the Breakpoints window by choosing View > Debugger > Breakpoints.
3. In the Breakpoints window, right-click the breakpoint you just set and choose Edit.
4. In the Edit Breakpoint dialog, click Conditions.
5. Enter an expression in the Condition field, for example, mediumCount > 1
6. Click OK.

Use the Pass Count field to specify the number of times that a breakpoint must be passed before a breakpoint is activated. If the default number, one, is set, when the program reaches the breakpoint line, the breakpoint is activated, and the program pauses.

The Pass Count field specifies the number of times that a breakpoint must be passed for the breakpoint to be activated. Pass counts are useful when you think that a loop is failing on the nth iteration. The debugger pauses the program the nth time that the breakpoint is encountered during the program run. The default value is 1.

If the Pass Count column is shown in the Breakpoints window, you can see the pass count value decrement each time the breakpoint line of code is encountered during the program execution. If the pass count equals 1 when the breakpoint line is encountered, the breakpoint is activated, and the program pauses at that line.

When pass counts are used together with breakpoint conditions, the breakpoint pauses the program execution the nth time that the condition is true; the condition must be true for the pass count to be decremented.

Select Breakpoints in the Debugger menu for Window to view a list of breakpoints, and the breakpoints that have been validated by the debugger. Use the procedure to use the Breakpoints window to locate a breakpoint in the source editor.

1. In the Breakpoints window, select a breakpoint.
2. Right-click and choose Go to Source from the context menu.

Create a breakpoint group, enable or disable it, or remove it like a single breakpoint.

You can enable or disable several breakpoints with a single action, by creating a breakpoint group and putting breakpoints into it. Once you've created a breakpoint group, you can enable, disable, or remove it like a single breakpoint.

When debugging, use the Data, Smart Data, Inspector, or Watches windows to view and edit data items. In the Source Editor, when the program pauses at a breakpoint, hover the mouse pointer over an item to get its details.

Use the inspector window to modify an existing expression. Use the procedure to modify an expression in the Inspector window.

1. You can type the new expression in the corresponding text box, or in the Inspector window, right-click and choose Edit Expression from the context menu.

   The Edit Expression dialog appears.

2. Enter a new expression.
3. Click OK.

When debugging, in a data-related debugger window, filter the number of displayed fields for an expanded object so as to narrow focus, locate, and isolate potential errors in the program. Use the procedure to show or hide fields in the filtered classes list.

1. Select an object in a data-related debugger window. Right-click and choose Object Preferences from the context menu.

   Choosing Object Preferences lets you go directly to the Object Preferences dialog for this specific object from which you can specify filters to control which fields are displayed and which fields are not displayed when you expand an object.

2. In the Object Preferences dialog, you can easily traverse the superclass hierarchy of the selected object, defining or updating the filters for each superclass. Select a class in the Types window and choose the fields to hide or display in the Value column of the debugger window.
3. Click the arrows to shuttle filters from the Fields to Show list to the Fields to Hide list.
4. Click OK when you are done.

To Start a Java process in the Debug mode, configure the project for remote debugging, start the remote debugging session, and run the command appropriate to the debugging protocol and the environment.

java [-client|server] -cp <project_directory>\classes -agentlib:jdwp,<option1>[=<value1>],<option2>[=<value2>]... <java_main_class> 

A project must be configured for remote debugging. Use the procedure to configure a project for remote debugging.

1. Click Debug from the toolbar.

   The appropriate Attach to dialog appears.

2. In the Host list box, enter or select the name or IP address of the machine where the remote debuggee has been started.
3. In the Port list box, enter or select the port number for the remote debuggee.
4. Click OK.

   In the Log window, once the debugger has connected, a successful connection message appears.

5. If you are remote debugging a JSP or servlet, you will want to access your JSP or servlet by launching your browser.

   If you are remote debugging an EJB, you will want to run an EJB client that will access your EJB.

6. Continue with your debugging session as usual.
7. To detach the debugger from the remote debugging process without terminating the debuggee process, choose the Run > Detach menu option. T

   This option is appropriate for remote debugging an application server.

8. To terminate the remote debugging process, choose the Run > Terminate menu option, or select the Terminate icon.

Configure JDeveloper for remote debugging by using the Java Platform Debugger Architecture. Use the procedures to configure a project for remote debugging, and to configure JDeveloper for remote debugging.

1. Choose Application > Project Properties, select the Run/Debug/Profile node, select a run configuration and click Edit.
2. Select the Remote Debugging and Profiling check box.
3. On the Debugger - Remote page, verify that Protocol is set to Attach to JPDA.
4. Close the Preferences dialog.
5. Set breakpoints in your code and from the Debug button dropdown list select the desired run configuration. Complete the connection dialog and verify connection to the debuggee.
6. Access JSP previously deployed to server via a browser. The breakpoint should be hit and all work as expected.