Eclipse Conditional Breakpoints Broken?

Question

I am trying to set up a conditional breakpoint in decompiled code, but Eclipse keeps giving me the error:

Conditional breakpoint has compilation error(s)

Reason: Evaluations must contain either an expression or a block of well-formed statments

My case is pretty simple, just trying to compare against a string value. I've tried all of the following and I get errors with every single one:

myObj.toString() == "abc123"
myObj.toString().equals("abc123")
if(myObj.toString() == "abc123"){ return true; }
true == true

I've also tried every combination of having or not having a semicolon at the end of the line(s) and every combination of spacing and newlines and every combination of having or not having {} surrounding my condition. Basically, I have no idea why this isn't working...

The code I am trying to debug through is inside a jar that is decompiled with JD-Eclipse. Normal breakpoints work fine in this code.

Does anyone know what's going on here???

Answer 1

This Eclipse FAQ page contains the syntax of proper CBP definition and most common reasons for them not to work. In your case, I think the following applies:

This can happen if you are setting a breakpoint in a class whose class file does not contain a local variable table. For example, let's say you want to set a conditional breakpoint on Class.forName(String). If you have a source attachment for rt.jar the content assist will allow you to refer to the argument by its variable name, className. However, at debug runtime, the variable name will only be known if the class file contains a local variable table. Depending on the options used at compilation time, this information may have been stripped from the class file.

JD may have fabricated variable names while decompiling your jar, so using "myObj" in conditional expression produces a compile-time error.

Answer 2

In case of "true == true" condition you should just add return statement:

return true == true;

For the rest of the problems missing local variable table should be the explanation. +1 to Mazaneicha for that.

If you're trying to refer a method argument by its name then just try to change the name to "arg0", "arg1", etc.

For instance, you can do like this:

arg0 == null

It's easy to guess the variable name. Just put uncondidtional breakpoint and see the list of variables in the Variables view.