This is a convenient exploitation of how the Breakpoint Properties Page works.
A lot of people are aware of hot-code replacement functionality in the Eclipse JDT (Java Development Tools). This allows one to modify source code while an application is being debugged and have the generated class files be used in the current runtime.
This is great but in the past I have run into issues where this functionality, for some reason fails. This also depends on having editable source files, which doesn’t seem like such a big deal, except that it’s very possible to have source artifacts (fetched by Maven) or source bundles (in the PDE Target Platform) that show up as class files and can’t be (immediately) edited.
So what should you do when you’d like to do a hot-code replace on a class for which you have read-only sources ?
Enter the JDT Breakpoint Properties Page. Generally, this page is meant to help set the conditions on which a breakpoint causes the thread to suspend. For example, you may have some kind of loop that iterates through many values, but only want to investigate what happens on a particular value. Rather than setting a breakpoint in the loop, seeing it suspend on the line, checking the value, hitting resume, over and over until you get the desired value, you could set a condition to suspend when your value is set.
So the suspend can be triggered on some condition that will be evaluated prior to executing the line. But there’s nothing stopping us from making the “condition” a code snippet that always returns “false”. The result is a breakpoint that never causes a suspend, but still evaluates the entire code snippet.
One of the simplest things for which this can be used is to insert “printf” statements without actually having to litter them throughout your codebase. Much easier to track and clean :
System.out.println("..."); return false;
With this simple pattern, we can basically emulate something like the CDT’s dynamic printfs .Of course, since this merely inserts code there are some limitations to what can be done versus an actual hot-code replace, but this comes pretty close.