Java Mysteries

If you aren't a computer nerd -- you might want to skip this one.

I have started to use the FindBugs plugin for Eclipse, and it is very nice.  It finds many obscure failures that Eclipse or MyEclipse alone does not.  One particular problem it found in the code that I am attempting to brutalize into usefulness was use of == and != operators for doing String compares.  If you program in Java, you immedately recognize that:

    if (strObject == "hello")

is wrong.  String compares are done with

   if (strObject.equals("hello")

But we had almost 200 string compares using == or !=.  So why do we not have more problems?  The always useful StackOverflow explains why this often works, in spite of being wrong.  Java is smart enough to create a single copy of a String if it is a constant and there is another constant of the same content.  As a result, == and != will work if you are comparing two String objects that are both constants.  Thus, the many compares of the form strObj == "" work because the passed in parameter strObj was initialized somewhere to "".  If for any reason strObj is created in some other manner, such as new String(""), or as the result of some concatenation operation, the use of == or != is not going to work correctly.

As a result, in many cases, these really invalid uses of == and != work -- but it is a hazardous practice!

McCabe Cyclomatic Code Complexity Measure

I recently installed the Metrics plugin in MyEclipse at work.  It provides a great big stack of code complexity statistics -- of which the most easy to understand for non-computer geeks is the McCabe Cyclomatic Code Complexity metric.  This is effectively a measure of how many different paths there are through a particular piece of code. 

Imagine if you lived in a big city, and had to find your way to another spot in the same city.  Every place where you could make a decision of where to turn or go ahead represents complexity, in the same way that the decision points in a programming language represent complexity.  Pretty obviously, the more decision points there are, the more opportunities there are to make mistakes.  A cyclomatic code complexity greater than ten is supposed to be a sign that you need to refactor the code.  So what happens when you see lots of code with complexity measures above 30?  Oh dear.

And when I actually look at some of the functions with high code complexity measures, what do I find?  The equivalent of dropping a mouse at Santa Monica Blvd. and Ocean Avenue in Santa Monica, and telling it to find its way to Boyle Heights in East Los Angeles.

There is a lifetime (perhaps several lifetimes) of work to clean up this pile.

Java Question

The project that I am currently working on has an interesting issue.  We just started using a tool called YourKit Java Profiler, and it shows that we have 26 MB of duplicate copies of the empty string "".  My first reaction was shock: I thought all compilers were smart enough to recognize that immutable strings (such as string constants) that are identical should reference a single version of that string.  But if YourKit Java Profiler is to be believed, that is NOT happening.  I asked the question here, and the answers that I received indicated that Java does create only a single version of a string constant -- but that the problem might be:

String str = i + ""

which is a very common Java construct for converting an integer to a string, is turning into something like:

String str = new StringBuilder("").append(i).toString();  

The implication is that the new StringBuilder("") is producing a distinct object each time, because that is a mutable string.  The solution is to use the somewhat less easy 

String.valueOf(i)

to produce the string version of i instead.  Does this seem like a plausible explanation of how we end up with 26 MB of "" copies?