Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: neutral (herse.apache.org: local policy)
Message-ID: <4575A440.60608@tackline.plus.com>
Date: Tue, 05 Dec 2006 16:54:24 +0000
From: Thomas Hawtin <tackline@tackline.plus.com>
User-Agent: Thunderbird 1.5.0.4 (X11/20060602)
MIME-Version: 1.0
To: dev@harmony.apache.org
Subject: Re: [-SPAM-] RE: [classlib][swing] an odd code in swing
References: <8E389A5F2FEABA4CB1DEC35A25CB39CE7DC014@mssmsx411>
In-Reply-To: <8E389A5F2FEABA4CB1DEC35A25CB39CE7DC014@mssmsx411>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Ivanov, Alexey A wrote:
> I think synchronized block can be safely removed.
> Any way Swing is not thread-safe, and these methods are not explicitly
> marked as thread-safe.

This is a static mutable variables [bad]. In an environment where there 
are multiple 'AppContexts', such as Applets, it may be accessed by 
multiple threads.

>> From: Mikhail Loenko [mailto:mloenko@gmail.com]
>>
>> javax.swing.Timer
>>
>> this is an attomic operation, why synchronized?

That is not a valid argument.

One issue is that the change would not necessarily visible to other 
threads if not synchronized/volatile. Secondly, if there are other 
non-atomic operation using synchronized, then these may fail. However, 
in this case volatile looks fine, and no-one would really notice if even 
that was not present.

>>    public static void setLogTimers(final boolean isLogTimers) {
>>        synchronized (Timer.class) {
>>            Timer.isLogTimers = isLogTimers;
>>        }
>>    }

Tom Hawtin