Home of The JavaSpecialists' Newsletter

008boolean comparisons

Posted: 2001-02-08Category: LanguageJava Version: Dr. Heinz M. Kabutz
 

Abstract: Java was based on ideas taken from C/C++, but the designers of the language tightened up the language significantly. In C/C++, a zero (0) means false and non-zero (e.g. 1) means true. In this newsletter, we examine how we should be comparing booleans.

 

Welcome to the 8th issue of The Java(tm) Specialists' Newsletter, where we look at "in-the-field" tips and tricks used by Java professionals. My intention with this newsletter is to have some fun spreading knowledge of advanced Java concepts, and in the process learning new things, so please keep on forwarding your ideas, comments and criticisms.

A special welcome to those of you who found out about this newsletter through Bruce Eckel's website, and a very hearty "thank you" to Bruce, the author of the best Java learning book of all time!

Birthday and Anniversary Special: Since the 30th November 2017 is the 17th anniversary of our newsletter and my birthday is coming up on the 4th December, we are giving away a 30% discount on our new Data Structures for Java 9 Course (Late 2017 Edition). Whether you are a seasoned Java programmer or you just want to get ready for your next job interview, this course will help you. Besides detailed lectures, the course has over 130 questions that will help you discover what you missed.

Comparing boolean variables with true or false

Java was based on ideas taken from C/C++, but the designers of the language tightened up the language significantly. In C/C++, a zero (0) means false and non-zero (e.g. 1) means true. This caused a lot of bugs that were not found at compile time, especially with assignment vs. comparison.

Here's a snippet of C++ code, which has the same syntax as Java

int i = someNumber;
if (i == 4) {
  /* do something */
}
In C/C++ it is extremely easy to write
int i = someNumber;
if (i = 4) { // note we are doing assignment, not comparison!
  /* do something */
}

This will have the effect of assigning 4 to "i", regardless of what "someNumber" was equal to, the result will be non-zero, i.e. true, and after this code, "i" would equal 4.

In Java, we now have the "boolean" type which is either "true" or "false". The parameter to the "if" statement has to be "boolean", rather than an int as in C/C++. The code assigning 4 to i would not compile in Java. This is great, because we find a lot of bugs at compile time.

---
Warning Advanced:
Memory optimisation insider trick: Incidentally, when you have a boolean data member, according to my experiments, it is counted as 4 bytes! A boolean array uses one byte per boolean.
---

This is all very fundamental, so why am I writing this in an advanced Java newsletter? When we assign one boolean to another, the returned value is that of the value we are assigning to. This means that the bug mentioned above is still possible if we are doing boolean comparisons! I have often seen code such as the following, even from experienced, otherwise good, Java programmers (I counted over 150 occurance in the project I'm currently working in):

boolean pentiumTMcpu = Utils.isCpuAPentium();
if (pentiumTMcpu == true) {
  /* work out incorrect salary using double */
}

This will compile fine in Java, but so will the following, which assigns true to pentiumTMcpu and will always work out the salary using the Pentium bug (younger readers would not remember):

boolean pentiumTMcpu = Utils.isCpuAPentium();
if (pentiumTMcpu = true) {
  /* this code will always be executed */
}

Instead, it would be a lot safer to write

boolean pentiumTMcpu = Utils.isCpuAPentium();
if (pentiumTMcpu) {
  /* work out incorrect salary using double */
}

It is very easy for a bug to slip in during maintenance so we should always think about how we can reduce the possibility of bugs being introduced by less experienced, less expensive, less intelligent, less careful future programmers who have to maintain the code we write. (I'm kidding about the less expensive.)

There is a technique used alot in Microsoft's C++ libraries in which they would have written the comparison as:

boolean pentiumTMcpu = Utils.isCpuAPentium();
if (true == pentiumTMcpu) {
  /* work out incorrect salary using double */
}

This is also quite safe, since you cannot assign anything to true, and so you would get a compiler error if you only had one "=". I personally don't like that style, but it is just as safe as writing "if (pentiumTMcpu)", except that you might confuse someone who comes to Java having never written C/C++.

That's the end of this newsletter. I am trying to keep these newsletters short, but sometimes get carried away with my story telling, please forgive me. I generally have topics lined up one month in advance, but if there is something you would like to contribute, please send me an email.

Next week I will look at a topic I call "depth-first-polymorphism", brought to my attention by Dr. Jung, who wrote an earlier newsletter.

Until next week

Heinz

 

Related Articles

Browse the Newsletter Archive

About the Author

demo

Java Champion, author of the Javaspecialists Newsletter, conference speaking regular... About Heinz

Java Training

We deliver relevant courses, by top Java developers to produce more resourceful and efficient programmers within their organisations.

Java Consulting

Nobody ever wants to call a Java performance consultant, but with first-hand experience repairing and improving commercial Java applications - JavaSpecialists are a good place to start...

Threading Emergency?

If your system is down, we will review it for 15 minutes and give you our findings for just 1 € without any obligation.