File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Beginning Java and the fly likes Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Java 8 in Action this week in the Java 8 forum!
JavaRanch » Java Forums » Java » Beginning Java
Bookmark ""if" thinks false is true" Watch ""if" thinks false is true" New topic
Author

"if" thinks false is true

Erwin Poeze
Greenhorn

Joined: Aug 20, 2008
Posts: 12
Hi,

The following code is from a static class member:



In the test case !Utils.IsTextNode(tNode) returns false. The if statements acts as if it returned true and jumps to the second if statement.

If I assign the result of !Utils.IsTextNode(tNode) to a boolean variable first, then the if statement evaluates the boolean correctly.


I can not think of any reason that explains this behaviour. Any ideas?

Any help is appreciated!
Vijitha Kumara
Bartender

Joined: Mar 24, 2008
Posts: 3775

Both code fragments are identical (in terms of the functionality). I cannot think of anything that make two fragments behave differently. Did you use the same parameters/data in those two fragments?


SCJP 5 | SCWCD 5
[How to ask questions] [Twitter]
fred rosenberger
lowercase baba
Bartender

Joined: Oct 02, 2003
Posts: 10929
    
  12

i'd verify "Utils.IsTextNode(tNode)" is really returning what you think it is. put in some System.out.println() statements to be sure.


There are only two hard things in computer science: cache invalidation, naming things, and off-by-one errors
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18161
    
    8

My guess is that for the first run, you were looking at source code which didn't match the compiled class which you ran. Then you changed the source code and recompiled before the second run. This would explain why the second run did what you expected.

To test my theory, change the code back to the version for the first run and recompile it. If my theory is correct, the third run should also do what you expected.
Max Rahder
Ranch Hand

Joined: Nov 06, 2000
Posts: 177
(Fairly irrelevant story: I once worked on a FORTRAN system where there was a bug that allowed you to pass a literal, like 1, by reference. In that way you could re-assign it to another value. In other words, it allowed you to make (1 .EQ. 2) evaluate to true.)
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18161
    
    8

Max Rahder wrote:(Fairly irrelevant story: I once worked on a FORTRAN system where there was a bug that allowed you to pass a literal, like 1, by reference. In that way you could re-assign it to another value. In other words, it allowed you to make (1 .EQ. 2) evaluate to true.)


I remember that well, because I worked with somebody who treated that as a feature. He would use the literal 23, let's say, all over the program, and then do the thing which assigned 47 to it and it would actually use 47 all over the program.
Rahul P Kumar
Ranch Hand

Joined: Sep 26, 2009
Posts: 188
Let us say qq = Utils.IsTextNode(tNode) returns boolean. Now qq alone should serve your purpose. Anyway there is no difference between reassigning. So, check for qq, what it is returning, take the opposite meaning.
Erwin Poeze
Greenhorn

Joined: Aug 20, 2008
Posts: 12
Paul Clapham wrote:My guess is that for the first run, you were looking at source code which didn't match the compiled class which you ran. Then you changed the source code and recompiled before the second run. This would explain why the second run did what you expected.

To test my theory, change the code back to the version for the first run and recompile it. If my theory is correct, the third run should also do what you expected.


I did as you asked, but the behaviour is reproducable.

fred rosenberger wrote:i'd verify "Utils.IsTextNode(tNode)" is really returning what you think it is. put in some System.out.println() statements to be sure.

Rahul.p Kumar wrote:Let us say qq = Utils.IsTextNode(tNode) returns boolean. Now qq alone should serve your purpose. Anyway there is no difference between reassigning. So, check for qq, what it is returning, take the opposite meaning.


I included two System.out.println statements:


This proved that the problem is not caused by Java, but by NetBeans. In the debugger the line (Current Program Counter) jumps inside the if statement (to be exact, it jumps to numVNodes++; directly, skipping the second if statement), but this code is not executed. Adding lines above the first if statement influences the debugger behaviour, so it seems that adding the additional qq variable 'solves' the problem, but it is all visual!

Thanks for all your trouble helping me out! I'll pay a visit to the netbeans forum to sort things out.

Thanks again.
Rahul P Kumar
Ranch Hand

Joined: Sep 26, 2009
Posts: 188
Erwin Poeze wrote:
This proved that the problem is not caused by Java, but by NetBeans. In the debugger the line (Current Program Counter) jumps inside the if statement (to be exact, it jumps to numVNodes++; directly, skipping the second if statement), but this code is not executed. Adding lines above the first if statement influences the debugger behaviour, so it seems that adding the additional qq variable 'solves' the problem, but it is all visual!


Delete your class file. Probably your class file and java are not in sync. have you added that if line later than rest of lines ? please don't forget to post the final outcome from netbeans forum.
Erwin Poeze
Greenhorn

Joined: Aug 20, 2008
Posts: 12
Rahul.p Kumar wrote:

Delete your class file. Probably your class file and java are not in sync. have you added that if line later than rest of lines ? please don't forget to post the final outcome from netbeans forum.


Deleting the class files has no effect. I'll post the outcome of the Netbeans forum.
Erwin Poeze
Greenhorn

Joined: Aug 20, 2008
Posts: 12
Respons after filing the issue as a bug report:

"This problem is caused by a defect in Java compiler and cannot be fixed in NetBeans. It has been already reported
against JDK, see issue 168365 for more details."

http://www.netbeans.org/issues/show_bug.cgi?id=168365
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 36598
    
  16
A bug? That's interesting. What happens when you run it from the command line, or use another IDE (eg Eclipse)?
Erwin Poeze
Greenhorn

Joined: Aug 20, 2008
Posts: 12
Well, it seems to be a bug in the jdk (i'm using 1.6) that makes the Netbeans debugger (6.7.1) behave wrongly. However, the java code itself shows the correct results.
I added a System.out.println in the second if block and in the debugger the program counter jumps to it. However, the println is not executed.

So, it seems a bug that creates some confusion in the debugger, but has no influence on the actual java execution.
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 36598
    
  16
Very peculiar. Try a different IDE.
Erwin Poeze
Greenhorn

Joined: Aug 20, 2008
Posts: 12
I installed eclipse and tested the same class. The Eclipse debugger seems to have no problem interpreting the if statement correctly.
Vijitha Kumara
Bartender

Joined: Mar 24, 2008
Posts: 3775

I wonder how that become a bug of JDK then.
Erwin Poeze
Greenhorn

Joined: Aug 20, 2008
Posts: 12
If I interpret the bug report (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6765597) correctly, it does seem a bug in the compiler. Maybe eclipse faces the same problem in other situations?

The bug has a low priority, it is discovered in Oct 2008 and still seems to exist. For me it is a reason to consider moving from netbeans to eclipse.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: "if" thinks false is true
 
Similar Threads
K&B bk,question regarding Boolean Wrapper Class
diff bet using return true false at same time
Boolean unboxing.
Operator Precedence
If Statement Problem