Return-Path: Delivered-To: apmail-harmony-dev-archive@www.apache.org Received: (qmail 86291 invoked from network); 10 Apr 2007 20:11:14 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 10 Apr 2007 20:11:14 -0000 Received: (qmail 65659 invoked by uid 500); 10 Apr 2007 20:11:17 -0000 Delivered-To: apmail-harmony-dev-archive@harmony.apache.org Received: (qmail 65633 invoked by uid 500); 10 Apr 2007 20:11:17 -0000 Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@harmony.apache.org Delivered-To: mailing list dev@harmony.apache.org Received: (qmail 65624 invoked by uid 99); 10 Apr 2007 20:11:17 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 10 Apr 2007 13:11:17 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of nbeyer@gmail.com designates 64.233.162.225 as permitted sender) Received: from [64.233.162.225] (HELO nz-out-0506.google.com) (64.233.162.225) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 10 Apr 2007 13:11:09 -0700 Received: by nz-out-0506.google.com with SMTP id j2so1422696nzf for ; Tue, 10 Apr 2007 13:10:49 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=f/9gdYPF8entSxxvT+Opgck7/EpwFIzsDESzr9kXyvNWe05PbnVJ++5vYidzvgCArOc50ztXsp6ybV+joJIVuaEIbvl9QMV6USewbFxJJNoJwhc6+B61oWvVS9X1heUjErrd1yevLnrEAnHysXp630Osb/ENAJ+fD8AekArIPSA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=qT1kOuW4u/tBU6ToltwQkfvWXXGkaN/y/R4hEhyjK5oRTWV+jcgEdVi/W/5wagnSSVAzofXpO3ga1965ZraUuC5kRVZWYz7nJaj5Ik+LmqYlYVMhKYP4uE+n8v8k4PP7mypeh+BpHpZ5NeIpbVZWENkVtH7YpaAgCKmSReR4wvQ= Received: by 10.114.190.6 with SMTP id n6mr2956213waf.1176235848790; Tue, 10 Apr 2007 13:10:48 -0700 (PDT) Received: by 10.114.195.5 with HTTP; Tue, 10 Apr 2007 13:10:48 -0700 (PDT) Message-ID: <3b3f27c60704101310l4e8cb81nc81289a416f55d60@mail.gmail.com> Date: Tue, 10 Apr 2007 15:10:48 -0500 From: "Nathan Beyer" Sender: nbeyer@gmail.com To: dev@harmony.apache.org Subject: Re: [jira][swing] Could someone please commit HARMONY-3454 ? In-Reply-To: <3D8E84095C6A524A985B787423094E40DE79CA@mssmsx411> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3b3f27c60704092141w4c33e6e8r9a7351ba3597a771@mail.gmail.com> <3D8E84095C6A524A985B787423094E40DE79CA@mssmsx411> X-Google-Sender-Auth: bb4b4db19da56a52 X-Virus-Checked: Checked by ClamAV on apache.org On 4/10/07, Zakharov, Vasily M wrote: > > Thanks for checking the patch, Nathan! > > 1.1. The problem is the wrapped fragment performs class loading, and > can easily produce LinkageError, ExceptionInInitializerError, > IllegalAccessError > etc. and all these must not disrupt the code operation. > > 1.2. It is a question of compatibility. RI seems to catch everything > at this point, including ThreadDeath. :( I guess if the RI is really capturing everything we can do it, but I'd prefer to go the way of a non-bug difference here, unless we have some applications that are depending on this behavior. > > 2.1. Adding synchronization is not a problem at all. But: > > 2.2. What is a point to make a tread-safe point in non-thread-safe > package? > If user can't and shouldn't rely on internal thread-safety and must > think > of synchronization himself, why waste performance (probably twice, as > user > provides his own synchronization) to provide thread-safety in one > particular > place? Isn't it a drop in the ocean? The synchronization would be a minimal performance hit, especially considering it's protecting the integrity of the data structure. > > 2.3. The only reason I see for adding the synchronization here is RI > uses > Hashtable that is synchronized, and we probably would like to be > compatible > in this manner. How do you know it's using a Hashtable? If it is, then it backs up my understanding of the thread-safety guarantees of Swing. There aren't any guarantees for code that's expected to be executed exclusively in the UI thread and protected via isolation, but shared data that could be updated or queried in any thread needs to be protected for consistency. In this case, I would suggest that we just protect the data structure itself, such that only the actual read/write of the Map is protected. This makes sure that the data structure itself doesn't blow up with a spurious NPE (or the like) during a read/write race within the Map itself. This is what a Hashtable would prevent because it makes each method invocation atomic. -Nathan > > Vasily > > > -----Original Message----- > From: nbeyer@gmail.com [mailto:nbeyer@gmail.com] On Behalf Of Nathan > Beyer > Sent: Tuesday, April 10, 2007 8:42 AM > To: dev@harmony.apache.org > Subject: Re: [jira][swing] Could someone please commit HARMONY-3454 ? > > I have a few comments about the patch - > > 1. I think the "catch(Throwable)" in JEditorPane should be change, at > a minimum, to "catch(Exception)". We don't want to hide things like > OutOfMemoryErrors, which could happen anywhere. > > 2. There's no concurrency protection for the static Map, contentTypes. > I realize that many parts of Swing and AWT aren't thread safe, but > this doesn't seem like one of them. Perhaps this wasn't properly > protected before, but we should add it now. > > -Nathan > > On 4/9/07, Zakharov, Vasily M wrote: > > Hi, > > > > Could someone please commit > > http://issues.apache.org/jira/browse/HARMONY-3454 ? > > > > It has patch available and it looks like the discussion over it is > over. > > > > Thank you! > > > > Vasily Zakharov > > Intel ESSD > > >