wood burning stoves 2.0*
The moose likes Beginning Java and the fly likes Final and immutable Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Final and immutable" Watch "Final and immutable" New topic
Author

Final and immutable

Arthur Blair
Ranch Hand

Joined: Sep 20, 2005
Posts: 71
What is the difference between final and immutable?

Do they essentially mean the same thing?

Thoughts appreciated
Arthur.
Jeff Albertson
Ranch Hand

Joined: Sep 16, 2005
Posts: 1780

final is a key word, immutable is a concept. They are unrelated. Here, field c is final and class C is mutable.


There is no emoticon for what I am feeling!
Jesper de Jong
Java Cowboy
Saloon Keeper

Joined: Aug 16, 2005
Posts: 14114
    
  16

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:


Java Beginners FAQ - JavaRanch SCJP FAQ - The Java Tutorial - Java SE 7 API documentation
Scala Notes - My blog about Scala
Ken Blair
Ranch Hand

Joined: Jul 15, 2003
Posts: 1078
Originally posted by Arthur Blair:
Do they essentially mean the same thing?


No, as the above have already explained. However, as far as I'm aware a primitive that's declared final is immutable.
Tony Morris
Ranch Hand

Joined: Sep 24, 2003
Posts: 1608
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).

I hope my rant helps.


Tony Morris
Java Q&A (FAQ, Trivia)
 
 
subject: Final and immutable