3

I have doubt a doubt regarding making an immutable class.

As per the java docs.

  1. I made the class final( no one can extend)
  2. field are private.
  3. no setter function.
  4. If fields are mutable then send a cloned copy of the field.

My doubt is that its compulsory to make a field of my class as final?

Luiggi Mendoza
  • 85,076
  • 16
  • 154
  • 332
dead programmer
  • 4,223
  • 9
  • 46
  • 77

3 Answers3

3

If there are no setter methods (and presumably no other methods to affect the fields' values) and the fields themselves are private, marking them as final is somewhat redundant. Having said that - its a good defensive practice which many projects' standards follow.

Mureinik
  • 297,002
  • 52
  • 306
  • 350
  • 1
    Private fields are not accessible to an inheriting class (that's the difference between `private` and `protected`). Moreover, OP already mentioned that the class itself is final, so it can't be extended anyway. – Mureinik Aug 30 '14 at 16:24
  • @YS Bhai refer this, same question has been answered [here](http://stackoverflow.com/questions/16061030/must-all-properties-of-an-immutable-object-be-final) – Ankur Singhal Aug 30 '14 at 16:24
  • @SotiriosDelimanolis Good point, since the base class has no setter methods. – Paul Aug 30 '14 at 16:25
  • @OliCharlesworth, back to bed with you...you're clearly off your game today! :) – Paul Aug 30 '14 at 16:25
  • 2
    Making fields final is not redundant, as final fields have additional memory visibility semantics. – Stuart Marks Aug 30 '14 at 17:14
2

Although as many say its not mandatory to mark the fields as final I would say atleast in one case that I can think of you need to mark the fields as final and that is in the case if you want to make your immutable class thread safe.

According to Java memory model:-

An object is considered to be completely initialized when its constructor finishes. A thread that can only see a reference to an object after that object has been completely initialized is guaranteed to see the correctly initialized values for that object's final fields.

JLS final thread safety

So if you have an immutable class with instance variables which you initialize in constructor as non final variables then there is no guarantee of thread safety as the writes to the non final variables may not be visible to other threads even though the constructor has fully run ( Note recreating this is very difficult as this may occur in a highly concurrent application)

Manjunath
  • 1,685
  • 9
  • 9
0

Immutable = not changeable. So making properties final is a good idea. If not all properties of an object are protected from being changed I wouldn't say the object is immutable.

BUT an object is also immutable if it doesn't provide any setters for it's private properties.

An immutable object will never change, but anything that it refers to might change. Deep immutability is much stronger: neither the base object nor any object you can navigate to from it will change.

Ankur Singhal
  • 26,012
  • 16
  • 82
  • 116
  • If we're talking about *behavioural* immutability, then it's quite possible to have internal state that changes, so long as it never has an observable effect. The canonical example is some kind of reference-counting mechanism. – Oliver Charlesworth Aug 30 '14 at 16:33