This post originated from an RSS feed registered with Agile Buzz by Laurent Bossavit. Original Post: Throw some Java salt over your shoulder Feed Title: Incipient(thoughts) Feed URL: http://bossavit.com/thoughts/index.rdf Feed Description: You're in a maze of twisty little decisions, all alike. You're in a maze of twisty little decisions, all different. Latest Agile Buzz Posts Latest Agile Buzz Posts by Laurent Bossavit Latest Posts From Incipient(thoughts)

I'm fairly sure you could accurately gauge the maturity of a programming team by the amount of superstition in the source code they produce. Code superstitions are a milder form of cargo cult software development, in which you find people writing code constructs that have no conceivable value with respect to the functions that the code is meant to fulfill.

A recent conversation reminded me of an example I find particularly disturbing. Sample code for dealing with JDBC is particularly prone to being littered with this particular error, as shown below. (I suspect that is not coincidental; I'll be coming back to that.) I have elided most braces out for clarity and terseness - imagine that this is a cross between Java and Python:

import java.sql.*; 

public class JdbcSample {
  public static void main(String[] args) {
    Connection conn = null;
    try
      conn = DriverManager.getConnection("jdbc:someUrl");
      // ...more JDBC stuff...
    catch (SQLException ex)
      // Too often that is silently ignored, but that's another blog entry
    finally
      if (conn != null)
        try
          conn.close();
        catch (SQLException sqlEx)
      conn = null; 
  }

The "superstition" part is that setting the connection to null can have absolutely no useful effect; being a local variable, "conn" will become eligible for garbage collection as soon as it goes out of scope anyway, which the most rudimentary analysis of flow control reveals it will immediately after being set to null.

I am always particularly interested in finding out what goes on in the minds of programmers who write this kind of thing, because that will sometimes reveal the roots of the superstition. Most of the time, though, if you raise question in a design review the programmer will say something like "I copied and pasted it from sample code". This is how the superstitions spread - and it's also a red flag with respect to the team's practice maturity - but rarely an occasion to gain insight into why the superstition took hold, which is what you'll need to know in "remedial" training.

Now, the "null" concept, obvious as it seems, is a likely place for superstitions to accrete around. If you look closely, "null" is nothing but obvious. Comparing Java and Smalltalk, for instance, we find that they differ radically with respect to calling instance methods on null, or "nil" as it's called in Smalltalk; "nil" does have some instance methods you can call. Also, what is the type of the "null" value in Java ? It is a special type called "the null type", which looks like a sensible answer but incidentally breaks the consistency of the type system - since any non-primitive variable can be assigned null, the type of null should either be the class Object, or a superclass of Object. (See here for another example of a Java superstition, also surprisingly common, as you can verify by Googling for "equals null".)

In the case of JDBC, I would bet that idioms of resource allocation and deallocation inherited from non-garbage collected languages, like C, were the main force in establishing the superstition. Even people new to Java get used to not calling "dispose" or "delete" to deallocate objects, but unfortunately the design of the JDBC "bridges" between the object and relational worlds suffer from a throwback to idioms of explicit resource allocation/deallocation.

Owing to what many see as a major design flaw in Java, "going out of scope" cannot be relied on as an indicator that a resource is no longer in use, either, so whenever they deal with JDBC Java programmers are suddenly thrown back into a different world, one where deallocation is something to think about, like not forgetting your keys at home. And so, in precisely the same way as I occasionally found myself patting my pockets to check for home keys when I left the office, our fingers reflexively type in the closest equivalent we find in Java to an explicit deallocation - setting to null.

You may object that the setting-to-null superstition is totally harmless. So is throwing salt over your shoulder. While this may be true of one particular superstition, I would be particularly concerned about a team which had many such habits, just like you wouldn't want to trust much of importance your batty old aunt who avoids stepping on cracks, stays home on Fridays, crosses herself on seeing a black cat, but always sends you candy for Christmas.