JDeveloper – Conditional Breakpoints saving time and a lot of clicking (IDE tip)

One of the biggest time-savers in in ADF 11g (R1) development, is working on the application while it is running on the WLS server in debug mode. In this mode, I can analyze the execution of my code, inspect variables and make many code changes that are applied ‘on the fly’. I can then analyze the execution of the modified code and so on.

Recently I was debugging a piece of Java code that was executed as part of a Web application. I had started the (ADF) web application on WebLogic Server in Debug mode and using JDeveloper for remote debugging. I had inserted several breakpoints in the code. Whenever the thread would hit the breakpoint, execution would be paused and control was handed to me to inspect and potentially manipulate variables, analyze the callstack and step-by-step investigate code execution. Wonderful!

Unfortunately however, the breakpoint was in a section that was invoked quite frequently, probably because it was somehow located inside a loop. I was interested only in inspecting a very specific situation – only two out of more than one hundred breakpoint occurrences. After clicking my way through dozens of irrelevant breakpoint instances – and just missing the one that I did need to inspect – it dawned on me that JDeveloper debugging supports the notion of conditional breakpoints. This allows me to add a simple boolean expression to my breakpoint that governs whether or not the breakpoint will fire. A time (and frustration) saver if ever I saw one. This it how it goes:

Here you see one of my classes. I have created a breakpoint – to inspect the logic that derives the fine grained authorization permissions for the UI Components in my JSF page:

I am only interested in the situation for one specific component. Without conditional breakpoints, I am continuing the debug thread (F9) a zillion times. The solution is straightforward: right click the breakpoint:

and click on Edit Breakpoint.

Click on the Conditions tab. Enter a condition – or select a previously used condition from the dropdown list.

Note: the condition has to be a valid Java expression that resolved to a boolean. When the expression resolves to true, the breakpoint will be triggered and the execution of the thread is paused.

The expression can refer to all the variables that are currently available in the local scope. In other words: any expression that you can add to the code at the location of the breakpoint in a if ( expression) {} type of statement can be used as condition for the breakpoint.

Debugging becomes even easier and more useful with this simple addition to my toolkit!