Java - Common Gotchas [closed]

Answer 1

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

Answer 2

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.

Answer 3

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.

Answer 4

Overriding equals() but not hashCode()

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

Answer 5

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.

Answer 6

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.