Java - Common Gotchas [closed]

Answer 1

Not really specific to Java, since many (but not all) languages implement it this way, but the % operator isn't a true modulo operator, as it works with negative numbers. This makes it a remainder operator, and can lead to some surprises if you aren't aware of it.

The following code would appear to print either "even" or "odd" but it doesn't.

public static void main(String[] args)
{
    String a = null;
    int n = "number".hashCode();

    switch( n % 2 ) {
        case 0:
            a = "even";
            break;
        case 1:
            a = "odd";
            break;
    }

    System.out.println( a );
}

The problem is that the hash code for "number" is negative, so the n % 2 operation in the switch is also negative. Since there's no case in the switch to deal with the negative result, the variable a never gets set. The program prints out null.

Make sure you know how the % operator works with negative numbers, no matter what language you're working in.

Answer 2

The default hash is non-deterministic, so if used for objects in a HashMap, the ordering of entries in that map can change from run to run.

As a simple demonstration, the following program can give different results depending on how it is run:

public static void main(String[] args) {
    System.out.println(new Object().hashCode());
}

How much memory is allocated to the heap, or whether you're running it within a debugger, can both alter the result.

Answer 3

Among the common pitfalls, well known but still biting occasionally programmers, there is the classical if (a = b) which is found in all C-like languages.

In Java, it can work only if a and b are boolean, of course. But I see too often newbies testing like if (a == true) (while if (a) is shorter, more readable and safer...) and occasionally writing by mistake if (a = true), wondering why the test doesn't work.
For those not getting it: the last statement first assign true to a, then do the test, which always succeed!

-

One that bites lot of newbies, and even some distracted more experienced programmers (found it in our code), the if (str == "foo"). Note that I always wondered why Sun overrode the + sign for strings but not the == one, at least for simple cases (case sensitive).

For newbies: == compares references, not the content of the strings. You can have two strings of same content, stored in different objects (different references), so == will be false.

Simple example:

final String F = "Foo";
String a = F;
String b = F;
assert a == b; // Works! They refer to the same object
String c = "F" + F.substring(1); // Still "Foo"
assert c.equals(a); // Works
assert c == a; // Fails

-

And I also saw if (a == b & c == d) or something like that. It works (curiously) but we lost the logical operator shortcut (don't try to write: if (r != null & r.isSomething())!).

For newbies: when evaluating a && b, Java doesn't evaluate b if a is false. In a & b, Java evaluates both parts then do the operation; but the second part can fail.

[EDIT] Good suggestion from J Coombs, I updated my answer.

Answer 4

Manipulating Swing components from outside the event dispatch thread can lead to bugs that are extremely hard to find. This is a thing even we (as seasoned programmers with 3 respective 6 years of java experience) forget frequently! Sometimes these bugs sneak in after having written code right and refactoring carelessly afterwards...

See this tutorial why you must.

Answer 5

Integer division

1/2 == 0 not 0.5

Answer 6

This one I just came across:

double[] aList = new double[400];

List l = Arrays.asList(aList);
//do intense stuff with l

Anyone see the problem?

---

What happens is, Arrays.asList() expects an array of object types (Double[], for example). It'd be nice if it just threw an error for the previous ocde. However, asList() can also take arguments like so:

Arrays.asList(1, 9, 4, 4, 20);

So what the code does is create a List with one element - a double[].

I should've figured when it took 0ms to sort a 750000 element array...