Java - Common Gotchas

In the same spirit of other platforms, it seemed logical to follow up with this question: What are common non-obvious mistakes in Java? Things that seem like they ought to work, but don't.

I won't give guidelines as to how to structure answers, or what's "too easy" to be considered a gotcha, since that's what the voting is for.

See also:

• Perl - Common gotchas
• .NET - Common gotchas

Comparing equality of objects using == instead of .equals() -- which behaves completely differently for primitives.

This gotcha ensures newcomers are befuddled when "foo" == "foo" but new String("foo") != new String("foo").

"a,b,c,d,,,".split(",").length

returns 4, not 7 as you might (and I certainly did) expect. split ignores all trailing empty Strings returned. That means:

",,,a,b,c,d".split(",").length

returns 7! To get what I would think of as the "least astonishing" behaviour, you need to do something quite astonishing:

"a,b,c,d,,,".split(",",-1).length

to get 7.

I think a very sneaky one is the String.substring method. This re-uses the same underlying char[] array as the original string with a different offset and length.

This can lead to very hard-to-see memory problems. For example, you may be parsing extremely large files (XML perhaps) for a few small bits. If you have converted the whole file to a String (rather than used a Reader to "walk" over the file) and use substring to grab the bits you want, you are still carrying around the full file-sized char[] array behind the scenes. I have seen this happen a number of times and it can be very difficult to spot.

In fact this is a perfect example of why interface can never be fully separated from implementation. And it was a perfect introduction (for me) a number of years ago as to why you should be suspicious of the quality of 3rd party code.

Overriding equals() but not hashCode()

It can have really unexpected results when using maps, sets or lists.

SimpleDateFormat is not thread safe.

Try reading Java Puzzlers which is full of scary stuff, even if much of it is not stuff you bump into every day. But it will destroy much of your confidence in the language.

List<Integer> list = new java.util.ArrayList<Integer>();
list.add(1);
list.remove(1); // throws...

The old APIs were not designed with boxing in mind, so overload with primitives and objects.

There are two that annoy me quite a bit.

Date/Calendar

First, the Java Date and Calendar classes are seriously messed up. I know there are proposals to fix them, I just hope they succeed.

Calendar.get(Calendar.DAY_OF_MONTH) is 1-based
Calendar.get(Calendar.MONTH) is 0-based

Auto-boxing preventing thinking

The other one is Integer vs int (this goes for any primitive version of an object). This is specifically an annoyance caused by not thinking of Integer as different from int (since you can treat them the same much of the time due to auto-boxing).

int x = 5;
int y = 5;
Integer z = new Integer(5);
Integer t = new Integer(5);

System.out.println(5 == x);     // Prints true
System.out.println(x == y);     // Prints true
System.out.println(x == z);     // Prints true (auto-boxing can be so nice)
System.out.println(5 == z);     // Prints true
System.out.println(z == t);     // Prints SOMETHING

Since z and t are objects, even they though hold the same value, they are (most likely) different objects. What you really meant is:

System.out.println(z.equals(t));   // Prints true

This one can be a pain to track down. You go debugging something, everything looks fine, and you finally end up finding that your problem is that 5 != 5 when both are objects.

Being able to say

List<Integer> stuff = new ArrayList<Integer>();

stuff.add(5);

is so nice. It made Java so much more usable to not have to put all those "new Integer(5)"s and "((Integer) list.get(3)).intValue()" lines all over the place. But those benefits come with this gotcha.

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...

this one has trumped me a few times and I've heard quite a few experienced java devs wasting a lot of time.

ClassNotFoundException --- you know that the class is in the classpath BUT you are NOT sure why the class is NOT getting loaded.

Actually, this class has a static block. There was an exception in the static block and someone ate the exception. they should NOT. They should be throwing ExceptionInInitializerError. So, always look for static blocks to trip you. It also helps to move any code in static blocks to go into static methods so that debugging the method is much more easier with a debugger.

Floats

I don't know many times I've seen

floata == floatb

where the "correct" test should be

Math.abs(floata - floatb) < 0.001

I really wish BigDecimal with a literal syntax was the default decimal type...

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.

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.

Immutable strings, which means that certain methods don't change the original object but instead return a modified object copy. When starting with Java I used to forget this all the time and wondered why the replace method didn't seem to work on my string object.

String text = "foobar";
text.replace("foo", "super");
System.out.print(text); // still prints "foobar" instead of "superbar"

