1

Should a Java class' fields always be final？ Is it a good practice?

I know what 'final' means for a primitive or Object Type. My question is should I often (or always) use fields with final?

e.g.

public class MemoryUsage {
    private final long init;
    private final long used;
    private final long committed;
    private final long max;

    /**
     * Constructs a <tt>MemoryUsage</tt> object.
     *
     * @param init      the initial amount of memory in bytes that
     *                  the Java virtual machine allocates;
     *                  or <tt>-1</tt> if undefined.
     * @param used      the amount of used memory in bytes.
     * @param committed the amount of committed memory in bytes.
     * @param max       the maximum amount of memory in bytes that
     *                  can be used; or <tt>-1</tt> if undefined.
     *
     * @throws IllegalArgumentException if
     * <ul>
     * <li> the value of <tt>init</tt> or <tt>max</tt> is negative
     *      but not <tt>-1</tt>; or</li>
     * <li> the value of <tt>used</tt> or <tt>committed</tt> is negative;
     *      or</li>
     * <li> <tt>used</tt> is greater than the value of <tt>committed</tt>;
     *      or</li>
     * <li> <tt>committed</tt> is greater than the value of <tt>max</tt> 
     *      <tt>max</tt> if defined.</li>
     * </ul>
     */
gvlasov
  • 18,638
  • 21
  • 74
  • 110
topCoder
  • 95
  • 8
  • Short answer: no. Long answer: read the docs on `final` fields. – Mena Apr 27 '15 at 10:06
  • possible duplicate of [When should one use final for method parameters and local variables?](http://stackoverflow.com/questions/154314/when-should-one-use-final-for-method-parameters-and-local-variables) – Unihedron Apr 27 '15 at 10:06
  • @Unihedron How on earth is it a duplicate of that? OP is asking about the fields of a class. That question is about method parameters and local variables. – Dawood ibn Kareem Apr 27 '15 at 10:07
  • @Mena first thanks a lot !but i read docs and find no statisfied answer!could you show me more details – topCoder Apr 27 '15 at 10:08
  • @DavidWallace The _answer_ covers the scope about final fields and final static fields. – Unihedron Apr 27 '15 at 10:09
  • That sounds like a good reason NOT to close this one as a duplicate, but instead to answer it with a link to that other one. Otherwise, you lose track of which question was actually answered. – Dawood ibn Kareem Apr 27 '15 at 10:10
  • 1
    @CsBalazsHungary this question is a poor fit for Programmers - it would be quickly voted down and closed over there, see http://meta.programmers.stackexchange.com/questions/6483/why-was-my-question-closed-or-down-voted/6490#6490 Recommended reading: **[What goes on Programmers.SE? A guide for Stack Overflow](http://meta.programmers.stackexchange.com/q/7182/31260)** – gnat Apr 27 '15 at 16:15

3 Answers3

2

Just a short example, let's say you have a class 'Student'. In there, you have a field 'birthDate'.

Now, this field can be final, because it is safe to assume, that if yesterday the date of your birth was 20th of january 1980, it 'll still be that date next year.

But, if you have a field:

private String major;

This, should not be final. You would make it impossible for a student to change majors, which is something that happens quite often.

So, for a primitive type: will the value never change during the entire flow of your application/lifetime of the object, then it can (but doesn't have to be) final.

If it's an object: if it shouldn't be possible to re-reference it, it can be final.

But, no. Far from all variables should be final.

Stultuske
  • 9,296
  • 1
  • 25
  • 37
0

No, Final means you cannot change the values of the fields once instantiated. Of course some values you would rather never change such as the value of Pi, but most of the time you wouldn't want that

svarog
  • 9,477
  • 4
  • 61
  • 77
  • 3
    For primitives it means you can't change the values, for Objects, it means you can't re-reference them. Not necessarily the same. – Stultuske Apr 27 '15 at 10:10
  • they are not just not necessarily the same, they are totally different, thanks for pointing that out! – svarog Apr 27 '15 at 10:13
0

As addition to the other answers:

If you make all fields of an object final and also ensure that referenced object have the same restrictions you create an Immutable Object with its own benefits (i.e. thread safety, no side effects) and drawbacks (you have to use copy on write, no side effects).

An example for this design is the java.time package.

Dawnkeeper
  • 2,844
  • 1
  • 25
  • 41