On 14 Nov 2008, at 19:12, [EMAIL PROTECTED] wrote:
https://issues.apache.org/bugzilla/show_bug.cgi?id=46211
<snip />
... 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
be properly
initialized (some threads may see 'null' instead of the Object
instance)
b) since it is not final, it is theoretically possible to re-assign
the
changeLock member to a different instance, which would lead to
unpredictable
behavior. It is possible for two threads to enter the synchronized
block, since
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
sense...
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.
WDYT? Anyone?
Andreas