I think i big gotcha that would always stump me when i was a young programmer, was the concurrent modification exception when removing from an array that you were iterating:

  List list = new ArrayList();
    Iterator it = list.iterator();
    while(it.hasNext()){
      //some code that does some stuff
      list.remove(0); //BOOM!
  }

if you have a method that has the same name as the constructor BUT has a return type. Although this method looks like a constructor(to a noob), it is NOT.

passing arguments to the main method -- it takes some time for noobs to get used to.

passing . as the argument to classpath for executing a program in the current directory.

Realizing that the name of an Array of Strings is not obvious

hashCode and equals : a lot of java developers with more than 5 years experience don't quite get it.

Set vs List

Till JDK 6, Java did not have NavigableSets to let you easily iterate through a Set and Map.

Integer division

1/2 == 0 not 0.5

Using the ? generics wildcard.

People see it and think they have to, e.g. use a List<?> when they want a List they can add anything to, without stopping to think that a List<Object> already does that. Then they wonder why the compiler won't let them use add(), because a List<?> really means "a list of some specific type I don't know", so the only thing you can do with that List is get Object instances from it.

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.

(un)Boxing and Long/long confusion. Contrary to pre-Java 5 experience, you can get a NullPointerException on the 2nd line below.

Long msec = getSleepMsec();
Thread.sleep(msec);

If getSleepTime() returns a null, unboxing throws.

When you create a duplicate or slice of a ByteBuffer, it does not inherit the value of the order property from the parent buffer, so code like this will not do what you expect:

ByteBuffer buffer1 = ByteBuffer.allocate(8);
buffer1.order(ByteOrder.LITTLE_ENDIAN);
buffer1.putInt(2, 1234);

ByteBuffer buffer2 = buffer1.duplicate();
System.out.println(buffer2.getInt(2));
// Output is "-771489792", not "1234" as expected

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.

The non-unified type system contradicts the object orientation idea. Even though everything doesn't have to be heap-allocated objects, the programmer should still be allowed to treat primitive types by calling methods on them.

The generic type system implementation with type-erasure is horrible, and throws most students off when they learn about generics for the first in Java: Why do we still have to typecast if the type parameter is already supplied? Yes, they ensured backward-compatibility, but at a rather silly cost.

Going first, here's one I caught today. It had to do with Long/long confusion.

public void foo(Object obj) {
    if (grass.isGreen()) {
        Long id = grass.getId();
        foo(id);
    }
}
private void foo(long id) {
    Lawn lawn = bar.getLawn(id);
    if (lawn == null) {
        throw new IllegalStateException("grass should be associated with a lawn");
    }   
}

Obviously, the names have been changed to protect the innocent :)

Another one I'd like to point out is the (too prevalent) drive to make APIs generic. Using well-designed generic code is fine. Designing your own is complicated. Very complicated!

Just look at the sorting/filtering functionality in the new Swing JTable. It's a complete nightmare. It's obvious that you are likely to want to chain filters in real life but I have found it impossible to do so without just using the raw typed version of the classes provided.

	System.out.println(Calendar.getInstance(TimeZone.getTimeZone("Asia/Hong_Kong")).getTime());
	System.out.println(Calendar.getInstance(TimeZone.getTimeZone("America/Jamaica")).getTime());

The output is the same.

I had some fun debugging a TreeSet once, as I was not aware of this information from the API:

>Note that the ordering maintained by a set (whether or not an explicit comparator is provided) must be consistent with equals if it is to correctly implement the Set interface. (See Comparable or Comparator for a precise definition of consistent with equals.) This is so because the Set interface is defined in terms of the equals operation, but a TreeSet instance performs all key comparisons using its compareTo (or compare) method, so two keys that are deemed equal by this method are, from the standpoint of the set, equal. The behavior of a set is well-defined even if its ordering is inconsistent with equals; it just fails to obey the general contract of the Set interface. http://download.oracle.com/javase/1.4.2/docs/api/java/util/TreeSet.html

Objects with correct equals/hashcode implementations were being added and never seen again as the compareTo implementation was inconsistent with equals.

IMHO

1. Using vector.add(Collection) instead of vector.addall(Collection). The first adds the collection object to vector and second one adds the contents of collection.
2. Though not related to programming exactly, the use of xml parsers that come from multiple sources like xerces, jdom. Relying on different parsers and having their jars in the classpath is a nightmare.