One of the things you see in numerous places in the standard java library is final classes. It is claimed that this is for immutability which I an extent.

Suppose you have a class:

final public class ImmutableTest {
    private String value;
    public ImmutableTest(String value) {
        this.value = value;
    public String getValue() {
        return this.value;

You can say that the value is immutable because it can't be adapted after creation. However this limits usability of the class as no one can extend it (for example to use as a drop-in for a bad interfaceless design...).

Now suppose you have this class:

public class ImmutableTest {
    private String value;
    public ImmutableTest(String value) {
        this.value = value;
    final public String getValue() {
        return this.value;

The "value" is still immutable but now at least people can extend the class. Someone once interjected: but if you extend it, the extended class is not guaranteed to be immutable!

While this is true, I think it is immaterial to the class itself.

If user A uses my ImmutableTest class everywhere in his code, he only has access to the "value" anyway which remains immutable. Unless he does explicit casting (in other words: he's aware that he's trying to access other stuff) he can't access a "mutable" part of the actual instance which means from the developer's point of view the class is as immutable as it should be, even if the actual instance has other mutable variables.

So in short: my opinion is that final classes are superfluous as final methods are all you need. I would love to hear arguments to the contrary though!


To clarify: I'm not claiming that adding "final" to a class or its methods makes it immutable.

Suppose you have a class that is designed to be immutable but you do not make the methods or class final, a subclass can of course make it mutable again. This argument is used as to why some classes in the standard library are final. My opinion is that it should've been enough to finalize the accessor methods to the immutable part and leave the class non-final.

This may leave the window open to the child objects adding mutable fields but the original set of fields would remain immutable hence satisfying the "immutable" requirement for the initial set of methods.


The conclusion being that final classes have no real purpose except perhaps brevity which in itself is not enough of a reason to lose extensibility in my opinion.

  • Well, one reason would be readability and brevity. If your example class had in fact multiple private values with multiple "getters", without the class-level "final" you'd have to copy paste it on the declaration of each method. Also, if you intended to make the class immutable (rather than just making some of its methods final), its easier to convey that through one word at the very top, rather than multiple instances of that word peppered around in the class body. – Shivan Dragon Oct 15 '13 at 11:47
  • 1
    You're throwing two different concepts togethers that are only loosely related. – Pieter B Oct 15 '13 at 12:29
  • @PieterB… – Shivan Dragon Oct 15 '13 at 13:38
  • @PieterB it is not meant as a comment on finality in general, it is meant as a comment on finality with regards to immutability. In that respect they are very much related if guarantees are to be made by the class designer. – nablex Oct 15 '13 at 13:39
  • One more point to make is that inherited methods (like those from Object such as hashCode, equals, and toString also need to be made final if the class itself is not made final. – cdeszaq Dec 13 '17 at 18:04

Declaring immutable class final saves programmer from the need to repeat declaring final in each and every method declaration, over and over and over again.

In classes like java.lang.String, having over 60 methods, this is substantial save, as well as important guarantee that necessary modifier won't be omitted by mistake.

When object is intended to be immutable, mistakes to declare final method may be hard to detect, because there is no reliable way to tell whether programmer omitted final modifier intentionally or by mistake.

final classes have no real purpose except perhaps brevity

Besides brevity and helping to avoid mistakes, a strong benefit of declaring immutable class final is that this makes programmer's intent explicit, unambiguously communicating to API users that none of class methods are intended for override.

Alternative way, that is, declaring all methods final, lacks this important "feature", as it leaves users of the API in the indecisive state, whether API designers intended to only protect some methods from overloading, and it only accidentally turned out that all of them got final, or there was a design decision to cover all the class.

my opinion is that final classes are superfluous as final methods are all you need

Given above, having final modifier for class doesn't look superfluous to me.

It is worth noting that Sun/Oracle Java tutorial presents final classes as a matter of usefulness and not as that of convenience. If final classes purpose was mere brevity / syntactic sugar, one would expect tutorial to explain these as convenience. can also declare an entire class final. A class that is declared final cannot be subclassed. This is particularly useful, for example, when creating an immutable class like the String class.

  • 1
    While what you say is true, the same can be said of a lot of language constructs. Developer errors will always occur, adding a shortcut to avoid having to think about a problem is how dynamic typing was invented :) – nablex Oct 15 '13 at 12:33
  • How do we know they didn't "accidently" declare the class final? – user949300 Apr 11 at 14:12
  • As for "saving the need to repeat final" a skillion times, sorry, repetition in Java, for better or worse, is a feature. How many skillions of times must you write private RepeatMe foo = new RepeatMe();? – user949300 Apr 11 at 14:18
  • I can't make sense of this question sorry. I'm talking about uncertainty when there's a mix of final and non-final methods within the class. Final modifier at class level is a whole different game, it is either present or absent: there's no ambiguity (side note with Java 10 repetitive example no longer holds, it's private var foo = new RepeatMe();) – gnat Apr 11 at 14:24

Classes are not mutable or immutable, mutability usually refers to the state of objects at runtime.

Final classes, methods and members have different goals.

An final class cannot be extended by other classes. Depending on your design, this may be a desirable design property of this class. It does not mean that all members of this class are immutable by default! Logical immutability can be a side effect as in your example. If a class is final and all of its fields are as well, the object is strongly immutable.

Final methods mean that the method cannot be overridden in a subclass. This can be for example useful with the template method pattern where you do not want clients to override the template method instead of the hooks. This, again, has nothing to do with immutable state because it does not directly relate to a member being immutable.

Final fields is where immutablity comes really into play. If you placed the final keyword in front of value like private final String value;, you would make sure that a value could not be overriden no matter who extended what.

  • I meant to say that the argument is used that the entire class is final because its fields have to be immutable, not that the class itself is "immutable" as it of course refers to its fields. – nablex Oct 15 '13 at 11:47
  • 1
    Well, if field immutability is the goal, making the fields final is the way to go. – ftr Oct 15 '13 at 11:53
  • Making a field final is not good enough if the getter isn't final. A child class can simply override the getter and use some other mutable value – nablex Oct 15 '13 at 12:00
  • 2
    The getter has nothing to do with the immutability of value, though. But if you want to make value immutable and prohibit overriding of the getter, you can just make both the field and the getter final. Overriding a getter of an immutable field has a smelly feeling to it anyway. – ftr Oct 15 '13 at 12:07
  • The immutability of the private variable "value" is wasted without protecting the getter. – nablex Oct 15 '13 at 12:17

State is defined by the fields in a class and so making them immutable(using final and private) should work for primitive type variables. But in case of variables containing a reference to some another object, say x, this x should be immutable too. While publishing the x from getter, we need to ensure that we are not compromising with x's immutability. For example:

class A
final int i;

final HashMap<int, B> map;

public A(int i,Map map){
public int getI(){
return i;
public int getJ(int index){
return map.get(index).getJ();

class B{
 int j;
public int getJ()
return j;

public void setJ(int j)


From above code snippet, map is immutable since its final and the map is never published to outer world.

But what if some other class say C, extends A and then overrides getJ(int index) method?

To prevent it, we need to declare getJ(int index) method final. Now there can be many such methods in a class and checking whether each of them should be final can be error-prone. So we declare the class final and let other knows that none of its methods and variables are bounded to change and so overriding it is not possible.

We can declare map as private and final both , so its not accessible to child classes, but then again there can be some other mutable fields/variables in A or B which can be used and published by child class C.

  • Actually, your class A is mutable because you did not copy the Map parameter in the contstructor. While the field cannot take another reference (because it is final), the value can be modified from the outer world. For example: Map m = new HashMap(); A a = new A(1, m); m.put(2,"test"); – Julien Kronegg Jun 15 at 19:26
  • Yeah, map shouldn't be used directly, copying the map value to new one and then referencing it to instance variable should be fine. – thakurnitesh27 Oct 28 at 11:07

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.