This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
The Java keyword 'final' is used for several purposes: if you make a class final, it means the class can't be extended (you can't subclass it).
A final member variable is a variable that can only be initialized once - it's value can't be modified after initialization.
Immutable is not a Java keyword. When a class is immutable, it means that if you have an instance of the class, the value that that object represents can't be modified.
Examples of immutable classes in the Java standard API are class String and the primitive wrapper classes (Integer, Long, Byte etc.). It's important to keep in mind that those classes are immutable if you're working with them. Class String contains some methods that perform operations on the content of the string (for example, toUpperCase(), etc.) but those methods always return a new String object, and do not modify the original String object. People who don't know that often make mistakes like this:
The definition of immutable has never been formalised, and the Java community has forumlated very contrived definitions that have digressed from the original intention of the term into an extremely superficial existence.
A common definition is that an immutable type in one that you cannot invoke an operation, and observe a side-effect through some other operation. Another definition, which is much the same but more formalised, is that invocation of any given operation with a fixed set of parameters will consistently return the same value, regardless of whether any other operations have been invoked. As an example, you can observe that java.lang.String is immutable, since for example given charAt called with a fixed value, will always return the same result, regardless of the invocation of any other operations. This can be said for all other operations of java.lang.String, therefore, we say it is immutable.
It is this very concept that defines OO. Others erroneously assign inheritance or polymorphic behaviour or some such to OO, but it is the concept of "identity" that sets it apart. One can abandon inheritance and/or polymorphic behaviour and still have an OO language. As soon as contract identity is lost, you have a functional language. It is also important to note that "identity" and "newness" are not exactly the same thing - that is, you could abandon the notion of constructors as we know them, and still have OO. What is required is the notion of identity of contract implementation such that you have "mutable types" - the ability to invoke an operation on "some contract implementation with an identity" and observe a side effect. Then you might invoke some operation on "some other contract implementation with a different identity" and observe a side effect.
You will note that although ContractualJ does not (since it cannot ala Java) express contract operation relationships accurately, it does not abandon the notion of identity - since some contract operations mandate that a contract implementation with a different identity are returned. It can also be observed that some contracts contain operations that have a void return type - which have no use other than to have a side effect observed through some other operation (as an aside, "effecting operations" - those with a void return type - have a unidirectional dependency relationship with one or more "simple operations", but this relationship (and many others) cannot be accurately expressed in Java - this is one of many shortfalls).