Should references in java.util.Timer be final?

Question

I was going through the code all of which gets invoked while constructing a Timer class object. I could see the following

public class Timer {
/**
 * The timer task queue.  This data structure is shared with the timer
 * thread.  The timer produces tasks, via its various schedule calls,
 * and the timer thread consumes, executing timer tasks as appropriate,
 * and removing them from the queue when they're obsolete.
 */
private **final** TaskQueue **queue** = new TaskQueue();

/**
 * The timer thread.
 */
private **final** TimerThread **thread** = new TimerThread(queue);

Could some one please explain me the need for declaring queue, thread object references as final ? They anyway are declared private variables.

Thanks!

Would there be any reason to have them be mutable? – kviiri Dec 10 '13 at 17:55 — kviiri, Dec 10 '13 at 17:55
To prevent `Serialization`? – Elliott Frisch Dec 10 '13 at 18:01 — Elliott Frisch, Dec 10 '13 at 18:01

score 1 · Accepted Answer · edited May 23 '17 at 12:29

1

Putting final makes it clear that queue and thread should not be assigned different references after their initializations, both to a reader and to the compiler.

This may not be the entire reason behind it, but if you have objects that you know should not be assigned new references, then you should be using final.

You seem to have a misunderstanding of what private means, please see this post about modifiers in Java.

EDIT (based off of comment)
Yes, a private field can be changed through reflection if a SecurityManager is not used, see this post; however, I very much doubt that that would be a reason why final is included here.

As stated above, the primary reasons are most likely to inform the users/readers of the code, and to make sure that when coding, the programmer is not accidentally changing the references for these objects.

edited May 23 '17 at 12:29

Community

1
1

answered Dec 10 '13 at 18:03

Steve P.

14,489
8
42
72

Is there a method or any way (given the current code) that we can make queue and thread references point to a different object ? The whole point of not providing setter methods and making these references private is to make sure that these references are not meant to be changed. – userx Dec 10 '13 at 18:11
@gagansab No, you have a slight misunderstanding of `private`. `final` is what is used to have references not change. See edit... – Steve P. Dec 10 '13 at 18:15
@gagansab Or are you asking if it were not final, could we change it? – Steve P. Dec 10 '13 at 18:18
Thank you for the link to class modifiers, I do understand what private means and what final means, but my intent about the question was what you have rightly pointed out in your second comment, if you do not make it final, is there a way we can change it (given the current code of Timer) ? – userx Dec 10 '13 at 18:21

Malcolm · Answer 2 · 2013-12-10T18:18:59.217

Usually the main reason behind declaring some field as final is to make the class immutable (or less mutable). This helps a lot in multithreaded environment as immutable objects are easy to manipulate because you don't have to worry about any concurrency issues.

It is a good practice, however, to declare fields as final by default unless you have to modify them at some point. This not only will help if you decide to use the object in multiple threads, but also shows the intent for those who will read the code in the future.

Oracle tutorials have an explanation of the reason behind having immutable objects and how immutable objects are defined.

Should references in java.util.Timer be final?

2 Answers2