• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

"if" thinks false is true

 
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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!
 
Bartender
Posts: 4116
72
Mac TypeScript Chrome Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
lowercase baba
Posts: 13089
67
Chrome Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
i'd verify "Utils.IsTextNode(tNode)" is really returning what you think it is. put in some System.out.println() statements to be sure.
 
Marshal
Posts: 28193
95
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 177
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
(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
Marshal
Posts: 28193
95
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Ranch Hand
Posts: 188
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 188
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Marshal
Posts: 79177
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
A bug? That's interesting. What happens when you run it from the command line, or use another IDE (eg Eclipse)?
 
Erwin Poeze
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Marshal
Posts: 79177
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Very peculiar. Try a different IDE.
 
Erwin Poeze
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I installed eclipse and tested the same class. The Eclipse debugger seems to have no problem interpreting the if statement correctly.
 
Vijitha Kumara
Bartender
Posts: 4116
72
Mac TypeScript Chrome Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I wonder how that become a bug of JDK then.
 
Erwin Poeze
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
There's a city wid manhunt for this tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic