Every now and then we run into code where the what is written does not reflect the author’s intent, that’s a bad thing.  Here’s an example of Java code that does not reflect the author’s intent most of the time.

pubic class Foo {

    private int[] myInts;
    // Constructors...
    // Methods...
    public int hashCode() {
        return this.myInts.hashCode();
    }
}

What’s the problem? The catch here is that invoking hashCode() on an array does not take into consideration the data that resides inside the array and is the same as invoking System.identityCode(…).  This could lead to potential problems when using hash code dependent structures such as HashSet or HashMap.  If you run the following code you will find that both printouts are identical.

public class Test {
    public static void main ( String[] args ) {
        int[] a = new int[1];
        a[0] = 1;
        System.out.println(a.hashCode()); // A value
        a[0] = 5000;
        System.out.println(a.hashCode()); // That value again
    }
}

What do we do then?  The fix for this is to use the Arrays.hashCode(…) method which is overloaded for all of the primitive arrays and Object array as well.  The usage of Arrays.hashCode(…) is shown below.

public class Test {
    public static void main ( String[] args ) {
        int[] a = new int[1];
        a[0] = 1;
        System.out.println(Arrays.hashCode(a)); // A value
        a[0] = 5000;
        System.out.println(Arrays.hashCode(a)); // Another value
    }
}

Be careful when using methods, be absolutely certain about the behavior of the methods you invoke.  If you are a developer and recognize that you are doing something that might look questionable then document defensively for fear that another developer may come along and fix your “mistake” which was actually what you intended.

Introduction

Coming from an object oriented background, recently I was introduced to the functional paradigm.  Functional languages tend to lean towards building applications using functions which produce no side effects and have objects be immutable.  Producing no side effects means every function has an input, an output, and no state outside of the scope of the method is modified.  We are focusing on the second aspect of functional languages which is immutability.

#define Immutability

What does it mean exactly to have objects be immutable?  An immutable object is simply an object where after creation its state cannot be changed.

    Point p = new Point(2,5);  // Create a new Point object with coordinates (2,5).

    // If the Point object is immutable, there is nothing we can do to change the state of the object that p references now!

Why immutability?

The question now is, what does immutability buy us, isn’t it merely inconvenient if I can’t modify the state of an object?  First of all, something you should be asking yourself before you allow for modification of the state of an object is, do I really need to be able to change its state?  If the answer is a blatant no then you should do whatever is necessary in the language you are working in to make this object immutable, why even have mutability if it is not necessary?  As Josh Bloch would say, “When in doubt, leave it out”.

Aside from this practice that many developers follow there are actual benefits to immutability.  With immutability, concurrent access in these areas is thread safe because nothing will ever change which simplifies your code by removing any necessary locking mechanisms you would need to put in.  Also with immutability, shallow copies of an immutable object are just as good as a deep copy.  An object reference to an object which cannot change is just as good as an object reference to a new object which cannot change with the same values.  The amount of memory saved with using shallow copies per object with the same state is approximately the sum of the memory taken up by all member variables for the object subtracted by the memory used for an object reference.

Consequences of Immutable Objects

Now that we know what immutability is and what it buys us I can dive into some of the consequences of immutable objects.  Take the following code for example assuming that Point is immutable:

    Point p = new Point(3,5);  // Create a new Point object with coordinates (2,5).

    for(awhile) {
        sleep(100);

        p = new Point(p.getX()+1, p.getY());  // Move the point +1 on the x-axis.
    }

Something you might be thinking is, why on earth are we making an object every time we move the Point over by +1 on the x-axis?  Immutability is the reason!  We can’t change the x coordinate of the Point that p references so the only way we can move the Point that p references is by creating a new Point and referencing that Point.  This is unfortunate because everytime we do this we need to create a new Point object, the more we do this the more memory we will use.  Fortunately it is the case that most object oriented programmers would not take the route of immutability here and simply add a setter to allow modification of the coordinates of a Point.

Functional Languages demand Immutability

Functional languages are not as flexible as object oriented languages however, meaning that you cannot just go in and modify an object since immutability is baseline.  How do functional languages deal with the memory inefficiencies of creating so many objects?  Take for instance the following clojure(lisp) code:

    (def myList (list (range 1000000))) // Set myList to be a list of numbers from 0 to 999999.
    (print (rest myList)) // Print all but the first element in myList.

In the more interesting second line we are creating an anonymous list object by using the rest function and passing that returned value into the print function.  In order to do this the rest function would make a copy of all of the numbers from 1 to 999999, pack them into a list and return it.  This is exactly the type of inefficiencies we discussed above that using immutable objects brings about.

Functional language implementations have indeed thought this through though and to counteract it they use something called “Persistent Data Structures”.  Persistent data structures are data structures that keep track of modifications to itself, essentially a diffing mechanism for data structures.  Using the example above, the implementation of the language would essentially note that the argument passed into the print function is “myList without the first element”.  This save us from needing to copy the numbers from 1 to 999999 and passing that into print, instead we just remember that we are passing in “myList without the first element” which is much cheaper.  This type of behavior is implemented in functional languages such as Clojure, Ocaml, and Haskell.

Conclusion

Immutability is a good thing, use it when you can.  I have also shredded one of the fallacies I had about programming in a functional language which is that I would be creating so many objects everytime I make a function call that memory usage would be too high.  It is probably a good idea to do a bit of reading on some of the implementation details of various languages before making any such assumptions.