

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer

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.

share|improve this question
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
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

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.


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.

share|improve this answer
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

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.

share|improve this answer
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
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
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

Your Answer


