http://kenai.com/bugzilla/show_bug.cgi?id=4511
--- Comment #2 from charpov_at_kenai.com 2011-10-04 22:45:31 ---
(In reply to comment #1)
> The fields are private and are only ever written in the constructor.
> Why do you think making them final will make any difference to
> thread safety?
Technically, they must be final to ensure visibility. According to the JMM,
threads other than the thread creating the instance could see default values
(here 'null') instead of the values assigned in the constructor.
As a funny illustration, java.util.concurrent.ReentrantReadWriteLock contains
this beautiful constructor:
Sync() {
readHolds = new ThreadLocalHoldCounter();
setState(getState()); // ensures visibility of readHolds
}
(readHolds is a non-final, non-volatile field initialized in the constructor
and never changed elsewhere; setState(getState()) reads a volatile int and
writes it back)
Note that since the fields of PasswordAuthentication are never changed, things
would still work if, for instance, every shared instance of
PasswordAuthentication is always stored in a final field. But that's
impossible to enforce and why bother with such complications?
MC
--
Configure bugmail: http://kenai.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.