Story By Dr. Kabutz: Boolean comparisons

  Click here to read full story

The Java Specialists' Newsletter [Issue 008] - boolean comparisons

Author: Dr. Heinz M. Kabutz

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!

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 */
}

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

Copyright 2000-2003 Maximum Solutions, South Africa

4038 bytes more | comments? |    | Story By Dr. Kabutz | Score: 0

The class Robot was introduced in Java version 1.3 and belongs to awt (java.awt.

  Click here to read full story

Question: The class Robot was introduced in Java version 1.3 and belongs to awt (java.awt.Robot). Why? I got an impression that all new GUI features come to Swing and Robot class is GUI related class...

Answer: The reason is simple: The Swing toolkit is a fully-featured UI component library implemented entirely in the Java programming language. The Robot class is used to generate native system input events for the purposes of test automation, self-running demos, and other applications where control of the mouse and keyboard is needed. The primary purpose of Robot is to facilitate automated testing of Java platform implementations.

Using the class to generate input events differs from posting events to the AWT event queue or AWT components in that the events are generated in the platform's native input queue. For example, Robot.mouseMove will actually move the mouse cursor instead of just generating mouse move events.
*******************************************
Our older tips: March 22, 2001 - October 21, 2002 READ HERE
All published and not published on the site tips read HERE

26 comments |    | Score: 3