On 14 Nov 2008, at 19:12, [EMAIL PROTECTED] wrote:
... there seems to be another problem: changeLock is not
a 'final' variable, nor is it declared 'volatile'.
As a consequence:
a) since it is neither final nor volatile, it is not guaranteed to
initialized (some threads may see 'null' instead of the Object
b) since it is not final, it is theoretically possible to re-assign
changeLock member to a different instance, which would lead to
behavior. It is possible for two threads to enter the synchronized
they have each locked a separate instance.
Looking closer at the code, changeLock is only re-assigned in case of
a call to the private FontCache.readObject() method. Since this method
does not seem to be used, maybe making the member final would make
OTOH, I'm not the creator of this class, hence why I'm asking first:
Does anyone see a potential problem with the proposed change?
* removal of the unused readObject()
* changing the changeLock member to become final
* the small change proposed by the reporter
This should resolve any multi-threading weirdness, IIC.