• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Final and immutable

 
Ranch Hand
Posts: 71
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
What is the difference between final and immutable?

Do they essentially mean the same thing?

Thoughts appreciated
Arthur.
 
Ranch Hand
Posts: 1780
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

final is a key word, immutable is a concept. They are unrelated. Here, field c is final and class C is mutable.
 
Java Cowboy
Posts: 16084
88
Android Scala IntelliJ IDE Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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:
 
Ranch Hand
Posts: 1078
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Ranch Hand
Posts: 1608
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic