From yuri.nesterenko at oracle.com  Mon Sep  1 08:44:10 2014
From: yuri.nesterenko at oracle.com (Yuri Nesterenko)
Date: Mon, 01 Sep 2014 12:44:10 +0400
Subject: <Swing Dev> [9] Review Request for 8056991: Provide OSInfo
 functionality to regression tests
Message-ID: <540431DA.5090406@oracle.com>

Colleagues,

please review this minimal change to fix
https://bugs.openjdk.java.net/browse/JDK-8056991

http://cr.openjdk.java.net/~yan/8056991/webrev.00

In the webrev there is an example of a test refactored.

We need to clean up regression tests from internal
dependencies. One of them, dependency on sun.awt.OSInfo.java, a
standard (however internal) tool to provide a version
of current OS.
Here, I'm just copying the file to a test helper directory.
(1) no swing library class depending on OSInfo will be affected
(2) no public API change occurs
A person updating sun.awt.OSInfo in future should, however,
duplicate changes in this test copy as well which is an ugly
compromise.

Thanks,
-yan


From pavel.porvatov at oracle.com  Wed Sep  3 10:25:58 2014
From: pavel.porvatov at oracle.com (pavel porvatov)
Date: Wed, 03 Sep 2014 14:25:58 +0400
Subject: <Swing Dev> New SWING Group Lead: Alexander Scherbatiy
Message-ID: <5406ECB6.4090107@oracle.com>

I hereby nominate Alexander Scherbatiy to SWING Group Lead [1].

Alexander has been working in Swing group for several years and now he does the most significant job 
in the group.

Votes are due by September 17, 2014.

Only current Members of the SWING Group [2] are eligible to
vote on this nomination.  Votes must be cast in the open by
replying to this mailing list.

For Simple Majority voting instructions, see [3].

Pavel Porvatov

[1]: http://openjdk.java.net/bylaws#group-lead
[2]: http://openjdk.java.net/census
[3]: http://openjdk.java.net/groups#lead-vote


From pavel.porvatov at oracle.com  Wed Sep  3 10:37:28 2014
From: pavel.porvatov at oracle.com (pavel porvatov)
Date: Wed, 03 Sep 2014 14:37:28 +0400
Subject: <Swing Dev> New SWING Group Lead: Alexander Scherbatiy
In-Reply-To: <5406ECB6.4090107@oracle.com>
References: <5406ECB6.4090107@oracle.com>
Message-ID: <5406EF68.4060701@oracle.com>

Vote: yes

On 9/3/2014 2:25 PM, pavel porvatov wrote:
> I hereby nominate Alexander Scherbatiy to SWING Group Lead [1].
>
> Alexander has been working in Swing group for several years and now he does the most significant job
> in the group.
>
> Votes are due by September 17, 2014.
>
> Only current Members of the SWING Group [2] are eligible to
> vote on this nomination.  Votes must be cast in the open by
> replying to this mailing list.
>
> For Simple Majority voting instructions, see [3].
>
> Pavel Porvatov
>
> [1]: http://openjdk.java.net/bylaws#group-lead
> [2]: http://openjdk.java.net/census
> [3]: http://openjdk.java.net/groups#lead-vote


From petr.pchelko at oracle.com  Wed Sep  3 10:38:28 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Wed, 3 Sep 2014 14:38:28 +0400
Subject: <Swing Dev> New SWING Group Lead: Alexander Scherbatiy
In-Reply-To: <5406EF68.4060701@oracle.com>
References: <5406ECB6.4090107@oracle.com> <5406EF68.4060701@oracle.com>
Message-ID: <4F31F6E1-35D0-4CA3-8A56-0A644D927154@oracle.com>

Vote: YES.

With best regards. Petr.

> On Sep 3, 2014, at 2:37 PM, pavel porvatov <pavel.porvatov at oracle.com> wrote:
> 
> Vote: yes
> 
> On 9/3/2014 2:25 PM, pavel porvatov wrote:
>> I hereby nominate Alexander Scherbatiy to SWING Group Lead [1].
>> 
>> Alexander has been working in Swing group for several years and now he does the most significant job
>> in the group.
>> 
>> Votes are due by September 17, 2014.
>> 
>> Only current Members of the SWING Group [2] are eligible to
>> vote on this nomination.  Votes must be cast in the open by
>> replying to this mailing list.
>> 
>> For Simple Majority voting instructions, see [3].
>> 
>> Pavel Porvatov
>> 
>> [1]: http://openjdk.java.net/bylaws#group-lead
>> [2]: http://openjdk.java.net/census
>> [3]: http://openjdk.java.net/groups#lead-vote



From leonid.popov at oracle.com  Wed Sep  3 10:43:15 2014
From: leonid.popov at oracle.com (Leonid Popov)
Date: Wed, 03 Sep 2014 14:43:15 +0400
Subject: <Swing Dev> New SWING Group Lead: Alexander Scherbatiy
In-Reply-To: <5406ECB6.4090107@oracle.com>
References: <5406ECB6.4090107@oracle.com>
Message-ID: <5406F0C3.4020403@oracle.com>

Vote: yes

On 9/3/2014 2:25 PM, pavel porvatov wrote:
> I hereby nominate Alexander Scherbatiy to SWING Group Lead [1].
>
> Alexander has been working in Swing group for several years and now he 
> does the most significant job in the group.
>
> Votes are due by September 17, 2014.
>
> Only current Members of the SWING Group [2] are eligible to
> vote on this nomination.  Votes must be cast in the open by
> replying to this mailing list.
>
> For Simple Majority voting instructions, see [3].
>
> Pavel Porvatov
>
> [1]: http://openjdk.java.net/bylaws#group-lead
> [2]: http://openjdk.java.net/census
> [3]: http://openjdk.java.net/groups#lead-vote

-- 
-- Thanks, Leonid



From kirill.kirichenko at oracle.com  Thu Sep  4 09:34:17 2014
From: kirill.kirichenko at oracle.com (Kirill Kirichenko)
Date: Thu, 04 Sep 2014 13:34:17 +0400
Subject: <Swing Dev>  New SWING Group Lead: Alexander Scherbatiy
Message-ID: <54083219.9030800@oracle.com>

Vote: yes


From alexandr.scherbatiy at oracle.com  Thu Sep  4 11:29:26 2014
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Thu, 04 Sep 2014 15:29:26 +0400
Subject: <Swing Dev> [9] Review request for 8057184 JCK8's
 api/javax_swing/JDesktopPane/descriptions.html#getset failed with
 GTKLookAndFeel on Linux and Solaris run v.s. JDK8+
Message-ID: <54084D16.6070405@oracle.com>


Hello,

Could you review the fix:
   bug: https://bugs.openjdk.java.net/browse/JDK-8057184
   webrev: http://cr.openjdk.java.net/~alexsch/8057184/webrev.00

   The fix skips the same internal frames from the 
JDesktopPane.getAllFrames() results.

Thanks,
Alexandr.



From alexander.zvegintsev at oracle.com  Thu Sep  4 12:19:16 2014
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Thu, 04 Sep 2014 16:19:16 +0400
Subject: <Swing Dev> [9] Review request for 8057184 JCK8's
 api/javax_swing/JDesktopPane/descriptions.html#getset failed with
 GTKLookAndFeel on Linux and Solaris run v.s. JDK8+
In-Reply-To: <54084D16.6070405@oracle.com>
References: <54084D16.6070405@oracle.com>
Message-ID: <540858C4.1010906@oracle.com>

Hello Alexandr,

the fix looks good to me.

--
Thanks,
Alexander.

On 09/04/2014 03:29 PM, Alexander Scherbatiy wrote:
>
> Hello,
>
> Could you review the fix:
>   bug: https://bugs.openjdk.java.net/browse/JDK-8057184
>   webrev: http://cr.openjdk.java.net/~alexsch/8057184/webrev.00
>
>   The fix skips the same internal frames from the 
> JDesktopPane.getAllFrames() results.
>
> Thanks,
> Alexandr.
>



From anton.tarasov at oracle.com  Thu Sep  4 12:24:27 2014
From: anton.tarasov at oracle.com (Anton V. Tarasov)
Date: Thu, 04 Sep 2014 16:24:27 +0400
Subject: <Swing Dev> [9] Review request for 8057184 JCK8's
 api/javax_swing/JDesktopPane/descriptions.html#getset failed with
 GTKLookAndFeel on Linux and Solaris run v.s. JDK8+
In-Reply-To: <54084D16.6070405@oracle.com>
References: <54084D16.6070405@oracle.com>
Message-ID: <540859FB.5090502@oracle.com>

Hi Alexander,

Looks fine for me, however you could use HashSet instead of ArrayList in order to avoid the check 
for "contains".

Thanks,
Anton.

On 04.09.2014 15:29, Alexander Scherbatiy wrote:
>
> Hello,
>
> Could you review the fix:
>   bug: https://bugs.openjdk.java.net/browse/JDK-8057184
>   webrev: http://cr.openjdk.java.net/~alexsch/8057184/webrev.00
>
>   The fix skips the same internal frames from the JDesktopPane.getAllFrames() results.
>
> Thanks,
> Alexandr.
>



From alexandr.scherbatiy at oracle.com  Thu Sep  4 13:32:00 2014
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Thu, 04 Sep 2014 17:32:00 +0400
Subject: <Swing Dev> [9] Review request for 8057184 JCK8's
 api/javax_swing/JDesktopPane/descriptions.html#getset failed with
 GTKLookAndFeel on Linux and Solaris run v.s. JDK8+
In-Reply-To: <540859FB.5090502@oracle.com>
References: <54084D16.6070405@oracle.com> <540859FB.5090502@oracle.com>
Message-ID: <540869D0.6090600@oracle.com>

On 9/4/2014 4:24 PM, Anton V. Tarasov wrote:
> Hi Alexander,
>
> Looks fine for me, however you could use HashSet instead of ArrayList 
> in order to avoid the check for "contains".
>
  Could you review the updated fix:
   http://cr.openjdk.java.net/~alexsch/8057184/webrev.01

   I changed the ArrayList to LinkedHashSet just to preserve the order 
of added internal frames.
   The javadoc does not require it but it preserves the previous behavior.

   Thanks,
   Alexandr.

> Thanks,
> Anton.
>
> On 04.09.2014 15:29, Alexander Scherbatiy wrote:
>>
>> Hello,
>>
>> Could you review the fix:
>>   bug: https://bugs.openjdk.java.net/browse/JDK-8057184
>>   webrev: http://cr.openjdk.java.net/~alexsch/8057184/webrev.00
>>
>>   The fix skips the same internal frames from the 
>> JDesktopPane.getAllFrames() results.
>>
>> Thanks,
>> Alexandr.
>>
>



From anton.tarasov at oracle.com  Thu Sep  4 13:54:51 2014
From: anton.tarasov at oracle.com (Anton V. Tarasov)
Date: Thu, 04 Sep 2014 17:54:51 +0400
Subject: <Swing Dev> [9] Review request for 8057184 JCK8's
 api/javax_swing/JDesktopPane/descriptions.html#getset failed with
 GTKLookAndFeel on Linux and Solaris run v.s. JDK8+
In-Reply-To: <540869D0.6090600@oracle.com>
References: <54084D16.6070405@oracle.com> <540859FB.5090502@oracle.com>
	<540869D0.6090600@oracle.com>
Message-ID: <54086F2B.4030109@oracle.com>

That's fine now!

Thanks,
Anton.

On 04.09.2014 17:32, Alexander Scherbatiy wrote:
> On 9/4/2014 4:24 PM, Anton V. Tarasov wrote:
>> Hi Alexander,
>>
>> Looks fine for me, however you could use HashSet instead of ArrayList in order to avoid the check 
>> for "contains".
>>
>  Could you review the updated fix:
>   http://cr.openjdk.java.net/~alexsch/8057184/webrev.01
>
>   I changed the ArrayList to LinkedHashSet just to preserve the order of added internal frames.
>   The javadoc does not require it but it preserves the previous behavior.
>
>   Thanks,
>   Alexandr.
>
>> Thanks,
>> Anton.
>>
>> On 04.09.2014 15:29, Alexander Scherbatiy wrote:
>>>
>>> Hello,
>>>
>>> Could you review the fix:
>>>   bug: https://bugs.openjdk.java.net/browse/JDK-8057184
>>>   webrev: http://cr.openjdk.java.net/~alexsch/8057184/webrev.00
>>>
>>>   The fix skips the same internal frames from the JDesktopPane.getAllFrames() results.
>>>
>>> Thanks,
>>> Alexandr.
>>>
>>
>



From alexander.zvegintsev at oracle.com  Thu Sep  4 14:02:21 2014
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Thu, 04 Sep 2014 18:02:21 +0400
Subject: <Swing Dev> [9] Review request for 8057184 JCK8's
 api/javax_swing/JDesktopPane/descriptions.html#getset failed with
 GTKLookAndFeel on Linux and Solaris run v.s. JDK8+
In-Reply-To: <54086F2B.4030109@oracle.com>
References: <54084D16.6070405@oracle.com>
	<540859FB.5090502@oracle.com>	<540869D0.6090600@oracle.com>
	<54086F2B.4030109@oracle.com>
Message-ID: <540870ED.10007@oracle.com>

looks fine to me too.

--
Thanks,
Alexander.

On 09/04/2014 05:54 PM, Anton V. Tarasov wrote:
> That's fine now!
>
> Thanks,
> Anton.
>
> On 04.09.2014 17:32, Alexander Scherbatiy wrote:
>> On 9/4/2014 4:24 PM, Anton V. Tarasov wrote:
>>> Hi Alexander,
>>>
>>> Looks fine for me, however you could use HashSet instead of 
>>> ArrayList in order to avoid the check for "contains".
>>>
>>  Could you review the updated fix:
>>   http://cr.openjdk.java.net/~alexsch/8057184/webrev.01
>>
>>   I changed the ArrayList to LinkedHashSet just to preserve the order 
>> of added internal frames.
>>   The javadoc does not require it but it preserves the previous 
>> behavior.
>>
>>   Thanks,
>>   Alexandr.
>>
>>> Thanks,
>>> Anton.
>>>
>>> On 04.09.2014 15:29, Alexander Scherbatiy wrote:
>>>>
>>>> Hello,
>>>>
>>>> Could you review the fix:
>>>>   bug: https://bugs.openjdk.java.net/browse/JDK-8057184
>>>>   webrev: http://cr.openjdk.java.net/~alexsch/8057184/webrev.00
>>>>
>>>>   The fix skips the same internal frames from the 
>>>> JDesktopPane.getAllFrames() results.
>>>>
>>>> Thanks,
>>>> Alexandr.
>>>>
>>>
>>
>



From vivi.an at oracle.com  Thu Sep  4 18:56:41 2014
From: vivi.an at oracle.com (Vivi An)
Date: Thu, 04 Sep 2014 11:56:41 -0700
Subject: <Swing Dev> [9] Review request for 8033699: Incorrect radio button
 behavior
Message-ID: <5408B5E9.6080901@oracle.com>

Hello,

Please review fix for JDK-8033699.  Changes made:
1) When tab or shift-tab key pressed,  focus moved to next/previous
component outside of the radio button group
2) Using up/down or left/right arrow key to change selection inside
radio button group

Bug:https://bugs.openjdk.java.net/browse/JDK-8033699
Webrev:http://cr.openjdk.java.net/~van/8033699/webrev.00/

JPRT build succeeded, JCK tests for JRadiobutton and JCheckBox all passed.

Thank you

Regards,

Vivi



From yuri.nesterenko at oracle.com  Mon Sep  8 09:09:39 2014
From: yuri.nesterenko at oracle.com (Yuri Nesterenko)
Date: Mon, 08 Sep 2014 13:09:39 +0400
Subject: <Swing Dev> [9] Review Request for 8056991: Provide OSInfo
 functionality to regression tests
In-Reply-To: <540431DA.5090406@oracle.com>
References: <540431DA.5090406@oracle.com>
Message-ID: <540D7253.7090403@oracle.com>

Weekly reminder!

Cheers,
-yan

On 09/01/2014 12:44 PM, Yuri Nesterenko wrote:
> Colleagues,
>
> please review this minimal change to fix
> https://bugs.openjdk.java.net/browse/JDK-8056991
>
> http://cr.openjdk.java.net/~yan/8056991/webrev.00
>
> In the webrev there is an example of a test refactored.
>
> We need to clean up regression tests from internal
> dependencies. One of them, dependency on sun.awt.OSInfo.java, a
> standard (however internal) tool to provide a version
> of current OS.
> Here, I'm just copying the file to a test helper directory.
> (1) no swing library class depending on OSInfo will be affected
> (2) no public API change occurs
> A person updating sun.awt.OSInfo in future should, however,
> duplicate changes in this test copy as well which is an ugly
> compromise.
>
> Thanks,
> -yan



From pavel.porvatov at oracle.com  Mon Sep  8 10:29:29 2014
From: pavel.porvatov at oracle.com (pavel porvatov)
Date: Mon, 08 Sep 2014 14:29:29 +0400
Subject: <Swing Dev> Resignation as SWING Group Lead
Message-ID: <540D8509.3030301@oracle.com>

Hi,

I'm working in another group now, and therefore at this time, I wish to resign as SWING Group Lead.

I proposed Alexander Scherbatiy as a new SWING Group Lead in another mail.

Regards, Pavel


From dmitry.markov at oracle.com  Mon Sep  8 10:39:20 2014
From: dmitry.markov at oracle.com (dmitry markov)
Date: Mon, 08 Sep 2014 14:39:20 +0400
Subject: <Swing Dev> [9] Review request for 8048110: Using tables in
 JTextPane leads to infinite loop in FlowLayout.layoutRow
In-Reply-To: <53FDB686.1070006@oracle.com>
References: <50d74d59-9ebb-4c8b-8e8f-1f4e17bf1074@default>
	<53F1B4FA.4080009@oracle.com> <53F5B5FB.9070702@oracle.com>
	<53FC5B49.90801@oracle.com> <53FDB686.1070006@oracle.com>
Message-ID: <540D8758.7010305@oracle.com>

Friendly reminder

Thanks,
Dmitry
On 27/08/2014 14:44, dmitry markov wrote:
> Hello Alexandr,
>
> Thank you for the review. I have updated the fix according to your 
> comments. Please find new version here - 
> http://cr.openjdk.java.net/~dmarkov/8048110/jdk9/webrev.02/
> Now FlowView.forwardUpdate() invokes super.forwardUpdate() to update 
> the view responsible for the changed element and then sends update 
> event to the GlyphViews followed by the changed place. It updates the 
> GlyphViews regardless the type of the first view. Also new views are 
> not updated twice anymore.
>
> Thanks,
> Dmitry
> On 26/08/2014 14:02, Alexander Scherbatiy wrote:
>>
>>   - The fix sends an update event to all views followed by the 
>> changed place only if the first updated view is GlyphView.
>>     Should the GlyphViews be updated if the first view is not the 
>> GlyphView?
>>
>>   - The javadoc for forwardUpdate() methods says: "If there were 
>> changes to the element this view is responsible for, that should be 
>> considered when forwarding (i.e. new child views should not get 
>> notified)."
>>     Does it mean that new views will be updated twice first in the 
>> FlowView.forwardUpdate()  method and second during initialization?
>>
>>   Thanks,
>>   Alexandr.
>>
>> On 8/21/2014 1:03 PM, dmitry markov wrote:
>>> Hello,
>>>
>>> Reminder. Could you review this, please?
>>>
>>> Thanks,
>>> Dmitry
>>> On 18/08/2014 12:10, dmitry markov wrote:
>>>> Hello Sergey,
>>>>
>>>> LogicalView.forwardUpdate() sends update event to all views 
>>>> followed by the changed place. This event will cause view to drop 
>>>> the cache and re-calculate its break points. This method was added 
>>>> under JDK-8024395 
>>>> <https://bugs.openjdk.java.net/browse/JDK-8024395> and intended for 
>>>> the documents contained only text elements. The current 
>>>> implementation does not expect that non-text element, (e.g. a 
>>>> table) can be added to the document.
>>>> If the table is added to the document with flow layout, the 
>>>> invocation of LogicalView.forwardUpdate() will produce some 
>>>> negative visual effects (table will be displayed several times). In 
>>>> case of replacing the text by the table the situation much worse, 
>>>> since the FlowView will try to re-layout the removed text and hangs.
>>>>
>>>> We have to send the update events to all instances of GlyphView 
>>>> followed by changed place for proper text line breaks calculation, 
>>>> see JDK-8024395 <https://bugs.openjdk.java.net/browse/JDK-8024395>, 
>>>> JDK-8014863 <https://bugs.openjdk.java.net/browse/JDK-8014863>. 
>>>> That's why I added checks for GlyphView instance. I understand this 
>>>> might be not a good place, but only here we have information about 
>>>> all views in the document and can forward update to them, if any.
>>>> Please note another approach to solve the problems with line breaks 
>>>> calculation - re-calculate break spots any time when a view is laid 
>>>> out. As far as I know it is used in jdk6, but this solution is not 
>>>> suitable, since it causes serious performance problems in case of 
>>>> large documents.
>>>>
>>>> Also I have updated the fix. New version - 
>>>> http://cr.openjdk.java.net/~dmarkov/8048110/jdk9/webrev.01/
>>>> Now LogicalView.forwardUpdate() sends update only to GlyphView 
>>>> followed by the changed place. This resolves the problem when the 
>>>> table is located in the middle of the text line.
>>>>
>>>> Thanks,
>>>> Dmitry
>>>>
>>>> On 15/08/2014 12:56, Sergey Bylokhov wrote:
>>>>> Hello, Dmitry.
>>>>>>> The LogicalView.forwardUpdate() should send an update event to 
>>>>>>> the views
>>>>>>> followed by the changed place, only when an instance of 
>>>>>>> GlyphView has
>>>>>>> changed; otherwise it should invoke View.forwardUpdate() to 
>>>>>>> handle the
>>>>>>> update properly.
>>>>> Can you share additional information about the fix. Why 
>>>>> LogicalView should send an update if GlyphView was changed only. 
>>>>> Because before the fix LocalView knows nothing about GlyphView.
>>>>>
>>>>> Thanks,
>>>>> Dmitry
>>>>
>>>
>>
>



From alexandr.scherbatiy at oracle.com  Mon Sep  8 10:44:56 2014
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Mon, 08 Sep 2014 14:44:56 +0400
Subject: <Swing Dev> [9] Review request for 8048110: Using tables in
 JTextPane leads to infinite loop in FlowLayout.layoutRow
In-Reply-To: <53FDB686.1070006@oracle.com>
References: <50d74d59-9ebb-4c8b-8e8f-1f4e17bf1074@default>
	<53F1B4FA.4080009@oracle.com> <53F5B5FB.9070702@oracle.com>
	<53FC5B49.90801@oracle.com> <53FDB686.1070006@oracle.com>
Message-ID: <540D88A8.5070005@oracle.com>

On 8/27/2014 2:44 PM, dmitry markov wrote:
> Hello Alexandr,
>
> Thank you for the review. I have updated the fix according to your 
> comments. Please find new version here - 
> http://cr.openjdk.java.net/~dmarkov/8048110/jdk9/webrev.02/
> Now FlowView.forwardUpdate() invokes super.forwardUpdate() to update 
> the view responsible for the changed element and then sends update 
> event to the GlyphViews followed by the changed place. It updates the 
> GlyphViews regardless the type of the first view. Also new views are 
> not updated twice anymore.

    The FlowView checks directly the type of a view in the 
forwardUpdate() method. May be it is better to add method 
updateAfterChange() with package access to View which does nothing by 
default and update elements for  GlyphView?

   Thanks,
   Alexandr.

>
> Thanks,
> Dmitry
> On 26/08/2014 14:02, Alexander Scherbatiy wrote:
>>
>>   - The fix sends an update event to all views followed by the 
>> changed place only if the first updated view is GlyphView.
>>     Should the GlyphViews be updated if the first view is not the 
>> GlyphView?
>>
>>   - The javadoc for forwardUpdate() methods says: "If there were 
>> changes to the element this view is responsible for, that should be 
>> considered when forwarding (i.e. new child views should not get 
>> notified)."
>>     Does it mean that new views will be updated twice first in the 
>> FlowView.forwardUpdate()  method and second during initialization?
>>
>>   Thanks,
>>   Alexandr.
>>
>> On 8/21/2014 1:03 PM, dmitry markov wrote:
>>> Hello,
>>>
>>> Reminder. Could you review this, please?
>>>
>>> Thanks,
>>> Dmitry
>>> On 18/08/2014 12:10, dmitry markov wrote:
>>>> Hello Sergey,
>>>>
>>>> LogicalView.forwardUpdate() sends update event to all views 
>>>> followed by the changed place. This event will cause view to drop 
>>>> the cache and re-calculate its break points. This method was added 
>>>> under JDK-8024395 
>>>> <https://bugs.openjdk.java.net/browse/JDK-8024395> and intended for 
>>>> the documents contained only text elements. The current 
>>>> implementation does not expect that non-text element, (e.g. a 
>>>> table) can be added to the document.
>>>> If the table is added to the document with flow layout, the 
>>>> invocation of LogicalView.forwardUpdate() will produce some 
>>>> negative visual effects (table will be displayed several times). In 
>>>> case of replacing the text by the table the situation much worse, 
>>>> since the FlowView will try to re-layout the removed text and hangs.
>>>>
>>>> We have to send the update events to all instances of GlyphView 
>>>> followed by changed place for proper text line breaks calculation, 
>>>> see JDK-8024395 <https://bugs.openjdk.java.net/browse/JDK-8024395>, 
>>>> JDK-8014863 <https://bugs.openjdk.java.net/browse/JDK-8014863>. 
>>>> That's why I added checks for GlyphView instance. I understand this 
>>>> might be not a good place, but only here we have information about 
>>>> all views in the document and can forward update to them, if any.
>>>> Please note another approach to solve the problems with line breaks 
>>>> calculation - re-calculate break spots any time when a view is laid 
>>>> out. As far as I know it is used in jdk6, but this solution is not 
>>>> suitable, since it causes serious performance problems in case of 
>>>> large documents.
>>>>
>>>> Also I have updated the fix. New version - 
>>>> http://cr.openjdk.java.net/~dmarkov/8048110/jdk9/webrev.01/
>>>> Now LogicalView.forwardUpdate() sends update only to GlyphView 
>>>> followed by the changed place. This resolves the problem when the 
>>>> table is located in the middle of the text line.
>>>>
>>>> Thanks,
>>>> Dmitry
>>>>
>>>> On 15/08/2014 12:56, Sergey Bylokhov wrote:
>>>>> Hello, Dmitry.
>>>>>>> The LogicalView.forwardUpdate() should send an update event to 
>>>>>>> the views
>>>>>>> followed by the changed place, only when an instance of 
>>>>>>> GlyphView has
>>>>>>> changed; otherwise it should invoke View.forwardUpdate() to 
>>>>>>> handle the
>>>>>>> update properly.
>>>>> Can you share additional information about the fix. Why 
>>>>> LogicalView should send an update if GlyphView was changed only. 
>>>>> Because before the fix LocalView knows nothing about GlyphView.
>>>>>
>>>>> Thanks,
>>>>> Dmitry
>>>>
>>>
>>
>



From alexandr.scherbatiy at oracle.com  Mon Sep  8 12:43:59 2014
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Mon, 08 Sep 2014 16:43:59 +0400
Subject: <Swing Dev> [9] Review request for 8033699: Incorrect radio
 button behavior
In-Reply-To: <5408B5E9.6080901@oracle.com>
References: <5408B5E9.6080901@oracle.com>
Message-ID: <540DA48F.2020409@oracle.com>

On 9/4/2014 10:56 PM, Vivi An wrote:
> Hello,
>
> Please review fix for JDK-8033699.  Changes made:
> 1) When tab or shift-tab key pressed,  focus moved to next/previous
> component outside of the radio button group
> 2) Using up/down or left/right arrow key to change selection inside
> radio button group
>
> Bug:https://bugs.openjdk.java.net/browse/JDK-8033699
> Webrev:http://cr.openjdk.java.net/~van/8033699/webrev.00/

   56     private KeyListener keyListener = null;
   57     private KeyHandler handler = null;

It seems that these both fields point to the same object. Is it possible 
to get rid of one of them?


  152         if ( keyListener != null ) {
  153             button.removeKeyListener( keyListener );
  154         }

Some UIs also set the listener to null in the 
uninstallUI()/uninstallListeners() methods (like BasicComboBoxUI or 
BasicColorChooserUI).
Should the keyListener also be set to null to free the KeyHandler object?

  369         if (!(eventSrc instanceof JRadioButton &&
  370             ((JRadioButton) eventSrc).isVisible() && 
((JRadioButton) eventSrc).isEnabled()))

This check is used several times. It can be moved to a separate method.

  373         // Get the button model from the source.
  374         ButtonModel model = ((AbstractButton) eventSrc).getModel();
  375         if (!(model instanceof DefaultButtonModel))
  376             return;
  377
  378         // If the button model is DefaultButtonModel, and use it, 
otherwise return.
  379         DefaultButtonModel bm = (DefaultButtonModel) model;
  380         if (bm == null)
  381             return;

The second check is not necessary because (model instanceof 
DefaultButtonModel) returns false for null model.


  404         AbstractButton curElement = null;

   The curElement variable declaration could be moved into the 'while' 
block.


  408             if (curElement instanceof JRadioButton &&
  409                     ((JRadioButton) curElement).isVisible() &&
  410                     ((JRadioButton) curElement).isEnabled()){

   It is possible to use 'continue' here to not put the other code 
inside the 'if' block.


  418                 else if (!srcFound){
  422                 } else if (srcFound && nextBtn == null){

It is not necessary to check the srcFound in the second 'if' because it 
should already have true value.


  444             if (newSelectedBtn != null){
  445                 newSelectedBtn.requestFocusInWindow();
  446                 newSelectedBtn.setSelected(true);
  447             }


Is it possible here that newSelectedBtn == eventSrc?

  522         private void jumpToNextComponent(JRadioButton btn, boolean 
next){

The code that retrieves elements from a button group is also used in the 
selectRadioButton()
and can be moved to a separate method.

Thanks,
Alexandr.

>
> JPRT build succeeded, JCK tests for JRadiobutton and JCheckBox all 
> passed.
>
> Thank you
>
> Regards,
>
> Vivi
>



From alexandr.scherbatiy at oracle.com  Mon Sep  8 13:56:22 2014
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Mon, 08 Sep 2014 17:56:22 +0400
Subject: <Swing Dev> CFV: New Swing Group Member: Alexander Zvegintsev
Message-ID: <540DB586.1000608@oracle.com>


I hereby nominate Alexander Zvegintsev (OpenJDK user name: azvegint) to 
Membership in the Swing Group.

Alexander has contributed some changes in Swing, which are a part of JDK 9.
Here is the list of fixes:

http://hg.openjdk.java.net/jdk9/client/jdk/log?rev=zvegint&revcount=100

Votes are due by Sep 23, 2014.

Only current Members of the Swing  Group [1] are eligible
to vote on this nomination.

For Lazy Consensus voting instructions, see [2].

Thanks,
Alexandr.

[1] http://openjdk.java.net/census#swing
[2] http://openjdk.java.net/groups/#member-vote



From artem.ananiev at oracle.com  Mon Sep  8 14:27:31 2014
From: artem.ananiev at oracle.com (Artem Ananiev)
Date: Mon, 08 Sep 2014 18:27:31 +0400
Subject: <Swing Dev> CFV: New Swing Group Member: Alexander Zvegintsev
In-Reply-To: <540DB586.1000608@oracle.com>
References: <540DB586.1000608@oracle.com>
Message-ID: <540DBCD3.4020907@oracle.com>


Vote: yes

Artem

On 9/8/2014 5:56 PM, Alexander Scherbatiy wrote:
>
> I hereby nominate Alexander Zvegintsev (OpenJDK user name: azvegint) to
> Membership in the Swing Group.
>
> Alexander has contributed some changes in Swing, which are a part of JDK 9.
> Here is the list of fixes:
>
> http://hg.openjdk.java.net/jdk9/client/jdk/log?rev=zvegint&revcount=100
>
> Votes are due by Sep 23, 2014.
>
> Only current Members of the Swing  Group [1] are eligible
> to vote on this nomination.
>
> For Lazy Consensus voting instructions, see [2].
>
> Thanks,
> Alexandr.
>
> [1] http://openjdk.java.net/census#swing
> [2] http://openjdk.java.net/groups/#member-vote
>


From Sergey.Bylokhov at oracle.com  Mon Sep  8 17:49:23 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 08 Sep 2014 21:49:23 +0400
Subject: <Swing Dev> [9] Review Request: 8057819 No CCC approving removing
 final modifier from
 javax.swing.SwingUtilities.isRectangleContainingRectangle static method
Message-ID: <540DEC23.2060705@oracle.com>

Hello.
Please review the small fix for jdk 9.
Part of the JDK-8046595 was reverted.

Bug: https://bugs.openjdk.java.net/browse/JDK-8057819
Webrev can be found at: http://cr.openjdk.java.net/~serb/8057819/webrev.00

-- 
Best regards, Sergey.



From alexandr.scherbatiy at oracle.com  Tue Sep  9 08:47:47 2014
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Tue, 09 Sep 2014 12:47:47 +0400
Subject: <Swing Dev> [9] Review Request: 8057819 No CCC approving
 removing final modifier from
 javax.swing.SwingUtilities.isRectangleContainingRectangle static method
In-Reply-To: <540DEC23.2060705@oracle.com>
References: <540DEC23.2060705@oracle.com>
Message-ID: <540EBEB3.1030502@oracle.com>


   The fix looks good to me.

   Thanks,
   Alexandr.

On 9/8/2014 9:49 PM, Sergey Bylokhov wrote:
> Hello.
> Please review the small fix for jdk 9.
> Part of the JDK-8046595 was reverted.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8057819
> Webrev can be found at: 
> http://cr.openjdk.java.net/~serb/8057819/webrev.00
>



From alexander.zvegintsev at oracle.com  Tue Sep  9 09:38:05 2014
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Tue, 09 Sep 2014 13:38:05 +0400
Subject: <Swing Dev> [9] Review Request: 8057819 No CCC approving
 removing final modifier from
 javax.swing.SwingUtilities.isRectangleContainingRectangle static method
In-Reply-To: <540EBEB3.1030502@oracle.com>
References: <540DEC23.2060705@oracle.com> <540EBEB3.1030502@oracle.com>
Message-ID: <540ECA7D.2050004@oracle.com>

The fix looks good to me too.

Thanks,

Alexander.

On 09/09/2014 12:47 PM, Alexander Scherbatiy wrote:
>
>   The fix looks good to me.
>
>   Thanks,
>   Alexandr.
>
> On 9/8/2014 9:49 PM, Sergey Bylokhov wrote:
>> Hello.
>> Please review the small fix for jdk 9.
>> Part of the JDK-8046595 was reverted.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8057819
>> Webrev can be found at: 
>> http://cr.openjdk.java.net/~serb/8057819/webrev.00
>>
>



From dmitry.markov at oracle.com  Tue Sep  9 09:53:13 2014
From: dmitry.markov at oracle.com (dmitry markov)
Date: Tue, 09 Sep 2014 13:53:13 +0400
Subject: <Swing Dev> [9] Review request for 8048110: Using tables in
 JTextPane leads to infinite loop in FlowLayout.layoutRow
In-Reply-To: <540D88A8.5070005@oracle.com>
References: <50d74d59-9ebb-4c8b-8e8f-1f4e17bf1074@default>
	<53F1B4FA.4080009@oracle.com> <53F5B5FB.9070702@oracle.com>
	<53FC5B49.90801@oracle.com> <53FDB686.1070006@oracle.com>
	<540D88A8.5070005@oracle.com>
Message-ID: <540ECE09.8060705@oracle.com>

Hi Alexandr,

I have added updateAfterChange() method as you suggested. New version is 
located at http://cr.openjdk.java.net/~dmarkov/8048110/jdk9/webrev.03/

Thanks,
Dmitry
On 08/09/2014 14:44, Alexander Scherbatiy wrote:
> On 8/27/2014 2:44 PM, dmitry markov wrote:
>> Hello Alexandr,
>>
>> Thank you for the review. I have updated the fix according to your 
>> comments. Please find new version here - 
>> http://cr.openjdk.java.net/~dmarkov/8048110/jdk9/webrev.02/
>> Now FlowView.forwardUpdate() invokes super.forwardUpdate() to update 
>> the view responsible for the changed element and then sends update 
>> event to the GlyphViews followed by the changed place. It updates the 
>> GlyphViews regardless the type of the first view. Also new views are 
>> not updated twice anymore.
>
>    The FlowView checks directly the type of a view in the 
> forwardUpdate() method. May be it is better to add method 
> updateAfterChange() with package access to View which does nothing by 
> default and update elements for  GlyphView?
>
>   Thanks,
>   Alexandr.
>
>>
>> Thanks,
>> Dmitry
>> On 26/08/2014 14:02, Alexander Scherbatiy wrote:
>>>
>>>   - The fix sends an update event to all views followed by the 
>>> changed place only if the first updated view is GlyphView.
>>>     Should the GlyphViews be updated if the first view is not the 
>>> GlyphView?
>>>
>>>   - The javadoc for forwardUpdate() methods says: "If there were 
>>> changes to the element this view is responsible for, that should be 
>>> considered when forwarding (i.e. new child views should not get 
>>> notified)."
>>>     Does it mean that new views will be updated twice first in the 
>>> FlowView.forwardUpdate()  method and second during initialization?
>>>
>>>   Thanks,
>>>   Alexandr.
>>>
>>> On 8/21/2014 1:03 PM, dmitry markov wrote:
>>>> Hello,
>>>>
>>>> Reminder. Could you review this, please?
>>>>
>>>> Thanks,
>>>> Dmitry
>>>> On 18/08/2014 12:10, dmitry markov wrote:
>>>>> Hello Sergey,
>>>>>
>>>>> LogicalView.forwardUpdate() sends update event to all views 
>>>>> followed by the changed place. This event will cause view to drop 
>>>>> the cache and re-calculate its break points. This method was added 
>>>>> under JDK-8024395 
>>>>> <https://bugs.openjdk.java.net/browse/JDK-8024395> and intended 
>>>>> for the documents contained only text elements. The current 
>>>>> implementation does not expect that non-text element, (e.g. a 
>>>>> table) can be added to the document.
>>>>> If the table is added to the document with flow layout, the 
>>>>> invocation of LogicalView.forwardUpdate() will produce some 
>>>>> negative visual effects (table will be displayed several times). 
>>>>> In case of replacing the text by the table the situation much 
>>>>> worse, since the FlowView will try to re-layout the removed text 
>>>>> and hangs.
>>>>>
>>>>> We have to send the update events to all instances of GlyphView 
>>>>> followed by changed place for proper text line breaks calculation, 
>>>>> see JDK-8024395 
>>>>> <https://bugs.openjdk.java.net/browse/JDK-8024395>, JDK-8014863 
>>>>> <https://bugs.openjdk.java.net/browse/JDK-8014863>. That's why I 
>>>>> added checks for GlyphView instance. I understand this might be 
>>>>> not a good place, but only here we have information about all 
>>>>> views in the document and can forward update to them, if any.
>>>>> Please note another approach to solve the problems with line 
>>>>> breaks calculation - re-calculate break spots any time when a view 
>>>>> is laid out. As far as I know it is used in jdk6, but this 
>>>>> solution is not suitable, since it causes serious performance 
>>>>> problems in case of large documents.
>>>>>
>>>>> Also I have updated the fix. New version - 
>>>>> http://cr.openjdk.java.net/~dmarkov/8048110/jdk9/webrev.01/
>>>>> Now LogicalView.forwardUpdate() sends update only to GlyphView 
>>>>> followed by the changed place. This resolves the problem when the 
>>>>> table is located in the middle of the text line.
>>>>>
>>>>> Thanks,
>>>>> Dmitry
>>>>>
>>>>> On 15/08/2014 12:56, Sergey Bylokhov wrote:
>>>>>> Hello, Dmitry.
>>>>>>>> The LogicalView.forwardUpdate() should send an update event to 
>>>>>>>> the views
>>>>>>>> followed by the changed place, only when an instance of 
>>>>>>>> GlyphView has
>>>>>>>> changed; otherwise it should invoke View.forwardUpdate() to 
>>>>>>>> handle the
>>>>>>>> update properly.
>>>>>> Can you share additional information about the fix. Why 
>>>>>> LogicalView should send an update if GlyphView was changed only. 
>>>>>> Because before the fix LocalView knows nothing about GlyphView.
>>>>>>
>>>>>> Thanks,
>>>>>> Dmitry
>>>>>
>>>>
>>>
>>
>



From alexandr.scherbatiy at oracle.com  Tue Sep  9 10:26:24 2014
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Tue, 09 Sep 2014 14:26:24 +0400
Subject: <Swing Dev> [9] Review request for 8048110: Using tables in
 JTextPane leads to infinite loop in FlowLayout.layoutRow
In-Reply-To: <540ECE09.8060705@oracle.com>
References: <50d74d59-9ebb-4c8b-8e8f-1f4e17bf1074@default>
	<53F1B4FA.4080009@oracle.com> <53F5B5FB.9070702@oracle.com>
	<53FC5B49.90801@oracle.com> <53FDB686.1070006@oracle.com>
	<540D88A8.5070005@oracle.com> <540ECE09.8060705@oracle.com>
Message-ID: <540ED5D0.6000906@oracle.com>


   The fix looks good to me.

   Thanks,
   Alexandr.

On 9/9/2014 1:53 PM, dmitry markov wrote:
> Hi Alexandr,
>
> I have added updateAfterChange() method as you suggested. New version 
> is located at http://cr.openjdk.java.net/~dmarkov/8048110/jdk9/webrev.03/
>
> Thanks,
> Dmitry
> On 08/09/2014 14:44, Alexander Scherbatiy wrote:
>> On 8/27/2014 2:44 PM, dmitry markov wrote:
>>> Hello Alexandr,
>>>
>>> Thank you for the review. I have updated the fix according to your 
>>> comments. Please find new version here - 
>>> http://cr.openjdk.java.net/~dmarkov/8048110/jdk9/webrev.02/
>>> Now FlowView.forwardUpdate() invokes super.forwardUpdate() to update 
>>> the view responsible for the changed element and then sends update 
>>> event to the GlyphViews followed by the changed place. It updates 
>>> the GlyphViews regardless the type of the first view. Also new views 
>>> are not updated twice anymore.
>>
>>    The FlowView checks directly the type of a view in the 
>> forwardUpdate() method. May be it is better to add method 
>> updateAfterChange() with package access to View which does nothing by 
>> default and update elements for  GlyphView?
>>
>>   Thanks,
>>   Alexandr.
>>
>>>
>>> Thanks,
>>> Dmitry
>>> On 26/08/2014 14:02, Alexander Scherbatiy wrote:
>>>>
>>>>   - The fix sends an update event to all views followed by the 
>>>> changed place only if the first updated view is GlyphView.
>>>>     Should the GlyphViews be updated if the first view is not the 
>>>> GlyphView?
>>>>
>>>>   - The javadoc for forwardUpdate() methods says: "If there were 
>>>> changes to the element this view is responsible for, that should be 
>>>> considered when forwarding (i.e. new child views should not get 
>>>> notified)."
>>>>     Does it mean that new views will be updated twice first in the 
>>>> FlowView.forwardUpdate()  method and second during initialization?
>>>>
>>>>   Thanks,
>>>>   Alexandr.
>>>>
>>>> On 8/21/2014 1:03 PM, dmitry markov wrote:
>>>>> Hello,
>>>>>
>>>>> Reminder. Could you review this, please?
>>>>>
>>>>> Thanks,
>>>>> Dmitry
>>>>> On 18/08/2014 12:10, dmitry markov wrote:
>>>>>> Hello Sergey,
>>>>>>
>>>>>> LogicalView.forwardUpdate() sends update event to all views 
>>>>>> followed by the changed place. This event will cause view to drop 
>>>>>> the cache and re-calculate its break points. This method was 
>>>>>> added under JDK-8024395 
>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8024395> and intended 
>>>>>> for the documents contained only text elements. The current 
>>>>>> implementation does not expect that non-text element, (e.g. a 
>>>>>> table) can be added to the document.
>>>>>> If the table is added to the document with flow layout, the 
>>>>>> invocation of LogicalView.forwardUpdate() will produce some 
>>>>>> negative visual effects (table will be displayed several times). 
>>>>>> In case of replacing the text by the table the situation much 
>>>>>> worse, since the FlowView will try to re-layout the removed text 
>>>>>> and hangs.
>>>>>>
>>>>>> We have to send the update events to all instances of GlyphView 
>>>>>> followed by changed place for proper text line breaks 
>>>>>> calculation, see JDK-8024395 
>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8024395>, JDK-8014863 
>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8014863>. That's why I 
>>>>>> added checks for GlyphView instance. I understand this might be 
>>>>>> not a good place, but only here we have information about all 
>>>>>> views in the document and can forward update to them, if any.
>>>>>> Please note another approach to solve the problems with line 
>>>>>> breaks calculation - re-calculate break spots any time when a 
>>>>>> view is laid out. As far as I know it is used in jdk6, but this 
>>>>>> solution is not suitable, since it causes serious performance 
>>>>>> problems in case of large documents.
>>>>>>
>>>>>> Also I have updated the fix. New version - 
>>>>>> http://cr.openjdk.java.net/~dmarkov/8048110/jdk9/webrev.01/
>>>>>> Now LogicalView.forwardUpdate() sends update only to GlyphView 
>>>>>> followed by the changed place. This resolves the problem when the 
>>>>>> table is located in the middle of the text line.
>>>>>>
>>>>>> Thanks,
>>>>>> Dmitry
>>>>>>
>>>>>> On 15/08/2014 12:56, Sergey Bylokhov wrote:
>>>>>>> Hello, Dmitry.
>>>>>>>>> The LogicalView.forwardUpdate() should send an update event to 
>>>>>>>>> the views
>>>>>>>>> followed by the changed place, only when an instance of 
>>>>>>>>> GlyphView has
>>>>>>>>> changed; otherwise it should invoke View.forwardUpdate() to 
>>>>>>>>> handle the
>>>>>>>>> update properly.
>>>>>>> Can you share additional information about the fix. Why 
>>>>>>> LogicalView should send an update if GlyphView was changed only. 
>>>>>>> Because before the fix LocalView knows nothing about GlyphView.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Dmitry
>>>>>>
>>>>>
>>>>
>>>
>>
>



From alexander.zvegintsev at oracle.com  Tue Sep  9 10:51:19 2014
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Tue, 09 Sep 2014 14:51:19 +0400
Subject: <Swing Dev> [9] Review request for 8057770:
 api/javax_swing/JScrollPane/indexTGF.html#UpdateUI failed with
 MotifLookAndFeel on all platform
Message-ID: <540EDBA7.5080904@oracle.com>

Hello,

please review the fix
http://cr.openjdk.java.net/~azvegint/jdk/9/8057770/00/
for the issue
https://bugs.openjdk.java.net/browse/JDK-8057770

This  issue
MotifScrollPaneUI does not override uninstallListeners() method from 
BasicScrollPaneUI

It has following signature
protected void uninstallListeners(JScrollPane scrollPane)
but it should be
protected void uninstallListeners(JComponent c)

Hence listeners will never be deleted. This type of issues can be 
avoided by using @Override annotation.
Same issue fixed in XAWTScrollPaneUI.




-- 
Thanks,

Alexander.



From alexandr.scherbatiy at oracle.com  Tue Sep  9 11:30:58 2014
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Tue, 09 Sep 2014 15:30:58 +0400
Subject: <Swing Dev> [9] Review request for 8057770:
 api/javax_swing/JScrollPane/indexTGF.html#UpdateUI failed with
 MotifLookAndFeel on all platform
In-Reply-To: <540EDBA7.5080904@oracle.com>
References: <540EDBA7.5080904@oracle.com>
Message-ID: <540EE4F2.10007@oracle.com>


The fix looks good to me.

Thanks,
Alexandr.

On 9/9/2014 2:51 PM, Alexander Zvegintsev wrote:
> Hello,
>
> please review the fix
> http://cr.openjdk.java.net/~azvegint/jdk/9/8057770/00/
> for the issue
> https://bugs.openjdk.java.net/browse/JDK-8057770
>
> This  issue
> MotifScrollPaneUI does not override uninstallListeners() method from 
> BasicScrollPaneUI
>
> It has following signature
> protected void uninstallListeners(JScrollPane scrollPane)
> but it should be
> protected void uninstallListeners(JComponent c)
>
> Hence listeners will never be deleted. This type of issues can be 
> avoided by using @Override annotation.
> Same issue fixed in XAWTScrollPaneUI.
>
>
>
>



From Sergey.Bylokhov at oracle.com  Tue Sep  9 12:01:22 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 09 Sep 2014 16:01:22 +0400
Subject: <Swing Dev> [9] Review request for 8057770:
 api/javax_swing/JScrollPane/indexTGF.html#UpdateUI failed with
 MotifLookAndFeel on all platform
In-Reply-To: <540EDBA7.5080904@oracle.com>
References: <540EDBA7.5080904@oracle.com>
Message-ID: <540EEC12.20101@oracle.com>

Hi, Alexander.
The fix looks good.

On 09.09.2014 14:51, Alexander Zvegintsev wrote:
> Hello,
>
> please review the fix
> http://cr.openjdk.java.net/~azvegint/jdk/9/8057770/00/
> for the issue
> https://bugs.openjdk.java.net/browse/JDK-8057770
>
> This  issue
> MotifScrollPaneUI does not override uninstallListeners() method from 
> BasicScrollPaneUI
>
> It has following signature
> protected void uninstallListeners(JScrollPane scrollPane)
> but it should be
> protected void uninstallListeners(JComponent c)
>
> Hence listeners will never be deleted. This type of issues can be 
> avoided by using @Override annotation.
> Same issue fixed in XAWTScrollPaneUI.
>
>
>
>


-- 
Best regards, Sergey.



From Sergey.Bylokhov at oracle.com  Wed Sep 10 12:11:18 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 10 Sep 2014 16:11:18 +0400
Subject: <Swing Dev> [9] Review Request: 8055326 Fix typos in
	client-related packages
In-Reply-To: <53F634BB.7000905@oracle.com>
References: <53F62E90.90401@oracle.com> <53F634BB.7000905@oracle.com>
Message-ID: <54103FE6.5070104@oracle.com>

Hi, Phil.
It seems both changes are unnecessary:
http://cr.openjdk.java.net/~serb/8055326/webrev.01

On 21.08.2014 22:04, Phil Race wrote:
> Was the additional spce on the 2nd line intended here ?
>
> --- 
> old/src/java.desktop/share/classes/java/awt/ContainerOrderFocusTraversalPolicy.java 
> 2014-08-21 20:50:04.859532400 +0400
> +++ 
> new/src/java.desktop/share/classes/java/awt/ContainerOrderFocusTraversalPolicy.java 
> 2014-08-21 20:50:04.663521200 +0400
> @@ -166,8 +166,8 @@
>                      retComp = 
> cont.getFocusTraversalPolicy().getDefaultComponent(cont);
>
>                      if (retComp != null && 
> log.isLoggable(PlatformLogger.Level.FINE)) {
> -                        log.fine("### Transfered focus down-cycle to 
> " + retComp +
> -                                 " in the focus cycle root " + cont);
> +                        log.fine("### Transferred focus down-cycle to 
> " + retComp +
> +                                " in the focus cycle root " + cont);
>
>
> And I don't see what was so wrong with this, perhaps because I wrote 
> it :-)
>
> -         * so that when the Font2D is GC'd it can also remove the file.
> +         * so that when the Font2D is GC'ed it can also remove the file.
>
>
> Other than that, looks good.
> Some fun new words in there. I particularly liked utilitized and unclude.
>
> -phil.
>
> On 8/21/2014 10:38 AM, Sergey Bylokhov wrote:
>> Hello,
>> Please review the fix for jdk 9.
>> The fix was contributed by  pavel.rappo at oracle.com
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8055326
>> Webrev can be found at: 
>> http://cr.openjdk.java.net/~serb/8055326/webrev.00
>>
>


-- 
Best regards, Sergey.



From alexander.potochkin at oracle.com  Wed Sep 10 12:21:09 2014
From: alexander.potochkin at oracle.com (Alexander Potochkin)
Date: Wed, 10 Sep 2014 16:21:09 +0400
Subject: <Swing Dev> [9] Review request for 8048110: Using tables in
 JTextPane leads to infinite loop in FlowLayout.layoutRow
In-Reply-To: <540ECE09.8060705@oracle.com>
References: <50d74d59-9ebb-4c8b-8e8f-1f4e17bf1074@default>	<53F1B4FA.4080009@oracle.com>
	<53F5B5FB.9070702@oracle.com>	<53FC5B49.90801@oracle.com>
	<53FDB686.1070006@oracle.com>	<540D88A8.5070005@oracle.com>
	<540ECE09.8060705@oracle.com>
Message-ID: <54104235.20209@oracle.com>


looks good

Thanks
alexp

On 9/9/2014 1:53 PM, dmitry markov wrote:
> Hi Alexandr,
>
> I have added updateAfterChange() method as you suggested. New version 
> is located at http://cr.openjdk.java.net/~dmarkov/8048110/jdk9/webrev.03/
>
> Thanks,
> Dmitry
> On 08/09/2014 14:44, Alexander Scherbatiy wrote:
>> On 8/27/2014 2:44 PM, dmitry markov wrote:
>>> Hello Alexandr,
>>>
>>> Thank you for the review. I have updated the fix according to your 
>>> comments. Please find new version here - 
>>> http://cr.openjdk.java.net/~dmarkov/8048110/jdk9/webrev.02/
>>> Now FlowView.forwardUpdate() invokes super.forwardUpdate() to update 
>>> the view responsible for the changed element and then sends update 
>>> event to the GlyphViews followed by the changed place. It updates 
>>> the GlyphViews regardless the type of the first view. Also new views 
>>> are not updated twice anymore.
>>
>>    The FlowView checks directly the type of a view in the 
>> forwardUpdate() method. May be it is better to add method 
>> updateAfterChange() with package access to View which does nothing by 
>> default and update elements for  GlyphView?
>>
>>   Thanks,
>>   Alexandr.
>>
>>>
>>> Thanks,
>>> Dmitry
>>> On 26/08/2014 14:02, Alexander Scherbatiy wrote:
>>>>
>>>>   - The fix sends an update event to all views followed by the 
>>>> changed place only if the first updated view is GlyphView.
>>>>     Should the GlyphViews be updated if the first view is not the 
>>>> GlyphView?
>>>>
>>>>   - The javadoc for forwardUpdate() methods says: "If there were 
>>>> changes to the element this view is responsible for, that should be 
>>>> considered when forwarding (i.e. new child views should not get 
>>>> notified)."
>>>>     Does it mean that new views will be updated twice first in the 
>>>> FlowView.forwardUpdate()  method and second during initialization?
>>>>
>>>>   Thanks,
>>>>   Alexandr.
>>>>
>>>> On 8/21/2014 1:03 PM, dmitry markov wrote:
>>>>> Hello,
>>>>>
>>>>> Reminder. Could you review this, please?
>>>>>
>>>>> Thanks,
>>>>> Dmitry
>>>>> On 18/08/2014 12:10, dmitry markov wrote:
>>>>>> Hello Sergey,
>>>>>>
>>>>>> LogicalView.forwardUpdate() sends update event to all views 
>>>>>> followed by the changed place. This event will cause view to drop 
>>>>>> the cache and re-calculate its break points. This method was 
>>>>>> added under JDK-8024395 
>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8024395> and intended 
>>>>>> for the documents contained only text elements. The current 
>>>>>> implementation does not expect that non-text element, (e.g. a 
>>>>>> table) can be added to the document.
>>>>>> If the table is added to the document with flow layout, the 
>>>>>> invocation of LogicalView.forwardUpdate() will produce some 
>>>>>> negative visual effects (table will be displayed several times). 
>>>>>> In case of replacing the text by the table the situation much 
>>>>>> worse, since the FlowView will try to re-layout the removed text 
>>>>>> and hangs.
>>>>>>
>>>>>> We have to send the update events to all instances of GlyphView 
>>>>>> followed by changed place for proper text line breaks 
>>>>>> calculation, see JDK-8024395 
>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8024395>, JDK-8014863 
>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8014863>. That's why I 
>>>>>> added checks for GlyphView instance. I understand this might be 
>>>>>> not a good place, but only here we have information about all 
>>>>>> views in the document and can forward update to them, if any.
>>>>>> Please note another approach to solve the problems with line 
>>>>>> breaks calculation - re-calculate break spots any time when a 
>>>>>> view is laid out. As far as I know it is used in jdk6, but this 
>>>>>> solution is not suitable, since it causes serious performance 
>>>>>> problems in case of large documents.
>>>>>>
>>>>>> Also I have updated the fix. New version - 
>>>>>> http://cr.openjdk.java.net/~dmarkov/8048110/jdk9/webrev.01/
>>>>>> Now LogicalView.forwardUpdate() sends update only to GlyphView 
>>>>>> followed by the changed place. This resolves the problem when the 
>>>>>> table is located in the middle of the text line.
>>>>>>
>>>>>> Thanks,
>>>>>> Dmitry
>>>>>>
>>>>>> On 15/08/2014 12:56, Sergey Bylokhov wrote:
>>>>>>> Hello, Dmitry.
>>>>>>>>> The LogicalView.forwardUpdate() should send an update event to 
>>>>>>>>> the views
>>>>>>>>> followed by the changed place, only when an instance of 
>>>>>>>>> GlyphView has
>>>>>>>>> changed; otherwise it should invoke View.forwardUpdate() to 
>>>>>>>>> handle the
>>>>>>>>> update properly.
>>>>>>> Can you share additional information about the fix. Why 
>>>>>>> LogicalView should send an update if GlyphView was changed only. 
>>>>>>> Because before the fix LocalView knows nothing about GlyphView.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Dmitry
>>>>>>
>>>>>
>>>>
>>>
>>
>



From vivi.an at oracle.com  Wed Sep 10 22:56:31 2014
From: vivi.an at oracle.com (Vivi An)
Date: Wed, 10 Sep 2014 15:56:31 -0700
Subject: <Swing Dev> [9] Review request for 8033699: Incorrect radio
 button behavior
In-Reply-To: <540DA48F.2020409@oracle.com>
References: <5408B5E9.6080901@oracle.com> <540DA48F.2020409@oracle.com>
Message-ID: <5410D71F.3040405@oracle.com>

Hello Alexander,

Thanks for nice review, new patch is available as below:
webrev: http://cr.openjdk.java.net/~van/8033699/webrev.01/

Regards,

~ Vivi


On 9/8/2014 5:43 AM, Alexander Scherbatiy wrote:
> On 9/4/2014 10:56 PM, Vivi An wrote:
>> Hello,
>>
>> Please review fix for JDK-8033699.  Changes made:
>> 1) When tab or shift-tab key pressed,  focus moved to next/previous
>> component outside of the radio button group
>> 2) Using up/down or left/right arrow key to change selection inside
>> radio button group
>>
>> Bug:https://bugs.openjdk.java.net/browse/JDK-8033699
>> Webrev:http://cr.openjdk.java.net/~van/8033699/webrev.00/
>
>   56     private KeyListener keyListener = null;
>   57     private KeyHandler handler = null;
>
> It seems that these both fields point to the same object. Is it 
> possible to get rid of one of them?
>
>
>  152         if ( keyListener != null ) {
>  153             button.removeKeyListener( keyListener );
>  154         }
>
> Some UIs also set the listener to null in the 
> uninstallUI()/uninstallListeners() methods (like BasicComboBoxUI or 
> BasicColorChooserUI).
> Should the keyListener also be set to null to free the KeyHandler object?
>
>  369         if (!(eventSrc instanceof JRadioButton &&
>  370             ((JRadioButton) eventSrc).isVisible() && 
> ((JRadioButton) eventSrc).isEnabled()))
>
> This check is used several times. It can be moved to a separate method.
>
>  373         // Get the button model from the source.
>  374         ButtonModel model = ((AbstractButton) eventSrc).getModel();
>  375         if (!(model instanceof DefaultButtonModel))
>  376             return;
>  377
>  378         // If the button model is DefaultButtonModel, and use it, 
> otherwise return.
>  379         DefaultButtonModel bm = (DefaultButtonModel) model;
>  380         if (bm == null)
>  381             return;
>
> The second check is not necessary because (model instanceof 
> DefaultButtonModel) returns false for null model.
>
>
>  404         AbstractButton curElement = null;
>
>   The curElement variable declaration could be moved into the 'while' 
> block.
>
>
>  408             if (curElement instanceof JRadioButton &&
>  409                     ((JRadioButton) curElement).isVisible() &&
>  410                     ((JRadioButton) curElement).isEnabled()){
>
>   It is possible to use 'continue' here to not put the other code 
> inside the 'if' block.
>
>
>  418                 else if (!srcFound){
>  422                 } else if (srcFound && nextBtn == null){
>
> It is not necessary to check the srcFound in the second 'if' because 
> it should already have true value.
>
>
>  444             if (newSelectedBtn != null){
>  445                 newSelectedBtn.requestFocusInWindow();
>  446                 newSelectedBtn.setSelected(true);
>  447             }
>
>
> Is it possible here that newSelectedBtn == eventSrc?
>
>  522         private void jumpToNextComponent(JRadioButton btn, 
> boolean next){
>
> The code that retrieves elements from a button group is also used in 
> the selectRadioButton()
> and can be moved to a separate method.
>
> Thanks,
> Alexandr.
>
>>
>> JPRT build succeeded, JCK tests for JRadiobutton and JCheckBox all 
>> passed.
>>
>> Thank you
>>
>> Regards,
>>
>> Vivi
>>
>



From alexandr.scherbatiy at oracle.com  Thu Sep 11 10:21:34 2014
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Thu, 11 Sep 2014 14:21:34 +0400
Subject: <Swing Dev> [9] Review request for 8033699: Incorrect radio
 button behavior
In-Reply-To: <5410D71F.3040405@oracle.com>
References: <5408B5E9.6080901@oracle.com> <540DA48F.2020409@oracle.com>
	<5410D71F.3040405@oracle.com>
Message-ID: <541177AE.6040305@oracle.com>

On 9/11/2014 2:56 AM, Vivi An wrote:
> Hello Alexander,
>
> Thanks for nice review, new patch is available as below:
> webrev: http://cr.openjdk.java.net/~van/8033699/webrev.01/

  163         if ( keyListener != null ) {
  164             button.removeKeyListener( keyListener );

Could you formate the code in the brackets.

  355     private boolean isValidRadioButtonObj(Object obj){
  356         if ((obj != null) && (obj instanceof JRadioButton) &&

It is possible to use "return (obj != null) && ...".


  375         if (isValidRadioButtonObj(eventSrc) == false)

It is possible to use "if (!isValidRadioButtonObj(eventSrc))". The same 
is for line 466.


  379         btnGroupInfo.getButtonGroupInfo();
  380         if (btnGroupInfo.srcFound){
  ....

You can move this code to the ButtonGroupInfo class 
getNewSelectedButton(boolean next) method.
It allows to use variable names (previousBtn) instead of 
btnGroupInfo.previousBtn.

  391             if (newSelectedBtn != null &&
  392                 (newSelectedBtn != (JRadioButton) eventSrc)){

It is not necessary to cast the eventSrc to JRadioButton here.

  401     private class SelectPreviousBtn extends AbstractAction
  402     {

Could you move the bracket to the class declaration line?

  505                 if (isValidRadioButtonObj(eventSrc))
  506                     e.consume();
  507                 jumpToNextComponent((JRadioButton)eventSrc, true);

Line 507 is not under the condition. It means that eventSrc can have 
different type from JRadioButton.


  543             if (next && btnGroupInfo.lastBtn != null)
  544                 KeyboardFocusManager.
  545 
getCurrentKeyboardFocusManager().focusNextComponent((JComponent)btnGroupInfo.lastBtn);
  546             else if (btnGroupInfo.firstBtn != null)
  547                 KeyboardFocusManager.
  548 
getCurrentKeyboardFocusManager().focusPreviousComponent((JComponent)btnGroupInfo.firstBtn);
  549         }

Should the first button be focused If next is true and last button is null?

Thanks,
Alexandr.

>
> Regards,
>
> ~ Vivi
>
>
> On 9/8/2014 5:43 AM, Alexander Scherbatiy wrote:
>> On 9/4/2014 10:56 PM, Vivi An wrote:
>>> Hello,
>>>
>>> Please review fix for JDK-8033699.  Changes made:
>>> 1) When tab or shift-tab key pressed,  focus moved to next/previous
>>> component outside of the radio button group
>>> 2) Using up/down or left/right arrow key to change selection inside
>>> radio button group
>>>
>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8033699
>>> Webrev:http://cr.openjdk.java.net/~van/8033699/webrev.00/
>>
>>   56     private KeyListener keyListener = null;
>>   57     private KeyHandler handler = null;
>>
>> It seems that these both fields point to the same object. Is it 
>> possible to get rid of one of them?
>>
>>
>>  152         if ( keyListener != null ) {
>>  153             button.removeKeyListener( keyListener );
>>  154         }
>>
>> Some UIs also set the listener to null in the 
>> uninstallUI()/uninstallListeners() methods (like BasicComboBoxUI or 
>> BasicColorChooserUI).
>> Should the keyListener also be set to null to free the KeyHandler 
>> object?
>>
>>  369         if (!(eventSrc instanceof JRadioButton &&
>>  370             ((JRadioButton) eventSrc).isVisible() && 
>> ((JRadioButton) eventSrc).isEnabled()))
>>
>> This check is used several times. It can be moved to a separate method.
>>
>>  373         // Get the button model from the source.
>>  374         ButtonModel model = ((AbstractButton) eventSrc).getModel();
>>  375         if (!(model instanceof DefaultButtonModel))
>>  376             return;
>>  377
>>  378         // If the button model is DefaultButtonModel, and use 
>> it, otherwise return.
>>  379         DefaultButtonModel bm = (DefaultButtonModel) model;
>>  380         if (bm == null)
>>  381             return;
>>
>> The second check is not necessary because (model instanceof 
>> DefaultButtonModel) returns false for null model.
>>
>>
>>  404         AbstractButton curElement = null;
>>
>>   The curElement variable declaration could be moved into the 'while' 
>> block.
>>
>>
>>  408             if (curElement instanceof JRadioButton &&
>>  409                     ((JRadioButton) curElement).isVisible() &&
>>  410                     ((JRadioButton) curElement).isEnabled()){
>>
>>   It is possible to use 'continue' here to not put the other code 
>> inside the 'if' block.
>>
>>
>>  418                 else if (!srcFound){
>>  422                 } else if (srcFound && nextBtn == null){
>>
>> It is not necessary to check the srcFound in the second 'if' because 
>> it should already have true value.
>>
>>
>>  444             if (newSelectedBtn != null){
>>  445                 newSelectedBtn.requestFocusInWindow();
>>  446                 newSelectedBtn.setSelected(true);
>>  447             }
>>
>>
>> Is it possible here that newSelectedBtn == eventSrc?
>>
>>  522         private void jumpToNextComponent(JRadioButton btn, 
>> boolean next){
>>
>> The code that retrieves elements from a button group is also used in 
>> the selectRadioButton()
>> and can be moved to a separate method.
>>
>> Thanks,
>> Alexandr.
>>
>>>
>>> JPRT build succeeded, JCK tests for JRadiobutton and JCheckBox all 
>>> passed.
>>>
>>> Thank you
>>>
>>> Regards,
>>>
>>> Vivi
>>>
>>
>



From alexander.potochkin at oracle.com  Fri Sep 12 11:29:52 2014
From: alexander.potochkin at oracle.com (Alexander Potochkin)
Date: Fri, 12 Sep 2014 15:29:52 +0400
Subject: <Swing Dev> CFV: New Swing Group Member: Alexander Zvegintsev
In-Reply-To: <540DB586.1000608@oracle.com>
References: <540DB586.1000608@oracle.com>
Message-ID: <5412D930.7000500@oracle.com>

Vote: yes

alexp

On 9/8/2014 5:56 PM, Alexander Scherbatiy wrote:
>
> I hereby nominate Alexander Zvegintsev (OpenJDK user name: azvegint) 
> to Membership in the Swing Group.
>
> Alexander has contributed some changes in Swing, which are a part of 
> JDK 9.
> Here is the list of fixes:
>
> http://hg.openjdk.java.net/jdk9/client/jdk/log?rev=zvegint&revcount=100
>
> Votes are due by Sep 23, 2014.
>
> Only current Members of the Swing  Group [1] are eligible
> to vote on this nomination.
>
> For Lazy Consensus voting instructions, see [2].
>
> Thanks,
> Alexandr.
>
> [1] http://openjdk.java.net/census#swing
> [2] http://openjdk.java.net/groups/#member-vote
>



From kirill.kirichenko at oracle.com  Fri Sep 12 13:52:24 2014
From: kirill.kirichenko at oracle.com (Kirill Kirichenko)
Date: Fri, 12 Sep 2014 17:52:24 +0400
Subject: <Swing Dev> CFV: New Swing Group Member: Alexander Zvegintsev
Message-ID: <5412FA98.2000706@oracle.com>

Vote: yes


From pavel.porvatov at oracle.com  Fri Sep 12 14:15:03 2014
From: pavel.porvatov at oracle.com (pavel porvatov)
Date: Fri, 12 Sep 2014 18:15:03 +0400
Subject: <Swing Dev> CFV: New Swing Group Member: Alexander Zvegintsev
In-Reply-To: <540DB586.1000608@oracle.com>
References: <540DB586.1000608@oracle.com>
Message-ID: <5412FFE7.2080501@oracle.com>

Vote: yes

On 9/8/2014 5:56 PM, Alexander Scherbatiy wrote:
>
> I hereby nominate Alexander Zvegintsev (OpenJDK user name: azvegint) to Membership in the Swing Group.
>
> Alexander has contributed some changes in Swing, which are a part of JDK 9.
> Here is the list of fixes:
>
> http://hg.openjdk.java.net/jdk9/client/jdk/log?rev=zvegint&revcount=100
>
> Votes are due by Sep 23, 2014.
>
> Only current Members of the Swing  Group [1] are eligible
> to vote on this nomination.
>
> For Lazy Consensus voting instructions, see [2].
>
> Thanks,
> Alexandr.
>
> [1] http://openjdk.java.net/census#swing
> [2] http://openjdk.java.net/groups/#member-vote
>


From vivi.an at oracle.com  Fri Sep 12 16:56:37 2014
From: vivi.an at oracle.com (Vivi An)
Date: Fri, 12 Sep 2014 09:56:37 -0700
Subject: <Swing Dev> [9] Review request for 8033699: Incorrect radio
 button behavior
In-Reply-To: <541177AE.6040305@oracle.com>
References: <5408B5E9.6080901@oracle.com> <540DA48F.2020409@oracle.com>
	<5410D71F.3040405@oracle.com> <541177AE.6040305@oracle.com>
Message-ID: <541325C5.6040800@oracle.com>

Thanks Alexander.

All items addressed except last one, please see comments inline.
New Webrev: http://cr.openjdk.java.net/~van/8033699/webrev.02/

Regards,

Vivi

On 9/11/2014 3:21 AM, Alexander Scherbatiy wrote:
> On 9/11/2014 2:56 AM, Vivi An wrote:
>> Hello Alexander,
>>
>> Thanks for nice review, new patch is available as below:
>> webrev: http://cr.openjdk.java.net/~van/8033699/webrev.01/
>
>  163         if ( keyListener != null ) {
>  164             button.removeKeyListener( keyListener );
>
> Could you formate the code in the brackets.
>
>  355     private boolean isValidRadioButtonObj(Object obj){
>  356         if ((obj != null) && (obj instanceof JRadioButton) &&
>
> It is possible to use "return (obj != null) && ...".
>
>
>  375         if (isValidRadioButtonObj(eventSrc) == false)
>
> It is possible to use "if (!isValidRadioButtonObj(eventSrc))". The 
> same is for line 466.
>
>
>  379         btnGroupInfo.getButtonGroupInfo();
>  380         if (btnGroupInfo.srcFound){
>  ....
>
> You can move this code to the ButtonGroupInfo class 
> getNewSelectedButton(boolean next) method.
> It allows to use variable names (previousBtn) instead of 
> btnGroupInfo.previousBtn.
>
>  391             if (newSelectedBtn != null &&
>  392                 (newSelectedBtn != (JRadioButton) eventSrc)){
>
> It is not necessary to cast the eventSrc to JRadioButton here.
eventSrc is Object so still need to be casted, in 02version, the 
functionality encapsulated in ButtonGroupInfo class, so now using 
activeBtn, no need to cast in this case.

>  401 private class SelectPreviousBtn extends AbstractAction
>  402     {
>
> Could you move the bracket to the class declaration line?
>
>  505                 if (isValidRadioButtonObj(eventSrc))
>  506                     e.consume();
>  507                 jumpToNextComponent((JRadioButton)eventSrc, true);
>
> Line 507 is not under the condition. It means that eventSrc can have 
> different type from JRadioButton.
>
>
>  543             if (next && btnGroupInfo.lastBtn != null)
>  544                 KeyboardFocusManager.
>  545 
> getCurrentKeyboardFocusManager().focusNextComponent((JComponent)btnGroupInfo.lastBtn);
>  546             else if (btnGroupInfo.firstBtn != null)
>  547                 KeyboardFocusManager.
>  548 
> getCurrentKeyboardFocusManager().focusPreviousComponent((JComponent)btnGroupInfo.firstBtn);
>  549         }
>
> Should the first button be focused If next is true and last button is 
> null?
Don't think last button could be null when this function is triggered, 
last and first will always be set in case there is at least one valid 
(enabled and visible) radio button in the group.
>
> Thanks,
> Alexandr.
>
>>
>> Regards,
>>
>> ~ Vivi
>>
>>
>> On 9/8/2014 5:43 AM, Alexander Scherbatiy wrote:
>>> On 9/4/2014 10:56 PM, Vivi An wrote:
>>>> Hello,
>>>>
>>>> Please review fix for JDK-8033699.  Changes made:
>>>> 1) When tab or shift-tab key pressed,  focus moved to next/previous
>>>> component outside of the radio button group
>>>> 2) Using up/down or left/right arrow key to change selection inside
>>>> radio button group
>>>>
>>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8033699
>>>> Webrev:http://cr.openjdk.java.net/~van/8033699/webrev.00/
>>>
>>>   56     private KeyListener keyListener = null;
>>>   57     private KeyHandler handler = null;
>>>
>>> It seems that these both fields point to the same object. Is it 
>>> possible to get rid of one of them?
>>>
>>>
>>>  152         if ( keyListener != null ) {
>>>  153             button.removeKeyListener( keyListener );
>>>  154         }
>>>
>>> Some UIs also set the listener to null in the 
>>> uninstallUI()/uninstallListeners() methods (like BasicComboBoxUI or 
>>> BasicColorChooserUI).
>>> Should the keyListener also be set to null to free the KeyHandler 
>>> object?
>>>
>>>  369         if (!(eventSrc instanceof JRadioButton &&
>>>  370             ((JRadioButton) eventSrc).isVisible() && 
>>> ((JRadioButton) eventSrc).isEnabled()))
>>>
>>> This check is used several times. It can be moved to a separate method.
>>>
>>>  373         // Get the button model from the source.
>>>  374         ButtonModel model = ((AbstractButton) 
>>> eventSrc).getModel();
>>>  375         if (!(model instanceof DefaultButtonModel))
>>>  376             return;
>>>  377
>>>  378         // If the button model is DefaultButtonModel, and use 
>>> it, otherwise return.
>>>  379         DefaultButtonModel bm = (DefaultButtonModel) model;
>>>  380         if (bm == null)
>>>  381             return;
>>>
>>> The second check is not necessary because (model instanceof 
>>> DefaultButtonModel) returns false for null model.
>>>
>>>
>>>  404         AbstractButton curElement = null;
>>>
>>>   The curElement variable declaration could be moved into the 
>>> 'while' block.
>>>
>>>
>>>  408             if (curElement instanceof JRadioButton &&
>>>  409                     ((JRadioButton) curElement).isVisible() &&
>>>  410                     ((JRadioButton) curElement).isEnabled()){
>>>
>>>   It is possible to use 'continue' here to not put the other code 
>>> inside the 'if' block.
>>>
>>>
>>>  418                 else if (!srcFound){
>>>  422                 } else if (srcFound && nextBtn == null){
>>>
>>> It is not necessary to check the srcFound in the second 'if' because 
>>> it should already have true value.
>>>
>>>
>>>  444             if (newSelectedBtn != null){
>>>  445                 newSelectedBtn.requestFocusInWindow();
>>>  446                 newSelectedBtn.setSelected(true);
>>>  447             }
>>>
>>>
>>> Is it possible here that newSelectedBtn == eventSrc?
>>>
>>>  522         private void jumpToNextComponent(JRadioButton btn, 
>>> boolean next){
>>>
>>> The code that retrieves elements from a button group is also used in 
>>> the selectRadioButton()
>>> and can be moved to a separate method.
>>>
>>> Thanks,
>>> Alexandr.
>>>
>>>>
>>>> JPRT build succeeded, JCK tests for JRadiobutton and JCheckBox all 
>>>> passed.
>>>>
>>>> Thank you
>>>>
>>>> Regards,
>>>>
>>>> Vivi
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20140912/d688da7e/attachment.html>

From yuri.nesterenko at oracle.com  Mon Sep 15 07:35:30 2014
From: yuri.nesterenko at oracle.com (Yuri Nesterenko)
Date: Mon, 15 Sep 2014 11:35:30 +0400
Subject: <Swing Dev> <AWT Dev> [9] Review Request for 8056991: Provide
 OSInfo functionality to regression tests
In-Reply-To: <540D7253.7090403@oracle.com>
References: <540431DA.5090406@oracle.com> <540D7253.7090403@oracle.com>
Message-ID: <541696C2.6000302@oracle.com>

Dear friends, one more weekly reminder!
Without this (or similar) fix applied, we cannot start changes of
~60 regtests, and time is short.

Cheers,
-yan

On 09/08/2014 01:09 PM, Yuri Nesterenko wrote:
> Weekly reminder!
>
> Cheers,
> -yan
>
> On 09/01/2014 12:44 PM, Yuri Nesterenko wrote:
>> Colleagues,
>>
>> please review this minimal change to fix
>> https://bugs.openjdk.java.net/browse/JDK-8056991
>>
>> http://cr.openjdk.java.net/~yan/8056991/webrev.00
>>
>> In the webrev there is an example of a test refactored.
>>
>> We need to clean up regression tests from internal
>> dependencies. One of them, dependency on sun.awt.OSInfo.java, a
>> standard (however internal) tool to provide a version
>> of current OS.
>> Here, I'm just copying the file to a test helper directory.
>> (1) no swing library class depending on OSInfo will be affected
>> (2) no public API change occurs
>> A person updating sun.awt.OSInfo in future should, however,
>> duplicate changes in this test copy as well which is an ugly
>> compromise.
>>
>> Thanks,
>> -yan
>



From alexandr.scherbatiy at oracle.com  Mon Sep 15 09:59:59 2014
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Mon, 15 Sep 2014 13:59:59 +0400
Subject: <Swing Dev> [9] Review request for 8033699: Incorrect radio
 button behavior
In-Reply-To: <541325C5.6040800@oracle.com>
References: <5408B5E9.6080901@oracle.com> <540DA48F.2020409@oracle.com>
	<5410D71F.3040405@oracle.com> <541177AE.6040305@oracle.com>
	<541325C5.6040800@oracle.com>
Message-ID: <5416B89F.5040301@oracle.com>

On 9/12/2014 8:56 PM, Vivi An wrote:
> Thanks Alexander.
>
> All items addressed except last one, please see comments inline.
> New Webrev: http://cr.openjdk.java.net/~van/8033699/webrev.02/

     163         if ( keyListener != null ) {

     Could you remove spaces in the brackets? After code formatting it 
should be "if (keyListener != null) {"

>> 543             if (next && btnGroupInfo.lastBtn != null)
>>  544                 KeyboardFocusManager.
>>  545 
>> getCurrentKeyboardFocusManager().focusNextComponent((JComponent)btnGroupInfo.lastBtn);
>>  546             else if (btnGroupInfo.firstBtn != null)
>>  547                 KeyboardFocusManager.
>>  548 
>> getCurrentKeyboardFocusManager().focusPreviousComponent((JComponent)btnGroupInfo.firstBtn);
>>  549         }
>>
>> Should the first button be focused If next is true and last button is 
>> null?
> Don't think last button could be null when this function is triggered, 
> last and first will always be set in case there is at least one valid 
> (enabled and visible) radio button in the group.

   It seems that lastBtn != null and firstBtn != null checks are not 
necessary in this case.

   Thanks,
   Alexandr.

>>
>> Thanks,
>> Alexandr.
>>
>>>
>>> Regards,
>>>
>>> ~ Vivi
>>>
>>>
>>> On 9/8/2014 5:43 AM, Alexander Scherbatiy wrote:
>>>> On 9/4/2014 10:56 PM, Vivi An wrote:
>>>>> Hello,
>>>>>
>>>>> Please review fix for JDK-8033699.  Changes made:
>>>>> 1) When tab or shift-tab key pressed,  focus moved to next/previous
>>>>> component outside of the radio button group
>>>>> 2) Using up/down or left/right arrow key to change selection inside
>>>>> radio button group
>>>>>
>>>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8033699
>>>>> Webrev:http://cr.openjdk.java.net/~van/8033699/webrev.00/
>>>>
>>>>   56     private KeyListener keyListener = null;
>>>>   57     private KeyHandler handler = null;
>>>>
>>>> It seems that these both fields point to the same object. Is it 
>>>> possible to get rid of one of them?
>>>>
>>>>
>>>>  152         if ( keyListener != null ) {
>>>>  153             button.removeKeyListener( keyListener );
>>>>  154         }
>>>>
>>>> Some UIs also set the listener to null in the 
>>>> uninstallUI()/uninstallListeners() methods (like BasicComboBoxUI or 
>>>> BasicColorChooserUI).
>>>> Should the keyListener also be set to null to free the KeyHandler 
>>>> object?
>>>>
>>>>  369         if (!(eventSrc instanceof JRadioButton &&
>>>>  370             ((JRadioButton) eventSrc).isVisible() && 
>>>> ((JRadioButton) eventSrc).isEnabled()))
>>>>
>>>> This check is used several times. It can be moved to a separate 
>>>> method.
>>>>
>>>>  373         // Get the button model from the source.
>>>>  374         ButtonModel model = ((AbstractButton) 
>>>> eventSrc).getModel();
>>>>  375         if (!(model instanceof DefaultButtonModel))
>>>>  376             return;
>>>>  377
>>>>  378         // If the button model is DefaultButtonModel, and use 
>>>> it, otherwise return.
>>>>  379         DefaultButtonModel bm = (DefaultButtonModel) model;
>>>>  380         if (bm == null)
>>>>  381             return;
>>>>
>>>> The second check is not necessary because (model instanceof 
>>>> DefaultButtonModel) returns false for null model.
>>>>
>>>>
>>>>  404         AbstractButton curElement = null;
>>>>
>>>>   The curElement variable declaration could be moved into the 
>>>> 'while' block.
>>>>
>>>>
>>>>  408             if (curElement instanceof JRadioButton &&
>>>>  409                     ((JRadioButton) curElement).isVisible() &&
>>>>  410                     ((JRadioButton) curElement).isEnabled()){
>>>>
>>>>   It is possible to use 'continue' here to not put the other code 
>>>> inside the 'if' block.
>>>>
>>>>
>>>>  418                 else if (!srcFound){
>>>>  422                 } else if (srcFound && nextBtn == null){
>>>>
>>>> It is not necessary to check the srcFound in the second 'if' 
>>>> because it should already have true value.
>>>>
>>>>
>>>>  444             if (newSelectedBtn != null){
>>>>  445                 newSelectedBtn.requestFocusInWindow();
>>>>  446                 newSelectedBtn.setSelected(true);
>>>>  447             }
>>>>
>>>>
>>>> Is it possible here that newSelectedBtn == eventSrc?
>>>>
>>>>  522         private void jumpToNextComponent(JRadioButton btn, 
>>>> boolean next){
>>>>
>>>> The code that retrieves elements from a button group is also used 
>>>> in the selectRadioButton()
>>>> and can be moved to a separate method.
>>>>
>>>> Thanks,
>>>> Alexandr.
>>>>
>>>>>
>>>>> JPRT build succeeded, JCK tests for JRadiobutton and JCheckBox all 
>>>>> passed.
>>>>>
>>>>> Thank you
>>>>>
>>>>> Regards,
>>>>>
>>>>> Vivi
>>>>>
>>>>
>>>
>>
>



From alexandr.scherbatiy at oracle.com  Mon Sep 15 10:42:00 2014
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Mon, 15 Sep 2014 14:42:00 +0400
Subject: <Swing Dev> <AWT Dev> [9] Review Request for 8056991: Provide
 OSInfo functionality to regression tests
In-Reply-To: <541696C2.6000302@oracle.com>
References: <540431DA.5090406@oracle.com> <540D7253.7090403@oracle.com>
	<541696C2.6000302@oracle.com>
Message-ID: <5416C278.2040909@oracle.com>


test/lib/testlibrary/jdk/testlibrary/OSInfo.java
32 import static jdk.testlibrary.OSInfo.OSType.*;

Is this import necessary?

  115     public static PrivilegedAction<OSType> getOSTypeAction() {
  116         return osTypeAction;
  117     }

Is this method used in the tests?

Thanks,
Alexandr.

On 9/15/2014 11:35 AM, Yuri Nesterenko wrote:
> Dear friends, one more weekly reminder!
> Without this (or similar) fix applied, we cannot start changes of
> ~60 regtests, and time is short.
>
> Cheers,
> -yan
>
> On 09/08/2014 01:09 PM, Yuri Nesterenko wrote:
>> Weekly reminder!
>>
>> Cheers,
>> -yan
>>
>> On 09/01/2014 12:44 PM, Yuri Nesterenko wrote:
>>> Colleagues,
>>>
>>> please review this minimal change to fix
>>> https://bugs.openjdk.java.net/browse/JDK-8056991
>>>
>>> http://cr.openjdk.java.net/~yan/8056991/webrev.00
>>>
>>> In the webrev there is an example of a test refactored.
>>>
>>> We need to clean up regression tests from internal
>>> dependencies. One of them, dependency on sun.awt.OSInfo.java, a
>>> standard (however internal) tool to provide a version
>>> of current OS.
>>> Here, I'm just copying the file to a test helper directory.
>>> (1) no swing library class depending on OSInfo will be affected
>>> (2) no public API change occurs
>>> A person updating sun.awt.OSInfo in future should, however,
>>> duplicate changes in this test copy as well which is an ugly
>>> compromise.
>>>
>>> Thanks,
>>> -yan
>>
>



From yuri.nesterenko at oracle.com  Mon Sep 15 11:00:28 2014
From: yuri.nesterenko at oracle.com (Yuri Nesterenko)
Date: Mon, 15 Sep 2014 15:00:28 +0400
Subject: <Swing Dev> <AWT Dev> [9] Review Request for 8056991: Provide
 OSInfo functionality to regression tests
In-Reply-To: <5416C278.2040909@oracle.com>
References: <540431DA.5090406@oracle.com> <540D7253.7090403@oracle.com>
	<541696C2.6000302@oracle.com> <5416C278.2040909@oracle.com>
Message-ID: <5416C6CC.6090103@oracle.com>

On 09/15/2014 02:42 PM, Alexander Scherbatiy wrote:
>
> test/lib/testlibrary/jdk/testlibrary/OSInfo.java
> 32 import static jdk.testlibrary.OSInfo.OSType.*;
>
> Is this import necessary?
Yes: many tests use enum without qualification -- it's
short and presumably elegant. Without this import
usage like OSInfo.OSType.WINDOWS is necessary (see an
example of changed test in this webrev).

>
>   115     public static PrivilegedAction<OSType> getOSTypeAction() {
>   116         return osTypeAction;
>   117     }
>
> Is this method used in the tests?
Well, no. Almost never. This method of sun.awt.OSInfo is in use
in Swing classes.
I'm retaining it because (1) no harm in it and (2) this way,
it would be much simpler to maintain a duplicate of
sun.awt.OSInfo in case of a change.

-yan

>
> Thanks,
> Alexandr.
>
> On 9/15/2014 11:35 AM, Yuri Nesterenko wrote:
>> Dear friends, one more weekly reminder!
>> Without this (or similar) fix applied, we cannot start changes of
>> ~60 regtests, and time is short.
>>
>> Cheers,
>> -yan
>>
>> On 09/08/2014 01:09 PM, Yuri Nesterenko wrote:
>>> Weekly reminder!
>>>
>>> Cheers,
>>> -yan
>>>
>>> On 09/01/2014 12:44 PM, Yuri Nesterenko wrote:
>>>> Colleagues,
>>>>
>>>> please review this minimal change to fix
>>>> https://bugs.openjdk.java.net/browse/JDK-8056991
>>>>
>>>> http://cr.openjdk.java.net/~yan/8056991/webrev.00
>>>>
>>>> In the webrev there is an example of a test refactored.
>>>>
>>>> We need to clean up regression tests from internal
>>>> dependencies. One of them, dependency on sun.awt.OSInfo.java, a
>>>> standard (however internal) tool to provide a version
>>>> of current OS.
>>>> Here, I'm just copying the file to a test helper directory.
>>>> (1) no swing library class depending on OSInfo will be affected
>>>> (2) no public API change occurs
>>>> A person updating sun.awt.OSInfo in future should, however,
>>>> duplicate changes in this test copy as well which is an ugly
>>>> compromise.
>>>>
>>>> Thanks,
>>>> -yan
>>>
>>
>



From alexandr.scherbatiy at oracle.com  Mon Sep 15 11:13:21 2014
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Mon, 15 Sep 2014 15:13:21 +0400
Subject: <Swing Dev> <AWT Dev> [9] Review Request for 8056991: Provide
 OSInfo functionality to regression tests
In-Reply-To: <5416C6CC.6090103@oracle.com>
References: <540431DA.5090406@oracle.com> <540D7253.7090403@oracle.com>
	<541696C2.6000302@oracle.com> <5416C278.2040909@oracle.com>
	<5416C6CC.6090103@oracle.com>
Message-ID: <5416C9D1.8030108@oracle.com>


   The fix looks good to me.

  Thanks,
  Alexandr.

On 9/15/2014 3:00 PM, Yuri Nesterenko wrote:
> On 09/15/2014 02:42 PM, Alexander Scherbatiy wrote:
>>
>> test/lib/testlibrary/jdk/testlibrary/OSInfo.java
>> 32 import static jdk.testlibrary.OSInfo.OSType.*;
>>
>> Is this import necessary?
> Yes: many tests use enum without qualification -- it's
> short and presumably elegant. Without this import
> usage like OSInfo.OSType.WINDOWS is necessary (see an
> example of changed test in this webrev).
>
>>
>>   115     public static PrivilegedAction<OSType> getOSTypeAction() {
>>   116         return osTypeAction;
>>   117     }
>>
>> Is this method used in the tests?
> Well, no. Almost never. This method of sun.awt.OSInfo is in use
> in Swing classes.
> I'm retaining it because (1) no harm in it and (2) this way,
> it would be much simpler to maintain a duplicate of
> sun.awt.OSInfo in case of a change.
>
> -yan
>
>>
>> Thanks,
>> Alexandr.
>>
>> On 9/15/2014 11:35 AM, Yuri Nesterenko wrote:
>>> Dear friends, one more weekly reminder!
>>> Without this (or similar) fix applied, we cannot start changes of
>>> ~60 regtests, and time is short.
>>>
>>> Cheers,
>>> -yan
>>>
>>> On 09/08/2014 01:09 PM, Yuri Nesterenko wrote:
>>>> Weekly reminder!
>>>>
>>>> Cheers,
>>>> -yan
>>>>
>>>> On 09/01/2014 12:44 PM, Yuri Nesterenko wrote:
>>>>> Colleagues,
>>>>>
>>>>> please review this minimal change to fix
>>>>> https://bugs.openjdk.java.net/browse/JDK-8056991
>>>>>
>>>>> http://cr.openjdk.java.net/~yan/8056991/webrev.00
>>>>>
>>>>> In the webrev there is an example of a test refactored.
>>>>>
>>>>> We need to clean up regression tests from internal
>>>>> dependencies. One of them, dependency on sun.awt.OSInfo.java, a
>>>>> standard (however internal) tool to provide a version
>>>>> of current OS.
>>>>> Here, I'm just copying the file to a test helper directory.
>>>>> (1) no swing library class depending on OSInfo will be affected
>>>>> (2) no public API change occurs
>>>>> A person updating sun.awt.OSInfo in future should, however,
>>>>> duplicate changes in this test copy as well which is an ugly
>>>>> compromise.
>>>>>
>>>>> Thanks,
>>>>> -yan
>>>>
>>>
>>
>



From yuri.nesterenko at oracle.com  Mon Sep 15 11:21:00 2014
From: yuri.nesterenko at oracle.com (Yuri Nesterenko)
Date: Mon, 15 Sep 2014 15:21:00 +0400
Subject: <Swing Dev> <AWT Dev> [9] Review Request for 8056991: Provide
 OSInfo functionality to regression tests
In-Reply-To: <5416C9D1.8030108@oracle.com>
References: <540431DA.5090406@oracle.com> <540D7253.7090403@oracle.com>
	<541696C2.6000302@oracle.com> <5416C278.2040909@oracle.com>
	<5416C6CC.6090103@oracle.com> <5416C9D1.8030108@oracle.com>
Message-ID: <5416CB9C.7070108@oracle.com>

Thank you Alexander!

I hope I may push it with your single review:
the change is in test area and seems virtually harmless.

Cheers,
-yan

On 09/15/2014 03:13 PM, Alexander Scherbatiy wrote:
>
>    The fix looks good to me.
>
>   Thanks,
>   Alexandr.
>
> On 9/15/2014 3:00 PM, Yuri Nesterenko wrote:
>> On 09/15/2014 02:42 PM, Alexander Scherbatiy wrote:
>>>
>>> test/lib/testlibrary/jdk/testlibrary/OSInfo.java
>>> 32 import static jdk.testlibrary.OSInfo.OSType.*;
>>>
>>> Is this import necessary?
>> Yes: many tests use enum without qualification -- it's
>> short and presumably elegant. Without this import
>> usage like OSInfo.OSType.WINDOWS is necessary (see an
>> example of changed test in this webrev).
>>
>>>
>>>   115     public static PrivilegedAction<OSType> getOSTypeAction() {
>>>   116         return osTypeAction;
>>>   117     }
>>>
>>> Is this method used in the tests?
>> Well, no. Almost never. This method of sun.awt.OSInfo is in use
>> in Swing classes.
>> I'm retaining it because (1) no harm in it and (2) this way,
>> it would be much simpler to maintain a duplicate of
>> sun.awt.OSInfo in case of a change.
>>
>> -yan
>>
>>>
>>> Thanks,
>>> Alexandr.
>>>
>>> On 9/15/2014 11:35 AM, Yuri Nesterenko wrote:
>>>> Dear friends, one more weekly reminder!
>>>> Without this (or similar) fix applied, we cannot start changes of
>>>> ~60 regtests, and time is short.
>>>>
>>>> Cheers,
>>>> -yan
>>>>
>>>> On 09/08/2014 01:09 PM, Yuri Nesterenko wrote:
>>>>> Weekly reminder!
>>>>>
>>>>> Cheers,
>>>>> -yan
>>>>>
>>>>> On 09/01/2014 12:44 PM, Yuri Nesterenko wrote:
>>>>>> Colleagues,
>>>>>>
>>>>>> please review this minimal change to fix
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8056991
>>>>>>
>>>>>> http://cr.openjdk.java.net/~yan/8056991/webrev.00
>>>>>>
>>>>>> In the webrev there is an example of a test refactored.
>>>>>>
>>>>>> We need to clean up regression tests from internal
>>>>>> dependencies. One of them, dependency on sun.awt.OSInfo.java, a
>>>>>> standard (however internal) tool to provide a version
>>>>>> of current OS.
>>>>>> Here, I'm just copying the file to a test helper directory.
>>>>>> (1) no swing library class depending on OSInfo will be affected
>>>>>> (2) no public API change occurs
>>>>>> A person updating sun.awt.OSInfo in future should, however,
>>>>>> duplicate changes in this test copy as well which is an ugly
>>>>>> compromise.
>>>>>>
>>>>>> Thanks,
>>>>>> -yan
>>>>>
>>>>
>>>
>>
>



From alexandr.scherbatiy at oracle.com  Mon Sep 15 14:17:48 2014
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Mon, 15 Sep 2014 18:17:48 +0400
Subject: <Swing Dev> [9] Review Request: 8055326 Fix typos in
	client-related packages
In-Reply-To: <54103FE6.5070104@oracle.com>
References: <53F62E90.90401@oracle.com> <53F634BB.7000905@oracle.com>
	<54103FE6.5070104@oracle.com>
Message-ID: <5416F50C.3020706@oracle.com>


   The fix looks good to me.

   Thanks,
   Alexandr.

On 9/10/2014 4:11 PM, Sergey Bylokhov wrote:
> Hi, Phil.
> It seems both changes are unnecessary:
> http://cr.openjdk.java.net/~serb/8055326/webrev.01
>
> On 21.08.2014 22:04, Phil Race wrote:
>> Was the additional spce on the 2nd line intended here ?
>>
>> --- 
>> old/src/java.desktop/share/classes/java/awt/ContainerOrderFocusTraversalPolicy.java 
>> 2014-08-21 20:50:04.859532400 +0400
>> +++ 
>> new/src/java.desktop/share/classes/java/awt/ContainerOrderFocusTraversalPolicy.java 
>> 2014-08-21 20:50:04.663521200 +0400
>> @@ -166,8 +166,8 @@
>>                      retComp = 
>> cont.getFocusTraversalPolicy().getDefaultComponent(cont);
>>
>>                      if (retComp != null && 
>> log.isLoggable(PlatformLogger.Level.FINE)) {
>> -                        log.fine("### Transfered focus down-cycle to 
>> " + retComp +
>> -                                 " in the focus cycle root " + cont);
>> +                        log.fine("### Transferred focus down-cycle 
>> to " + retComp +
>> +                                " in the focus cycle root " + cont);
>>
>>
>> And I don't see what was so wrong with this, perhaps because I wrote 
>> it :-)
>>
>> -         * so that when the Font2D is GC'd it can also remove the file.
>> +         * so that when the Font2D is GC'ed it can also remove the 
>> file.
>>
>>
>> Other than that, looks good.
>> Some fun new words in there. I particularly liked utilitized and 
>> unclude.
>>
>> -phil.
>>
>> On 8/21/2014 10:38 AM, Sergey Bylokhov wrote:
>>> Hello,
>>> Please review the fix for jdk 9.
>>> The fix was contributed by  pavel.rappo at oracle.com
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8055326
>>> Webrev can be found at: 
>>> http://cr.openjdk.java.net/~serb/8055326/webrev.00
>>>
>>
>
>



From alexander.zvegintsev at oracle.com  Mon Sep 15 15:37:29 2014
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Mon, 15 Sep 2014 19:37:29 +0400
Subject: <Swing Dev> [9] Review Request: 8055326 Fix typos in
	client-related packages
In-Reply-To: <54103FE6.5070104@oracle.com>
References: <53F62E90.90401@oracle.com> <53F634BB.7000905@oracle.com>
	<54103FE6.5070104@oracle.com>
Message-ID: <541707B9.2040908@oracle.com>

Hello Sergey,

The fix looks good to me in general, but I have a few comments:

It would be nice to add @Override annotation to 
java.awt.Window.adjustDescendantsOnParent()

--- old/src/java.desktop/share/classes/java/awt/Component.java	2014-09-10 15:11:22.601342000 +0400
+++ new/src/java.desktop/share/classes/java/awt/Component.java	2014-09-10 15:11:21.809727900 +0400
@@ -781,11 +781,12 @@
           */
          OTHER
      }
  
      /*
-     * The shape set with the applyCompoundShape() method. It uncludes the result
+     * The shape set with the applyCompoundShape() method. It includes the
+     * result
       * of the HW/LW mixing related shape computation. It may also include
       * the user-specified shape of the component.
       * The 'null' value means the component has normal shape (or has no shape at all)
       * and applyCompoundShape() will skip the following shape identical to normal.
       */

I think that result should not be at the next line. (80 chars per line 
limit already violated a few lines below
so changing only one line does not make any sense to me).


java/awt/Component.java "bootstrap class loader" vs 
java/awt/GraphicsEnvironment.java "bootstrap classloader"
I think that we should choose and use only one title.


This may be irrelevant to this issue, but after grepping sources for 
"Scirpt" usage I've found similar typo in CSS.java:
./java/awt/font/NumericShaper.java:92: * 
EnumSet.of(NumericShaper.Scirpt.ARABIC, NumericShaper.Range.TAMIL)
./javax/swing/text/html/CSS.java:879:         * If the vertical 
alignment is set to either superscirpt or


BTW,  I like the idea of advertisement in source code :) :
java/awt/image/ColorModel.java
             // algorithm for linear RGB to nonlinear sRGB conversion
             // is from the IEC 61966-2-1 International Standard,
             // Colour Management - Default RGB colour space - sRGB,
             // First Edition, 1999-10,
             // available for order at http://www.iec.ch

Thanks,

Alexander.

On 09/10/2014 04:11 PM, Sergey Bylokhov wrote:
> Hi, Phil.
> It seems both changes are unnecessary:
> http://cr.openjdk.java.net/~serb/8055326/webrev.01
>
> On 21.08.2014 22:04, Phil Race wrote:
>> Was the additional spce on the 2nd line intended here ?
>>
>> --- 
>> old/src/java.desktop/share/classes/java/awt/ContainerOrderFocusTraversalPolicy.java 
>> 2014-08-21 20:50:04.859532400 +0400
>> +++ 
>> new/src/java.desktop/share/classes/java/awt/ContainerOrderFocusTraversalPolicy.java 
>> 2014-08-21 20:50:04.663521200 +0400
>> @@ -166,8 +166,8 @@
>>                      retComp = 
>> cont.getFocusTraversalPolicy().getDefaultComponent(cont);
>>
>>                      if (retComp != null && 
>> log.isLoggable(PlatformLogger.Level.FINE)) {
>> -                        log.fine("### Transfered focus down-cycle to 
>> " + retComp +
>> -                                 " in the focus cycle root " + cont);
>> +                        log.fine("### Transferred focus down-cycle 
>> to " + retComp +
>> +                                " in the focus cycle root " + cont);
>>
>>
>> And I don't see what was so wrong with this, perhaps because I wrote 
>> it :-)
>>
>> -         * so that when the Font2D is GC'd it can also remove the file.
>> +         * so that when the Font2D is GC'ed it can also remove the 
>> file.
>>
>>
>> Other than that, looks good.
>> Some fun new words in there. I particularly liked utilitized and 
>> unclude.
>>
>> -phil.
>>
>> On 8/21/2014 10:38 AM, Sergey Bylokhov wrote:
>>> Hello,
>>> Please review the fix for jdk 9.
>>> The fix was contributed by  pavel.rappo at oracle.com
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8055326
>>> Webrev can be found at: 
>>> http://cr.openjdk.java.net/~serb/8055326/webrev.00
>>>
>>
>
>



From philip.race at oracle.com  Mon Sep 15 15:51:23 2014
From: philip.race at oracle.com (Phil Race)
Date: Mon, 15 Sep 2014 08:51:23 -0700
Subject: <Swing Dev> [9] Review Request: 8055326 Fix typos in
	client-related packages
In-Reply-To: <54103FE6.5070104@oracle.com>
References: <53F62E90.90401@oracle.com> <53F634BB.7000905@oracle.com>
	<54103FE6.5070104@oracle.com>
Message-ID: <54170AFB.8080000@oracle.com>

approved.

-phil.

On 9/10/2014 5:11 AM, Sergey Bylokhov wrote:
> Hi, Phil.
> It seems both changes are unnecessary:
> http://cr.openjdk.java.net/~serb/8055326/webrev.01
>
> On 21.08.2014 22:04, Phil Race wrote:
>> Was the additional spce on the 2nd line intended here ?
>>
>> --- 
>> old/src/java.desktop/share/classes/java/awt/ContainerOrderFocusTraversalPolicy.java 
>> 2014-08-21 20:50:04.859532400 +0400
>> +++ 
>> new/src/java.desktop/share/classes/java/awt/ContainerOrderFocusTraversalPolicy.java 
>> 2014-08-21 20:50:04.663521200 +0400
>> @@ -166,8 +166,8 @@
>>                      retComp = 
>> cont.getFocusTraversalPolicy().getDefaultComponent(cont);
>>
>>                      if (retComp != null && 
>> log.isLoggable(PlatformLogger.Level.FINE)) {
>> -                        log.fine("### Transfered focus down-cycle to 
>> " + retComp +
>> -                                 " in the focus cycle root " + cont);
>> +                        log.fine("### Transferred focus down-cycle 
>> to " + retComp +
>> +                                " in the focus cycle root " + cont);
>>
>>
>> And I don't see what was so wrong with this, perhaps because I wrote 
>> it :-)
>>
>> -         * so that when the Font2D is GC'd it can also remove the file.
>> +         * so that when the Font2D is GC'ed it can also remove the 
>> file.
>>
>>
>> Other than that, looks good.
>> Some fun new words in there. I particularly liked utilitized and 
>> unclude.
>>
>> -phil.
>>
>> On 8/21/2014 10:38 AM, Sergey Bylokhov wrote:
>>> Hello,
>>> Please review the fix for jdk 9.
>>> The fix was contributed by  pavel.rappo at oracle.com
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8055326
>>> Webrev can be found at: 
>>> http://cr.openjdk.java.net/~serb/8055326/webrev.00
>>>
>>
>
>



From vivi.an at oracle.com  Tue Sep 16 03:38:03 2014
From: vivi.an at oracle.com (Vivi An)
Date: Mon, 15 Sep 2014 20:38:03 -0700
Subject: <Swing Dev> [9] Review request for 8033699: Incorrect radio
 button behavior
In-Reply-To: <5416B89F.5040301@oracle.com>
References: <5408B5E9.6080901@oracle.com> <540DA48F.2020409@oracle.com>
	<5410D71F.3040405@oracle.com> <541177AE.6040305@oracle.com>
	<541325C5.6040800@oracle.com> <5416B89F.5040301@oracle.com>
Message-ID: <5417B09B.30807@oracle.com>

Fixed. New Webrev: http://cr.openjdk.java.net/~van/8033699/webrev.03/

Thanks Alex.

Regards,

~ Vivi

On 9/15/2014 2:59 AM, Alexander Scherbatiy wrote:
> On 9/12/2014 8:56 PM, Vivi An wrote:
>> Thanks Alexander.
>>
>> All items addressed except last one, please see comments inline.
>> New Webrev: http://cr.openjdk.java.net/~van/8033699/webrev.02/
>
>     163         if ( keyListener != null ) {
>
>     Could you remove spaces in the brackets? After code formatting it 
> should be "if (keyListener != null) {"
>
>>> 543             if (next && btnGroupInfo.lastBtn != null)
>>>  544                 KeyboardFocusManager.
>>>  545 
>>> getCurrentKeyboardFocusManager().focusNextComponent((JComponent)btnGroupInfo.lastBtn);
>>>  546             else if (btnGroupInfo.firstBtn != null)
>>>  547                 KeyboardFocusManager.
>>>  548 
>>> getCurrentKeyboardFocusManager().focusPreviousComponent((JComponent)btnGroupInfo.firstBtn);
>>>  549         }
>>>
>>> Should the first button be focused If next is true and last button 
>>> is null?
>> Don't think last button could be null when this function is 
>> triggered, last and first will always be set in case there is at 
>> least one valid (enabled and visible) radio button in the group.
>
>   It seems that lastBtn != null and firstBtn != null checks are not 
> necessary in this case.
>
>   Thanks,
>   Alexandr.
>
>>>
>>> Thanks,
>>> Alexandr.
>>>
>>>>
>>>> Regards,
>>>>
>>>> ~ Vivi
>>>>
>>>>
>>>> On 9/8/2014 5:43 AM, Alexander Scherbatiy wrote:
>>>>> On 9/4/2014 10:56 PM, Vivi An wrote:
>>>>>> Hello,
>>>>>>
>>>>>> Please review fix for JDK-8033699.  Changes made:
>>>>>> 1) When tab or shift-tab key pressed,  focus moved to next/previous
>>>>>> component outside of the radio button group
>>>>>> 2) Using up/down or left/right arrow key to change selection inside
>>>>>> radio button group
>>>>>>
>>>>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8033699
>>>>>> Webrev:http://cr.openjdk.java.net/~van/8033699/webrev.00/
>>>>>
>>>>>   56     private KeyListener keyListener = null;
>>>>>   57     private KeyHandler handler = null;
>>>>>
>>>>> It seems that these both fields point to the same object. Is it 
>>>>> possible to get rid of one of them?
>>>>>
>>>>>
>>>>>  152         if ( keyListener != null ) {
>>>>>  153             button.removeKeyListener( keyListener );
>>>>>  154         }
>>>>>
>>>>> Some UIs also set the listener to null in the 
>>>>> uninstallUI()/uninstallListeners() methods (like BasicComboBoxUI 
>>>>> or BasicColorChooserUI).
>>>>> Should the keyListener also be set to null to free the KeyHandler 
>>>>> object?
>>>>>
>>>>>  369         if (!(eventSrc instanceof JRadioButton &&
>>>>>  370             ((JRadioButton) eventSrc).isVisible() && 
>>>>> ((JRadioButton) eventSrc).isEnabled()))
>>>>>
>>>>> This check is used several times. It can be moved to a separate 
>>>>> method.
>>>>>
>>>>>  373         // Get the button model from the source.
>>>>>  374         ButtonModel model = ((AbstractButton) 
>>>>> eventSrc).getModel();
>>>>>  375         if (!(model instanceof DefaultButtonModel))
>>>>>  376             return;
>>>>>  377
>>>>>  378         // If the button model is DefaultButtonModel, and use 
>>>>> it, otherwise return.
>>>>>  379         DefaultButtonModel bm = (DefaultButtonModel) model;
>>>>>  380         if (bm == null)
>>>>>  381             return;
>>>>>
>>>>> The second check is not necessary because (model instanceof 
>>>>> DefaultButtonModel) returns false for null model.
>>>>>
>>>>>
>>>>>  404         AbstractButton curElement = null;
>>>>>
>>>>>   The curElement variable declaration could be moved into the 
>>>>> 'while' block.
>>>>>
>>>>>
>>>>>  408             if (curElement instanceof JRadioButton &&
>>>>>  409                     ((JRadioButton) curElement).isVisible() &&
>>>>>  410                     ((JRadioButton) curElement).isEnabled()){
>>>>>
>>>>>   It is possible to use 'continue' here to not put the other code 
>>>>> inside the 'if' block.
>>>>>
>>>>>
>>>>>  418                 else if (!srcFound){
>>>>>  422                 } else if (srcFound && nextBtn == null){
>>>>>
>>>>> It is not necessary to check the srcFound in the second 'if' 
>>>>> because it should already have true value.
>>>>>
>>>>>
>>>>>  444             if (newSelectedBtn != null){
>>>>>  445 newSelectedBtn.requestFocusInWindow();
>>>>>  446                 newSelectedBtn.setSelected(true);
>>>>>  447             }
>>>>>
>>>>>
>>>>> Is it possible here that newSelectedBtn == eventSrc?
>>>>>
>>>>>  522         private void jumpToNextComponent(JRadioButton btn, 
>>>>> boolean next){
>>>>>
>>>>> The code that retrieves elements from a button group is also used 
>>>>> in the selectRadioButton()
>>>>> and can be moved to a separate method.
>>>>>
>>>>> Thanks,
>>>>> Alexandr.
>>>>>
>>>>>>
>>>>>> JPRT build succeeded, JCK tests for JRadiobutton and JCheckBox 
>>>>>> all passed.
>>>>>>
>>>>>> Thank you
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Vivi
>>>>>>
>>>>>
>>>>
>>>
>>
>



From alexandr.scherbatiy at oracle.com  Tue Sep 16 07:39:17 2014
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Tue, 16 Sep 2014 11:39:17 +0400
Subject: <Swing Dev> [9] Review request for 8033699: Incorrect radio
 button behavior
In-Reply-To: <5417B09B.30807@oracle.com>
References: <5408B5E9.6080901@oracle.com> <540DA48F.2020409@oracle.com>
	<5410D71F.3040405@oracle.com> <541177AE.6040305@oracle.com>
	<541325C5.6040800@oracle.com> <5416B89F.5040301@oracle.com>
	<5417B09B.30807@oracle.com>
Message-ID: <5417E925.4090601@oracle.com>


   I have missed one more case:
  527         public void keyPressed(KeyEvent e) {
  528             if (e.getKeyCode() == KeyEvent.VK_TAB) {
                         // jumpToNextComponent(true)
  538             }
  539
  540             if (e.getKeyCode() == KeyEvent.VK_TAB && 
e.isShiftDown()) {
                         //jumpToNextComponent(false)
  550             }
  551         }

   It seems that if e.isShiftDown() is true then both 
jumpToNextComponent(true) and jumpToNextComponent(false) methods can be 
called.

   Thanks,
   Alexandr.


On 9/16/2014 7:38 AM, Vivi An wrote:
> Fixed. New Webrev: http://cr.openjdk.java.net/~van/8033699/webrev.03/
>
> Thanks Alex.
>
> Regards,
>
> ~ Vivi
>
> On 9/15/2014 2:59 AM, Alexander Scherbatiy wrote:
>> On 9/12/2014 8:56 PM, Vivi An wrote:
>>> Thanks Alexander.
>>>
>>> All items addressed except last one, please see comments inline.
>>> New Webrev: http://cr.openjdk.java.net/~van/8033699/webrev.02/
>>
>>     163         if ( keyListener != null ) {
>>
>>     Could you remove spaces in the brackets? After code formatting it 
>> should be "if (keyListener != null) {"
>>
>>>> 543             if (next && btnGroupInfo.lastBtn != null)
>>>>  544                 KeyboardFocusManager.
>>>>  545 
>>>> getCurrentKeyboardFocusManager().focusNextComponent((JComponent)btnGroupInfo.lastBtn);
>>>>  546             else if (btnGroupInfo.firstBtn != null)
>>>>  547                 KeyboardFocusManager.
>>>>  548 
>>>> getCurrentKeyboardFocusManager().focusPreviousComponent((JComponent)btnGroupInfo.firstBtn);
>>>>  549         }
>>>>
>>>> Should the first button be focused If next is true and last button 
>>>> is null?
>>> Don't think last button could be null when this function is 
>>> triggered, last and first will always be set in case there is at 
>>> least one valid (enabled and visible) radio button in the group.
>>
>>   It seems that lastBtn != null and firstBtn != null checks are not 
>> necessary in this case.
>>
>>   Thanks,
>>   Alexandr.
>>
>>>>
>>>> Thanks,
>>>> Alexandr.
>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>> ~ Vivi
>>>>>
>>>>>
>>>>> On 9/8/2014 5:43 AM, Alexander Scherbatiy wrote:
>>>>>> On 9/4/2014 10:56 PM, Vivi An wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> Please review fix for JDK-8033699.  Changes made:
>>>>>>> 1) When tab or shift-tab key pressed,  focus moved to next/previous
>>>>>>> component outside of the radio button group
>>>>>>> 2) Using up/down or left/right arrow key to change selection inside
>>>>>>> radio button group
>>>>>>>
>>>>>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8033699
>>>>>>> Webrev:http://cr.openjdk.java.net/~van/8033699/webrev.00/
>>>>>>
>>>>>>   56     private KeyListener keyListener = null;
>>>>>>   57     private KeyHandler handler = null;
>>>>>>
>>>>>> It seems that these both fields point to the same object. Is it 
>>>>>> possible to get rid of one of them?
>>>>>>
>>>>>>
>>>>>>  152         if ( keyListener != null ) {
>>>>>>  153             button.removeKeyListener( keyListener );
>>>>>>  154         }
>>>>>>
>>>>>> Some UIs also set the listener to null in the 
>>>>>> uninstallUI()/uninstallListeners() methods (like BasicComboBoxUI 
>>>>>> or BasicColorChooserUI).
>>>>>> Should the keyListener also be set to null to free the KeyHandler 
>>>>>> object?
>>>>>>
>>>>>>  369         if (!(eventSrc instanceof JRadioButton &&
>>>>>>  370             ((JRadioButton) eventSrc).isVisible() && 
>>>>>> ((JRadioButton) eventSrc).isEnabled()))
>>>>>>
>>>>>> This check is used several times. It can be moved to a separate 
>>>>>> method.
>>>>>>
>>>>>>  373         // Get the button model from the source.
>>>>>>  374         ButtonModel model = ((AbstractButton) 
>>>>>> eventSrc).getModel();
>>>>>>  375         if (!(model instanceof DefaultButtonModel))
>>>>>>  376             return;
>>>>>>  377
>>>>>>  378         // If the button model is DefaultButtonModel, and 
>>>>>> use it, otherwise return.
>>>>>>  379         DefaultButtonModel bm = (DefaultButtonModel) model;
>>>>>>  380         if (bm == null)
>>>>>>  381             return;
>>>>>>
>>>>>> The second check is not necessary because (model instanceof 
>>>>>> DefaultButtonModel) returns false for null model.
>>>>>>
>>>>>>
>>>>>>  404         AbstractButton curElement = null;
>>>>>>
>>>>>>   The curElement variable declaration could be moved into the 
>>>>>> 'while' block.
>>>>>>
>>>>>>
>>>>>>  408             if (curElement instanceof JRadioButton &&
>>>>>>  409                     ((JRadioButton) curElement).isVisible() &&
>>>>>>  410                     ((JRadioButton) curElement).isEnabled()){
>>>>>>
>>>>>>   It is possible to use 'continue' here to not put the other code 
>>>>>> inside the 'if' block.
>>>>>>
>>>>>>
>>>>>>  418                 else if (!srcFound){
>>>>>>  422                 } else if (srcFound && nextBtn == null){
>>>>>>
>>>>>> It is not necessary to check the srcFound in the second 'if' 
>>>>>> because it should already have true value.
>>>>>>
>>>>>>
>>>>>>  444             if (newSelectedBtn != null){
>>>>>>  445 newSelectedBtn.requestFocusInWindow();
>>>>>>  446                 newSelectedBtn.setSelected(true);
>>>>>>  447             }
>>>>>>
>>>>>>
>>>>>> Is it possible here that newSelectedBtn == eventSrc?
>>>>>>
>>>>>>  522         private void jumpToNextComponent(JRadioButton btn, 
>>>>>> boolean next){
>>>>>>
>>>>>> The code that retrieves elements from a button group is also used 
>>>>>> in the selectRadioButton()
>>>>>> and can be moved to a separate method.
>>>>>>
>>>>>> Thanks,
>>>>>> Alexandr.
>>>>>>
>>>>>>>
>>>>>>> JPRT build succeeded, JCK tests for JRadiobutton and JCheckBox 
>>>>>>> all passed.
>>>>>>>
>>>>>>> Thank you
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Vivi
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>



From vivi.an at oracle.com  Wed Sep 17 05:17:00 2014
From: vivi.an at oracle.com (Vivi An)
Date: Tue, 16 Sep 2014 22:17:00 -0700
Subject: <Swing Dev> [9] Review request for 8033699: Incorrect radio
 button behavior
In-Reply-To: <5417E925.4090601@oracle.com>
References: <5408B5E9.6080901@oracle.com> <540DA48F.2020409@oracle.com>
	<5410D71F.3040405@oracle.com> <541177AE.6040305@oracle.com>
	<541325C5.6040800@oracle.com> <5416B89F.5040301@oracle.com>
	<5417B09B.30807@oracle.com> <5417E925.4090601@oracle.com>
Message-ID: <5419194C.9030001@oracle.com>

You are right. Fixed now.

http://cr.openjdk.java.net/~van/8033699/webrev.04/

Thank you

~ Vivi

On 9/16/2014 12:39 AM, Alexander Scherbatiy wrote:
>
>   I have missed one more case:
>  527         public void keyPressed(KeyEvent e) {
>  528             if (e.getKeyCode() == KeyEvent.VK_TAB) {
>                         // jumpToNextComponent(true)
>  538             }
>  539
>  540             if (e.getKeyCode() == KeyEvent.VK_TAB && 
> e.isShiftDown()) {
>                         //jumpToNextComponent(false)
>  550             }
>  551         }
>
>   It seems that if e.isShiftDown() is true then both 
> jumpToNextComponent(true) and jumpToNextComponent(false) methods can 
> be called.
>
>   Thanks,
>   Alexandr.
>
>
> On 9/16/2014 7:38 AM, Vivi An wrote:
>> Fixed. New Webrev: http://cr.openjdk.java.net/~van/8033699/webrev.03/
>>
>> Thanks Alex.
>>
>> Regards,
>>
>> ~ Vivi
>>
>> On 9/15/2014 2:59 AM, Alexander Scherbatiy wrote:
>>> On 9/12/2014 8:56 PM, Vivi An wrote:
>>>> Thanks Alexander.
>>>>
>>>> All items addressed except last one, please see comments inline.
>>>> New Webrev: http://cr.openjdk.java.net/~van/8033699/webrev.02/
>>>
>>>     163         if ( keyListener != null ) {
>>>
>>>     Could you remove spaces in the brackets? After code formatting 
>>> it should be "if (keyListener != null) {"
>>>
>>>>> 543             if (next && btnGroupInfo.lastBtn != null)
>>>>>  544                 KeyboardFocusManager.
>>>>>  545 
>>>>> getCurrentKeyboardFocusManager().focusNextComponent((JComponent)btnGroupInfo.lastBtn);
>>>>>  546             else if (btnGroupInfo.firstBtn != null)
>>>>>  547                 KeyboardFocusManager.
>>>>>  548 
>>>>> getCurrentKeyboardFocusManager().focusPreviousComponent((JComponent)btnGroupInfo.firstBtn);
>>>>>  549         }
>>>>>
>>>>> Should the first button be focused If next is true and last button 
>>>>> is null?
>>>> Don't think last button could be null when this function is 
>>>> triggered, last and first will always be set in case there is at 
>>>> least one valid (enabled and visible) radio button in the group.
>>>
>>>   It seems that lastBtn != null and firstBtn != null checks are not 
>>> necessary in this case.
>>>
>>>   Thanks,
>>>   Alexandr.
>>>
>>>>>
>>>>> Thanks,
>>>>> Alexandr.
>>>>>
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> ~ Vivi
>>>>>>
>>>>>>
>>>>>> On 9/8/2014 5:43 AM, Alexander Scherbatiy wrote:
>>>>>>> On 9/4/2014 10:56 PM, Vivi An wrote:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> Please review fix for JDK-8033699.  Changes made:
>>>>>>>> 1) When tab or shift-tab key pressed,  focus moved to 
>>>>>>>> next/previous
>>>>>>>> component outside of the radio button group
>>>>>>>> 2) Using up/down or left/right arrow key to change selection 
>>>>>>>> inside
>>>>>>>> radio button group
>>>>>>>>
>>>>>>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8033699
>>>>>>>> Webrev:http://cr.openjdk.java.net/~van/8033699/webrev.00/
>>>>>>>
>>>>>>>   56     private KeyListener keyListener = null;
>>>>>>>   57     private KeyHandler handler = null;
>>>>>>>
>>>>>>> It seems that these both fields point to the same object. Is it 
>>>>>>> possible to get rid of one of them?
>>>>>>>
>>>>>>>
>>>>>>>  152         if ( keyListener != null ) {
>>>>>>>  153             button.removeKeyListener( keyListener );
>>>>>>>  154         }
>>>>>>>
>>>>>>> Some UIs also set the listener to null in the 
>>>>>>> uninstallUI()/uninstallListeners() methods (like BasicComboBoxUI 
>>>>>>> or BasicColorChooserUI).
>>>>>>> Should the keyListener also be set to null to free the 
>>>>>>> KeyHandler object?
>>>>>>>
>>>>>>>  369         if (!(eventSrc instanceof JRadioButton &&
>>>>>>>  370             ((JRadioButton) eventSrc).isVisible() && 
>>>>>>> ((JRadioButton) eventSrc).isEnabled()))
>>>>>>>
>>>>>>> This check is used several times. It can be moved to a separate 
>>>>>>> method.
>>>>>>>
>>>>>>>  373         // Get the button model from the source.
>>>>>>>  374         ButtonModel model = ((AbstractButton) 
>>>>>>> eventSrc).getModel();
>>>>>>>  375         if (!(model instanceof DefaultButtonModel))
>>>>>>>  376             return;
>>>>>>>  377
>>>>>>>  378         // If the button model is DefaultButtonModel, and 
>>>>>>> use it, otherwise return.
>>>>>>>  379         DefaultButtonModel bm = (DefaultButtonModel) model;
>>>>>>>  380         if (bm == null)
>>>>>>>  381             return;
>>>>>>>
>>>>>>> The second check is not necessary because (model instanceof 
>>>>>>> DefaultButtonModel) returns false for null model.
>>>>>>>
>>>>>>>
>>>>>>>  404         AbstractButton curElement = null;
>>>>>>>
>>>>>>>   The curElement variable declaration could be moved into the 
>>>>>>> 'while' block.
>>>>>>>
>>>>>>>
>>>>>>>  408             if (curElement instanceof JRadioButton &&
>>>>>>>  409                     ((JRadioButton) curElement).isVisible() &&
>>>>>>>  410                     ((JRadioButton) curElement).isEnabled()){
>>>>>>>
>>>>>>>   It is possible to use 'continue' here to not put the other 
>>>>>>> code inside the 'if' block.
>>>>>>>
>>>>>>>
>>>>>>>  418                 else if (!srcFound){
>>>>>>>  422                 } else if (srcFound && nextBtn == null){
>>>>>>>
>>>>>>> It is not necessary to check the srcFound in the second 'if' 
>>>>>>> because it should already have true value.
>>>>>>>
>>>>>>>
>>>>>>>  444             if (newSelectedBtn != null){
>>>>>>>  445 newSelectedBtn.requestFocusInWindow();
>>>>>>>  446                 newSelectedBtn.setSelected(true);
>>>>>>>  447             }
>>>>>>>
>>>>>>>
>>>>>>> Is it possible here that newSelectedBtn == eventSrc?
>>>>>>>
>>>>>>>  522         private void jumpToNextComponent(JRadioButton btn, 
>>>>>>> boolean next){
>>>>>>>
>>>>>>> The code that retrieves elements from a button group is also 
>>>>>>> used in the selectRadioButton()
>>>>>>> and can be moved to a separate method.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Alexandr.
>>>>>>>
>>>>>>>>
>>>>>>>> JPRT build succeeded, JCK tests for JRadiobutton and JCheckBox 
>>>>>>>> all passed.
>>>>>>>>
>>>>>>>> Thank you
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>> Vivi
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>



From alexandr.scherbatiy at oracle.com  Wed Sep 17 07:44:06 2014
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Wed, 17 Sep 2014 11:44:06 +0400
Subject: <Swing Dev> [9] Review request for 8033699: Incorrect radio
 button behavior
In-Reply-To: <5419194C.9030001@oracle.com>
References: <5408B5E9.6080901@oracle.com> <540DA48F.2020409@oracle.com>
	<5410D71F.3040405@oracle.com> <541177AE.6040305@oracle.com>
	<541325C5.6040800@oracle.com> <5416B89F.5040301@oracle.com>
	<5417B09B.30807@oracle.com> <5417E925.4090601@oracle.com>
	<5419194C.9030001@oracle.com>
Message-ID: <54193BC6.8020105@oracle.com>

On 9/17/2014 9:17 AM, Vivi An wrote:
> You are right. Fixed now.
>
> http://cr.openjdk.java.net/~van/8033699/webrev.04/

  528             if (e.isShiftDown()) {
  529                 if (e.getKeyCode() == KeyEvent.VK_TAB) {
  537                         // ... 
btnGroupInfo.jumpToNextComponent(false);
  539                 }
  540             } else if (e.getKeyCode() == KeyEvent.VK_TAB) {
  548                     // ... btnGroupInfo.jumpToNextComponent(true);
  550             }

   The code in the if/else branches is almost the same except the 
true/false argument.
   I would suggest to unify them in the following way:

      if (e.getKeyCode() == KeyEvent.VK_TAB) {
         // ... jumpToNextComponent(!e.isShiftDown())
      }


  510             if (next)
  511                 KeyboardFocusManager.
  512 
getCurrentKeyboardFocusManager().focusNextComponent((JComponent)lastBtn);
  513             else
  514                 KeyboardFocusManager.
  515 
getCurrentKeyboardFocusManager().focusPreviousComponent((JComponent)firstBtn);

  This code can be also a little bit optimized:

     KeyboardFocusManager.getCurrentKeyboardFocusManager().
         focusPreviousComponent((JComponent) (next ? lastBtn : firstBtn));

  Thanks,
  Alexandr.

>
> Thank you
>
> ~ Vivi
>
> On 9/16/2014 12:39 AM, Alexander Scherbatiy wrote:
>>
>>   I have missed one more case:
>>  527         public void keyPressed(KeyEvent e) {
>>  528             if (e.getKeyCode() == KeyEvent.VK_TAB) {
>>                         // jumpToNextComponent(true)
>>  538             }
>>  539
>>  540             if (e.getKeyCode() == KeyEvent.VK_TAB && 
>> e.isShiftDown()) {
>>                         //jumpToNextComponent(false)
>>  550             }
>>  551         }
>>
>>   It seems that if e.isShiftDown() is true then both 
>> jumpToNextComponent(true) and jumpToNextComponent(false) methods can 
>> be called.
>>
>>   Thanks,
>>   Alexandr.
>>
>>
>> On 9/16/2014 7:38 AM, Vivi An wrote:
>>> Fixed. New Webrev: http://cr.openjdk.java.net/~van/8033699/webrev.03/
>>>
>>> Thanks Alex.
>>>
>>> Regards,
>>>
>>> ~ Vivi
>>>
>>> On 9/15/2014 2:59 AM, Alexander Scherbatiy wrote:
>>>> On 9/12/2014 8:56 PM, Vivi An wrote:
>>>>> Thanks Alexander.
>>>>>
>>>>> All items addressed except last one, please see comments inline.
>>>>> New Webrev: http://cr.openjdk.java.net/~van/8033699/webrev.02/
>>>>
>>>>     163         if ( keyListener != null ) {
>>>>
>>>>     Could you remove spaces in the brackets? After code formatting 
>>>> it should be "if (keyListener != null) {"
>>>>
>>>>>> 543             if (next && btnGroupInfo.lastBtn != null)
>>>>>>  544                 KeyboardFocusManager.
>>>>>>  545 
>>>>>> getCurrentKeyboardFocusManager().focusNextComponent((JComponent)btnGroupInfo.lastBtn);
>>>>>>  546             else if (btnGroupInfo.firstBtn != null)
>>>>>>  547                 KeyboardFocusManager.
>>>>>>  548 
>>>>>> getCurrentKeyboardFocusManager().focusPreviousComponent((JComponent)btnGroupInfo.firstBtn);
>>>>>>  549         }
>>>>>>
>>>>>> Should the first button be focused If next is true and last 
>>>>>> button is null?
>>>>> Don't think last button could be null when this function is 
>>>>> triggered, last and first will always be set in case there is at 
>>>>> least one valid (enabled and visible) radio button in the group.
>>>>
>>>>   It seems that lastBtn != null and firstBtn != null checks are not 
>>>> necessary in this case.
>>>>
>>>>   Thanks,
>>>>   Alexandr.
>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> Alexandr.
>>>>>>
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> ~ Vivi
>>>>>>>
>>>>>>>
>>>>>>> On 9/8/2014 5:43 AM, Alexander Scherbatiy wrote:
>>>>>>>> On 9/4/2014 10:56 PM, Vivi An wrote:
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> Please review fix for JDK-8033699.  Changes made:
>>>>>>>>> 1) When tab or shift-tab key pressed,  focus moved to 
>>>>>>>>> next/previous
>>>>>>>>> component outside of the radio button group
>>>>>>>>> 2) Using up/down or left/right arrow key to change selection 
>>>>>>>>> inside
>>>>>>>>> radio button group
>>>>>>>>>
>>>>>>>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8033699
>>>>>>>>> Webrev:http://cr.openjdk.java.net/~van/8033699/webrev.00/
>>>>>>>>
>>>>>>>>   56     private KeyListener keyListener = null;
>>>>>>>>   57     private KeyHandler handler = null;
>>>>>>>>
>>>>>>>> It seems that these both fields point to the same object. Is it 
>>>>>>>> possible to get rid of one of them?
>>>>>>>>
>>>>>>>>
>>>>>>>>  152         if ( keyListener != null ) {
>>>>>>>>  153             button.removeKeyListener( keyListener );
>>>>>>>>  154         }
>>>>>>>>
>>>>>>>> Some UIs also set the listener to null in the 
>>>>>>>> uninstallUI()/uninstallListeners() methods (like 
>>>>>>>> BasicComboBoxUI or BasicColorChooserUI).
>>>>>>>> Should the keyListener also be set to null to free the 
>>>>>>>> KeyHandler object?
>>>>>>>>
>>>>>>>>  369         if (!(eventSrc instanceof JRadioButton &&
>>>>>>>>  370             ((JRadioButton) eventSrc).isVisible() && 
>>>>>>>> ((JRadioButton) eventSrc).isEnabled()))
>>>>>>>>
>>>>>>>> This check is used several times. It can be moved to a separate 
>>>>>>>> method.
>>>>>>>>
>>>>>>>>  373         // Get the button model from the source.
>>>>>>>>  374         ButtonModel model = ((AbstractButton) 
>>>>>>>> eventSrc).getModel();
>>>>>>>>  375         if (!(model instanceof DefaultButtonModel))
>>>>>>>>  376             return;
>>>>>>>>  377
>>>>>>>>  378         // If the button model is DefaultButtonModel, and 
>>>>>>>> use it, otherwise return.
>>>>>>>>  379         DefaultButtonModel bm = (DefaultButtonModel) model;
>>>>>>>>  380         if (bm == null)
>>>>>>>>  381             return;
>>>>>>>>
>>>>>>>> The second check is not necessary because (model instanceof 
>>>>>>>> DefaultButtonModel) returns false for null model.
>>>>>>>>
>>>>>>>>
>>>>>>>>  404         AbstractButton curElement = null;
>>>>>>>>
>>>>>>>>   The curElement variable declaration could be moved into the 
>>>>>>>> 'while' block.
>>>>>>>>
>>>>>>>>
>>>>>>>>  408             if (curElement instanceof JRadioButton &&
>>>>>>>>  409                     ((JRadioButton) 
>>>>>>>> curElement).isVisible() &&
>>>>>>>>  410                     ((JRadioButton) curElement).isEnabled()){
>>>>>>>>
>>>>>>>>   It is possible to use 'continue' here to not put the other 
>>>>>>>> code inside the 'if' block.
>>>>>>>>
>>>>>>>>
>>>>>>>>  418                 else if (!srcFound){
>>>>>>>>  422                 } else if (srcFound && nextBtn == null){
>>>>>>>>
>>>>>>>> It is not necessary to check the srcFound in the second 'if' 
>>>>>>>> because it should already have true value.
>>>>>>>>
>>>>>>>>
>>>>>>>>  444             if (newSelectedBtn != null){
>>>>>>>>  445 newSelectedBtn.requestFocusInWindow();
>>>>>>>>  446 newSelectedBtn.setSelected(true);
>>>>>>>>  447             }
>>>>>>>>
>>>>>>>>
>>>>>>>> Is it possible here that newSelectedBtn == eventSrc?
>>>>>>>>
>>>>>>>>  522         private void jumpToNextComponent(JRadioButton btn, 
>>>>>>>> boolean next){
>>>>>>>>
>>>>>>>> The code that retrieves elements from a button group is also 
>>>>>>>> used in the selectRadioButton()
>>>>>>>> and can be moved to a separate method.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Alexandr.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> JPRT build succeeded, JCK tests for JRadiobutton and JCheckBox 
>>>>>>>>> all passed.
>>>>>>>>>
>>>>>>>>> Thank you
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>>
>>>>>>>>> Vivi
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>



From vivi.an at oracle.com  Wed Sep 17 23:09:09 2014
From: vivi.an at oracle.com (Vivi An)
Date: Wed, 17 Sep 2014 16:09:09 -0700
Subject: <Swing Dev> [9] Review request for 8033699: Incorrect radio
 button behavior
In-Reply-To: <54193BC6.8020105@oracle.com>
References: <5408B5E9.6080901@oracle.com> <540DA48F.2020409@oracle.com>
	<5410D71F.3040405@oracle.com> <541177AE.6040305@oracle.com>
	<541325C5.6040800@oracle.com> <5416B89F.5040301@oracle.com>
	<5417B09B.30807@oracle.com> <5417E925.4090601@oracle.com>
	<5419194C.9030001@oracle.com> <54193BC6.8020105@oracle.com>
Message-ID: <541A1495.8060003@oracle.com>

Hello Alex,

On 9/17/2014 12:44 AM, Alexander Scherbatiy wrote:
> On 9/17/2014 9:17 AM, Vivi An wrote:
>> You are right. Fixed now.
>>
>> http://cr.openjdk.java.net/~van/8033699/webrev.04/
>
>  528             if (e.isShiftDown()) {
>  529                 if (e.getKeyCode() == KeyEvent.VK_TAB) {
>  537                         // ... 
> btnGroupInfo.jumpToNextComponent(false);
>  539                 }
>  540             } else if (e.getKeyCode() == KeyEvent.VK_TAB) {
>  548                     // ... btnGroupInfo.jumpToNextComponent(true);
>  550             }
>
>   The code in the if/else branches is almost the same except the 
> true/false argument.
>   I would suggest to unify them in the following way:
>
>      if (e.getKeyCode() == KeyEvent.VK_TAB) {
>         // ... jumpToNextComponent(!e.isShiftDown())
>      }
>
Fixed.
>
>  510             if (next)
>  511                 KeyboardFocusManager.
>  512 
> getCurrentKeyboardFocusManager().focusNextComponent((JComponent)lastBtn);
>  513             else
>  514                 KeyboardFocusManager.
>  515 
> getCurrentKeyboardFocusManager().focusPreviousComponent((JComponent)firstBtn);
>
>  This code can be also a little bit optimized:
>
>     KeyboardFocusManager.getCurrentKeyboardFocusManager().
>         focusPreviousComponent((JComponent) (next ? lastBtn : firstBtn));
>
It's different function call,  one for focusNextComponent and the other 
for focusPreviousComponent, not able to optimize in suggested way.

http://cr.openjdk.java.net/~van/8033699/webrev.05/

Thanks

Vivi

>  Thanks,
>  Alexandr.
>
>>
>> Thank you
>>
>> ~ Vivi
>>
>> On 9/16/2014 12:39 AM, Alexander Scherbatiy wrote:
>>>
>>>   I have missed one more case:
>>>  527         public void keyPressed(KeyEvent e) {
>>>  528             if (e.getKeyCode() == KeyEvent.VK_TAB) {
>>>                         // jumpToNextComponent(true)
>>>  538             }
>>>  539
>>>  540             if (e.getKeyCode() == KeyEvent.VK_TAB && 
>>> e.isShiftDown()) {
>>>                         //jumpToNextComponent(false)
>>>  550             }
>>>  551         }
>>>
>>>   It seems that if e.isShiftDown() is true then both 
>>> jumpToNextComponent(true) and jumpToNextComponent(false) methods can 
>>> be called.
>>>
>>>   Thanks,
>>>   Alexandr.
>>>
>>>
>>> On 9/16/2014 7:38 AM, Vivi An wrote:
>>>> Fixed. New Webrev: http://cr.openjdk.java.net/~van/8033699/webrev.03/
>>>>
>>>> Thanks Alex.
>>>>
>>>> Regards,
>>>>
>>>> ~ Vivi
>>>>
>>>> On 9/15/2014 2:59 AM, Alexander Scherbatiy wrote:
>>>>> On 9/12/2014 8:56 PM, Vivi An wrote:
>>>>>> Thanks Alexander.
>>>>>>
>>>>>> All items addressed except last one, please see comments inline.
>>>>>> New Webrev: http://cr.openjdk.java.net/~van/8033699/webrev.02/
>>>>>
>>>>>     163         if ( keyListener != null ) {
>>>>>
>>>>>     Could you remove spaces in the brackets? After code formatting 
>>>>> it should be "if (keyListener != null) {"
>>>>>
>>>>>>> 543             if (next && btnGroupInfo.lastBtn != null)
>>>>>>>  544                 KeyboardFocusManager.
>>>>>>>  545 
>>>>>>> getCurrentKeyboardFocusManager().focusNextComponent((JComponent)btnGroupInfo.lastBtn);
>>>>>>>  546             else if (btnGroupInfo.firstBtn != null)
>>>>>>>  547                 KeyboardFocusManager.
>>>>>>>  548 
>>>>>>> getCurrentKeyboardFocusManager().focusPreviousComponent((JComponent)btnGroupInfo.firstBtn);
>>>>>>>  549         }
>>>>>>>
>>>>>>> Should the first button be focused If next is true and last 
>>>>>>> button is null?
>>>>>> Don't think last button could be null when this function is 
>>>>>> triggered, last and first will always be set in case there is at 
>>>>>> least one valid (enabled and visible) radio button in the group.
>>>>>
>>>>>   It seems that lastBtn != null and firstBtn != null checks are 
>>>>> not necessary in this case.
>>>>>
>>>>>   Thanks,
>>>>>   Alexandr.
>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Alexandr.
>>>>>>>
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>> ~ Vivi
>>>>>>>>
>>>>>>>>
>>>>>>>> On 9/8/2014 5:43 AM, Alexander Scherbatiy wrote:
>>>>>>>>> On 9/4/2014 10:56 PM, Vivi An wrote:
>>>>>>>>>> Hello,
>>>>>>>>>>
>>>>>>>>>> Please review fix for JDK-8033699.  Changes made:
>>>>>>>>>> 1) When tab or shift-tab key pressed,  focus moved to 
>>>>>>>>>> next/previous
>>>>>>>>>> component outside of the radio button group
>>>>>>>>>> 2) Using up/down or left/right arrow key to change selection 
>>>>>>>>>> inside
>>>>>>>>>> radio button group
>>>>>>>>>>
>>>>>>>>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8033699
>>>>>>>>>> Webrev:http://cr.openjdk.java.net/~van/8033699/webrev.00/
>>>>>>>>>
>>>>>>>>>   56     private KeyListener keyListener = null;
>>>>>>>>>   57     private KeyHandler handler = null;
>>>>>>>>>
>>>>>>>>> It seems that these both fields point to the same object. Is 
>>>>>>>>> it possible to get rid of one of them?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>  152         if ( keyListener != null ) {
>>>>>>>>>  153             button.removeKeyListener( keyListener );
>>>>>>>>>  154         }
>>>>>>>>>
>>>>>>>>> Some UIs also set the listener to null in the 
>>>>>>>>> uninstallUI()/uninstallListeners() methods (like 
>>>>>>>>> BasicComboBoxUI or BasicColorChooserUI).
>>>>>>>>> Should the keyListener also be set to null to free the 
>>>>>>>>> KeyHandler object?
>>>>>>>>>
>>>>>>>>>  369         if (!(eventSrc instanceof JRadioButton &&
>>>>>>>>>  370             ((JRadioButton) eventSrc).isVisible() && 
>>>>>>>>> ((JRadioButton) eventSrc).isEnabled()))
>>>>>>>>>
>>>>>>>>> This check is used several times. It can be moved to a 
>>>>>>>>> separate method.
>>>>>>>>>
>>>>>>>>>  373         // Get the button model from the source.
>>>>>>>>>  374         ButtonModel model = ((AbstractButton) 
>>>>>>>>> eventSrc).getModel();
>>>>>>>>>  375         if (!(model instanceof DefaultButtonModel))
>>>>>>>>>  376             return;
>>>>>>>>>  377
>>>>>>>>>  378         // If the button model is DefaultButtonModel, and 
>>>>>>>>> use it, otherwise return.
>>>>>>>>>  379         DefaultButtonModel bm = (DefaultButtonModel) model;
>>>>>>>>>  380         if (bm == null)
>>>>>>>>>  381             return;
>>>>>>>>>
>>>>>>>>> The second check is not necessary because (model instanceof 
>>>>>>>>> DefaultButtonModel) returns false for null model.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>  404         AbstractButton curElement = null;
>>>>>>>>>
>>>>>>>>>   The curElement variable declaration could be moved into the 
>>>>>>>>> 'while' block.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>  408             if (curElement instanceof JRadioButton &&
>>>>>>>>>  409                     ((JRadioButton) 
>>>>>>>>> curElement).isVisible() &&
>>>>>>>>>  410                     ((JRadioButton) 
>>>>>>>>> curElement).isEnabled()){
>>>>>>>>>
>>>>>>>>>   It is possible to use 'continue' here to not put the other 
>>>>>>>>> code inside the 'if' block.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>  418                 else if (!srcFound){
>>>>>>>>>  422                 } else if (srcFound && nextBtn == null){
>>>>>>>>>
>>>>>>>>> It is not necessary to check the srcFound in the second 'if' 
>>>>>>>>> because it should already have true value.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>  444             if (newSelectedBtn != null){
>>>>>>>>>  445 newSelectedBtn.requestFocusInWindow();
>>>>>>>>>  446 newSelectedBtn.setSelected(true);
>>>>>>>>>  447             }
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Is it possible here that newSelectedBtn == eventSrc?
>>>>>>>>>
>>>>>>>>>  522         private void jumpToNextComponent(JRadioButton 
>>>>>>>>> btn, boolean next){
>>>>>>>>>
>>>>>>>>> The code that retrieves elements from a button group is also 
>>>>>>>>> used in the selectRadioButton()
>>>>>>>>> and can be moved to a separate method.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Alexandr.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> JPRT build succeeded, JCK tests for JRadiobutton and 
>>>>>>>>>> JCheckBox all passed.
>>>>>>>>>>
>>>>>>>>>> Thank you
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>>
>>>>>>>>>> Vivi
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20140917/197c7e1f/attachment.html>

From alexandr.scherbatiy at oracle.com  Thu Sep 18 07:55:23 2014
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Thu, 18 Sep 2014 11:55:23 +0400
Subject: <Swing Dev> [9] Review request for 8033699: Incorrect radio
 button behavior
In-Reply-To: <541A1495.8060003@oracle.com>
References: <5408B5E9.6080901@oracle.com> <540DA48F.2020409@oracle.com>
	<5410D71F.3040405@oracle.com> <541177AE.6040305@oracle.com>
	<541325C5.6040800@oracle.com> <5416B89F.5040301@oracle.com>
	<5417B09B.30807@oracle.com> <5417E925.4090601@oracle.com>
	<5419194C.9030001@oracle.com> <54193BC6.8020105@oracle.com>
	<541A1495.8060003@oracle.com>
Message-ID: <541A8FEB.6000607@oracle.com>


   The fix looks good to me.

   Thanks,
   Alexandr.

On 9/18/2014 3:09 AM, Vivi An wrote:
> Hello Alex,
>
> On 9/17/2014 12:44 AM, Alexander Scherbatiy wrote:
>> On 9/17/2014 9:17 AM, Vivi An wrote:
>>> You are right. Fixed now.
>>>
>>> http://cr.openjdk.java.net/~van/8033699/webrev.04/
>>
>>  528             if (e.isShiftDown()) {
>>  529                 if (e.getKeyCode() == KeyEvent.VK_TAB) {
>>  537                         // ... 
>> btnGroupInfo.jumpToNextComponent(false);
>>  539                 }
>>  540             } else if (e.getKeyCode() == KeyEvent.VK_TAB) {
>>  548                     // ... btnGroupInfo.jumpToNextComponent(true);
>>  550             }
>>
>>   The code in the if/else branches is almost the same except the 
>> true/false argument.
>>   I would suggest to unify them in the following way:
>>
>>      if (e.getKeyCode() == KeyEvent.VK_TAB) {
>>         // ... jumpToNextComponent(!e.isShiftDown())
>>      }
>>
> Fixed.
>>
>>  510             if (next)
>>  511                 KeyboardFocusManager.
>>  512 
>> getCurrentKeyboardFocusManager().focusNextComponent((JComponent)lastBtn);
>>  513             else
>>  514                 KeyboardFocusManager.
>>  515 
>> getCurrentKeyboardFocusManager().focusPreviousComponent((JComponent)firstBtn);
>>
>>  This code can be also a little bit optimized:
>>
>>     KeyboardFocusManager.getCurrentKeyboardFocusManager().
>>         focusPreviousComponent((JComponent) (next ? lastBtn : 
>> firstBtn));
>>
> It's different function call,  one for focusNextComponent and the 
> other for focusPreviousComponent, not able to optimize in suggested way.
>
> http://cr.openjdk.java.net/~van/8033699/webrev.05/
>
> Thanks
>
> Vivi
>
>>  Thanks,
>>  Alexandr.
>>
>>>
>>> Thank you
>>>
>>> ~ Vivi
>>>
>>> On 9/16/2014 12:39 AM, Alexander Scherbatiy wrote:
>>>>
>>>>   I have missed one more case:
>>>>  527         public void keyPressed(KeyEvent e) {
>>>>  528             if (e.getKeyCode() == KeyEvent.VK_TAB) {
>>>>                         // jumpToNextComponent(true)
>>>>  538             }
>>>>  539
>>>>  540             if (e.getKeyCode() == KeyEvent.VK_TAB && 
>>>> e.isShiftDown()) {
>>>>                         //jumpToNextComponent(false)
>>>>  550             }
>>>>  551         }
>>>>
>>>>   It seems that if e.isShiftDown() is true then both 
>>>> jumpToNextComponent(true) and jumpToNextComponent(false) methods 
>>>> can be called.
>>>>
>>>>   Thanks,
>>>>   Alexandr.
>>>>
>>>>
>>>> On 9/16/2014 7:38 AM, Vivi An wrote:
>>>>> Fixed. New Webrev: http://cr.openjdk.java.net/~van/8033699/webrev.03/
>>>>>
>>>>> Thanks Alex.
>>>>>
>>>>> Regards,
>>>>>
>>>>> ~ Vivi
>>>>>
>>>>> On 9/15/2014 2:59 AM, Alexander Scherbatiy wrote:
>>>>>> On 9/12/2014 8:56 PM, Vivi An wrote:
>>>>>>> Thanks Alexander.
>>>>>>>
>>>>>>> All items addressed except last one, please see comments inline.
>>>>>>> New Webrev: http://cr.openjdk.java.net/~van/8033699/webrev.02/
>>>>>>
>>>>>>     163         if ( keyListener != null ) {
>>>>>>
>>>>>>     Could you remove spaces in the brackets? After code 
>>>>>> formatting it should be "if (keyListener != null) {"
>>>>>>
>>>>>>>> 543             if (next && btnGroupInfo.lastBtn != null)
>>>>>>>>  544                 KeyboardFocusManager.
>>>>>>>>  545 
>>>>>>>> getCurrentKeyboardFocusManager().focusNextComponent((JComponent)btnGroupInfo.lastBtn);
>>>>>>>>  546             else if (btnGroupInfo.firstBtn != null)
>>>>>>>>  547                 KeyboardFocusManager.
>>>>>>>>  548 
>>>>>>>> getCurrentKeyboardFocusManager().focusPreviousComponent((JComponent)btnGroupInfo.firstBtn);
>>>>>>>>  549         }
>>>>>>>>
>>>>>>>> Should the first button be focused If next is true and last 
>>>>>>>> button is null?
>>>>>>> Don't think last button could be null when this function is 
>>>>>>> triggered, last and first will always be set in case there is at 
>>>>>>> least one valid (enabled and visible) radio button in the group.
>>>>>>
>>>>>>   It seems that lastBtn != null and firstBtn != null checks are 
>>>>>> not necessary in this case.
>>>>>>
>>>>>>   Thanks,
>>>>>>   Alexandr.
>>>>>>
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Alexandr.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>>
>>>>>>>>> ~ Vivi
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 9/8/2014 5:43 AM, Alexander Scherbatiy wrote:
>>>>>>>>>> On 9/4/2014 10:56 PM, Vivi An wrote:
>>>>>>>>>>> Hello,
>>>>>>>>>>>
>>>>>>>>>>> Please review fix for JDK-8033699.  Changes made:
>>>>>>>>>>> 1) When tab or shift-tab key pressed,  focus moved to 
>>>>>>>>>>> next/previous
>>>>>>>>>>> component outside of the radio button group
>>>>>>>>>>> 2) Using up/down or left/right arrow key to change selection 
>>>>>>>>>>> inside
>>>>>>>>>>> radio button group
>>>>>>>>>>>
>>>>>>>>>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8033699
>>>>>>>>>>> Webrev:http://cr.openjdk.java.net/~van/8033699/webrev.00/
>>>>>>>>>>
>>>>>>>>>>   56     private KeyListener keyListener = null;
>>>>>>>>>>   57     private KeyHandler handler = null;
>>>>>>>>>>
>>>>>>>>>> It seems that these both fields point to the same object. Is 
>>>>>>>>>> it possible to get rid of one of them?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>  152         if ( keyListener != null ) {
>>>>>>>>>>  153             button.removeKeyListener( keyListener );
>>>>>>>>>>  154         }
>>>>>>>>>>
>>>>>>>>>> Some UIs also set the listener to null in the 
>>>>>>>>>> uninstallUI()/uninstallListeners() methods (like 
>>>>>>>>>> BasicComboBoxUI or BasicColorChooserUI).
>>>>>>>>>> Should the keyListener also be set to null to free the 
>>>>>>>>>> KeyHandler object?
>>>>>>>>>>
>>>>>>>>>>  369         if (!(eventSrc instanceof JRadioButton &&
>>>>>>>>>>  370             ((JRadioButton) eventSrc).isVisible() && 
>>>>>>>>>> ((JRadioButton) eventSrc).isEnabled()))
>>>>>>>>>>
>>>>>>>>>> This check is used several times. It can be moved to a 
>>>>>>>>>> separate method.
>>>>>>>>>>
>>>>>>>>>>  373         // Get the button model from the source.
>>>>>>>>>>  374         ButtonModel model = ((AbstractButton) 
>>>>>>>>>> eventSrc).getModel();
>>>>>>>>>>  375         if (!(model instanceof DefaultButtonModel))
>>>>>>>>>>  376             return;
>>>>>>>>>>  377
>>>>>>>>>>  378         // If the button model is DefaultButtonModel, 
>>>>>>>>>> and use it, otherwise return.
>>>>>>>>>>  379         DefaultButtonModel bm = (DefaultButtonModel) model;
>>>>>>>>>>  380         if (bm == null)
>>>>>>>>>>  381             return;
>>>>>>>>>>
>>>>>>>>>> The second check is not necessary because (model instanceof 
>>>>>>>>>> DefaultButtonModel) returns false for null model.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>  404         AbstractButton curElement = null;
>>>>>>>>>>
>>>>>>>>>>   The curElement variable declaration could be moved into the 
>>>>>>>>>> 'while' block.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>  408             if (curElement instanceof JRadioButton &&
>>>>>>>>>>  409                     ((JRadioButton) 
>>>>>>>>>> curElement).isVisible() &&
>>>>>>>>>>  410                     ((JRadioButton) 
>>>>>>>>>> curElement).isEnabled()){
>>>>>>>>>>
>>>>>>>>>>   It is possible to use 'continue' here to not put the other 
>>>>>>>>>> code inside the 'if' block.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>  418                 else if (!srcFound){
>>>>>>>>>>  422                 } else if (srcFound && nextBtn == null){
>>>>>>>>>>
>>>>>>>>>> It is not necessary to check the srcFound in the second 'if' 
>>>>>>>>>> because it should already have true value.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>  444             if (newSelectedBtn != null){
>>>>>>>>>>  445 newSelectedBtn.requestFocusInWindow();
>>>>>>>>>>  446 newSelectedBtn.setSelected(true);
>>>>>>>>>>  447             }
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Is it possible here that newSelectedBtn == eventSrc?
>>>>>>>>>>
>>>>>>>>>>  522         private void jumpToNextComponent(JRadioButton 
>>>>>>>>>> btn, boolean next){
>>>>>>>>>>
>>>>>>>>>> The code that retrieves elements from a button group is also 
>>>>>>>>>> used in the selectRadioButton()
>>>>>>>>>> and can be moved to a separate method.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Alexandr.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> JPRT build succeeded, JCK tests for JRadiobutton and 
>>>>>>>>>>> JCheckBox all passed.
>>>>>>>>>>>
>>>>>>>>>>> Thank you
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>>
>>>>>>>>>>> Vivi
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>



From pooja.chopra at oracle.com  Thu Sep 18 09:00:14 2014
From: pooja.chopra at oracle.com (pooja chopra)
Date: Thu, 18 Sep 2014 14:30:14 +0530
Subject: <Swing Dev> [9] Review Request: 8058635 Fix type in client-related
 package for Compilation fail in
 sun/awt/datatransfer/SuplementaryCharactersTransferTest.java
Message-ID: <541A9F1E.9070409@oracle.com>

|Hello, |
||
|Please review a fix ||for| |the issue: |
||
|8058635| |[TEST_BUG] 
||sun/awt/datatransfer/SuplementaryCharactersTransferTest.java fails 
with Compilation error
|||
||
|Test bug fix.
|
||
|https://bugs.openjdk.java.net/browse/JDK-8058635|||
||
|The webrev is: http://cr.openjdk.java.net/~kshefov/8058635/webrev.00/

|||
||
|Thanks |
|Pooja|
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20140918/51f7fab9/attachment.html>

From Lily.LL.Pang at pccw.com  Thu Sep 18 02:09:01 2014
From: Lily.LL.Pang at pccw.com (Pang, Lily LL)
Date: Thu, 18 Sep 2014 10:09:01 +0800
Subject: <Swing Dev> JRE version for the fix of JDK-8042465
Message-ID: <6AF490692C1EF14B9EBBD78FBA1AF5C40B58EF5C@NTEXCV02.corphq.hk.pccw.com>

To Whom it may concern,

 

I am writing to seek for the advise concerning the below issue,

 

https://bugs.openjdk.java.net/browse/JDK-8042465
<https://bugs.openjdk.java.net/browse/JDK-8042465> 

 

This issue has already been marked "resolved", and I tried the latest
JRE for Mac (JRE 1.7.67) today, and the fix seems not yet included in
the latest JRE.

 

It would be much appreciated if there is a JRE release which includes
the above fix, or suggesting a target date for the mentioned JRE
release.

 

Thank you very much for your consideration, and I am looking forward to
your reply.

 

Should you have any queries or concerns, please feel free to email us.

 

Thanks and regards,

Lily

 



-------------------------------------------------------------------------------------------------------------------------
Disclaimer: This message (and any attachments) may contain information that is confidential, proprietary, privileged or otherwise protected by law. The message is intended solely for the named addressee (or a person responsible for delivering it to the addressee). If you are not the intended recipient of this message, you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this message in error, please destroy the message or delete it from your system immediately and notify the sender.
????: ???(?????)??????????????????????????????(???????????????)????????????????????????????????????????????????????????????????????????????????????????????????????????????/?????????????????????????????????????????????/??????????????????????????????????????????????????????
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20140918/1388c815/attachment.html>

From alexandr.scherbatiy at oracle.com  Thu Sep 18 09:18:02 2014
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Thu, 18 Sep 2014 13:18:02 +0400
Subject: <Swing Dev> [9] Review Request: 8058635 Fix type in
 client-related package for Compilation fail in
 sun/awt/datatransfer/SuplementaryCharactersTransferTest.java
In-Reply-To: <541A9F1E.9070409@oracle.com>
References: <541A9F1E.9070409@oracle.com>
Message-ID: <541AA34A.5050509@oracle.com>


   The fix looks good to me.

   Thanks,
   Alexandr.

On 9/18/2014 1:00 PM, pooja chopra wrote:
> |Hello, |
> ||
> |Please review a fix ||for| |the issue: |
> ||
> |8058635| |[TEST_BUG] 
> ||sun/awt/datatransfer/SuplementaryCharactersTransferTest.java fails 
> with Compilation error
> |||
> ||
> |Test bug fix.
> |
> ||
> |https://bugs.openjdk.java.net/browse/JDK-8058635|||
> ||
> |The webrev is: http://cr.openjdk.java.net/~kshefov/8058635/webrev.00/
>
> |||
> ||
> |Thanks |
> |Pooja|



From dmitry.markov at oracle.com  Thu Sep 18 10:13:10 2014
From: dmitry.markov at oracle.com (dmitry markov)
Date: Thu, 18 Sep 2014 14:13:10 +0400
Subject: <Swing Dev> JRE version for the fix of JDK-8042465
In-Reply-To: <6AF490692C1EF14B9EBBD78FBA1AF5C40B58EF5C@NTEXCV02.corphq.hk.pccw.com>
References: <6AF490692C1EF14B9EBBD78FBA1AF5C40B58EF5C@NTEXCV02.corphq.hk.pccw.com>
Message-ID: <541AB036.8020101@oracle.com>

Hello Lily,

You are right JDK-8042465 was fixed. Unfortunately the fix was not 
integrated in JRE 1.7.67. It was included into JRE 1.7.76 and JRE 
1.7.80-b02. As far as I know these JREs should be released in the 
beginning of 2015. Also JRE 1.8.20 contains the fix. It was released 
several weeks ago and now available for download.

Thanks,
Dmitry
On 18/09/2014 06:09, Pang, Lily LL wrote:
>
> To Whom it may concern,
>
> I am writing to seek for the advise concerning the below issue,
>
> https://bugs.openjdk.java.net/browse/JDK-8042465
>
> This issue has already been marked "resolved", and I tried the latest 
> JRE for Mac (JRE 1.7.67) today, and the fix seems not yet included in 
> the latest JRE.
>
> It would be much appreciated if there is a JRE release which includes 
> the above fix, or suggesting a target date for the mentioned JRE release.
>
> Thank you very much for your consideration, and I am looking forward 
> to your reply.
>
> Should you have any queries or concerns, please feel free to email us.
>
> Thanks and regards,
>
> Lily
>
> ------------------------------------------------------------------------
> -------------------------------------------------------------------------------------------------------------------------
> Disclaimer: This message (and any attachments) may contain information 
> that is confidential, proprietary, privileged or otherwise protected 
> by law. The message is intended solely for the named addressee (or a 
> person responsible for delivering it to the addressee). If you are not 
> the intended recipient of this message, you are not authorized to 
> read, print, retain, copy or disseminate this message or any part of 
> it. If you have received this message in error, please destroy the 
> message or delete it from your system immediately and notify the sender.
> ????: ???(?????)????????????????????? 
> ?????????(???????????????)?????????? 
> ????? ???????????????????????????? 
> ??????????????????????????????????? 
> ? ?????????????????????????????/???? 
> ?????????????????????????????? ???? 
> ???????/??????????????????????????? 
> ????????????????????????? ??

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20140918/6845fa67/attachment.html>

From yuri.nesterenko at oracle.com  Thu Sep 18 10:48:46 2014
From: yuri.nesterenko at oracle.com (Yuri Nesterenko)
Date: Thu, 18 Sep 2014 14:48:46 +0400
Subject: <Swing Dev> [9] Review request for 8058726: Update regtests using
 sun.awt.OSInfo, part 1
Message-ID: <541AB88E.406@oracle.com>

Colleagues,

please review this change in tests only:

http://cr.openjdk.java.net/~yan/8058726/webrev.00 and
http://cr.openjdk.java.net/~yan/8058726/webrev.diff.00

for a bug https://bugs.openjdk.java.net/browse/JDK-8058726

Thanks,
-yan


From alexandr.scherbatiy at oracle.com  Thu Sep 18 12:30:47 2014
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Thu, 18 Sep 2014 16:30:47 +0400
Subject: <Swing Dev> [9] Review request for 8058726: Update regtests
 using sun.awt.OSInfo, part 1
In-Reply-To: <541AB88E.406@oracle.com>
References: <541AB88E.406@oracle.com>
Message-ID: <541AD077.2020008@oracle.com>


   The fix looks good to me.

   Thanks,
   Alexandr.

On 9/18/2014 2:48 PM, Yuri Nesterenko wrote:
> Colleagues,
>
> please review this change in tests only:
>
> http://cr.openjdk.java.net/~yan/8058726/webrev.00 and
> http://cr.openjdk.java.net/~yan/8058726/webrev.diff.00
>
> for a bug https://bugs.openjdk.java.net/browse/JDK-8058726
>
> Thanks,
> -yan



From Sergey.Bylokhov at oracle.com  Thu Sep 18 12:57:26 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 18 Sep 2014 16:57:26 +0400
Subject: <Swing Dev> [9] Review Request: 8058635 Fix type in
 client-related package for Compilation fail in
 sun/awt/datatransfer/SuplementaryCharactersTransferTest.java
In-Reply-To: <541A9F1E.9070409@oracle.com>
References: <541A9F1E.9070409@oracle.com>
Message-ID: <541AD6B6.1040107@oracle.com>

Looks fine.
On 18.09.2014 13:00, pooja chopra wrote:
> |Hello, |
> ||
> |Please review a fix ||for| |the issue: |
> ||
> |8058635| |[TEST_BUG] 
> ||sun/awt/datatransfer/SuplementaryCharactersTransferTest.java fails 
> with Compilation error
> |||
> ||
> |Test bug fix.
> |
> ||
> |https://bugs.openjdk.java.net/browse/JDK-8058635|||
> ||
> |The webrev is: http://cr.openjdk.java.net/~kshefov/8058635/webrev.00/
>
> |||
> ||
> |Thanks |
> |Pooja|


-- 
Best regards, Sergey.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20140918/f182ede4/attachment.html>

From yuri.nesterenko at oracle.com  Thu Sep 18 13:23:53 2014
From: yuri.nesterenko at oracle.com (Yuri Nesterenko)
Date: Thu, 18 Sep 2014 17:23:53 +0400
Subject: <Swing Dev> [9] Review request for 8058726: Update regtests
 using sun.awt.OSInfo, part 1
In-Reply-To: <541AD077.2020008@oracle.com>
References: <541AB88E.406@oracle.com> <541AD077.2020008@oracle.com>
Message-ID: <541ADCE9.2000702@oracle.com>

Great, thank you!

-yan

On 09/18/2014 04:30 PM, Alexander Scherbatiy wrote:
>
>    The fix looks good to me.
>
>    Thanks,
>    Alexandr.
>
> On 9/18/2014 2:48 PM, Yuri Nesterenko wrote:
>> Colleagues,
>>
>> please review this change in tests only:
>>
>> http://cr.openjdk.java.net/~yan/8058726/webrev.00 and
>> http://cr.openjdk.java.net/~yan/8058726/webrev.diff.00
>>
>> for a bug https://bugs.openjdk.java.net/browse/JDK-8058726
>>
>> Thanks,
>> -yan
>



From vivi.an at oracle.com  Thu Sep 18 17:23:02 2014
From: vivi.an at oracle.com (Vivi An)
Date: Thu, 18 Sep 2014 10:23:02 -0700
Subject: <Swing Dev> [9] Review request for 8033699: Incorrect radio
 button behavior
In-Reply-To: <541A8FEB.6000607@oracle.com>
References: <5408B5E9.6080901@oracle.com> <540DA48F.2020409@oracle.com>
	<5410D71F.3040405@oracle.com> <541177AE.6040305@oracle.com>
	<541325C5.6040800@oracle.com> <5416B89F.5040301@oracle.com>
	<5417B09B.30807@oracle.com> <5417E925.4090601@oracle.com>
	<5419194C.9030001@oracle.com> <54193BC6.8020105@oracle.com>
	<541A1495.8060003@oracle.com> <541A8FEB.6000607@oracle.com>
Message-ID: <541B14F6.4070603@oracle.com>

Thank you Alexandr.

Need one more review for this. Alexander, could you please take a look 
at below fix?
http://cr.openjdk.java.net/~van/8033699/webrev.05/

Thanks

Vivi

On 9/18/2014 12:55 AM, Alexander Scherbatiy wrote:
>
>   The fix looks good to me.
>
>   Thanks,
>   Alexandr.
>
> On 9/18/2014 3:09 AM, Vivi An wrote:
>> Hello Alex,
>>
>> On 9/17/2014 12:44 AM, Alexander Scherbatiy wrote:
>>> On 9/17/2014 9:17 AM, Vivi An wrote:
>>>> You are right. Fixed now.
>>>>
>>>> http://cr.openjdk.java.net/~van/8033699/webrev.04/
>>>
>>>  528             if (e.isShiftDown()) {
>>>  529                 if (e.getKeyCode() == KeyEvent.VK_TAB) {
>>>  537                         // ... 
>>> btnGroupInfo.jumpToNextComponent(false);
>>>  539                 }
>>>  540             } else if (e.getKeyCode() == KeyEvent.VK_TAB) {
>>>  548                     // ... btnGroupInfo.jumpToNextComponent(true);
>>>  550             }
>>>
>>>   The code in the if/else branches is almost the same except the 
>>> true/false argument.
>>>   I would suggest to unify them in the following way:
>>>
>>>      if (e.getKeyCode() == KeyEvent.VK_TAB) {
>>>         // ... jumpToNextComponent(!e.isShiftDown())
>>>      }
>>>
>> Fixed.
>>>
>>>  510             if (next)
>>>  511                 KeyboardFocusManager.
>>>  512 
>>> getCurrentKeyboardFocusManager().focusNextComponent((JComponent)lastBtn);
>>>  513             else
>>>  514                 KeyboardFocusManager.
>>>  515 
>>> getCurrentKeyboardFocusManager().focusPreviousComponent((JComponent)firstBtn);
>>>
>>>  This code can be also a little bit optimized:
>>>
>>>     KeyboardFocusManager.getCurrentKeyboardFocusManager().
>>>         focusPreviousComponent((JComponent) (next ? lastBtn : 
>>> firstBtn));
>>>
>> It's different function call,  one for focusNextComponent and the 
>> other for focusPreviousComponent, not able to optimize in suggested way.
>>
>> http://cr.openjdk.java.net/~van/8033699/webrev.05/
>>
>> Thanks
>>
>> Vivi
>>
>>>  Thanks,
>>>  Alexandr.
>>>
>>>>
>>>> Thank you
>>>>
>>>> ~ Vivi
>>>>
>>>> On 9/16/2014 12:39 AM, Alexander Scherbatiy wrote:
>>>>>
>>>>>   I have missed one more case:
>>>>>  527         public void keyPressed(KeyEvent e) {
>>>>>  528             if (e.getKeyCode() == KeyEvent.VK_TAB) {
>>>>>                         // jumpToNextComponent(true)
>>>>>  538             }
>>>>>  539
>>>>>  540             if (e.getKeyCode() == KeyEvent.VK_TAB && 
>>>>> e.isShiftDown()) {
>>>>>                         //jumpToNextComponent(false)
>>>>>  550             }
>>>>>  551         }
>>>>>
>>>>>   It seems that if e.isShiftDown() is true then both 
>>>>> jumpToNextComponent(true) and jumpToNextComponent(false) methods 
>>>>> can be called.
>>>>>
>>>>>   Thanks,
>>>>>   Alexandr.
>>>>>
>>>>>
>>>>> On 9/16/2014 7:38 AM, Vivi An wrote:
>>>>>> Fixed. New Webrev: 
>>>>>> http://cr.openjdk.java.net/~van/8033699/webrev.03/
>>>>>>
>>>>>> Thanks Alex.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> ~ Vivi
>>>>>>
>>>>>> On 9/15/2014 2:59 AM, Alexander Scherbatiy wrote:
>>>>>>> On 9/12/2014 8:56 PM, Vivi An wrote:
>>>>>>>> Thanks Alexander.
>>>>>>>>
>>>>>>>> All items addressed except last one, please see comments inline.
>>>>>>>> New Webrev: http://cr.openjdk.java.net/~van/8033699/webrev.02/
>>>>>>>
>>>>>>>     163         if ( keyListener != null ) {
>>>>>>>
>>>>>>>     Could you remove spaces in the brackets? After code 
>>>>>>> formatting it should be "if (keyListener != null) {"
>>>>>>>
>>>>>>>>> 543             if (next && btnGroupInfo.lastBtn != null)
>>>>>>>>>  544                 KeyboardFocusManager.
>>>>>>>>>  545 
>>>>>>>>> getCurrentKeyboardFocusManager().focusNextComponent((JComponent)btnGroupInfo.lastBtn);
>>>>>>>>>  546             else if (btnGroupInfo.firstBtn != null)
>>>>>>>>>  547                 KeyboardFocusManager.
>>>>>>>>>  548 
>>>>>>>>> getCurrentKeyboardFocusManager().focusPreviousComponent((JComponent)btnGroupInfo.firstBtn);
>>>>>>>>>  549         }
>>>>>>>>>
>>>>>>>>> Should the first button be focused If next is true and last 
>>>>>>>>> button is null?
>>>>>>>> Don't think last button could be null when this function is 
>>>>>>>> triggered, last and first will always be set in case there is 
>>>>>>>> at least one valid (enabled and visible) radio button in the 
>>>>>>>> group.
>>>>>>>
>>>>>>>   It seems that lastBtn != null and firstBtn != null checks are 
>>>>>>> not necessary in this case.
>>>>>>>
>>>>>>>   Thanks,
>>>>>>>   Alexandr.
>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Alexandr.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>>
>>>>>>>>>> ~ Vivi
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 9/8/2014 5:43 AM, Alexander Scherbatiy wrote:
>>>>>>>>>>> On 9/4/2014 10:56 PM, Vivi An wrote:
>>>>>>>>>>>> Hello,
>>>>>>>>>>>>
>>>>>>>>>>>> Please review fix for JDK-8033699.  Changes made:
>>>>>>>>>>>> 1) When tab or shift-tab key pressed,  focus moved to 
>>>>>>>>>>>> next/previous
>>>>>>>>>>>> component outside of the radio button group
>>>>>>>>>>>> 2) Using up/down or left/right arrow key to change 
>>>>>>>>>>>> selection inside
>>>>>>>>>>>> radio button group
>>>>>>>>>>>>
>>>>>>>>>>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8033699
>>>>>>>>>>>> Webrev:http://cr.openjdk.java.net/~van/8033699/webrev.00/
>>>>>>>>>>>
>>>>>>>>>>>   56     private KeyListener keyListener = null;
>>>>>>>>>>>   57     private KeyHandler handler = null;
>>>>>>>>>>>
>>>>>>>>>>> It seems that these both fields point to the same object. Is 
>>>>>>>>>>> it possible to get rid of one of them?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>  152         if ( keyListener != null ) {
>>>>>>>>>>>  153             button.removeKeyListener( keyListener );
>>>>>>>>>>>  154         }
>>>>>>>>>>>
>>>>>>>>>>> Some UIs also set the listener to null in the 
>>>>>>>>>>> uninstallUI()/uninstallListeners() methods (like 
>>>>>>>>>>> BasicComboBoxUI or BasicColorChooserUI).
>>>>>>>>>>> Should the keyListener also be set to null to free the 
>>>>>>>>>>> KeyHandler object?
>>>>>>>>>>>
>>>>>>>>>>>  369         if (!(eventSrc instanceof JRadioButton &&
>>>>>>>>>>>  370             ((JRadioButton) eventSrc).isVisible() && 
>>>>>>>>>>> ((JRadioButton) eventSrc).isEnabled()))
>>>>>>>>>>>
>>>>>>>>>>> This check is used several times. It can be moved to a 
>>>>>>>>>>> separate method.
>>>>>>>>>>>
>>>>>>>>>>>  373         // Get the button model from the source.
>>>>>>>>>>>  374         ButtonModel model = ((AbstractButton) 
>>>>>>>>>>> eventSrc).getModel();
>>>>>>>>>>>  375         if (!(model instanceof DefaultButtonModel))
>>>>>>>>>>>  376             return;
>>>>>>>>>>>  377
>>>>>>>>>>>  378         // If the button model is DefaultButtonModel, 
>>>>>>>>>>> and use it, otherwise return.
>>>>>>>>>>>  379         DefaultButtonModel bm = (DefaultButtonModel) 
>>>>>>>>>>> model;
>>>>>>>>>>>  380         if (bm == null)
>>>>>>>>>>>  381             return;
>>>>>>>>>>>
>>>>>>>>>>> The second check is not necessary because (model instanceof 
>>>>>>>>>>> DefaultButtonModel) returns false for null model.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>  404         AbstractButton curElement = null;
>>>>>>>>>>>
>>>>>>>>>>>   The curElement variable declaration could be moved into 
>>>>>>>>>>> the 'while' block.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>  408             if (curElement instanceof JRadioButton &&
>>>>>>>>>>>  409                     ((JRadioButton) 
>>>>>>>>>>> curElement).isVisible() &&
>>>>>>>>>>>  410                     ((JRadioButton) 
>>>>>>>>>>> curElement).isEnabled()){
>>>>>>>>>>>
>>>>>>>>>>>   It is possible to use 'continue' here to not put the other 
>>>>>>>>>>> code inside the 'if' block.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>  418                 else if (!srcFound){
>>>>>>>>>>>  422                 } else if (srcFound && nextBtn == null){
>>>>>>>>>>>
>>>>>>>>>>> It is not necessary to check the srcFound in the second 'if' 
>>>>>>>>>>> because it should already have true value.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>  444             if (newSelectedBtn != null){
>>>>>>>>>>>  445 newSelectedBtn.requestFocusInWindow();
>>>>>>>>>>>  446 newSelectedBtn.setSelected(true);
>>>>>>>>>>>  447             }
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Is it possible here that newSelectedBtn == eventSrc?
>>>>>>>>>>>
>>>>>>>>>>>  522         private void jumpToNextComponent(JRadioButton 
>>>>>>>>>>> btn, boolean next){
>>>>>>>>>>>
>>>>>>>>>>> The code that retrieves elements from a button group is also 
>>>>>>>>>>> used in the selectRadioButton()
>>>>>>>>>>> and can be moved to a separate method.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Alexandr.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> JPRT build succeeded, JCK tests for JRadiobutton and 
>>>>>>>>>>>> JCheckBox all passed.
>>>>>>>>>>>>
>>>>>>>>>>>> Thank you
>>>>>>>>>>>>
>>>>>>>>>>>> Regards,
>>>>>>>>>>>>
>>>>>>>>>>>> Vivi
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>



From alexander.zvegintsev at oracle.com  Fri Sep 19 10:22:08 2014
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Fri, 19 Sep 2014 14:22:08 +0400
Subject: <Swing Dev> [9] Review request for 8033699: Incorrect radio
 button behavior
In-Reply-To: <541B14F6.4070603@oracle.com>
References: <5408B5E9.6080901@oracle.com> <540DA48F.2020409@oracle.com>
	<5410D71F.3040405@oracle.com> <541177AE.6040305@oracle.com>
	<541325C5.6040800@oracle.com> <5416B89F.5040301@oracle.com>
	<5417B09B.30807@oracle.com> <5417E925.4090601@oracle.com>
	<5419194C.9030001@oracle.com> <54193BC6.8020105@oracle.com>
	<541A1495.8060003@oracle.com> <541A8FEB.6000607@oracle.com>
	<541B14F6.4070603@oracle.com>
Message-ID: <541C03D0.1030300@oracle.com>

Hello Vivi,

Since you are touching this code, could you please add missing @Override 
annotations?

         void jumpToNextComponent(boolean next) {
             if (!getButtonGroupInfo())
                 return;

This leads to an issue: we can't switch to a next component with a TAB 
key if JRadioButton
is not in a ButtonGroup. (It may be a reason to write another test.)

     private boolean isValidRadioButtonObj(Object obj) {
         return ((obj != null) && (obj instanceof JRadioButton) &&
                     ((JRadioButton) obj).isVisible() &&
                     ((JRadioButton) obj).isEnabled());
     }

There is no need to do a null check before instanceof [1]

      * @param evt, the event object.
      * @param next, indicate if it's next one
      */
     private void selectRadioButton(ActionEvent event, boolean next) {

typo: evt should be event


I run the test and it fails at least on Linux. It happens due to a big 
auto delay:
Robot holds key for too long so system sends TAB key multiple time.
So I think auto delay should be about 100 ms.

robot.setAutoDelay(300);

It is enough to call it once after Robot creation, this will 
automatically add a 300 ms delay
between Robot generated events (such as keyPress, mouseMove, etc).
If you really want a delay between test runs please use Thread.sleep().

I see many calls to hitKey() and then to realSync(), so we can move 
realSync() call to the end of hitKey().
checkResult() may be combined with runTest(), hence we call one function 
instead of two.

         int sum = 0;
         for (int i = 0; i < testResults.length; i++) {
             if (testResults[i] == false)
                 sum++;
         }

         if (sum != 0){
             System.out.println("Total 5 tests, failed test(s): " + sum);
             throw new RuntimeException("Test failed.");
         }


I don't think that this logic is applicable here, each test depends on 
previous: Test2 failure means that
focus is on a wrong component, so all following tests will fail.
BTW, this code is unreachable in case of test failure, since 
checkResult() already throws an exception.

http://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.20.2

--
Thanks,
Alexander.

On 09/18/2014 09:23 PM, Vivi An wrote:
> Thank you Alexandr.
>
> Need one more review for this. Alexander, could you please take a look 
> at below fix?
> http://cr.openjdk.java.net/~van/8033699/webrev.05/
>
> Thanks
>
> Vivi
>
> On 9/18/2014 12:55 AM, Alexander Scherbatiy wrote:
>>
>>   The fix looks good to me.
>>
>>   Thanks,
>>   Alexandr.
>>
>> On 9/18/2014 3:09 AM, Vivi An wrote:
>>> Hello Alex,
>>>
>>> On 9/17/2014 12:44 AM, Alexander Scherbatiy wrote:
>>>> On 9/17/2014 9:17 AM, Vivi An wrote:
>>>>> You are right. Fixed now.
>>>>>
>>>>> http://cr.openjdk.java.net/~van/8033699/webrev.04/
>>>>
>>>>  528             if (e.isShiftDown()) {
>>>>  529                 if (e.getKeyCode() == KeyEvent.VK_TAB) {
>>>>  537                         // ... 
>>>> btnGroupInfo.jumpToNextComponent(false);
>>>>  539                 }
>>>>  540             } else if (e.getKeyCode() == KeyEvent.VK_TAB) {
>>>>  548                     // ... 
>>>> btnGroupInfo.jumpToNextComponent(true);
>>>>  550             }
>>>>
>>>>   The code in the if/else branches is almost the same except the 
>>>> true/false argument.
>>>>   I would suggest to unify them in the following way:
>>>>
>>>>      if (e.getKeyCode() == KeyEvent.VK_TAB) {
>>>>         // ... jumpToNextComponent(!e.isShiftDown())
>>>>      }
>>>>
>>> Fixed.
>>>>
>>>>  510             if (next)
>>>>  511                 KeyboardFocusManager.
>>>>  512 
>>>> getCurrentKeyboardFocusManager().focusNextComponent((JComponent)lastBtn);
>>>>  513             else
>>>>  514                 KeyboardFocusManager.
>>>>  515 
>>>> getCurrentKeyboardFocusManager().focusPreviousComponent((JComponent)firstBtn);
>>>>
>>>>  This code can be also a little bit optimized:
>>>>
>>>>     KeyboardFocusManager.getCurrentKeyboardFocusManager().
>>>>         focusPreviousComponent((JComponent) (next ? lastBtn : 
>>>> firstBtn));
>>>>
>>> It's different function call,  one for focusNextComponent and the 
>>> other for focusPreviousComponent, not able to optimize in suggested 
>>> way.
>>>
>>> http://cr.openjdk.java.net/~van/8033699/webrev.05/
>>>
>>> Thanks
>>>
>>> Vivi
>>>
>>>>  Thanks,
>>>>  Alexandr.
>>>>
>>>>>
>>>>> Thank you
>>>>>
>>>>> ~ Vivi
>>>>>
>>>>> On 9/16/2014 12:39 AM, Alexander Scherbatiy wrote:
>>>>>>
>>>>>>   I have missed one more case:
>>>>>>  527         public void keyPressed(KeyEvent e) {
>>>>>>  528             if (e.getKeyCode() == KeyEvent.VK_TAB) {
>>>>>>                         // jumpToNextComponent(true)
>>>>>>  538             }
>>>>>>  539
>>>>>>  540             if (e.getKeyCode() == KeyEvent.VK_TAB && 
>>>>>> e.isShiftDown()) {
>>>>>>                         //jumpToNextComponent(false)
>>>>>>  550             }
>>>>>>  551         }
>>>>>>
>>>>>>   It seems that if e.isShiftDown() is true then both 
>>>>>> jumpToNextComponent(true) and jumpToNextComponent(false) methods 
>>>>>> can be called.
>>>>>>
>>>>>>   Thanks,
>>>>>>   Alexandr.
>>>>>>
>>>>>>
>>>>>> On 9/16/2014 7:38 AM, Vivi An wrote:
>>>>>>> Fixed. New Webrev: 
>>>>>>> http://cr.openjdk.java.net/~van/8033699/webrev.03/
>>>>>>>
>>>>>>> Thanks Alex.
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> ~ Vivi
>>>>>>>
>>>>>>> On 9/15/2014 2:59 AM, Alexander Scherbatiy wrote:
>>>>>>>> On 9/12/2014 8:56 PM, Vivi An wrote:
>>>>>>>>> Thanks Alexander.
>>>>>>>>>
>>>>>>>>> All items addressed except last one, please see comments inline.
>>>>>>>>> New Webrev: http://cr.openjdk.java.net/~van/8033699/webrev.02/
>>>>>>>>
>>>>>>>>     163         if ( keyListener != null ) {
>>>>>>>>
>>>>>>>>     Could you remove spaces in the brackets? After code 
>>>>>>>> formatting it should be "if (keyListener != null) {"
>>>>>>>>
>>>>>>>>>> 543             if (next && btnGroupInfo.lastBtn != null)
>>>>>>>>>>  544                 KeyboardFocusManager.
>>>>>>>>>>  545 
>>>>>>>>>> getCurrentKeyboardFocusManager().focusNextComponent((JComponent)btnGroupInfo.lastBtn);
>>>>>>>>>>  546             else if (btnGroupInfo.firstBtn != null)
>>>>>>>>>>  547                 KeyboardFocusManager.
>>>>>>>>>>  548 
>>>>>>>>>> getCurrentKeyboardFocusManager().focusPreviousComponent((JComponent)btnGroupInfo.firstBtn);
>>>>>>>>>>  549         }
>>>>>>>>>>
>>>>>>>>>> Should the first button be focused If next is true and last 
>>>>>>>>>> button is null?
>>>>>>>>> Don't think last button could be null when this function is 
>>>>>>>>> triggered, last and first will always be set in case there is 
>>>>>>>>> at least one valid (enabled and visible) radio button in the 
>>>>>>>>> group.
>>>>>>>>
>>>>>>>>   It seems that lastBtn != null and firstBtn != null checks are 
>>>>>>>> not necessary in this case.
>>>>>>>>
>>>>>>>>   Thanks,
>>>>>>>>   Alexandr.
>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Alexandr.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>>
>>>>>>>>>>> ~ Vivi
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 9/8/2014 5:43 AM, Alexander Scherbatiy wrote:
>>>>>>>>>>>> On 9/4/2014 10:56 PM, Vivi An wrote:
>>>>>>>>>>>>> Hello,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Please review fix for JDK-8033699. Changes made:
>>>>>>>>>>>>> 1) When tab or shift-tab key pressed, focus moved to 
>>>>>>>>>>>>> next/previous
>>>>>>>>>>>>> component outside of the radio button group
>>>>>>>>>>>>> 2) Using up/down or left/right arrow key to change 
>>>>>>>>>>>>> selection inside
>>>>>>>>>>>>> radio button group
>>>>>>>>>>>>>
>>>>>>>>>>>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8033699
>>>>>>>>>>>>> Webrev:http://cr.openjdk.java.net/~van/8033699/webrev.00/
>>>>>>>>>>>>
>>>>>>>>>>>>   56     private KeyListener keyListener = null;
>>>>>>>>>>>>   57     private KeyHandler handler = null;
>>>>>>>>>>>>
>>>>>>>>>>>> It seems that these both fields point to the same object. 
>>>>>>>>>>>> Is it possible to get rid of one of them?
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>  152         if ( keyListener != null ) {
>>>>>>>>>>>>  153             button.removeKeyListener( keyListener );
>>>>>>>>>>>>  154         }
>>>>>>>>>>>>
>>>>>>>>>>>> Some UIs also set the listener to null in the 
>>>>>>>>>>>> uninstallUI()/uninstallListeners() methods (like 
>>>>>>>>>>>> BasicComboBoxUI or BasicColorChooserUI).
>>>>>>>>>>>> Should the keyListener also be set to null to free the 
>>>>>>>>>>>> KeyHandler object?
>>>>>>>>>>>>
>>>>>>>>>>>>  369         if (!(eventSrc instanceof JRadioButton &&
>>>>>>>>>>>>  370             ((JRadioButton) eventSrc).isVisible() && 
>>>>>>>>>>>> ((JRadioButton) eventSrc).isEnabled()))
>>>>>>>>>>>>
>>>>>>>>>>>> This check is used several times. It can be moved to a 
>>>>>>>>>>>> separate method.
>>>>>>>>>>>>
>>>>>>>>>>>>  373         // Get the button model from the source.
>>>>>>>>>>>>  374         ButtonModel model = ((AbstractButton) 
>>>>>>>>>>>> eventSrc).getModel();
>>>>>>>>>>>>  375         if (!(model instanceof DefaultButtonModel))
>>>>>>>>>>>>  376             return;
>>>>>>>>>>>>  377
>>>>>>>>>>>>  378         // If the button model is DefaultButtonModel, 
>>>>>>>>>>>> and use it, otherwise return.
>>>>>>>>>>>>  379         DefaultButtonModel bm = (DefaultButtonModel) 
>>>>>>>>>>>> model;
>>>>>>>>>>>>  380         if (bm == null)
>>>>>>>>>>>>  381             return;
>>>>>>>>>>>>
>>>>>>>>>>>> The second check is not necessary because (model instanceof 
>>>>>>>>>>>> DefaultButtonModel) returns false for null model.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>  404         AbstractButton curElement = null;
>>>>>>>>>>>>
>>>>>>>>>>>>   The curElement variable declaration could be moved into 
>>>>>>>>>>>> the 'while' block.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>  408             if (curElement instanceof JRadioButton &&
>>>>>>>>>>>>  409                     ((JRadioButton) 
>>>>>>>>>>>> curElement).isVisible() &&
>>>>>>>>>>>>  410                     ((JRadioButton) 
>>>>>>>>>>>> curElement).isEnabled()){
>>>>>>>>>>>>
>>>>>>>>>>>>   It is possible to use 'continue' here to not put the 
>>>>>>>>>>>> other code inside the 'if' block.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>  418                 else if (!srcFound){
>>>>>>>>>>>>  422                 } else if (srcFound && nextBtn == null){
>>>>>>>>>>>>
>>>>>>>>>>>> It is not necessary to check the srcFound in the second 
>>>>>>>>>>>> 'if' because it should already have true value.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>  444             if (newSelectedBtn != null){
>>>>>>>>>>>>  445 newSelectedBtn.requestFocusInWindow();
>>>>>>>>>>>>  446 newSelectedBtn.setSelected(true);
>>>>>>>>>>>>  447             }
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Is it possible here that newSelectedBtn == eventSrc?
>>>>>>>>>>>>
>>>>>>>>>>>>  522         private void jumpToNextComponent(JRadioButton 
>>>>>>>>>>>> btn, boolean next){
>>>>>>>>>>>>
>>>>>>>>>>>> The code that retrieves elements from a button group is 
>>>>>>>>>>>> also used in the selectRadioButton()
>>>>>>>>>>>> and can be moved to a separate method.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Alexandr.
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> JPRT build succeeded, JCK tests for JRadiobutton and 
>>>>>>>>>>>>> JCheckBox all passed.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thank you
>>>>>>>>>>>>>
>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Vivi
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>



From pooja.chopra at oracle.com  Fri Sep 19 11:34:01 2014
From: pooja.chopra at oracle.com (pooja chopra)
Date: Fri, 19 Sep 2014 17:04:01 +0530
Subject: <Swing Dev> [9] Review Request: JDK-8058805 Fix type in
 client-related package for tray.policy file missing in
 java/awt/TrayIcon/SecurityCheck/NoPermissionTest
Message-ID: <541C14A9.6000304@oracle.com>

|Hello, |
||
|Please review a fix ||for| |the issue: |
||
|8058805| |[TEST_BUG] 
java/awt/TrayIcon/SecurityCheck/NoPermissionTest||/|||NoPermissionTest.java| 
fails with Cant find Policy file error.|||
||
|Test bug fix.
|
||
|https://bugs.openjdk.java.net/browse/JDK-8058805|||
||
|
The webrev is: http://cr.openjdk.java.net/~kshefov/8058805/webrev.00

|||
||
|Thanks |
|Pooja|
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20140919/9c30e114/attachment.html>

From anton.tarasov at oracle.com  Mon Sep 22 13:36:16 2014
From: anton.tarasov at oracle.com (Anton V. Tarasov)
Date: Mon, 22 Sep 2014 17:36:16 +0400
Subject: <Swing Dev> <SwingDev> [9] Review request: JDK-8058870 Mac:
 JFXPanel deadlocks in jnlp mode
Message-ID: <542025D0.3040005@oracle.com>

Hello,

Please review a fix:

https://bugs.openjdk.java.net/browse/JDK-8058870
http://cr.openjdk.java.net/~ant/JDK-8058870/webrev.0

A deadlock has been revealed on MacOS X with JFXPanel involved in an app launched via JNLP. Find 
more details in jira, please.

Thanks,
Anton.


From Sergey.Bylokhov at oracle.com  Mon Sep 22 13:52:17 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 22 Sep 2014 17:52:17 +0400
Subject: <Swing Dev> <SwingDev> [9] Review request: JDK-8058870 Mac:
 JFXPanel deadlocks in jnlp mode
In-Reply-To: <542025D0.3040005@oracle.com>
References: <542025D0.3040005@oracle.com>
Message-ID: <54202991.1070903@oracle.com>

Hi, Anton.
I think after the fix,  getFlag+setFlag are not atomic anymore in the 
revalidate().

On 22.09.2014 17:36, Anton V. Tarasov wrote:
> Hello,
>
> Please review a fix:
>
> https://bugs.openjdk.java.net/browse/JDK-8058870
> http://cr.openjdk.java.net/~ant/JDK-8058870/webrev.0
>
> A deadlock has been revealed on MacOS X with JFXPanel involved in an 
> app launched via JNLP. Find more details in jira, please.
>
> Thanks,
> Anton.


-- 
Best regards, Sergey.



From anton.tarasov at oracle.com  Mon Sep 22 15:00:38 2014
From: anton.tarasov at oracle.com (Anton V. Tarasov)
Date: Mon, 22 Sep 2014 19:00:38 +0400
Subject: <Swing Dev> <SwingDev> [9] Review request: JDK-8058870 Mac:
 JFXPanel deadlocks in jnlp mode
In-Reply-To: <54202991.1070903@oracle.com>
References: <542025D0.3040005@oracle.com> <54202991.1070903@oracle.com>
Message-ID: <54203996.8050900@oracle.com>

On 9/22/14 5:52 PM, Sergey Bylokhov wrote:
> Hi, Anton.
> I think after the fix,  getFlag+setFlag are not atomic anymore in the 
> revalidate().

I assumed revalidate() is called on EDT in case of pure Swing, and may 
be called from JavaFX App Thread in case of swing/javafx interop only.
However, I didn't take into account swing/awt mixing where this 
particular method is "allowed" to be called from non-EDT threads.
In this case, you're right, the getFlag+setFlag, being called on two 
concurrent threads, are not synchronized.

Ok, I'm still trying to keep the scheme lock-free. What do you think of 
the following approach?

http://cr.openjdk.java.net/~ant/JDK-8058870/webrev.1

We're eliminating the flag and using AtomicBoolean instead.

The "flags" field is private. REVALIDATE_RUNNABLE_SCHEDULED is only used 
for this single case. So, the only concern is serialization, for which I 
reinitialize the new field in readObject. At the worst case, we will 
have maximum two revalidate runnables in the queue, which shouldn't hit 
performance any noticeably (and as far as I understand, this code cares 
about performance only).

Thanks,
Anton.

>
> On 22.09.2014 17:36, Anton V. Tarasov wrote:
>> Hello,
>>
>> Please review a fix:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8058870
>> http://cr.openjdk.java.net/~ant/JDK-8058870/webrev.0
>>
>> A deadlock has been revealed on MacOS X with JFXPanel involved in an 
>> app launched via JNLP. Find more details in jira, please.
>>
>> Thanks,
>> Anton.
>
>



From Sergey.Bylokhov at oracle.com  Tue Sep 23 11:57:28 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 23 Sep 2014 15:57:28 +0400
Subject: <Swing Dev> <SwingDev> [9] Review request: JDK-8058870 Mac:
 JFXPanel deadlocks in jnlp mode
In-Reply-To: <54203996.8050900@oracle.com>
References: <542025D0.3040005@oracle.com> <54202991.1070903@oracle.com>
	<54203996.8050900@oracle.com>
Message-ID: <54216028.80104@oracle.com>

Hi, Anton.
The fix looks good.

On 22.09.2014 19:00, Anton V. Tarasov wrote:
> On 9/22/14 5:52 PM, Sergey Bylokhov wrote:
>> Hi, Anton.
>> I think after the fix,  getFlag+setFlag are not atomic anymore in the 
>> revalidate().
>
> I assumed revalidate() is called on EDT in case of pure Swing, and may 
> be called from JavaFX App Thread in case of swing/javafx interop only.
> However, I didn't take into account swing/awt mixing where this 
> particular method is "allowed" to be called from non-EDT threads.
> In this case, you're right, the getFlag+setFlag, being called on two 
> concurrent threads, are not synchronized.
>
> Ok, I'm still trying to keep the scheme lock-free. What do you think 
> of the following approach?
>
> http://cr.openjdk.java.net/~ant/JDK-8058870/webrev.1
>
> We're eliminating the flag and using AtomicBoolean instead.
>
> The "flags" field is private. REVALIDATE_RUNNABLE_SCHEDULED is only 
> used for this single case. So, the only concern is serialization, for 
> which I reinitialize the new field in readObject. At the worst case, 
> we will have maximum two revalidate runnables in the queue, which 
> shouldn't hit performance any noticeably (and as far as I understand, 
> this code cares about performance only).
>
> Thanks,
> Anton.
>
>>
>> On 22.09.2014 17:36, Anton V. Tarasov wrote:
>>> Hello,
>>>
>>> Please review a fix:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8058870
>>> http://cr.openjdk.java.net/~ant/JDK-8058870/webrev.0
>>>
>>> A deadlock has been revealed on MacOS X with JFXPanel involved in an 
>>> app launched via JNLP. Find more details in jira, please.
>>>
>>> Thanks,
>>> Anton.
>>
>>
>


-- 
Best regards, Sergey.



From alexandr.scherbatiy at oracle.com  Tue Sep 23 13:26:49 2014
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Tue, 23 Sep 2014 17:26:49 +0400
Subject: <Swing Dev> <SwingDev> [9] Review request: JDK-8058870 Mac:
 JFXPanel deadlocks in jnlp mode
In-Reply-To: <54216028.80104@oracle.com>
References: <542025D0.3040005@oracle.com> <54202991.1070903@oracle.com>
	<54203996.8050900@oracle.com> <54216028.80104@oracle.com>
Message-ID: <54217519.1020206@oracle.com>


   The fix looks good to me.

   Thanks,
   Alexandr.

On 9/23/2014 3:57 PM, Sergey Bylokhov wrote:
> Hi, Anton.
> The fix looks good.
>
> On 22.09.2014 19:00, Anton V. Tarasov wrote:
>> On 9/22/14 5:52 PM, Sergey Bylokhov wrote:
>>> Hi, Anton.
>>> I think after the fix,  getFlag+setFlag are not atomic anymore in 
>>> the revalidate().
>>
>> I assumed revalidate() is called on EDT in case of pure Swing, and 
>> may be called from JavaFX App Thread in case of swing/javafx interop 
>> only.
>> However, I didn't take into account swing/awt mixing where this 
>> particular method is "allowed" to be called from non-EDT threads.
>> In this case, you're right, the getFlag+setFlag, being called on two 
>> concurrent threads, are not synchronized.
>>
>> Ok, I'm still trying to keep the scheme lock-free. What do you think 
>> of the following approach?
>>
>> http://cr.openjdk.java.net/~ant/JDK-8058870/webrev.1
>>
>> We're eliminating the flag and using AtomicBoolean instead.
>>
>> The "flags" field is private. REVALIDATE_RUNNABLE_SCHEDULED is only 
>> used for this single case. So, the only concern is serialization, for 
>> which I reinitialize the new field in readObject. At the worst case, 
>> we will have maximum two revalidate runnables in the queue, which 
>> shouldn't hit performance any noticeably (and as far as I understand, 
>> this code cares about performance only).
>>
>> Thanks,
>> Anton.
>>
>>>
>>> On 22.09.2014 17:36, Anton V. Tarasov wrote:
>>>> Hello,
>>>>
>>>> Please review a fix:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8058870
>>>> http://cr.openjdk.java.net/~ant/JDK-8058870/webrev.0
>>>>
>>>> A deadlock has been revealed on MacOS X with JFXPanel involved in 
>>>> an app launched via JNLP. Find more details in jira, please.
>>>>
>>>> Thanks,
>>>> Anton.
>>>
>>>
>>
>
>



From anton.tarasov at oracle.com  Tue Sep 23 14:59:44 2014
From: anton.tarasov at oracle.com (Anton V. Tarasov)
Date: Tue, 23 Sep 2014 18:59:44 +0400
Subject: <Swing Dev> <SwingDev> [9] Review request: JDK-8058870 Mac:
 JFXPanel deadlocks in jnlp mode
In-Reply-To: <54217519.1020206@oracle.com>
References: <542025D0.3040005@oracle.com> <54202991.1070903@oracle.com>
	<54203996.8050900@oracle.com> <54216028.80104@oracle.com>
	<54217519.1020206@oracle.com>
Message-ID: <54218AE0.6050804@oracle.com>

Thanks for the review!

Anton.

On 9/23/14 5:26 PM, Alexander Scherbatiy wrote:
>
>   The fix looks good to me.
>
>   Thanks,
>   Alexandr.
>
> On 9/23/2014 3:57 PM, Sergey Bylokhov wrote:
>> Hi, Anton.
>> The fix looks good.
>>
>> On 22.09.2014 19:00, Anton V. Tarasov wrote:
>>> On 9/22/14 5:52 PM, Sergey Bylokhov wrote:
>>>> Hi, Anton.
>>>> I think after the fix,  getFlag+setFlag are not atomic anymore in 
>>>> the revalidate().
>>>
>>> I assumed revalidate() is called on EDT in case of pure Swing, and 
>>> may be called from JavaFX App Thread in case of swing/javafx interop 
>>> only.
>>> However, I didn't take into account swing/awt mixing where this 
>>> particular method is "allowed" to be called from non-EDT threads.
>>> In this case, you're right, the getFlag+setFlag, being called on two 
>>> concurrent threads, are not synchronized.
>>>
>>> Ok, I'm still trying to keep the scheme lock-free. What do you think 
>>> of the following approach?
>>>
>>> http://cr.openjdk.java.net/~ant/JDK-8058870/webrev.1
>>>
>>> We're eliminating the flag and using AtomicBoolean instead.
>>>
>>> The "flags" field is private. REVALIDATE_RUNNABLE_SCHEDULED is only 
>>> used for this single case. So, the only concern is serialization, 
>>> for which I reinitialize the new field in readObject. At the worst 
>>> case, we will have maximum two revalidate runnables in the queue, 
>>> which shouldn't hit performance any noticeably (and as far as I 
>>> understand, this code cares about performance only).
>>>
>>> Thanks,
>>> Anton.
>>>
>>>>
>>>> On 22.09.2014 17:36, Anton V. Tarasov wrote:
>>>>> Hello,
>>>>>
>>>>> Please review a fix:
>>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-8058870
>>>>> http://cr.openjdk.java.net/~ant/JDK-8058870/webrev.0
>>>>>
>>>>> A deadlock has been revealed on MacOS X with JFXPanel involved in 
>>>>> an app launched via JNLP. Find more details in jira, please.
>>>>>
>>>>> Thanks,
>>>>> Anton.
>>>>
>>>>
>>>
>>
>>
>



From Sergey.Bylokhov at oracle.com  Tue Sep 23 17:59:48 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 23 Sep 2014 21:59:48 +0400
Subject: <Swing Dev> [9] Review Request: 6329748 Invalid/old variable
 name - newModel in setModel method in JTable class
In-Reply-To: <53F20B2D.1080704@oracle.com>
References: <53F20B2D.1080704@oracle.com>
Message-ID: <5421B514.6030903@oracle.com>

Hello.
Any volunteers?

On 18.08.2014 18:18, Sergey Bylokhov wrote:
> Hello.
> Please review the small fix for jdk 9.
> Bug description:
> Long long time ago all our JTable.set*model methods used newModel as a 
> parameter.
> Since then:
>  - setModel() parameterand at param tag were changed from newModel to 
> dataModel, but method description and @exception were not updated.
>  - setColumnModel parameter, @param and @exception tags werechanged 
> from newModel to columnModel, but method description was not updated.
>  - setSelectionModel was not updated at all.
>
> Plus in the fix I align description of all of these methods to the one 
> style.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-6329748
> Webrev can be found at: 
> http://cr.openjdk.java.net/~serb/6329748/webrev.00
>


-- 
Best regards, Sergey.



From philip.race at oracle.com  Tue Sep 23 18:09:37 2014
From: philip.race at oracle.com (Phil Race)
Date: Tue, 23 Sep 2014 11:09:37 -0700
Subject: <Swing Dev> [9] Review Request: 6329748 Invalid/old variable
 name - newModel in setModel method in JTable class
In-Reply-To: <5421B514.6030903@oracle.com>
References: <53F20B2D.1080704@oracle.com> <5421B514.6030903@oracle.com>
Message-ID: <5421B761.7060405@oracle.com>

looks ok to me

-phil.

On 9/23/2014 10:59 AM, Sergey Bylokhov wrote:
> Hello.
> Any volunteers?
>
> On 18.08.2014 18:18, Sergey Bylokhov wrote:
>> Hello.
>> Please review the small fix for jdk 9.
>> Bug description:
>> Long long time ago all our JTable.set*model methods used newModel as 
>> a parameter.
>> Since then:
>>  - setModel() parameterand at param tag were changed from newModel to 
>> dataModel, but method description and @exception were not updated.
>>  - setColumnModel parameter, @param and @exception tags werechanged 
>> from newModel to columnModel, but method description was not updated.
>>  - setSelectionModel was not updated at all.
>>
>> Plus in the fix I align description of all of these methods to the 
>> one style.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-6329748
>> Webrev can be found at: 
>> http://cr.openjdk.java.net/~serb/6329748/webrev.00
>>
>
>



From alexandr.scherbatiy at oracle.com  Wed Sep 24 10:28:02 2014
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Wed, 24 Sep 2014 14:28:02 +0400
Subject: <Swing Dev> Result: New Swing Group Member: Alexander Zvegintsev
Message-ID: <54229CB2.9090205@oracle.com>


The vote for Alexander Zvegintsev [1] is now closed.

Yes: 4
Veto: 0
Abstain: 0

According to the Bylaws definition of Lazy Consensus, this is
sufficient to approve the nomination.

Thanks,
Alexandr.

[1] 
http://mail.openjdk.java.net/pipermail/swing-dev/2014-September/003895.html
[2] http://openjdk.java.net/bylaws#lazy-consensus



From alexander.potochkin at oracle.com  Wed Sep 24 17:18:43 2014
From: alexander.potochkin at oracle.com (Alexander Potochkin)
Date: Wed, 24 Sep 2014 21:18:43 +0400
Subject: <Swing Dev> [9] Review request for JDK-8054543 Setting a border on
 a JLayer causes an Exceptions
Message-ID: <5422FCF3.80208@oracle.com>

Hello

Please review the fix the the following RFE:
https://bugs.openjdk.java.net/browse/JDK-8054543

JLayer.setBorder() method is implemented to constantly throw an 
IllegalArgumentException for every parameter except null. It breaks some 
of the third party libraries which set borders for a component they are 
receiving.

The proposed API change provides the required API for JDK9
http://cr.openjdk.java.net/~alexp/8054543/webrev.00/

The request to the public API change will be filed after the technical 
review

Thanks
alexp


From alexandr.scherbatiy at oracle.com  Thu Sep 25 09:44:58 2014
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Thu, 25 Sep 2014 13:44:58 +0400
Subject: <Swing Dev> [9] Review request for JDK-8054543 Setting a border
 on a JLayer causes an Exceptions
In-Reply-To: <5422FCF3.80208@oracle.com>
References: <5422FCF3.80208@oracle.com>
Message-ID: <5423E41A.1060200@oracle.com>


   The fix looks good to me.

   Thanks,
   Alexandr.

On 9/24/2014 9:18 PM, Alexander Potochkin wrote:
> Hello
>
> Please review the fix the the following RFE:
> https://bugs.openjdk.java.net/browse/JDK-8054543
>
> JLayer.setBorder() method is implemented to constantly throw an 
> IllegalArgumentException for every parameter except null. It breaks 
> some of the third party libraries which set borders for a component 
> they are receiving.
>
> The proposed API change provides the required API for JDK9
> http://cr.openjdk.java.net/~alexp/8054543/webrev.00/
>
> The request to the public API change will be filed after the technical 
> review
>
> Thanks
> alexp



From alexandr.scherbatiy at oracle.com  Thu Sep 25 14:20:30 2014
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Thu, 25 Sep 2014 18:20:30 +0400
Subject: <Swing Dev> [9] Review request for 8058305 BadLocationException is
 not thrown by javax.swing.text.View.getNextVisualPositionFrom() for invalid
 positions
Message-ID: <542424AE.9060004@oracle.com>


Hello,

Could you review the fix:
   bug: https://bugs.openjdk.java.net/browse/JDK-8058305
   webrev: http://cr.openjdk.java.net/~alexsch/8058305/webrev.00

   According to the  View.getNextVisualPositionFrom(...) method javadoc 
http://docs.oracle.com/javase/8/docs/api/javax/swing/text/View.html
   the BadLocationException should be thrown if the given position is 
not a valid position within the document

   The issue is covered by JCK tests.

Thanks,
Alexandr.



From alexander.zvegintsev at oracle.com  Thu Sep 25 15:04:24 2014
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Thu, 25 Sep 2014 19:04:24 +0400
Subject: <Swing Dev> [9] Review request for 8058305 BadLocationException
 is not thrown by javax.swing.text.View.getNextVisualPositionFrom() for
 invalid positions
In-Reply-To: <542424AE.9060004@oracle.com>
References: <542424AE.9060004@oracle.com>
Message-ID: <54242EF8.4030601@oracle.com>

Hi Alexandr,

We still don't throw a BadLocationException if component is not painted yet.
(see BasicTextUI.getNextVisualPositionFrom() at 1121 line).
This can be reproduced with sample code from the JBS issue.

--
Thanks,
Alexander.

On 09/25/2014 06:20 PM, Alexander Scherbatiy wrote:
>
> Hello,
>
> Could you review the fix:
>   bug: https://bugs.openjdk.java.net/browse/JDK-8058305
>   webrev: http://cr.openjdk.java.net/~alexsch/8058305/webrev.00
>
>   According to the  View.getNextVisualPositionFrom(...) method javadoc 
> http://docs.oracle.com/javase/8/docs/api/javax/swing/text/View.html
>   the BadLocationException should be thrown if the given position is 
> not a valid position within the document
>
>   The issue is covered by JCK tests.
>
> Thanks,
> Alexandr.
>



From alexandr.scherbatiy at oracle.com  Fri Sep 26 12:56:36 2014
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Fri, 26 Sep 2014 16:56:36 +0400
Subject: <Swing Dev> [9] Review request for 8058305 BadLocationException
 is not thrown by javax.swing.text.View.getNextVisualPositionFrom() for
 invalid positions
In-Reply-To: <54242EF8.4030601@oracle.com>
References: <542424AE.9060004@oracle.com> <54242EF8.4030601@oracle.com>
Message-ID: <54256284.80104@oracle.com>


   Could you review the updated fix:
     http://cr.openjdk.java.net/~alexsch/8058305/webrev.01

   - the position check is added to the missed places
   - the test is added

  Thanks,
  Alexandr.

On 9/25/2014 7:04 PM, Alexander Zvegintsev wrote:
> Hi Alexandr,
>
> We still don't throw a BadLocationException if component is not 
> painted yet.
> (see BasicTextUI.getNextVisualPositionFrom() at 1121 line).
> This can be reproduced with sample code from the JBS issue.
>
> -- 
> Thanks,
> Alexander.
>
> On 09/25/2014 06:20 PM, Alexander Scherbatiy wrote:
>>
>> Hello,
>>
>> Could you review the fix:
>>   bug: https://bugs.openjdk.java.net/browse/JDK-8058305
>>   webrev: http://cr.openjdk.java.net/~alexsch/8058305/webrev.00
>>
>>   According to the  View.getNextVisualPositionFrom(...) method 
>> javadoc 
>> http://docs.oracle.com/javase/8/docs/api/javax/swing/text/View.html
>>   the BadLocationException should be thrown if the given position is 
>> not a valid position within the document
>>
>>   The issue is covered by JCK tests.
>>
>> Thanks,
>> Alexandr.
>>
>



From dmitry.markov at oracle.com  Mon Sep 29 07:10:44 2014
From: dmitry.markov at oracle.com (dmitry markov)
Date: Mon, 29 Sep 2014 11:10:44 +0400
Subject: <Swing Dev> [9] Review request for 8058120: Rendering / caret
 errors with HTMLDocument
Message-ID: <542905F4.8050200@oracle.com>

Hello,

Could you review the fix for jdk9, please?

     bug: https://bugs.openjdk.java.net/browse/JDK-8058120
     webrev: http://cr.openjdk.java.net/~dmarkov/8058120/jdk9/webrev.00/

Problem description: if some text (not wrapped by HTML tags) is inserted 
via insertAfterEnd() method, the text is added directly to the body of 
HTML document. This will cause incorrect representation of added fragment.
Fix: it is necessary to detect the insertion of the text to the body and 
wrap the text by p-implied tags.

Thanks,
Dmitry


From Sergey.Bylokhov at oracle.com  Mon Sep 29 12:09:04 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 29 Sep 2014 16:09:04 +0400
Subject: <Swing Dev> [9] Review request for JDK-8054543 Setting a border
 on a JLayer causes an Exceptions
In-Reply-To: <5422FCF3.80208@oracle.com>
References: <5422FCF3.80208@oracle.com>
Message-ID: <54294BE0.5080301@oracle.com>

Hi, Alexander.
The fix looks good.

On 24.09.2014 21:18, Alexander Potochkin wrote:
> Hello
>
> Please review the fix the the following RFE:
> https://bugs.openjdk.java.net/browse/JDK-8054543
>
> JLayer.setBorder() method is implemented to constantly throw an 
> IllegalArgumentException for every parameter except null. It breaks 
> some of the third party libraries which set borders for a component 
> they are receiving.
>
> The proposed API change provides the required API for JDK9
> http://cr.openjdk.java.net/~alexp/8054543/webrev.00/
>
> The request to the public API change will be filed after the technical 
> review
>
> Thanks
> alexp


-- 
Best regards, Sergey.



From pooja.chopra at oracle.com  Tue Sep 30 13:46:00 2014
From: pooja.chopra at oracle.com (pooja chopra)
Date: Tue, 30 Sep 2014 19:16:00 +0530
Subject: <Swing Dev> [9] Review Request: JDK-8058805 Fix type in
 client-related package for tray.policy file missing in
 java/awt/TrayIcon/SecurityCheck/NoPermissionTest
In-Reply-To: <541C14A9.6000304@oracle.com>
References: <541C14A9.6000304@oracle.com>
Message-ID: <542AB418.3070107@oracle.com>

Hello All,
Gentle reminder . Please review below fix .

Regards,
Pooja
On 9/19/2014 5:04 PM, pooja chopra wrote:
> |Hello, |
> ||
> |Please review a fix ||for| |the issue: |
> ||
> |8058805| |[TEST_BUG] 
> java/awt/TrayIcon/SecurityCheck/NoPermissionTest||/|||NoPermissionTest.java| 
> fails with Cant find Policy file error.|||
> ||
> |Test bug fix.
> |
> ||
> |https://bugs.openjdk.java.net/browse/JDK-8058805|||
> ||
> |
> The webrev is: |http://cr.openjdk.java.net/~kshefov/8058805/webrev.00/ |
>
> |||
> ||
> |Thanks |
> |Pooja|

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20140930/0b3ad84b/attachment.html>

From vivi.an at oracle.com  Tue Sep 30 21:15:19 2014
From: vivi.an at oracle.com (Vivi An)
Date: Tue, 30 Sep 2014 14:15:19 -0700
Subject: <Swing Dev> [9] Review request for 8033699: Incorrect radio
 button behavior
In-Reply-To: <541C03D0.1030300@oracle.com>
References: <5408B5E9.6080901@oracle.com> <540DA48F.2020409@oracle.com>
	<5410D71F.3040405@oracle.com> <541177AE.6040305@oracle.com>
	<541325C5.6040800@oracle.com> <5416B89F.5040301@oracle.com>
	<5417B09B.30807@oracle.com> <5417E925.4090601@oracle.com>
	<5419194C.9030001@oracle.com> <54193BC6.8020105@oracle.com>
	<541A1495.8060003@oracle.com> <541A8FEB.6000607@oracle.com>
	<541B14F6.4070603@oracle.com> <541C03D0.1030300@oracle.com>
Message-ID: <542B1D67.1030400@oracle.com>

Hello Alexander,

Thanks for the review.

New patch is available under 
http://cr.openjdk.java.net/~van/8033699/webrev.06/

Regards,

Vivi

On 9/19/2014 3:22 AM, Alexander Zvegintsev wrote:
> Hello Vivi,
>
> Since you are touching this code, could you please add missing 
> @Override annotations?
>
Added
> void jumpToNextComponent(boolean next) {
>             if (!getButtonGroupInfo())
>                 return;
>
> This leads to an issue: we can't switch to a next component with a TAB 
> key if JRadioButton
> is not in a ButtonGroup. (It may be a reason to write another test.)
Fixed
>
>     private boolean isValidRadioButtonObj(Object obj) {
>         return ((obj != null) && (obj instanceof JRadioButton) &&
>                     ((JRadioButton) obj).isVisible() &&
>                     ((JRadioButton) obj).isEnabled());
>     }
Fixed
>
> There is no need to do a null check before instanceof [1]
>
>      * @param evt, the event object.
>      * @param next, indicate if it's next one
>      */
>     private void selectRadioButton(ActionEvent event, boolean next) {
>
> typo: evt should be event
>
Fixed
>
> I run the test and it fails at least on Linux. It happens due to a big 
> auto delay:
> Robot holds key for too long so system sends TAB key multiple time.
> So I think auto delay should be about 100 ms.
>
> robot.setAutoDelay(300);
>
> It is enough to call it once after Robot creation, this will 
> automatically add a 300 ms delay
> between Robot generated events (such as keyPress, mouseMove, etc).
> If you really want a delay between test runs please use Thread.sleep().
>
> I see many calls to hitKey() and then to realSync(), so we can move 
> realSync() call to the end of hitKey().
> checkResult() may be combined with runTest(), hence we call one 
> function instead of two.
>
>         int sum = 0;
>         for (int i = 0; i < testResults.length; i++) {
>             if (testResults[i] == false)
>                 sum++;
>         }
>
>         if (sum != 0){
>             System.out.println("Total 5 tests, failed test(s): " + sum);
>             throw new RuntimeException("Test failed.");
>         }
>
>
> I don't think that this logic is applicable here, each test depends on 
> previous: Test2 failure means that
> focus is on a wrong component, so all following tests will fail.
> BTW, this code is unreachable in case of test failure, since 
> checkResult() already throws an exception.
>
> http://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.20.2
Test is updated, non-grouped radio button test is added,  test passed on 
Oracle Linux 5 u6 32 bits and Windows 7.
>
> -- 
> Thanks,
> Alexander.
>
> On 09/18/2014 09:23 PM, Vivi An wrote:
>> Thank you Alexandr.
>>
>> Need one more review for this. Alexander, could you please take a 
>> look at below fix?
>> http://cr.openjdk.java.net/~van/8033699/webrev.05/
>>
>> Thanks
>>
>> Vivi
>>
>> On 9/18/2014 12:55 AM, Alexander Scherbatiy wrote:
>>>
>>>   The fix looks good to me.
>>>
>>>   Thanks,
>>>   Alexandr.
>>>
>>> On 9/18/2014 3:09 AM, Vivi An wrote:
>>>> Hello Alex,
>>>>
>>>> On 9/17/2014 12:44 AM, Alexander Scherbatiy wrote:
>>>>> On 9/17/2014 9:17 AM, Vivi An wrote:
>>>>>> You are right. Fixed now.
>>>>>>
>>>>>> http://cr.openjdk.java.net/~van/8033699/webrev.04/
>>>>>
>>>>>  528             if (e.isShiftDown()) {
>>>>>  529                 if (e.getKeyCode() == KeyEvent.VK_TAB) {
>>>>>  537                         // ... 
>>>>> btnGroupInfo.jumpToNextComponent(false);
>>>>>  539                 }
>>>>>  540             } else if (e.getKeyCode() == KeyEvent.VK_TAB) {
>>>>>  548                     // ... 
>>>>> btnGroupInfo.jumpToNextComponent(true);
>>>>>  550             }
>>>>>
>>>>>   The code in the if/else branches is almost the same except the 
>>>>> true/false argument.
>>>>>   I would suggest to unify them in the following way:
>>>>>
>>>>>      if (e.getKeyCode() == KeyEvent.VK_TAB) {
>>>>>         // ... jumpToNextComponent(!e.isShiftDown())
>>>>>      }
>>>>>
>>>> Fixed.
>>>>>
>>>>>  510             if (next)
>>>>>  511                 KeyboardFocusManager.
>>>>>  512 
>>>>> getCurrentKeyboardFocusManager().focusNextComponent((JComponent)lastBtn);
>>>>>  513             else
>>>>>  514                 KeyboardFocusManager.
>>>>>  515 
>>>>> getCurrentKeyboardFocusManager().focusPreviousComponent((JComponent)firstBtn);
>>>>>
>>>>>  This code can be also a little bit optimized:
>>>>>
>>>>>     KeyboardFocusManager.getCurrentKeyboardFocusManager().
>>>>>         focusPreviousComponent((JComponent) (next ? lastBtn : 
>>>>> firstBtn));
>>>>>
>>>> It's different function call,  one for focusNextComponent and the 
>>>> other for focusPreviousComponent, not able to optimize in suggested 
>>>> way.
>>>>
>>>> http://cr.openjdk.java.net/~van/8033699/webrev.05/
>>>>
>>>> Thanks
>>>>
>>>> Vivi
>>>>
>>>>>  Thanks,
>>>>>  Alexandr.
>>>>>
>>>>>>
>>>>>> Thank you
>>>>>>
>>>>>> ~ Vivi
>>>>>>
>>>>>> On 9/16/2014 12:39 AM, Alexander Scherbatiy wrote:
>>>>>>>
>>>>>>>   I have missed one more case:
>>>>>>>  527         public void keyPressed(KeyEvent e) {
>>>>>>>  528             if (e.getKeyCode() == KeyEvent.VK_TAB) {
>>>>>>>                         // jumpToNextComponent(true)
>>>>>>>  538             }
>>>>>>>  539
>>>>>>>  540             if (e.getKeyCode() == KeyEvent.VK_TAB && 
>>>>>>> e.isShiftDown()) {
>>>>>>>                         //jumpToNextComponent(false)
>>>>>>>  550             }
>>>>>>>  551         }
>>>>>>>
>>>>>>>   It seems that if e.isShiftDown() is true then both 
>>>>>>> jumpToNextComponent(true) and jumpToNextComponent(false) methods 
>>>>>>> can be called.
>>>>>>>
>>>>>>>   Thanks,
>>>>>>>   Alexandr.
>>>>>>>
>>>>>>>
>>>>>>> On 9/16/2014 7:38 AM, Vivi An wrote:
>>>>>>>> Fixed. New Webrev: 
>>>>>>>> http://cr.openjdk.java.net/~van/8033699/webrev.03/
>>>>>>>>
>>>>>>>> Thanks Alex.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>> ~ Vivi
>>>>>>>>
>>>>>>>> On 9/15/2014 2:59 AM, Alexander Scherbatiy wrote:
>>>>>>>>> On 9/12/2014 8:56 PM, Vivi An wrote:
>>>>>>>>>> Thanks Alexander.
>>>>>>>>>>
>>>>>>>>>> All items addressed except last one, please see comments inline.
>>>>>>>>>> New Webrev: http://cr.openjdk.java.net/~van/8033699/webrev.02/
>>>>>>>>>
>>>>>>>>>     163         if ( keyListener != null ) {
>>>>>>>>>
>>>>>>>>>     Could you remove spaces in the brackets? After code 
>>>>>>>>> formatting it should be "if (keyListener != null) {"
>>>>>>>>>
>>>>>>>>>>> 543             if (next && btnGroupInfo.lastBtn != null)
>>>>>>>>>>>  544                 KeyboardFocusManager.
>>>>>>>>>>>  545 
>>>>>>>>>>> getCurrentKeyboardFocusManager().focusNextComponent((JComponent)btnGroupInfo.lastBtn);
>>>>>>>>>>>  546             else if (btnGroupInfo.firstBtn != null)
>>>>>>>>>>>  547                 KeyboardFocusManager.
>>>>>>>>>>>  548 
>>>>>>>>>>> getCurrentKeyboardFocusManager().focusPreviousComponent((JComponent)btnGroupInfo.firstBtn);
>>>>>>>>>>>  549         }
>>>>>>>>>>>
>>>>>>>>>>> Should the first button be focused If next is true and last 
>>>>>>>>>>> button is null?
>>>>>>>>>> Don't think last button could be null when this function is 
>>>>>>>>>> triggered, last and first will always be set in case there is 
>>>>>>>>>> at least one valid (enabled and visible) radio button in the 
>>>>>>>>>> group.
>>>>>>>>>
>>>>>>>>>   It seems that lastBtn != null and firstBtn != null checks 
>>>>>>>>> are not necessary in this case.
>>>>>>>>>
>>>>>>>>>   Thanks,
>>>>>>>>>   Alexandr.
>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Alexandr.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Regards,
>>>>>>>>>>>>
>>>>>>>>>>>> ~ Vivi
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 9/8/2014 5:43 AM, Alexander Scherbatiy wrote:
>>>>>>>>>>>>> On 9/4/2014 10:56 PM, Vivi An wrote:
>>>>>>>>>>>>>> Hello,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Please review fix for JDK-8033699. Changes made:
>>>>>>>>>>>>>> 1) When tab or shift-tab key pressed, focus moved to 
>>>>>>>>>>>>>> next/previous
>>>>>>>>>>>>>> component outside of the radio button group
>>>>>>>>>>>>>> 2) Using up/down or left/right arrow key to change 
>>>>>>>>>>>>>> selection inside
>>>>>>>>>>>>>> radio button group
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8033699
>>>>>>>>>>>>>> Webrev:http://cr.openjdk.java.net/~van/8033699/webrev.00/
>>>>>>>>>>>>>
>>>>>>>>>>>>>   56     private KeyListener keyListener = null;
>>>>>>>>>>>>>   57     private KeyHandler handler = null;
>>>>>>>>>>>>>
>>>>>>>>>>>>> It seems that these both fields point to the same object. 
>>>>>>>>>>>>> Is it possible to get rid of one of them?
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>  152         if ( keyListener != null ) {
>>>>>>>>>>>>>  153             button.removeKeyListener( keyListener );
>>>>>>>>>>>>>  154         }
>>>>>>>>>>>>>
>>>>>>>>>>>>> Some UIs also set the listener to null in the 
>>>>>>>>>>>>> uninstallUI()/uninstallListeners() methods (like 
>>>>>>>>>>>>> BasicComboBoxUI or BasicColorChooserUI).
>>>>>>>>>>>>> Should the keyListener also be set to null to free the 
>>>>>>>>>>>>> KeyHandler object?
>>>>>>>>>>>>>
>>>>>>>>>>>>>  369         if (!(eventSrc instanceof JRadioButton &&
>>>>>>>>>>>>>  370             ((JRadioButton) eventSrc).isVisible() && 
>>>>>>>>>>>>> ((JRadioButton) eventSrc).isEnabled()))
>>>>>>>>>>>>>
>>>>>>>>>>>>> This check is used several times. It can be moved to a 
>>>>>>>>>>>>> separate method.
>>>>>>>>>>>>>
>>>>>>>>>>>>>  373         // Get the button model from the source.
>>>>>>>>>>>>>  374         ButtonModel model = ((AbstractButton) 
>>>>>>>>>>>>> eventSrc).getModel();
>>>>>>>>>>>>>  375         if (!(model instanceof DefaultButtonModel))
>>>>>>>>>>>>>  376             return;
>>>>>>>>>>>>>  377
>>>>>>>>>>>>>  378         // If the button model is DefaultButtonModel, 
>>>>>>>>>>>>> and use it, otherwise return.
>>>>>>>>>>>>>  379         DefaultButtonModel bm = (DefaultButtonModel) 
>>>>>>>>>>>>> model;
>>>>>>>>>>>>>  380         if (bm == null)
>>>>>>>>>>>>>  381             return;
>>>>>>>>>>>>>
>>>>>>>>>>>>> The second check is not necessary because (model 
>>>>>>>>>>>>> instanceof DefaultButtonModel) returns false for null model.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>  404         AbstractButton curElement = null;
>>>>>>>>>>>>>
>>>>>>>>>>>>>   The curElement variable declaration could be moved into 
>>>>>>>>>>>>> the 'while' block.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>  408             if (curElement instanceof JRadioButton &&
>>>>>>>>>>>>>  409                     ((JRadioButton) 
>>>>>>>>>>>>> curElement).isVisible() &&
>>>>>>>>>>>>>  410                     ((JRadioButton) 
>>>>>>>>>>>>> curElement).isEnabled()){
>>>>>>>>>>>>>
>>>>>>>>>>>>>   It is possible to use 'continue' here to not put the 
>>>>>>>>>>>>> other code inside the 'if' block.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>  418                 else if (!srcFound){
>>>>>>>>>>>>>  422                 } else if (srcFound && nextBtn == null){
>>>>>>>>>>>>>
>>>>>>>>>>>>> It is not necessary to check the srcFound in the second 
>>>>>>>>>>>>> 'if' because it should already have true value.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>  444             if (newSelectedBtn != null){
>>>>>>>>>>>>>  445 newSelectedBtn.requestFocusInWindow();
>>>>>>>>>>>>>  446 newSelectedBtn.setSelected(true);
>>>>>>>>>>>>>  447             }
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Is it possible here that newSelectedBtn == eventSrc?
>>>>>>>>>>>>>
>>>>>>>>>>>>>  522         private void jumpToNextComponent(JRadioButton 
>>>>>>>>>>>>> btn, boolean next){
>>>>>>>>>>>>>
>>>>>>>>>>>>> The code that retrieves elements from a button group is 
>>>>>>>>>>>>> also used in the selectRadioButton()
>>>>>>>>>>>>> and can be moved to a separate method.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> Alexandr.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> JPRT build succeeded, JCK tests for JRadiobutton and 
>>>>>>>>>>>>>> JCheckBox all passed.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thank you
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Vivi
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>