Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (nike.apache.org: domain of alexei.fedotov@gmail.com
 designates 209.85.220.166 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=Jo3R1wcufjvpd3Mm6ErMUJAr2iPElb2MqwjdP4hsSAHqSn4a1u+4B8F2tWU53xvs0d
         9UGMyUhs88pMC3nFkKofO7XVc7arecu4rljLNOz/CMS2ueVV8osRD94rHVh2n5kPeW4I
         VA3n8WUrCxy6oaBcD1Kv1CL3GfA34cKU/EAXE=
MIME-Version: 1.0
In-Reply-To: <3b3f27c60903251852s20473368h531cf92231e723de@mail.gmail.com>
References: <49C8E9E3.2070608@gmail.com>
	 <3b3f27c60903241938wf469626v74aa035115fc24f@mail.gmail.com>
	 <49CA0A31.4020808@gmail.com>
	 <3301EDEF-1A1F-423D-9425-7B9DA200215A@gmail.com>
	 <E1LmZBE-0005tU-0I@ptb-relay03.plus.net>
	 <3b3f27c60903251852s20473368h531cf92231e723de@mail.gmail.com>
Date: Thu, 26 Mar 2009 05:14:05 +0300
Message-ID: <c30d70960903251914nfc084dcwa1aebe52b7efa72c@mail.gmail.com>
Subject: Re: Remaining M9 issues
From: Alexei Fedotov <alexei.fedotov@gmail.com>
To: dev@harmony.apache.org
Content-Type: text/plain; charset=KOI8-R
Content-Transfer-Encoding: quoted-printable

Nathan,
I have just thrown a ping to Rustem. Even if found, this tool hardly
can be donated without upper level managerial support. Maybe Xiao Feng
would help us.

Honestly, I'm reluctant native bridge supporter myself. I dare to
think of it as another layer of wrappers. Removing the wrappers would
result in more compact code. I see the only viable argument in the
native bridge defense is "java is easier, why should we use C".

Thanks.


On Thu, Mar 26, 2009 at 4:52 AM, Nathan Beyer <ndbeyer@apache.org> wrote:
> On Wed, Mar 25, 2009 at 2:53 PM, Mark Hindess
> <mark.hindess@googlemail.com> wrote:
>>
>> In message <3301EDEF-1A1F-423D-9425-7B9DA200215A@gmail.com>, Nathan Beye=
r
>> writes:
>>>
>>> On Mar 25, 2009, at 5:40 AM, Tim Ellison <t.p.ellison@gmail.com> wrote:
>>>
>>> > Nathan Beyer wrote:
>>> >> On Tue, Mar 24, 2009 at 9:10 AM, Tim Ellison
>>> >> <t.p.ellison@gmail.com> wrote:
>>> >>> 3. Various AWT/Swing crashes/ failures
>>> >>
>>> >> Linux AWT/Swing crashes - works on Ubuntu 8.04, doesn't on 8.10
>>> >> https://issues.apache.org/jira/browse/HARMONY-6123
>>> >
>>> > Looks like a problem in the X.11 libraries, and looking around it
>>> > seems that we are far from the only ones who have uncovered this prob=
lem.
>>> >
>>> Agreed, but I got the impression that the new behavior is considered
>>> correct and it will be up to apps to fix their own code. Have you
>>> found any indication to the contrary?
>>
>> Well, there have been mistakes in the past - such as nested locking not
>> working as documented in the XLockDisplay man page and with locks being
>> held by the toolkit when user callbacks were invoked - but I think it is
>> quite likely that we need to do something to fix this.
>>
>> We currently call XInitThreads to allow multi-threaded support but we
>> do not actually seem to call XLockDisplay. =9AI don't think this can be
>> correct though I don't know which xlib calls need to be locking - I'm
>> guessing at least the two mentioned in your JIRA. =9AIf we had access
>> to the native bridge tool, we could probably make a safe fix of just
>> wrapping all Xlib calls with a lock but that would probably be overkill.
>> Having access to the native bridge tool would be useful anyway.[0]
>
> Is anyone from Intel still around that could provide some insight into
> the 'native bridge tool'? Anyone know who we could contact to maybe
> get some more information? This would help out with some of the Vista
> issues I'm seeing in Swing as well.
>
>>
>> I will try to get an ubuntu 8.10 kvm image installed and have a look at =
this
>> problem but since awt/swing are not really a priority for me.
>>
>>> > Since it is not a regression, and apparently not caused by anything w=
e
>>> > can fix (unless we can find a workaround), I propose that we declare
>>> > it a "Non-Blocker" for M9.
>>
>> +1
>>
>>> I'm fine with that. Maybe indicate it is a known issue.
>>
>> 1+ =9AIt should be mentioned in the release notes.
>>
>> Regards,
>> =9AMark.
>>
>> [0] I think there are some modularity problems lurking here... I think
>> luni depends on the org.apache.harmony.misc.accessors which depends on
>> some native bridge code in awt. =9AI suspect the common native bridge
>> probably should be brought back in to the misc module.
>>
>>
>>
>


--=20
With best regards / =D3 =CE=C1=C9=CC=D5=DE=DB=C9=CD=C9 =D0=CF=D6=C5=CC=C1=
=CE=C9=D1=CD=C9,
Alexei Fedotov / =E1=CC=C5=CB=D3=C5=CA =E6=C5=C4=CF=D4=CF=D7,
http://www.telecom-express.ru/
http://people.apache.org/~aaf/