Sometimes, when you’re debugging your application in eclipse, you see where you’ve made a mistake in your code, and that if you had assigned some variable differently, or had invoked some operation a bit earlier, your code would work. Trouble is, you’re not completely sure, and you don’t want to have to shut down your application, make your change, rebuild your jars, redeploy your jars, and then restart your application. Which is a lot to ask.

Well, if you’re running your application in eclipse, you might be able to try out your fix first, without needing to redeploy everything to find out that you were wrong, ’cause lets be honest here, the first time you try something, it usually blows.

How? This is easiest done with an example:

Consider this “application”

public class Plaything {
  public static void main(String[] args) {
    for (int i=0; i!= 5; i++) {
      doIt("monkey");
    }
  }

  static void doIt(String primate) {
    System.out.println(primate);
  }
}

If you run this, it will output the following:

monkey
monkey
monkey
monkey
monkey

Now, suppose you find out during debug, that you set the wrong parameter, and that perhaps the word “monkey” shouldn’t have been in there, and you want too see what would happen if you had passed a different parameter into doIt(String), “gorilla” perhaps.

What you can do is this:

  • Set a breakpoint on the first line of doIt.
  • Right click the breakpoint, and edit the “Breakpoint Properties”
  • Check the “Enable condition” checkbox, and drop in the following code
primate = "gorilla";
return false;


What we’re trying to do here is invoke some code in the breakpoint condition, every time eclipse gets to this point, but to make sure that the debugger doesn’t stop the execution. It works because of the following:

  • You can execute any code fragment you want in here, so long as the java is correct and the variables are in scope. In this case we change the value of the “primate” parameter, but you can pretty much do whatever you want, although inside of inner classes the parameter/field names will not be the same as they appear in code.
  • The return false; is important, it’s there so that the condition is never true, and so eclipse won’t stop on the breakpoint. If we returned true from this fragment then eclipse would stop on this breakpoint every time we hit it, and that’s what we’re trying to avoid.

The output of this code is as follows

gorilla
gorilla
gorilla
gorilla
gorilla

Is that all you can do? No wait… there’s more. Here’s a more complicated “application,” it’s so complicated that it breaks.

/**
* A simple enough class to demonstrate what
* we can do with breakpoint fragments
*/
public class Plaything {
  /**
  * A string value for later comparison. It's private
  * with no accessor, so I'll be forced to do some gymnastics
  * to get at it.
  */
  private String primate;

  /**
  * Create and populate the primate with the constructor
  * @param primate
  */
  Plaything(String primate) {
    this.primate = primate;
  }

  /**
  * Is the candidate string the same as the one we
  * passed in the constructor
  * @param candidate
  * @return
  */
  boolean isSame(String candidate) {
    return primate.equals(candidate);
  }

  /**
  * This will fail on an NullPointerException
  * because we created the plaything with a null
  * field
  * @param args
  */
  public static void main(String[] args) {
    Plaything plaything = new Plaything(null);
    System.out.println("Is it a monkey? " + plaything.isSame("monkey"));
    System.out.println("Is it a gorilla? " + plaything.isSame("gorilla"));;
  }
}

We create a Plaything with a null primate, and then later try to compare this with “monkey” the result is the all too familiar.

Exception in thread "main" java.lang.NullPointerException
  at com.braindelay.Plaything.isSame(Plaything.java:39)
  at com.braindelay.Plaything.main(Plaything.java:50)

Now, suppose we put a breakpoint on this line:

System.out.println("Is it a monkey? " + plaything.isSame("monkey"));

… and added this breakpoint condition

java.lang.reflect.Field field = Plaything.class.getDeclaredField("primate");
field.setAccessible(true);
field.set(plaything, "gorilla");
return false;

If we run this in debug mode now, we get the following output:

Is it a monkey? false
Is it a gorilla? true

Now, I’m aware that since Plaything is in the same class as the main operation, so we could have just accessed primate directly, but I was trying to make a point here: the code fragment that you put into the breakpoint condition can be pretty much anything you want; just make sure you return a false at the end of it.


So, the object of this lesson is that although you’re eventually going to have to fix the code properly, you can try things out on a running system without needing to take it down and recompile it to do so.

Enjoy.