From sergey.bylokhov at oracle.com  Mon Jan  9 18:36:00 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 9 Jan 2017 21:36:00 +0300
Subject: <Swing Dev> [8u]Typos in JComponent#setAlignment methods
In-Reply-To: <CAN4rkZ=758FojjUn0N3U=5SND6VXWaV5nFX5nmEPSf4g8wcTEQ@mail.gmail.com>
References: <CAN4rkZ=758FojjUn0N3U=5SND6VXWaV5nFX5nmEPSf4g8wcTEQ@mail.gmail.com>
Message-ID: <5333F16E-F070-42FD-8CBE-6EE85DA58321@oracle.com>

Hi, Robin.
It is not necessary to create a new CR, because this is request to backport the fix for fixed bug. You?ll need to request an approval for backport on jdk8u-dev at openjdk.java.net.
An example:
http://mail.openjdk.java.net/pipermail/jdk8u-dev/2017-January/006304.html

> 
> Hello,
> 
> please review (and commit) the following corrections to the javadoc of the JComponent#setAlignment methods.
> It looks like the javadoc of those methods was already corrected on jdk9, but it is still incorrect on jdk8.
> 
> Review: http://cr.openjdk.java.net/~rstevens/JComponent/webrev.00 <http://cr.openjdk.java.net/~rstevens/JComponent/webrev.00>
> 
> If needed, I can create a JIRA bug for this but as it is only a minor documentation change I did not bother with it.
> 
> Kind regards,
> 
> Robin

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

From sergey.bylokhov at oracle.com  Tue Jan 10 16:42:03 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 10 Jan 2017 19:42:03 +0300
Subject: <Swing Dev> [9] Review Request: 8149879 Examine
 UIDefaults::addResourceBundle(String bundleName) with resource
 encapsulation
In-Reply-To: <FD84773E-60DF-44A4-A6AD-239DD3DCE8EE@oracle.com>
References: <c29deee2-c659-ec94-1e83-490da916ee90@oracle.com>
	<ec27bb5a-bf7c-1e96-6508-5bce286489ff@oracle.com>
	<2d4dee6e-34aa-77c5-976f-1431976e794b@oracle.com>
	<f8b47bf4-a333-3a99-5f50-5af9a9614129@oracle.com>
	<34fe8cf6-fbdb-f042-c137-c7035908020d@oracle.com>
	<668e9d35-82f7-be58-da55-49a40283a52e@oracle.com>
	<1091d2bd-2ff3-6395-9e19-f51ae0413eea@oracle.com>
	<A58F4CCD-8704-4E5D-9623-62EF653B7236@oracle.com>
	<aff4c8e7-e805-e5ff-e412-d5f2df6fbfd8@oracle.com>
	<F21A86D7-F953-43E6-BBEF-064D9879CCE3@oracle.com>
	<df991568-fa75-c2ad-efd1-dc7b01c686e1@oracle.com>
	<AA86437E-CF6D-4C3C-B9B9-9DE4B5EAE825@oracle.com>
	<586534fe-0ac6-42a4-27c7-f9e9ba8352ed@oracle.com>
	<3661820D-965A-4B4B-8BFB-45D7F7C1C0BC@oracle.com>
	<4ab60466-8b8a-f2ff-cb99-f6c4cebd017e@oracle.com>
	<BA6E5EF2-3516-4289-9853-AEED72C27610@oracle.com>
	<d2215f2d-733e-dec6-4ae5-15a113a9e60d@oracle.com>
	<5FA74751-DECC-4A73-8778-62F61F37F1F6@oracle.com>
	<4FE75E35-86BA-4255-87FB-DB0856DE4F0B@oracle.com>
	<5ed5912c-6fdd-90a1-0f0a-9fa86edc23ef@oracle.com>
	<FD84773E-60DF-44A4-A6AD-239DD3DCE8EE@oracle.com>
Message-ID: <EC4FEAEF-23AD-4538-A03A-35B24E97CBB0@oracle.com>

Hello,
Please review the new version:
http://cr.openjdk.java.net/~serb/8149879/webrev.03 <http://cr.openjdk.java.net/~serb/8149879/webrev.03>
The specification of addResourceBundle() is updated.

> 
>> 
>> On Dec 22, 2016, at 1:33 AM, Semyon Sadetsky <semyon.sadetsky at oracle.com <mailto:semyon.sadetsky at oracle.com>> wrote:
>> 
>> 
>> 
>> 
>> On 20.12.2016 19:41, Mandy Chung wrote:
>>> 
>>>> On Dec 20, 2016, at 8:24 AM, Sergey Bylokhov <sergey.bylokhov at oracle.com <mailto:sergey.bylokhov at oracle.com>> wrote:
>>>> 
>>>>>>> If this private data can be loaded to the UIDefaults or to other class then it will be read anyway. Are the Swing/AWT properties files content really secret?
>>>>>> My point is that there are no secrets, but the bug description states that such bundles can be added some day later.
>>>>> But what secret can be here?
>>>> 
>>>> I think Mandy can clarify that.
>>> 
>>> 
>>> The API should only allow user code to request adding a resource bundle that is accessible to the user.   A private resource bundle in java.desktop that may contain security sensitive information  is not intended to be registered in UIDefaults and of course it should be encapsulated.  You may think that today there is no security sensitive information but we can?t guarantee until an audit to all resource bundles is done and also continuously for every change is made.
>> Okay, Mandy. It may make sens, but those sensitive files, if they appear, will be able to be extracted from the module jmod file.
>> 
>> I still think that the rule to search for resources should be explicitly clarified in the method spec. Do you think it's not necessary?
> 
> See my suggested spec clarification from:
> http://mail.openjdk.java.net/pipermail/swing-dev/2016-December/007097.html <http://mail.openjdk.java.net/pipermail/swing-dev/2016-December/007097.html>
> 
>> Also I have a question to the fix author:
>> What will be the result of the method call from another named module with aim to load resource bundle located in this named module?
> 
> This is a RFE that I think probably should provide a new API to pass a Supplier<ResourceBundle>
> 
> Mandy

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

From mandy.chung at oracle.com  Tue Jan 10 17:04:14 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 10 Jan 2017 09:04:14 -0800
Subject: <Swing Dev> [9] Review Request: 8149879 Examine
	UIDefaults::addResourceBundle(String bundleName) with
	resource encapsulation
In-Reply-To: <EC4FEAEF-23AD-4538-A03A-35B24E97CBB0@oracle.com>
References: <c29deee2-c659-ec94-1e83-490da916ee90@oracle.com>
	<ec27bb5a-bf7c-1e96-6508-5bce286489ff@oracle.com>
	<2d4dee6e-34aa-77c5-976f-1431976e794b@oracle.com>
	<f8b47bf4-a333-3a99-5f50-5af9a9614129@oracle.com>
	<34fe8cf6-fbdb-f042-c137-c7035908020d@oracle.com>
	<668e9d35-82f7-be58-da55-49a40283a52e@oracle.com>
	<1091d2bd-2ff3-6395-9e19-f51ae0413eea@oracle.com>
	<A58F4CCD-8704-4E5D-9623-62EF653B7236@oracle.com>
	<aff4c8e7-e805-e5ff-e412-d5f2df6fbfd8@oracle.com>
	<F21A86D7-F953-43E6-BBEF-064D9879CCE3@oracle.com>
	<df991568-fa75-c2ad-efd1-dc7b01c686e1@oracle.com>
	<AA86437E-CF6D-4C3C-B9B9-9DE4B5EAE825@oracle.com>
	<586534fe-0ac6-42a4-27c7-f9e9ba8352ed@oracle.com>
	<3661820D-965A-4B4B-8BFB-45D7F7C1C0BC@oracle.com>
	<4ab60466-8b8a-f2ff-cb99-f6c4cebd017e@oracle.com>
	<BA6E5EF2-3516-4289-9853-AEED72C27610@oracle.com>
	<d2215f2d-733e-dec6-4ae5-15a113a9e60d@oracle.com>
	<5FA74751-DECC-4A73-8778-62F61F37F1F6@oracle.com>
	<4FE75E35-86BA-4255-87FB-DB0856DE4F0B@oracle.com>
	<5ed5912c-6fdd-90a1-0f0a-9f! a86edc23ef@oracle.com>
	<FD84773E-60DF-44A4-A6AD-239DD3DCE8EE@oracle.com>
	<EC4FEAEF-23AD-4538-A03A-35B24E97CBB0@oracle.com>
Message-ID: <916E8312-7ACD-409D-8A2E-FAFF71AAA908@oracle.com>


> On Jan 10, 2017, at 8:42 AM, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
> 
> Hello,
> Please review the new version:
> http://cr.openjdk.java.net/~serb/8149879/webrev.03 <http://cr.openjdk.java.net/~serb/8149879/webrev.03>
> The specification of addResourceBundle() is updated.
> 

It would be useful to add  @see ResourceBundle#getBundle(String, Locale, ClassLoader).   The copyright end year needs to be updated to 2017.   Otherwise, looks good.

No need to send a new webrev unless others have comments to require a new webrev.

Mandy

>> 
>>> 
>>> On Dec 22, 2016, at 1:33 AM, Semyon Sadetsky <semyon.sadetsky at oracle.com <mailto:semyon.sadetsky at oracle.com>> wrote:
>>> 
>>> 
>>> 
>>> 
>>> On 20.12.2016 19:41, Mandy Chung wrote:
>>>> 
>>>>> On Dec 20, 2016, at 8:24 AM, Sergey Bylokhov <sergey.bylokhov at oracle.com <mailto:sergey.bylokhov at oracle.com>> wrote:
>>>>> 
>>>>>>>> If this private data can be loaded to the UIDefaults or to other class then it will be read anyway. Are the Swing/AWT properties files content really secret?
>>>>>>> My point is that there are no secrets, but the bug description states that such bundles can be added some day later.
>>>>>> But what secret can be here?
>>>>> 
>>>>> I think Mandy can clarify that.
>>>> 
>>>> 
>>>> The API should only allow user code to request adding a resource bundle that is accessible to the user.   A private resource bundle in java.desktop that may contain security sensitive information  is not intended to be registered in UIDefaults and of course it should be encapsulated.  You may think that today there is no security sensitive information but we can?t guarantee until an audit to all resource bundles is done and also continuously for every change is made.
>>> Okay, Mandy. It may make sens, but those sensitive files, if they appear, will be able to be extracted from the module jmod file.
>>> 
>>> I still think that the rule to search for resources should be explicitly clarified in the method spec. Do you think it's not necessary?
>> 
>> See my suggested spec clarification from:
>> http://mail.openjdk.java.net/pipermail/swing-dev/2016-December/007097.html <http://mail.openjdk.java.net/pipermail/swing-dev/2016-December/007097.html>
>> 
>>> Also I have a question to the fix author:
>>> What will be the result of the method call from another named module with aim to load resource bundle located in this named module?
>> 
>> This is a RFE that I think probably should provide a new API to pass a Supplier<ResourceBundle>
>> 
>> Mandy
> 

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

From avik.niyogi at oracle.com  Wed Jan 11 08:46:01 2017
From: avik.niyogi at oracle.com (Avik Niyogi)
Date: Wed, 11 Jan 2017 14:16:01 +0530
Subject: <Swing Dev> 8172509: [TEST_BUG] [macosx] Failure of the new test
	java/awt/Focus/FocusTraversalPolicy/ButtonGroupLayoutTraversal/ButtonGroupLayoutTraversalTest.java
Message-ID: <BF782AB0-2551-4FA7-BB41-CD63E4A30048@oracle.com>

Hi All,

Kindly review the proposed fix for JDK9.

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

Webrev: http://cr.openjdk.java.net/~aniyogi/8172509/webrev.00/ <http://cr.openjdk.java.net/~aniyogi/8172509/webrev.00/>

Issue: The focus traversal policy being tested was incorrect

Cause: For Aqua and Nimbus, the focus traversal policy used is different and as this is tested on default LAF, it fails on Mac OS X

Fix: Cross-platform (Metal) LAF is used in case the default LAF is either Aqua or Nimbus and the focus traversal works in those cases.

With Regards,
Avik Niyogi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20170111/694dde75/attachment.html>

From avik.niyogi at oracle.com  Wed Jan 11 10:39:29 2017
From: avik.niyogi at oracle.com (Avik Niyogi)
Date: Wed, 11 Jan 2017 16:09:29 +0530
Subject: <Swing Dev> [9] Review request for 8165207: [macosx] Test
	javax/swing/Popup/TaskbarPositionTest.java fails on Mac 10.12
Message-ID: <FD06471F-9D6D-47B7-A417-97CA66D1C1B2@oracle.com>

Hi Alexander,
The following is my input for this webrev:

In case the LAF is Aqua, the check for combobox alignment is skipped. 
Instead, if default LAF is Aqua, the LAF should be changed to cross platform LAF to check if it works on other LAF or not.
Either run this in a loop with checks for all LAF versions available on OS, or check for default LAF at the beginning and change it to Cross-Platform LAF to check for alignment.
The current changes makes the test pass but does seem to give false positives by process of elimination for Aqua LAF.

Also, found the following minor issues which could be looked into if possible:
variables done and error are unused.
numData, dayData and mnDayData could be declared as final.
@override annotations are missing for methods used in ComboPopupCheckListener, PopupHandler.
panel is redeclared within scope instead of reusing available variable in method createContentPane().
wildcard * is used in import statements which according to guidelines should be replace to use only the classes required.

With Regards,
Avik Niyogi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20170111/9819d87d/attachment.html>

From prasanta.sadhukhan at oracle.com  Wed Jan 11 10:52:38 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Wed, 11 Jan 2017 16:22:38 +0530
Subject: <Swing Dev> 8172509: [TEST_BUG] [macosx] Failure of the new test
 java/awt/Focus/FocusTraversalPolicy/ButtonGroupLayoutTraversal/ButtonGroupLayoutTraversalTest.java
In-Reply-To: <BF782AB0-2551-4FA7-BB41-CD63E4A30048@oracle.com>
References: <BF782AB0-2551-4FA7-BB41-CD63E4A30048@oracle.com>
Message-ID: <7082ba94-5034-0f37-637a-e58e86562acb@oracle.com>

I guess we need to throw the exception if changing LaF fails instead of 
silently consuming it!!

Regards
Prasanta
On 1/11/2017 2:16 PM, Avik Niyogi wrote:
> Hi All,
>
> Kindly review the proposed fix for JDK9.
>
> *Bug: https://bugs.openjdk.java.net/browse/JDK-8172509*
> *
> *
> *Webrev: http://cr.openjdk.java.net/~aniyogi/8172509/webrev.00/ 
> <http://cr.openjdk.java.net/%7Eaniyogi/8172509/webrev.00/>*
> *
> *
> *Issue: *The focus traversal policy being tested was incorrect
>
> *Cause:* For Aqua and Nimbus, the focus traversal policy used is 
> different and as this is tested on default LAF, it fails on Mac OS X
>
> *Fix: *Cross-platform (Metal) LAF is used in case the default LAF is 
> either Aqua or Nimbus and the focus traversal works in those cases.
>
> With Regards,
> Avik Niyogi

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

From avik.niyogi at oracle.com  Wed Jan 11 11:01:46 2017
From: avik.niyogi at oracle.com (Avik Niyogi)
Date: Wed, 11 Jan 2017 16:31:46 +0530
Subject: <Swing Dev> 8172509: [TEST_BUG] [macosx] Failure of the new test
	java/awt/Focus/FocusTraversalPolicy/ButtonGroupLayoutTraversal/ButtonGroupLayoutTraversalTest.java
In-Reply-To: <7082ba94-5034-0f37-637a-e58e86562acb@oracle.com>
References: <BF782AB0-2551-4FA7-BB41-CD63E4A30048@oracle.com>
	<7082ba94-5034-0f37-637a-e58e86562acb@oracle.com>
Message-ID: <FF6AD8C6-A37E-4660-AC62-52D40CC684EB@oracle.com>

Hi All,
I have addressed the inputs received in the following update. Please review the same for JDK 9.
http://cr.openjdk.java.net/~aniyogi/8172509/webrev.01/ <http://cr.openjdk.java.net/~aniyogi/8172509/webrev.01/>

With Regards,
Avik Niyogi
> On 11-Jan-2017, at 4:22 pm, Prasanta Sadhukhan <prasanta.sadhukhan at oracle.com> wrote:
> 
> I guess we need to throw the exception if changing LaF fails instead of silently consuming it!! 
> Regards
> Prasanta
> On 1/11/2017 2:16 PM, Avik Niyogi wrote:
>> Hi All,
>> 
>> Kindly review the proposed fix for JDK9.
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8172509 <https://bugs.openjdk.java.net/browse/JDK-8172509>
>> 
>> Webrev: http://cr.openjdk.java.net/~aniyogi/8172509/webrev.00/ <http://cr.openjdk.java.net/%7Eaniyogi/8172509/webrev.00/>
>> 
>> Issue: The focus traversal policy being tested was incorrect
>> 
>> Cause: For Aqua and Nimbus, the focus traversal policy used is different and as this is tested on default LAF, it fails on Mac OS X
>> 
>> Fix: Cross-platform (Metal) LAF is used in case the default LAF is either Aqua or Nimbus and the focus traversal works in those cases.
>> 
>> With Regards,
>> Avik Niyogi
> 

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

From alexandr.scherbatiy at oracle.com  Wed Jan 11 14:08:51 2017
From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy)
Date: Wed, 11 Jan 2017 17:08:51 +0300
Subject: <Swing Dev> 8172509: [TEST_BUG] [macosx] Failure of the new test
 java/awt/Focus/FocusTraversalPolicy/ButtonGroupLayoutTraversal/ButtonGroupLayoutTraversalTest.java
In-Reply-To: <FF6AD8C6-A37E-4660-AC62-52D40CC684EB@oracle.com>
References: <BF782AB0-2551-4FA7-BB41-CD63E4A30048@oracle.com>
	<7082ba94-5034-0f37-637a-e58e86562acb@oracle.com>
	<FF6AD8C6-A37E-4660-AC62-52D40CC684EB@oracle.com>
Message-ID: <bcc124da-958e-1bb5-39d3-35493738fd82@oracle.com>

On 1/11/2017 2:01 PM, Avik Niyogi wrote:
> Hi All,
> I have addressed the inputs received in the following update. Please 
> review the same for JDK 9.
> http://cr.openjdk.java.net/~aniyogi/8172509/webrev.01/ 
> <http://cr.openjdk.java.net/%7Eaniyogi/8172509/webrev.01/>
>
> With Regards,
> Avik Niyogi
>> On 11-Jan-2017, at 4:22 pm, Prasanta Sadhukhan 
>> <prasanta.sadhukhan at oracle.com 
>> <mailto:prasanta.sadhukhan at oracle.com>> wrote:
>>
>> I guess we need to throw the exception if changing LaF fails instead 
>> of silently consuming it!!
>>
>> Regards
>> Prasanta
>> On 1/11/2017 2:16 PM, Avik Niyogi wrote:
>>> Hi All,
>>>
>>> Kindly review the proposed fix for JDK9.
>>>
>>> *Bug: https://bugs.openjdk.java.net/browse/JDK-8172509*
>>> *
>>> *
>>> *Webrev: http://cr.openjdk.java.net/~aniyogi/8172509/webrev.00/ 
>>> <http://cr.openjdk.java.net/%7Eaniyogi/8172509/webrev.00/>*
>>> *
>>> *
>>> *Issue: *The focus traversal policy being tested was incorrect
>>>
>>> *Cause:* For Aqua and Nimbus, the focus traversal policy used is 
>>> different and as this is tested on default LAF, it fails on Mac OS X
   Could you give more details what are the differences between using 
the focus traversal policy in Metal, Nimbus and Aqua L&F?

   Thanks,
   Alexandr.
>>>
>>> *Fix: *Cross-platform (Metal) LAF is used in case the default LAF is 
>>> either Aqua or Nimbus and the focus traversal works in those cases.
>>>
>>> With Regards,
>>> Avik Niyogi
>>
>

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

From avik.niyogi at oracle.com  Thu Jan 12 04:32:19 2017
From: avik.niyogi at oracle.com (Avik Niyogi)
Date: Thu, 12 Jan 2017 10:02:19 +0530
Subject: <Swing Dev> 8172509: [TEST_BUG] [macosx] Failure of the new test
	java/awt/Focus/FocusTraversalPolicy/ButtonGroupLayoutTraversal/ButtonGroupLayoutTraversalTest.java
In-Reply-To: <bcc124da-958e-1bb5-39d3-35493738fd82@oracle.com>
References: <BF782AB0-2551-4FA7-BB41-CD63E4A30048@oracle.com>
	<7082ba94-5034-0f37-637a-e58e86562acb@oracle.com>
	<FF6AD8C6-A37E-4660-AC62-52D40CC684EB@oracle.com>
	<bcc124da-958e-1bb5-39d3-35493738fd82@oracle.com>
Message-ID: <3206B166-1389-4D45-91FF-F05941659088@oracle.com>

In Nimbus and Aqua LAF, for focus traversal, keybindings do not existing only arrow keys would work within ungrouped radio buttons but not within grouped radio button groups. Also, verified Aqua LAF with native application on MacBook. So to test this focus traversal, it works only in LAF which do not use Aqua. I was informed last time a similar bug was fixed about this behaviour regarding Nimbus LAF as well and was confirmed by me by testing it.

With Regards,
Avik Niyogi
> On 11-Jan-2017, at 7:38 pm, Alexandr Scherbatiy <alexandr.scherbatiy at oracle.com> wrote:
> 
> On 1/11/2017 2:01 PM, Avik Niyogi wrote:
>> Hi All,
>> I have addressed the inputs received in the following update. Please review the same for JDK 9.
>> http://cr.openjdk.java.net/~aniyogi/8172509/webrev.01/ <http://cr.openjdk.java.net/%7Eaniyogi/8172509/webrev.01/>
>> 
>> With Regards,
>> Avik Niyogi
>>> On 11-Jan-2017, at 4:22 pm, Prasanta Sadhukhan <prasanta.sadhukhan at oracle.com <mailto:prasanta.sadhukhan at oracle.com>> wrote:
>>> 
>>> I guess we need to throw the exception if changing LaF fails instead of silently consuming it!! 
>>> Regards
>>> Prasanta
>>> On 1/11/2017 2:16 PM, Avik Niyogi wrote:
>>>> Hi All,
>>>> 
>>>> Kindly review the proposed fix for JDK9.
>>>> 
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8172509 <https://bugs.openjdk.java.net/browse/JDK-8172509>
>>>> 
>>>> Webrev: http://cr.openjdk.java.net/~aniyogi/8172509/webrev.00/ <http://cr.openjdk.java.net/%7Eaniyogi/8172509/webrev.00/>
>>>> 
>>>> Issue: The focus traversal policy being tested was incorrect
>>>> 
>>>> Cause: For Aqua and Nimbus, the focus traversal policy used is different and as this is tested on default LAF, it fails on Mac OS X
>   Could you give more details what are the differences between using the focus traversal policy in Metal, Nimbus and Aqua L&F?
> 
>   Thanks,
>   Alexandr.
>>>> 
>>>> Fix: Cross-platform (Metal) LAF is used in case the default LAF is either Aqua or Nimbus and the focus traversal works in those cases.
>>>> 
>>>> With Regards,
>>>> Avik Niyogi
>>> 
>> 
> 

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

From prasanta.sadhukhan at oracle.com  Thu Jan 12 07:04:44 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Thu, 12 Jan 2017 12:34:44 +0530
Subject: <Swing Dev> [9] RFR JDK-8172558: [PIT][TEST_BUG] Bad filename for
 javax/swing/JTable/8133919/DrawGridLinesTest.java
Message-ID: <ebcaad2a-46da-97e9-48f9-0ae269b5b09d@oracle.com>

Hi All,

Please review the name change for this regression test which was causing 
jtreg to fail as it was not finding the test.

Bug: https://bugs.openjdk.java.net/browse/JDK-8172558

Filename was javax/swing/JTable/8133919/DrawGridLInesTest.java [whith 
capital I]

but test has jtreg tag @run main DrawGridLinesTest

Fix is to rename the test to correct name.

webrev: http://cr.openjdk.java.net/~psadhukhan/8172558/webrev.00/

Regards
Prasanta


From yuri.nesterenko at oracle.com  Thu Jan 12 08:04:28 2017
From: yuri.nesterenko at oracle.com (Yuri Nesterenko)
Date: Thu, 12 Jan 2017 11:04:28 +0300
Subject: <Swing Dev> [9] RFR JDK-8172558: [PIT][TEST_BUG] Bad filename
 for javax/swing/JTable/8133919/DrawGridLinesTest.java
In-Reply-To: <ebcaad2a-46da-97e9-48f9-0ae269b5b09d@oracle.com>
References: <ebcaad2a-46da-97e9-48f9-0ae269b5b09d@oracle.com>
Message-ID: <dc7cca04-4af9-ce34-7e1f-80b076b8d370@oracle.com>

It's fine and necessary fix but it should be done in the integration
repository, not in client. Otherwise, the bug would stay in master for
2 next builds and prevent jtreg starting at all.

+1

-yan

On 01/12/2017 10:04 AM, Prasanta Sadhukhan wrote:
> Hi All,
>
> Please review the name change for this regression test which was causing
> jtreg to fail as it was not finding the test.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8172558
>
> Filename was javax/swing/JTable/8133919/DrawGridLInesTest.java [whith
> capital I]
>
> but test has jtreg tag @run main DrawGridLinesTest
>
> Fix is to rename the test to correct name.
>
> webrev: http://cr.openjdk.java.net/~psadhukhan/8172558/webrev.00/
>
> Regards
> Prasanta



From vikrant.v.agarwal at oracle.com  Thu Jan 12 08:26:24 2017
From: vikrant.v.agarwal at oracle.com (Vikrant Agarwal)
Date: Thu, 12 Jan 2017 00:26:24 -0800 (PST)
Subject: <Swing Dev> Review Request for JDK-8172500
Message-ID: <2932ec97-6313-4fdd-98cc-b171ca66fb79@default>

Hi All,

 

Please review the following:

Bug : https://bugs.openjdk.java.net/browse/JDK-8172500

 

Webrev Link: http://cr.openjdk.java.net/~vagarwal/8172500/webrev_01/

 

Summary: This is a new test for automated testing of SwingSet SliderDemo using Jemmy.

Please see the bug for description of the scenario's automated.

 

Best Regards,

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

From vikrant.v.agarwal at oracle.com  Thu Jan 12 08:43:40 2017
From: vikrant.v.agarwal at oracle.com (Vikrant Agarwal)
Date: Thu, 12 Jan 2017 00:43:40 -0800 (PST)
Subject: <Swing Dev> Review request for JDK-8172489
Message-ID: <3c025e1c-63a5-4404-9157-40d7f4305e29@default>

Hi All,

 

Please review the following:

 

Bug : https://bugs.openjdk.java.net/browse/JDK-8172489

 

Webrev Link: http://cr.openjdk.java.net/~vagarwal/8172489/webrev_01/

 

Summary: This is a fix for a bug in Jemmy, that we found while automating the SwingSet Demo.

JSlider was not able to scroll to negative value on Mac because in JSliderAPIDriver.jump(final ComponentOperator oper, final ScrollAdjuster adj) 
, newValue = -1; was being done, and after assigning a new value to newValue conditionally, it was calling JSliderAPIDriver. setValue(ComponentOperator oper, int value) 
which was setting the new value using JSliderOperator.setValue only if the newValue is not -1, which had been set as initial value, this was being done as a check that the value of newValue has not changed, but when the slider needs to goto a negative value, then this gets stuck at 0, because -1 value cannot be assigned.

 

Please see the bug for more description.

 

Best Regards,

Vikrant

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

From alexandr.scherbatiy at oracle.com  Thu Jan 12 11:19:48 2017
From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy)
Date: Thu, 12 Jan 2017 14:19:48 +0300
Subject: <Swing Dev> [9] RFR JDK-8172558: [PIT][TEST_BUG] Bad filename
 for javax/swing/JTable/8133919/DrawGridLinesTest.java
In-Reply-To: <ebcaad2a-46da-97e9-48f9-0ae269b5b09d@oracle.com>
References: <ebcaad2a-46da-97e9-48f9-0ae269b5b09d@oracle.com>
Message-ID: <4cde4e79-cb23-965c-340e-9bd92fe85b14@oracle.com>

The fix looks good to me.

Thanks,
Alexandr.

On 1/12/2017 10:04 AM, Prasanta Sadhukhan wrote:
> Hi All,
>
> Please review the name change for this regression test which was 
> causing jtreg to fail as it was not finding the test.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8172558
>
> Filename was javax/swing/JTable/8133919/DrawGridLInesTest.java [whith 
> capital I]
>
> but test has jtreg tag @run main DrawGridLinesTest
>
> Fix is to rename the test to correct name.
>
> webrev: http://cr.openjdk.java.net/~psadhukhan/8172558/webrev.00/
>
> Regards
> Prasanta



From alexander.popov at oracle.com  Thu Jan 12 10:42:49 2017
From: alexander.popov at oracle.com (alexander popov)
Date: Thu, 12 Jan 2017 13:42:49 +0300
Subject: <Swing Dev> [9] Review request for 8165207: [macosx] Test
 javax/swing/Popup/TaskbarPositionTest.java fails on Mac 10.12
In-Reply-To: <FD06471F-9D6D-47B7-A417-97CA66D1C1B2@oracle.com>
References: <FD06471F-9D6D-47B7-A417-97CA66D1C1B2@oracle.com>
Message-ID: <b2f663fa-ddcc-a425-4baa-14f83ed3b6ec@oracle.com>

Yep, its reasonable!

Will fix that and update diff.


On 1/11/2017 1:39 PM, Avik Niyogi wrote:
> Hi Alexander,
> The following is my input for this webrev:
>
> In case the LAF is Aqua, the check for combobox alignment is skipped.
> Instead, if default LAF is Aqua, the LAF should be changed to cross 
> platform LAF to check if it works on other LAF or not.
> Either run this in a loop with checks for all LAF versions available 
> on OS, or check for default LAF at the beginning and change it to 
> Cross-Platform LAF to check for alignment.
> The current changes makes the test pass but does seem to give false 
> positives by process of elimination for Aqua LAF.
>
> Also, found the following minor issues which could be looked into if 
> possible:
> variables *done* and *error* are unused.
> *numData*, *dayData* and *mnDayData* could be declared as final.
> *@override* annotations are missing for methods used in 
> *ComboPopupCheckListener*, *PopupHandler*.
> *panel* is redeclared within scope instead of reusing available 
> variable in method *createContentPane()*.
> *wildcard* *** is used in *import* statements which according to 
> guidelines should be replace to use only the classes required.
>
> With Regards,
> Avik Niyogi

-- 
Best regards,
Alexander.

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

From sergey.bylokhov at oracle.com  Thu Jan 12 16:33:55 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 12 Jan 2017 19:33:55 +0300
Subject: <Swing Dev> Review Request for JDK-8172500
In-Reply-To: <2932ec97-6313-4fdd-98cc-b171ca66fb79@default>
References: <2932ec97-6313-4fdd-98cc-b171ca66fb79@default>
Message-ID: <0A02686C-240A-40F8-9AA9-A840401ED657@oracle.com>

Hi, Vikrant.

What look and feels are tested by this test?

> 
> Hi All,
>  
> Please review the following:
> Bug : https://bugs.openjdk.java.net/browse/JDK-8172500 <https://bugs.openjdk.java.net/browse/JDK-8172500>
>  
> Webrev Link: http://cr.openjdk.java.net/~vagarwal/8172500/webrev_01/ <http://cr.openjdk.java.net/~vagarwal/8172500/webrev_01/>
>  
> Summary: This is a new test for automated testing of SwingSet SliderDemo using Jemmy.
> Please see the bug for description of the scenario?s automated.
>  
> Best Regards,
> Vikrant

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

From alexander.kouznetsov at oracle.com  Thu Jan 12 18:32:30 2017
From: alexander.kouznetsov at oracle.com (Alexander Kouznetsov)
Date: Thu, 12 Jan 2017 10:32:30 -0800
Subject: <Swing Dev> Review request for JDK-8172489
In-Reply-To: <3c025e1c-63a5-4404-9157-40d7f4305e29@default>
References: <3c025e1c-63a5-4404-9157-40d7f4305e29@default>
Message-ID: <be9774e3-61eb-b1a2-f803-2091d1167af3@oracle.com>

Looks good to me.

Phil, could you please review?

Best regards,
Alexander Kouznetsov
(408) 276-0387

On 1/12/2017 12:43 AM, Vikrant Agarwal wrote:
>
> Hi All,
>
> Please review the following:
>
> *Bug :* https://bugs.openjdk.java.net/browse/JDK-8172489
>
> *Webrev Link:* http://cr.openjdk.java.net/~vagarwal/8172489/webrev_01/ 
> <http://cr.openjdk.java.net/%7Evagarwal/8172489/webrev_01/>
>
> *Summary:* This is a fix for a bug in Jemmy, that we found while 
> automating the SwingSet Demo.
>
> JSlider was not able to scroll to negative value on Mac because in 
> JSliderAPIDriver.jump(final ComponentOperator oper, final 
> ScrollAdjuster adj)
> , newValue = -1; was being done, and after assigning a new value to 
> newValue conditionally, it was calling JSliderAPIDriver. 
> setValue(ComponentOperator oper, int value)
> which was setting the new value using JSliderOperator.setValue only if 
> the newValue is not -1, which had been set as initial value, this was 
> being done as a check that the value of newValue has not changed, but 
> when the slider needs to goto a negative value, then this gets stuck 
> at 0, because -1 value cannot be assigned.
>
> Please see the bug for more description.
>
> Best Regards,
>
> Vikrant
>

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

From alexander.kouznetsov at oracle.com  Thu Jan 12 18:39:58 2017
From: alexander.kouznetsov at oracle.com (Alexander Kouznetsov)
Date: Thu, 12 Jan 2017 10:39:58 -0800
Subject: <Swing Dev> Review Request for JDK-8172500
In-Reply-To: <2932ec97-6313-4fdd-98cc-b171ca66fb79@default>
References: <2932ec97-6313-4fdd-98cc-b171ca66fb79@default>
Message-ID: <75e3ba79-57a9-9da7-5aa1-286baf5c13e8@oracle.com>

Looks good to me.

Best regards,
Alexander Kouznetsov
(408) 276-0387

On 1/12/2017 12:26 AM, Vikrant Agarwal wrote:
>
> Hi All,
>
> Please review the following:
>
> Bug : https://bugs.openjdk.java.net/browse/JDK-8172500
>
> Webrev Link: http://cr.openjdk.java.net/~vagarwal/8172500/webrev_01/ 
> <http://cr.openjdk.java.net/%7Evagarwal/8172500/webrev_01/>
>
> Summary: This is a new test for automated testing of SwingSet 
> SliderDemo using Jemmy.
>
> Please see the bug for description of the scenario?s automated.
>
> Best Regards,
>
> Vikrant
>

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

From alexandre.iline at oracle.com  Thu Jan 12 18:49:35 2017
From: alexandre.iline at oracle.com (Alexandre (Shura) Iline)
Date: Thu, 12 Jan 2017 10:49:35 -0800
Subject: <Swing Dev> Review request for JDK-8172489
In-Reply-To: <3c025e1c-63a5-4404-9157-40d7f4305e29@default>
References: <3c025e1c-63a5-4404-9157-40d7f4305e29@default>
Message-ID: <40513088-BB66-4652-8A5B-361D0922C8BD@oracle.com>

Looks good.

Thank.

Shura

> On Jan 12, 2017, at 12:43 AM, Vikrant Agarwal <vikrant.v.agarwal at oracle.com> wrote:
> 
> Hi All,
>  
> Please review the following:
>  
> Bug : https://bugs.openjdk.java.net/browse/JDK-8172489 <https://bugs.openjdk.java.net/browse/JDK-8172489>
>  
> Webrev Link: http://cr.openjdk.java.net/~vagarwal/8172489/webrev_01/ <http://cr.openjdk.java.net/~vagarwal/8172489/webrev_01/>
>  
> Summary: This is a fix for a bug in Jemmy, that we found while automating the SwingSet Demo.
> JSlider was not able to scroll to negative value on Mac because in JSliderAPIDriver.jump(final ComponentOperator oper, final ScrollAdjuster adj) 
> , newValue = -1; was being done, and after assigning a new value to newValue conditionally, it was calling JSliderAPIDriver. setValue(ComponentOperator oper, int value) 
> which was setting the new value using JSliderOperator.setValue only if the newValue is not -1, which had been set as initial value, this was being done as a check that the value of newValue has not changed, but when the slider needs to goto a negative value, then this gets stuck at 0, because -1 value cannot be assigned.
>  
> Please see the bug for more description.
>  
> Best Regards,
> Vikrant

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

From philip.race at oracle.com  Thu Jan 12 18:57:49 2017
From: philip.race at oracle.com (Philip Race)
Date: Thu, 12 Jan 2017 10:57:49 -0800
Subject: <Swing Dev> Review request for JDK-8172489
In-Reply-To: <be9774e3-61eb-b1a2-f803-2091d1167af3@oracle.com>
References: <3c025e1c-63a5-4404-9157-40d7f4305e29@default>
	<be9774e3-61eb-b1a2-f803-2091d1167af3@oracle.com>
Message-ID: <5877D1AD.9060107@oracle.com>

There's a change in the logic now so that if

adj.getScrollDirection() is not INCREASE or DECREASE nothing gets changed.

I presume that is deliberate. Assuming so, "+1".


-phil.



On 1/12/17, 10:32 AM, Alexander Kouznetsov wrote:
>
> Looks good to me.
>
> Phil, could you please review?
>
> Best regards,
> Alexander Kouznetsov
> (408) 276-0387
> On 1/12/2017 12:43 AM, Vikrant Agarwal wrote:
>>
>> Hi All,
>>
>> Please review the following:
>>
>> *Bug :* https://bugs.openjdk.java.net/browse/JDK-8172489
>>
>> *Webrev Link:* 
>> http://cr.openjdk.java.net/~vagarwal/8172489/webrev_01/ 
>> <http://cr.openjdk.java.net/%7Evagarwal/8172489/webrev_01/>
>>
>> *Summary:* This is a fix for a bug in Jemmy, that we found while 
>> automating the SwingSet Demo.
>>
>> JSlider was not able to scroll to negative value on Mac because in 
>> JSliderAPIDriver.jump(final ComponentOperator oper, final 
>> ScrollAdjuster adj)
>> , newValue = -1; was being done, and after assigning a new value to 
>> newValue conditionally, it was calling JSliderAPIDriver. 
>> setValue(ComponentOperator oper, int value)
>> which was setting the new value using JSliderOperator.setValue only 
>> if the newValue is not -1, which had been set as initial value, this 
>> was being done as a check that the value of newValue has not changed, 
>> but when the slider needs to goto a negative value, then this gets 
>> stuck at 0, because -1 value cannot be assigned.
>>
>> Please see the bug for more description.
>>
>> Best Regards,
>>
>> Vikrant
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20170112/7e7aacc1/attachment.html>

From vikrant.v.agarwal at oracle.com  Fri Jan 13 05:30:13 2017
From: vikrant.v.agarwal at oracle.com (Vikrant Agarwal)
Date: Thu, 12 Jan 2017 21:30:13 -0800 (PST)
Subject: <Swing Dev> Review Request for JDK-8172500
In-Reply-To: <0A02686C-240A-40F8-9AA9-A840401ED657@oracle.com>
References: <2932ec97-6313-4fdd-98cc-b171ca66fb79@default>
	<0A02686C-240A-40F8-9AA9-A840401ED657@oracle.com>
Message-ID: <a5fe3be4-bad3-4517-a42c-d11e5b6f6639@default>

Hi Sergey,

?

As of now we are testing Metal Look And Feel, but we have planned to first finish automation tests for all the individual Swingset demos and then add support for testing all the different look and feels.

?

Best Regards,

Vikrant

?

?

From: Sergey Bylokhov 
Sent: Thursday, January 12, 2017 10:04 PM
To: Vikrant Agarwal
Cc: swing-dev at openjdk.java.net; Aleksandre Iline; Alexander Kouznetsov
Subject: Re: <Swing Dev> Review Request for JDK-8172500

?

Hi,?Vikrant.

?

What look and feels are tested by this test?

?

?

Hi All,

?

Please review the following:

Bug :?https://bugs.openjdk.java.net/browse/JDK-8172500

?

Webrev Link:?http://cr.openjdk.java.net/~vagarwal/8172500/webrev_01/

?

Summary: This is a new test for automated testing of SwingSet SliderDemo using Jemmy.

Please see the bug for description of the scenario?s automated.

?

Best Regards,

Vikrant

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

From avik.niyogi at oracle.com  Fri Jan 13 06:13:08 2017
From: avik.niyogi at oracle.com (Avik Niyogi)
Date: Fri, 13 Jan 2017 11:43:08 +0530
Subject: <Swing Dev> 8172509: [TEST_BUG] [macosx] Failure of the new test
	java/awt/Focus/FocusTraversalPolicy/ButtonGroupLayoutTraversal/ButtonGroupLayoutTraversalTest.java
In-Reply-To: <3206B166-1389-4D45-91FF-F05941659088@oracle.com>
References: <BF782AB0-2551-4FA7-BB41-CD63E4A30048@oracle.com>
	<7082ba94-5034-0f37-637a-e58e86562acb@oracle.com>
	<FF6AD8C6-A37E-4660-AC62-52D40CC684EB@oracle.com>
	<bcc124da-958e-1bb5-39d3-35493738fd82@oracle.com>
	<3206B166-1389-4D45-91FF-F05941659088@oracle.com>
Message-ID: <75D0603B-FCFD-45CE-831C-8712C4FEE550@oracle.com>

A gentle reminder, please review the code changes made.

With Regards,
Avik Niyogi

> On 12-Jan-2017, at 10:02 am, Avik Niyogi <avik.niyogi at oracle.com> wrote:
> 
> In Nimbus and Aqua LAF, for focus traversal, keybindings do not existing only arrow keys would work within ungrouped radio buttons but not within grouped radio button groups. Also, verified Aqua LAF with native application on MacBook. So to test this focus traversal, it works only in LAF which do not use Aqua. I was informed last time a similar bug was fixed about this behaviour regarding Nimbus LAF as well and was confirmed by me by testing it.
> 
> With Regards,
> Avik Niyogi
>> On 11-Jan-2017, at 7:38 pm, Alexandr Scherbatiy <alexandr.scherbatiy at oracle.com <mailto:alexandr.scherbatiy at oracle.com>> wrote:
>> 
>> On 1/11/2017 2:01 PM, Avik Niyogi wrote:
>>> Hi All,
>>> I have addressed the inputs received in the following update. Please review the same for JDK 9.
>>> http://cr.openjdk.java.net/~aniyogi/8172509/webrev.01/ <http://cr.openjdk.java.net/%7Eaniyogi/8172509/webrev.01/>
>>> 
>>> With Regards,
>>> Avik Niyogi
>>>> On 11-Jan-2017, at 4:22 pm, Prasanta Sadhukhan <prasanta.sadhukhan at oracle.com <mailto:prasanta.sadhukhan at oracle.com>> wrote:
>>>> 
>>>> I guess we need to throw the exception if changing LaF fails instead of silently consuming it!! 
>>>> Regards
>>>> Prasanta
>>>> On 1/11/2017 2:16 PM, Avik Niyogi wrote:
>>>>> Hi All,
>>>>> 
>>>>> Kindly review the proposed fix for JDK9.
>>>>> 
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8172509 <https://bugs.openjdk.java.net/browse/JDK-8172509>
>>>>> 
>>>>> Webrev: http://cr.openjdk.java.net/~aniyogi/8172509/webrev.00/ <http://cr.openjdk.java.net/%7Eaniyogi/8172509/webrev.00/>
>>>>> 
>>>>> Issue: The focus traversal policy being tested was incorrect
>>>>> 
>>>>> Cause: For Aqua and Nimbus, the focus traversal policy used is different and as this is tested on default LAF, it fails on Mac OS X
>>   Could you give more details what are the differences between using the focus traversal policy in Metal, Nimbus and Aqua L&F?
>> 
>>   Thanks,
>>   Alexandr.
>>>>> 
>>>>> Fix: Cross-platform (Metal) LAF is used in case the default LAF is either Aqua or Nimbus and the focus traversal works in those cases.
>>>>> 
>>>>> With Regards,
>>>>> Avik Niyogi
>>>> 
>>> 
>> 
> 

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

From prasanta.sadhukhan at oracle.com  Fri Jan 13 10:48:29 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Fri, 13 Jan 2017 16:18:29 +0530
Subject: <Swing Dev> [9] RFR: JDK-8172012: [TEST_BUG] delays needed in
 javax/swing/JTree/4633594/bug4633594.java
Message-ID: <7932d11b-1e5d-5990-2629-5a8dd67af8c1@oracle.com>

Hi All,

Bug: https://bugs.openjdk.java.net/browse/JDK-8172012

The issue of not having a delay between robot events is already 
addressed by adding autodelay and
has been approved in closed crucible review.
This webrev addresses moving the closed test to open in addition to 
modify test to migrate from applet based test to main-based. 
Additionally, rename the testname to something meaningful.

webrev: http://cr.openjdk.java.net/~psadhukhan/8172012/webrev.00/

Regards
Prasanta



From abdul.kolarkunnu at oracle.com  Mon Jan 16 13:39:49 2017
From: abdul.kolarkunnu at oracle.com (Muneer Kolarkunnu)
Date: Mon, 16 Jan 2017 05:39:49 -0800 (PST)
Subject: <Swing Dev> RFR JDK-8172804: SwingSet Automation: Jemmy Library :
 FrameOperator: maximize() and demaximize() are not properly implemented
Message-ID: <cfc71374-9a64-4ea4-90c7-6fc3e7adcbe4@default>

Hi All,

 

Please review the following:

 

Bug : https://bugs.openjdk.java.net/browse/JDK-8172804

 

Webrev Link: http://cr.openjdk.java.net/~akolarkunnu/8172804/webrev.00/

 

Summary: This is a fix for a bug in Jemmy code, that we found while automating the SwingSet Demo.

Previously maximize() was implemented using Frame.setSize() which will set frame size as screen size, but its state is not changing, it will be Frame.NORMAL itself. 
Now it is implementing using, Frame.setExtendedState() with Frame.MAXIMIZED_BOTH as parameter, so that its actual state also will set to Frame.MAXIMIZED_BOTH. 



Also demaximize() is not implemented completely. So demaximize() is implementing using Frame.setExtendedState() with Frame.NORMAL .

 

Regards,

Muneer

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

From sergey.bylokhov at oracle.com  Mon Jan 16 16:08:40 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 16 Jan 2017 19:08:40 +0300
Subject: <Swing Dev> Review Request for JDK-8172500
In-Reply-To: <a5fe3be4-bad3-4517-a42c-d11e5b6f6639@default>
References: <2932ec97-6313-4fdd-98cc-b171ca66fb79@default>
	<0A02686C-240A-40F8-9AA9-A840401ED657@oracle.com>
	<a5fe3be4-bad3-4517-a42c-d11e5b6f6639@default>
Message-ID: <E59DE603-9512-47E1-8AC3-EA6A62337A7E@oracle.com>


> 13 ???. 2017 ?., ? 8:30, Vikrant Agarwal <vikrant.v.agarwal at oracle.com> ???????(?):
> 
> Hi Sergey,
>  
> As of now we are testing Metal Look And Feel, but we have planned to first finish automation tests for all the individual Swingset demos and then add support for testing all the different look and feels.

 Does it mean that it is set somewhere in the test? Because on MacOS it is set to Aqua by default.

>  
> Best Regards,
> Vikrant
>  
>  
> From: Sergey Bylokhov 
> Sent: Thursday, January 12, 2017 10:04 PM
> To: Vikrant Agarwal
> Cc: swing-dev at openjdk.java.net; Aleksandre Iline; Alexander Kouznetsov
> Subject: Re: <Swing Dev> Review Request for JDK-8172500
>  
> Hi, Vikrant.
>  
> What look and feels are tested by this test?
>  
>  
> Hi All,
>  
> Please review the following:
> Bug : https://bugs.openjdk.java.net/browse/JDK-8172500 <https://bugs.openjdk.java.net/browse/JDK-8172500>
>  
> Webrev Link: http://cr.openjdk.java.net/~vagarwal/8172500/webrev_01/ <http://cr.openjdk.java.net/~vagarwal/8172500/webrev_01/>
>  
> Summary: This is a new test for automated testing of SwingSet SliderDemo using Jemmy.
> Please see the bug for description of the scenario?s automated.
>  
> Best Regards,
> Vikrant

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

From yuri.nesterenko at oracle.com  Tue Jan 17 10:37:36 2017
From: yuri.nesterenko at oracle.com (Yuri Nesterenko)
Date: Tue, 17 Jan 2017 13:37:36 +0300
Subject: <Swing Dev> [9] RFR: JDK-8172012: [TEST_BUG] delays needed in
 javax/swing/JTree/4633594/bug4633594.java
In-Reply-To: <7932d11b-1e5d-5990-2629-5a8dd67af8c1@oracle.com>
References: <7932d11b-1e5d-5990-2629-5a8dd67af8c1@oracle.com>
Message-ID: <d51618de-1deb-29a6-df45-d37a42e26710@oracle.com>

+1

On 01/13/2017 01:48 PM, Prasanta Sadhukhan wrote:
> Hi All,
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8172012
>
> The issue of not having a delay between robot events is already
> addressed by adding autodelay and
> has been approved in closed crucible review.
> This webrev addresses moving the closed test to open in addition to
> modify test to migrate from applet based test to main-based.
> Additionally, rename the testname to something meaningful.
>
> webrev: http://cr.openjdk.java.net/~psadhukhan/8172012/webrev.00/
>
> Regards
> Prasanta
>



From vikrant.v.agarwal at oracle.com  Tue Jan 17 15:24:32 2017
From: vikrant.v.agarwal at oracle.com (Vikrant Agarwal)
Date: Tue, 17 Jan 2017 07:24:32 -0800 (PST)
Subject: <Swing Dev> Review Request for JDK-8172500
In-Reply-To: <E59DE603-9512-47E1-8AC3-EA6A62337A7E@oracle.com>
References: <2932ec97-6313-4fdd-98cc-b171ca66fb79@default>
	<0A02686C-240A-40F8-9AA9-A840401ED657@oracle.com>
	<a5fe3be4-bad3-4517-a42c-d11e5b6f6639@default>
	<E59DE603-9512-47E1-8AC3-EA6A62337A7E@oracle.com>
Message-ID: <5f6521a1-67fa-4db2-89bf-3d2f8218090f@default>

Hi Sergey,

?

We are not setting the look and feel explicitly anywhere so the ?_default_ L&F is being used right now, which being Aqua on Mac.

?

Best Regards,

Vikrant

?

From: Sergey Bylokhov 
Sent: Monday, January 16, 2017 9:39 PM
To: Vikrant Agarwal
Cc: swing-dev at openjdk.java.net; Aleksandre Iline; Alexander Kouznetsov
Subject: Re: <Swing Dev> Review Request for JDK-8172500

?

?

13 ???. 2017 ?., ? 8:30, Vikrant Agarwal <HYPERLINK "mailto:vikrant.v.agarwal at oracle.com"vikrant.v.agarwal at oracle.com> ???????(?):

?

Hi Sergey,

?

As of now we are testing Metal Look And Feel, but we have planned to first finish automation tests for all the individual Swingset demos and then add support for testing all the different look and feels.

?

?Does it mean that it is set somewhere in the test? Because on MacOS it is set to Aqua by default.





?

Best Regards,

Vikrant

?

?

From:?Sergey Bylokhov?
Sent:?Thursday, January 12, 2017 10:04 PM
To:?Vikrant Agarwal
Cc:?HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net; Aleksandre Iline; Alexander Kouznetsov
Subject:?Re: <Swing Dev> Review Request for JDK-8172500

?

Hi,?Vikrant.

?

What look and feels are tested by this test?

?

?

Hi All,

?

Please review the following:

Bug :?https://bugs.openjdk.java.net/browse/JDK-8172500

?

Webrev Link:?http://cr.openjdk.java.net/~vagarwal/8172500/webrev_01/

?

Summary: This is a new test for automated testing of SwingSet SliderDemo using Jemmy.

Please see the bug for description of the scenario?s automated.

?

Best Regards,

Vikrant

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

From sergey.bylokhov at oracle.com  Tue Jan 17 15:51:36 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 17 Jan 2017 18:51:36 +0300
Subject: <Swing Dev> [9] RFR: JDK-8172012: [TEST_BUG] delays needed in
 javax/swing/JTree/4633594/bug4633594.java
In-Reply-To: <d51618de-1deb-29a6-df45-d37a42e26710@oracle.com>
References: <7932d11b-1e5d-5990-2629-5a8dd67af8c1@oracle.com>
	<d51618de-1deb-29a6-df45-d37a42e26710@oracle.com>
Message-ID: <0DEEDA48-7DDB-4E80-8370-D81DCC9A4CFC@oracle.com>

Looks fine, but please update the dates in the header. I assume that the test was created long time ago(not in 2017), in 2017 it was updated.

> 
> +1
> 
> On 01/13/2017 01:48 PM, Prasanta Sadhukhan wrote:
>> Hi All,
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8172012
>> 
>> The issue of not having a delay between robot events is already
>> addressed by adding autodelay and
>> has been approved in closed crucible review.
>> This webrev addresses moving the closed test to open in addition to
>> modify test to migrate from applet based test to main-based.
>> Additionally, rename the testname to something meaningful.
>> 
>> webrev: http://cr.openjdk.java.net/~psadhukhan/8172012/webrev.00/
>> 
>> Regards
>> Prasanta
>> 
> 



From sergey.bylokhov at oracle.com  Tue Jan 17 15:52:16 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 17 Jan 2017 18:52:16 +0300
Subject: <Swing Dev> Review Request for JDK-8172500
In-Reply-To: <5f6521a1-67fa-4db2-89bf-3d2f8218090f@default>
References: <2932ec97-6313-4fdd-98cc-b171ca66fb79@default>
	<0A02686C-240A-40F8-9AA9-A840401ED657@oracle.com>
	<a5fe3be4-bad3-4517-a42c-d11e5b6f6639@default>
	<E59DE603-9512-47E1-8AC3-EA6A62337A7E@oracle.com>
	<5f6521a1-67fa-4db2-89bf-3d2f8218090f@default>
Message-ID: <1FD163EA-70E4-4CA9-AA0C-823348D17B68@oracle.com>

Ok. Looks fine.

> 
> Hi Sergey,
>  
> We are not setting the look and feel explicitly anywhere so the  _default_ L&F is being used right now, which being Aqua on Mac.
>  
> Best Regards,
> Vikrant
>  
> From: Sergey Bylokhov 
> Sent: Monday, January 16, 2017 9:39 PM
> To: Vikrant Agarwal
> Cc: swing-dev at openjdk.java.net; Aleksandre Iline; Alexander Kouznetsov
> Subject: Re: <Swing Dev> Review Request for JDK-8172500
>  
>  
> 13 ???. 2017 ?., ? 8:30, Vikrant Agarwal <vikrant.v.agarwal at oracle.com <mailto:vikrant.v.agarwal at oracle.com>> ???????(?):
>  
> Hi Sergey,
>  
> As of now we are testing Metal Look And Feel, but we have planned to first finish automation tests for all the individual Swingset demos and then add support for testing all the different look and feels.
>  
>  Does it mean that it is set somewhere in the test? Because on MacOS it is set to Aqua by default.
> 
> 
>  
> Best Regards,
> Vikrant
>  
>  
> From: Sergey Bylokhov 
> Sent: Thursday, January 12, 2017 10:04 PM
> To: Vikrant Agarwal
> Cc: swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>; Aleksandre Iline; Alexander Kouznetsov
> Subject: Re: <Swing Dev> Review Request for JDK-8172500
>  
> Hi, Vikrant.
>  
> What look and feels are tested by this test?
>  
>  
> Hi All,
>  
> Please review the following:
> Bug : https://bugs.openjdk.java.net/browse/JDK-8172500 <https://bugs.openjdk.java.net/browse/JDK-8172500>
>  
> Webrev Link: http://cr.openjdk.java.net/~vagarwal/8172500/webrev_01/ <http://cr.openjdk.java.net/~vagarwal/8172500/webrev_01/>
>  
> Summary: This is a new test for automated testing of SwingSet SliderDemo using Jemmy.
> Please see the bug for description of the scenario?s automated.
>  
> Best Regards,
> Vikrant

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

From sergey.bylokhov at oracle.com  Tue Jan 17 15:53:51 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 17 Jan 2017 18:53:51 +0300
Subject: <Swing Dev> 8172509: [TEST_BUG] [macosx] Failure of the new test
 java/awt/Focus/FocusTraversalPolicy/ButtonGroupLayoutTraversal/ButtonGroupLayoutTraversalTest.java
In-Reply-To: <3206B166-1389-4D45-91FF-F05941659088@oracle.com>
References: <BF782AB0-2551-4FA7-BB41-CD63E4A30048@oracle.com>
	<7082ba94-5034-0f37-637a-e58e86562acb@oracle.com>
	<FF6AD8C6-A37E-4660-AC62-52D40CC684EB@oracle.com>
	<bcc124da-958e-1bb5-39d3-35493738fd82@oracle.com>
	<3206B166-1389-4D45-91FF-F05941659088@oracle.com>
Message-ID: <F5A57DFA-9EE4-43D7-B360-739C17A1AFB2@oracle.com>

Hi, Avik.
> 
> In Nimbus and Aqua LAF, for focus traversal, keybindings do not existing only arrow keys would work within ungrouped radio buttons but not within grouped radio button groups. Also, verified Aqua LAF with native application on MacBook. So to test this focus traversal, it works only in LAF which do not use Aqua. I was informed last time a similar bug was fixed about this behaviour regarding Nimbus LAF as well and was confirmed by me by testing it.

Can you please clarify what bug was fixed in nimbus which was confirmed by you.

> 
> With Regards,
> Avik Niyogi
>> On 11-Jan-2017, at 7:38 pm, Alexandr Scherbatiy <alexandr.scherbatiy at oracle.com <mailto:alexandr.scherbatiy at oracle.com>> wrote:
>> 
>> On 1/11/2017 2:01 PM, Avik Niyogi wrote:
>>> Hi All,
>>> I have addressed the inputs received in the following update. Please review the same for JDK 9.
>>> http://cr.openjdk.java.net/~aniyogi/8172509/webrev.01/ <http://cr.openjdk.java.net/%7Eaniyogi/8172509/webrev.01/>
>>> 
>>> With Regards,
>>> Avik Niyogi
>>>> On 11-Jan-2017, at 4:22 pm, Prasanta Sadhukhan <prasanta.sadhukhan at oracle.com <mailto:prasanta.sadhukhan at oracle.com>> wrote:
>>>> 
>>>> I guess we need to throw the exception if changing LaF fails instead of silently consuming it!! 
>>>> Regards
>>>> Prasanta
>>>> On 1/11/2017 2:16 PM, Avik Niyogi wrote:
>>>>> Hi All,
>>>>> 
>>>>> Kindly review the proposed fix for JDK9.
>>>>> 
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8172509 <https://bugs.openjdk.java.net/browse/JDK-8172509>
>>>>> 
>>>>> Webrev: http://cr.openjdk.java.net/~aniyogi/8172509/webrev.00/ <http://cr.openjdk.java.net/%7Eaniyogi/8172509/webrev.00/>
>>>>> 
>>>>> Issue: The focus traversal policy being tested was incorrect
>>>>> 
>>>>> Cause: For Aqua and Nimbus, the focus traversal policy used is different and as this is tested on default LAF, it fails on Mac OS X
>>   Could you give more details what are the differences between using the focus traversal policy in Metal, Nimbus and Aqua L&F?
>> 
>>   Thanks,
>>   Alexandr.
>>>>> 
>>>>> Fix: Cross-platform (Metal) LAF is used in case the default LAF is either Aqua or Nimbus and the focus traversal works in those cases.
>>>>> 
>>>>> With Regards,
>>>>> Avik Niyogi
>>>> 
>>> 
>> 
> 

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

From sergey.bylokhov at oracle.com  Tue Jan 17 18:38:15 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 17 Jan 2017 21:38:15 +0300
Subject: <Swing Dev> RFR JDK-8172804: SwingSet Automation: Jemmy Library
 : FrameOperator: maximize() and demaximize() are not properly implemented
In-Reply-To: <cfc71374-9a64-4ea4-90c7-6fc3e7adcbe4@default>
References: <cfc71374-9a64-4ea4-90c7-6fc3e7adcbe4@default>
Message-ID: <B02EC83D-88A1-41F5-8B49-A0CCB6EC2582@oracle.com>

Looks fine.

> 
> Hi All,
>  
> Please review the following:
>  
> Bug : https://bugs.openjdk.java.net/browse/JDK-8172804 <https://bugs.openjdk.java.net/browse/JDK-8172804>
>  
> Webrev Link: http://cr.openjdk.java.net/~akolarkunnu/8172804/webrev.00/ <http://cr.openjdk.java.net/~akolarkunnu/8172804/webrev.00/>
>  
> Summary: This is a fix for a bug in Jemmy code, that we found while automating the SwingSet Demo.
> Previously maximize() was implemented using Frame.setSize() which will set frame size as screen size, but its state is not changing, it will be Frame.NORMAL itself. 
> Now it is implementing using, Frame.setExtendedState() with Frame.MAXIMIZED_BOTH as parameter, so that its actual state also will set to Frame.MAXIMIZED_BOTH. 
> 
> Also demaximize() is not implemented completely. So demaximize() is implementing using Frame.setExtendedState() with Frame.NORMAL .
>  
> Regards,
> Muneer

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

From alexandre.iline at oracle.com  Tue Jan 17 19:06:40 2017
From: alexandre.iline at oracle.com (Alexandre (Shura) Iline)
Date: Tue, 17 Jan 2017 11:06:40 -0800
Subject: <Swing Dev> RFR JDK-8172804: SwingSet Automation: Jemmy Library
 : FrameOperator: maximize() and demaximize() are not properly implemented
In-Reply-To: <cfc71374-9a64-4ea4-90c7-6fc3e7adcbe4@default>
References: <cfc71374-9a64-4ea4-90c7-6fc3e7adcbe4@default>
Message-ID: <227BC8A5-D548-452A-A1A8-C120212F1E7C@oracle.com>

Looks good.
> On Jan 16, 2017, at 5:39 AM, Muneer Kolarkunnu <abdul.kolarkunnu at oracle.com> wrote:
> 
> Hi All,
>  
> Please review the following:
>  
> Bug : https://bugs.openjdk.java.net/browse/JDK-8172804 <https://bugs.openjdk.java.net/browse/JDK-8172804>
>  
> Webrev Link: http://cr.openjdk.java.net/~akolarkunnu/8172804/webrev.00/ <http://cr.openjdk.java.net/~akolarkunnu/8172804/webrev.00/>
>  
> Summary: This is a fix for a bug in Jemmy code, that we found while automating the SwingSet Demo.
> Previously maximize() was implemented using Frame.setSize() which will set frame size as screen size, but its state is not changing, it will be Frame.NORMAL itself. 
> Now it is implementing using, Frame.setExtendedState() with Frame.MAXIMIZED_BOTH as parameter, so that its actual state also will set to Frame.MAXIMIZED_BOTH. 
> 
> Also demaximize() is not implemented completely. So demaximize() is implementing using Frame.setExtendedState() with Frame.NORMAL .
>  
> Regards,
> Muneer

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

From avik.niyogi at oracle.com  Tue Jan 17 20:44:26 2017
From: avik.niyogi at oracle.com (Avik Niyogi)
Date: Wed, 18 Jan 2017 02:14:26 +0530
Subject: <Swing Dev> 8172509: [TEST_BUG] [macosx] Failure of the new test
	java/awt/Focus/FocusTraversalPolicy/ButtonGroupLayoutTraversal/ButtonGroupLayoutTraversalTest.java
In-Reply-To: <F5A57DFA-9EE4-43D7-B360-739C17A1AFB2@oracle.com>
References: <BF782AB0-2551-4FA7-BB41-CD63E4A30048@oracle.com>
	<7082ba94-5034-0f37-637a-e58e86562acb@oracle.com>
	<FF6AD8C6-A37E-4660-AC62-52D40CC684EB@oracle.com>
	<bcc124da-958e-1bb5-39d3-35493738fd82@oracle.com>
	<3206B166-1389-4D45-91FF-F05941659088@oracle.com>
	<F5A57DFA-9EE4-43D7-B360-739C17A1AFB2@oracle.com>
Message-ID: <624B0CB9-C8EA-4220-8E3A-C9F308E1B63D@oracle.com>


> On 17-Jan-2017, at 9:23 pm, Sergey Bylokhov <sergey.bylokhov at oracle.com> wrote:
> 
> Hi, Avik.
>> 
>> In Nimbus and Aqua LAF, for focus traversal, keybindings do not existing only arrow keys would work within ungrouped radio buttons but not within grouped radio button groups. Also, verified Aqua LAF with native application on MacBook. So to test this focus traversal, it works only in LAF which do not use Aqua. I was informed last time a similar bug was fixed about this behaviour regarding Nimbus LAF as well and was confirmed by me by testing it.
> 
> Can you please clarify what bug was fixed in nimbus which was confirmed by you.
HI Sergey,
It was not a bug fixed in Nimbus, it was a test case fixed to include Nimbus behaviour along with Aqua LAF as mentioned by you in the review for bug ID: 8167160
 Please find the copied content of the mail chain for that bug ID below:


+1


On 11/23/2016 7:52 PM, Sergey Bylokhov wrote:
> On 22.11.16 8:49, Avik Niyogi wrote:
>> Hi All,
>> Please review the code changes made as suggested by reviewers for JDK9
>> as available for perusal in the link below:
>> http://cr.openjdk.java.net/~aniyogi/8167160/webrev.02/
>> Change note: Instead of rethrow of a RuntimeException, used
>> printStackTrace()
> 
> +1
> 
>> 
>> With Regards,
>> Avik Niyogi
>> 
>>> On 22-Nov-2016, at 4:01 am, Sergey Bylokhov
>>> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>>> 
>>> Hi, Avik.
>>> Is it necessary to use logging in the test?
>>> I guess that this code
>>> Logger.getLogger(bug8033699.class.getName()).log(Level.SEVERE, null, ex);
>>> can be replaced by rethrow a RuntimeException exception?
>>> 
>>> On 17.11.16 13:45, Avik Niyogi wrote:
>>>> Hi All,
>>>> Please review the code changes made as suggested by reviewers for JDK9
>>>> as available for perusal in the link below
>>>> http://cr.openjdk.java.net/~aniyogi/8167160/webrev.01/
>>>> With Regards,
>>>> Avik Niyogi
>>>> 
>>>> 
>>>>> On 14-Nov-2016, at 9:03 pm, Avik Niyogi <avik.niyogi at oracle.com
>>>>> <mailto:avik.niyogi at oracle.com>
>>>>> <mailto:avik.niyogi at oracle.com>> wrote:
>>>>> 
>>>>> If I use UIManager.setLookAndFeel() to metalLookAndFeel then it works
>>>>> but for default settings on mac it is not working.
>>>>> 
>>>>>> On 14-Nov-2016, at 8:03 pm, Sergey Bylokhov
>>>>>> <Sergey.Bylokhov at oracle.com
>>>>>> <mailto:Sergey.Bylokhov at oracle.com> <mailto:Sergey.Bylokhov at oracle.com>>
>>>>>> wrote:
>>>>>> 
>>>>>> On 14.11.16 17:18, Avik Niyogi wrote:
>>>>>>> I checked with MetalLAF as well. does not seem to work. also, tried
>>>>>>> with a native Mac app. Does not have any option for radio button
>>>>>>> focus traversal.
>>>>>> 
>>>>>> Can you please clarify how you set the L&F for this test? I also
>>>>>> checked it and the test passed on the current jdk9-client in case of
>>>>>> "-Dswing.defaultlaf=javax.swing.plaf.metal.MetalLookAndFeel"
>>>>>> 
>>>>>>> 
>>>>>>>> On 14-Nov-2016, at 6:22 pm, Sergey Bylokhov
>>>>>>>> <Sergey.Bylokhov at oracle.com
>>>>>>>> <mailto:Sergey.Bylokhov at oracle.com> <mailto:Sergey.Bylokhov at oracle.com>>
>>>>>>>> wrote:
>>>>>>>> 
>>>>>>>> On 14.11.16 6:43, Avik Niyogi wrote:
>>>>>>>>> This is OS X Specific.
>>>>>>>> 
>>>>>>>> Are you sure? I guess the test will pass if will be run using
>>>>>>>> MetalLookAndFeel.
>>>>>>>> 
>>>>>>>>>> On 14-Nov-2016, at 2:18 am, Sergey Bylokhov
>>>>>>>>>> <Sergey.Bylokhov at oracle.com
>>>>>>>>>> <mailto:Sergey.Bylokhov at oracle.com> <mailto:Sergey.Bylokhov at oracle.com>>
>>>>>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>> On 10.11.16 9:53, Avik Niyogi wrote:
>>>>>>>>>>> Arrow buttons for traversing a radio button group is not the
>>>>>>>>>>> expected OS X behaviour.
>>>>>>>>>> 
>>>>>>>>>> This behavior is OSX specific or it is related to the Aqua L&F
>>>>>>>>>> which is default on OSX?
>>>>>>>>>> 
>>>>>>>>>>> In OS X in default OS X apps, for radio button focus traversing
>>>>>>>>>>> to work, custom actions must be set using System Preferences.
>>>>>>>>>>>> On 09-Nov-2016, at 6:51 pm, Sergey Bylokhov
>>>>>>>>>>>> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>
>>>>>>>>>>>> <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> On 09.11.16 11:06, Avik Niyogi wrote:
>>>>>>>>>>>>> *Bug: https://bugs.openjdk.java.net/browse/JDK-8167160*
>>>>>>>>>>>>> 
>>>>>>>>>>>>> *Webrev: http://cr.openjdk.java.net/~aniyogi/8167160/webrev.00/*
>>>>>>>>>>>>> 
>>>>>>>>>>>>> *Issue: *The test case :
>>>>>>>>>>>>> javax/swing/JRadioButton/8033699/bug8033699.java fails on OS X
>>>>>>>>>>>>> 
>>>>>>>>>>>>> *Cause: * The test case does not apply for OS X and should
>>>>>>>>>>>>> work for
>>>>>>>>>>>>> windows and Linux
>>>>>>>>>>>> 
>>>>>>>>>>>> What is the reason why the test does not work on OSX?
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> -- 
>>>>>>>>>>>> Best regards, Sergey.
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> -- 
>>>>>>>>>> Best regards, Sergey.
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> -- 
>>>>>>>> Best regards, Sergey.
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> -- 
>>>>>> Best regards, Sergey.
>>>>> 
>>>> 
>>> 
>>> 
>>> -- 
>>> Best regards, Sergey.


> 
>> 
>> With Regards,
>> Avik Niyogi
>>> On 11-Jan-2017, at 7:38 pm, Alexandr Scherbatiy <alexandr.scherbatiy at oracle.com <mailto:alexandr.scherbatiy at oracle.com>> wrote:
>>> 
>>> On 1/11/2017 2:01 PM, Avik Niyogi wrote:
>>>> Hi All,
>>>> I have addressed the inputs received in the following update. Please review the same for JDK 9.
>>>> http://cr.openjdk.java.net/~aniyogi/8172509/webrev.01/ <http://cr.openjdk.java.net/%7Eaniyogi/8172509/webrev.01/>
>>>> 
>>>> With Regards,
>>>> Avik Niyogi
>>>>> On 11-Jan-2017, at 4:22 pm, Prasanta Sadhukhan <prasanta.sadhukhan at oracle.com <mailto:prasanta.sadhukhan at oracle.com>> wrote:
>>>>> 
>>>>> I guess we need to throw the exception if changing LaF fails instead of silently consuming it!! 
>>>>> Regards
>>>>> Prasanta
>>>>> On 1/11/2017 2:16 PM, Avik Niyogi wrote:
>>>>>> Hi All,
>>>>>> 
>>>>>> Kindly review the proposed fix for JDK9.
>>>>>> 
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8172509 <https://bugs.openjdk.java.net/browse/JDK-8172509>
>>>>>> 
>>>>>> Webrev: http://cr.openjdk.java.net/~aniyogi/8172509/webrev.00/ <http://cr.openjdk.java.net/%7Eaniyogi/8172509/webrev.00/>
>>>>>> 
>>>>>> Issue: The focus traversal policy being tested was incorrect
>>>>>> 
>>>>>> Cause: For Aqua and Nimbus, the focus traversal policy used is different and as this is tested on default LAF, it fails on Mac OS X
>>>   Could you give more details what are the differences between using the focus traversal policy in Metal, Nimbus and Aqua L&F?
>>> 
>>>   Thanks,
>>>   Alexandr.
>>>>>> 
>>>>>> Fix: Cross-platform (Metal) LAF is used in case the default LAF is either Aqua or Nimbus and the focus traversal works in those cases.
>>>>>> 
>>>>>> With Regards,
>>>>>> Avik Niyogi
>>>>> 
>>>> 
>>> 
>> 
> 

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

From prasanta.sadhukhan at oracle.com  Wed Jan 18 05:58:25 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Wed, 18 Jan 2017 11:28:25 +0530
Subject: <Swing Dev> [9] RFR: JDK-8172012: [TEST_BUG] delays needed in
 javax/swing/JTree/4633594/bug4633594.java
In-Reply-To: <0DEEDA48-7DDB-4E80-8370-D81DCC9A4CFC@oracle.com>
References: <7932d11b-1e5d-5990-2629-5a8dd67af8c1@oracle.com>
	<d51618de-1deb-29a6-df45-d37a42e26710@oracle.com>
	<0DEEDA48-7DDB-4E80-8370-D81DCC9A4CFC@oracle.com>
Message-ID: <626efe17-e9b2-e6d4-cc6e-8bc8051651c1@oracle.com>

Sure, I will update the header to 2002, 2017 as it seems the test was 
created in 2002.

Regards
Prasanta
On 1/17/2017 9:21 PM, Sergey Bylokhov wrote:
> Looks fine, but please update the dates in the header. I assume that the test was created long time ago(not in 2017), in 2017 it was updated.
>
>> +1
>>
>> On 01/13/2017 01:48 PM, Prasanta Sadhukhan wrote:
>>> Hi All,
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8172012
>>>
>>> The issue of not having a delay between robot events is already
>>> addressed by adding autodelay and
>>> has been approved in closed crucible review.
>>> This webrev addresses moving the closed test to open in addition to
>>> modify test to migrate from applet based test to main-based.
>>> Additionally, rename the testname to something meaningful.
>>>
>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8172012/webrev.00/
>>>
>>> Regards
>>> Prasanta
>>>



From sergey.bylokhov at oracle.com  Wed Jan 18 17:39:05 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 18 Jan 2017 20:39:05 +0300
Subject: <Swing Dev> 8172509: [TEST_BUG] [macosx] Failure of the new test
 java/awt/Focus/FocusTraversalPolicy/ButtonGroupLayoutTraversal/ButtonGroupLayoutTraversalTest.java
In-Reply-To: <624B0CB9-C8EA-4220-8E3A-C9F308E1B63D@oracle.com>
References: <BF782AB0-2551-4FA7-BB41-CD63E4A30048@oracle.com>
	<7082ba94-5034-0f37-637a-e58e86562acb@oracle.com>
	<FF6AD8C6-A37E-4660-AC62-52D40CC684EB@oracle.com>
	<bcc124da-958e-1bb5-39d3-35493738fd82@oracle.com>
	<3206B166-1389-4D45-91FF-F05941659088@oracle.com>
	<F5A57DFA-9EE4-43D7-B360-739C17A1AFB2@oracle.com>
	<624B0CB9-C8EA-4220-8E3A-C9F308E1B63D@oracle.com>
Message-ID: <2534C016-76D2-40AB-BDD7-0078F88ECA5E@oracle.com>


> 17 ???. 2017 ?., ? 23:44, Avik Niyogi <avik.niyogi at oracle.com> ???????(?):
> 
> 
>> On 17-Jan-2017, at 9:23 pm, Sergey Bylokhov <sergey.bylokhov at oracle.com <mailto:sergey.bylokhov at oracle.com>> wrote:
>> 
>> Hi, Avik.
>>> 
>>> In Nimbus and Aqua LAF, for focus traversal, keybindings do not existing only arrow keys would work within ungrouped radio buttons but not within grouped radio button groups. Also, verified Aqua LAF with native application on MacBook. So to test this focus traversal, it works only in LAF which do not use Aqua. I was informed last time a similar bug was fixed about this behaviour regarding Nimbus LAF as well and was confirmed by me by testing it.
>> 
>> Can you please clarify what bug was fixed in nimbus which was confirmed by you.
> HI Sergey,
> It was not a bug fixed in Nimbus, it was a test case fixed to include Nimbus behaviour along with Aqua LAF as mentioned by you in the review for bug ID: 8167160
>  Please find the copied content of the mail chain for that bug ID below:

Thanks. looks fine.

> 
> 
> +1
> 
> 
> On 11/23/2016 7:52 PM, Sergey Bylokhov wrote:
>> On 22.11.16 8:49, Avik Niyogi wrote:
>>> Hi All,
>>> Please review the code changes made as suggested by reviewers for JDK9
>>> as available for perusal in the link below:
>>> http://cr.openjdk.java.net/~aniyogi/8167160/webrev.02/ <http://cr.openjdk.java.net/~aniyogi/8167160/webrev.02/>
>>> Change note: Instead of rethrow of a RuntimeException, used
>>> printStackTrace()
>> 
>> +1
>> 
>>> 
>>> With Regards,
>>> Avik Niyogi
>>> 
>>>> On 22-Nov-2016, at 4:01 am, Sergey Bylokhov
>>>> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com> <mailto:Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>>> wrote:
>>>> 
>>>> Hi, Avik.
>>>> Is it necessary to use logging in the test?
>>>> I guess that this code
>>>> Logger.getLogger(bug8033699.class.getName()).log(Level.SEVERE, null, ex);
>>>> can be replaced by rethrow a RuntimeException exception?
>>>> 
>>>> On 17.11.16 13:45, Avik Niyogi wrote:
>>>>> Hi All,
>>>>> Please review the code changes made as suggested by reviewers for JDK9
>>>>> as available for perusal in the link below
>>>>> http://cr.openjdk.java.net/~aniyogi/8167160/webrev.01/ <http://cr.openjdk.java.net/~aniyogi/8167160/webrev.01/>
>>>>> With Regards,
>>>>> Avik Niyogi
>>>>> 
>>>>> 
>>>>>> On 14-Nov-2016, at 9:03 pm, Avik Niyogi <avik.niyogi at oracle.com <mailto:avik.niyogi at oracle.com>
>>>>>> <mailto:avik.niyogi at oracle.com <mailto:avik.niyogi at oracle.com>>
>>>>>> <mailto:avik.niyogi at oracle.com <mailto:avik.niyogi at oracle.com>>> wrote:
>>>>>> 
>>>>>> If I use UIManager.setLookAndFeel() to metalLookAndFeel then it works
>>>>>> but for default settings on mac it is not working.
>>>>>> 
>>>>>>> On 14-Nov-2016, at 8:03 pm, Sergey Bylokhov
>>>>>>> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>
>>>>>>> <mailto:Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>> <mailto:Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>>>
>>>>>>> wrote:
>>>>>>> 
>>>>>>> On 14.11.16 17:18, Avik Niyogi wrote:
>>>>>>>> I checked with MetalLAF as well. does not seem to work. also, tried
>>>>>>>> with a native Mac app. Does not have any option for radio button
>>>>>>>> focus traversal.
>>>>>>> 
>>>>>>> Can you please clarify how you set the L&F for this test? I also
>>>>>>> checked it and the test passed on the current jdk9-client in case of
>>>>>>> "-Dswing.defaultlaf=javax.swing.plaf.metal.MetalLookAndFeel"
>>>>>>> 
>>>>>>>> 
>>>>>>>>> On 14-Nov-2016, at 6:22 pm, Sergey Bylokhov
>>>>>>>>> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>
>>>>>>>>> <mailto:Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>> <mailto:Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>>>
>>>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>> On 14.11.16 6:43, Avik Niyogi wrote:
>>>>>>>>>> This is OS X Specific.
>>>>>>>>> 
>>>>>>>>> Are you sure? I guess the test will pass if will be run using
>>>>>>>>> MetalLookAndFeel.
>>>>>>>>> 
>>>>>>>>>>> On 14-Nov-2016, at 2:18 am, Sergey Bylokhov
>>>>>>>>>>> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>
>>>>>>>>>>> <mailto:Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>> <mailto:Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>>>
>>>>>>>>>>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>> On 10.11.16 9:53, Avik Niyogi wrote:
>>>>>>>>>>>> Arrow buttons for traversing a radio button group is not the
>>>>>>>>>>>> expected OS X behaviour.
>>>>>>>>>>> 
>>>>>>>>>>> This behavior is OSX specific or it is related to the Aqua L&F
>>>>>>>>>>> which is default on OSX?
>>>>>>>>>>> 
>>>>>>>>>>>> In OS X in default OS X apps, for radio button focus traversing
>>>>>>>>>>>> to work, custom actions must be set using System Preferences.
>>>>>>>>>>>>> On 09-Nov-2016, at 6:51 pm, Sergey Bylokhov
>>>>>>>>>>>>> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com> <mailto:Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>>
>>>>>>>>>>>>> <mailto:Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>>> wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> On 09.11.16 11:06, Avik Niyogi wrote:
>>>>>>>>>>>>>> *Bug: https://bugs.openjdk.java.net/browse/JDK-8167160* <https://bugs.openjdk.java.net/browse/JDK-8167160*>
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> *Webrev: http://cr.openjdk.java.net/~aniyogi/8167160/webrev.00/* <http://cr.openjdk.java.net/~aniyogi/8167160/webrev.00/*>
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> *Issue: *The test case :
>>>>>>>>>>>>>> javax/swing/JRadioButton/8033699/bug8033699.java fails on OS X
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> *Cause: * The test case does not apply for OS X and should
>>>>>>>>>>>>>> work for
>>>>>>>>>>>>>> windows and Linux
>>>>>>>>>>>>> 
>>>>>>>>>>>>> What is the reason why the test does not work on OSX?
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> -- 
>>>>>>>>>>>>> Best regards, Sergey.
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> -- 
>>>>>>>>>>> Best regards, Sergey.
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> -- 
>>>>>>>>> Best regards, Sergey.
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> -- 
>>>>>>> Best regards, Sergey.
>>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> -- 
>>>> Best regards, Sergey.
> 
> 
>> 
>>> 
>>> With Regards,
>>> Avik Niyogi
>>>> On 11-Jan-2017, at 7:38 pm, Alexandr Scherbatiy <alexandr.scherbatiy at oracle.com <mailto:alexandr.scherbatiy at oracle.com>> wrote:
>>>> 
>>>> On 1/11/2017 2:01 PM, Avik Niyogi wrote:
>>>>> Hi All,
>>>>> I have addressed the inputs received in the following update. Please review the same for JDK 9.
>>>>> http://cr.openjdk.java.net/~aniyogi/8172509/webrev.01/ <http://cr.openjdk.java.net/%7Eaniyogi/8172509/webrev.01/>
>>>>> 
>>>>> With Regards,
>>>>> Avik Niyogi
>>>>>> On 11-Jan-2017, at 4:22 pm, Prasanta Sadhukhan <prasanta.sadhukhan at oracle.com <mailto:prasanta.sadhukhan at oracle.com>> wrote:
>>>>>> 
>>>>>> I guess we need to throw the exception if changing LaF fails instead of silently consuming it!! 
>>>>>> Regards
>>>>>> Prasanta
>>>>>> On 1/11/2017 2:16 PM, Avik Niyogi wrote:
>>>>>>> Hi All,
>>>>>>> 
>>>>>>> Kindly review the proposed fix for JDK9.
>>>>>>> 
>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8172509 <https://bugs.openjdk.java.net/browse/JDK-8172509>
>>>>>>> 
>>>>>>> Webrev: http://cr.openjdk.java.net/~aniyogi/8172509/webrev.00/ <http://cr.openjdk.java.net/%7Eaniyogi/8172509/webrev.00/>
>>>>>>> 
>>>>>>> Issue: The focus traversal policy being tested was incorrect
>>>>>>> 
>>>>>>> Cause: For Aqua and Nimbus, the focus traversal policy used is different and as this is tested on default LAF, it fails on Mac OS X
>>>>   Could you give more details what are the differences between using the focus traversal policy in Metal, Nimbus and Aqua L&F?
>>>> 
>>>>   Thanks,
>>>>   Alexandr.
>>>>>>> 
>>>>>>> Fix: Cross-platform (Metal) LAF is used in case the default LAF is either Aqua or Nimbus and the focus traversal works in those cases.
>>>>>>> 
>>>>>>> With Regards,
>>>>>>> Avik Niyogi
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 

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

From mraz.martin.dev at gmail.com  Wed Jan 18 11:10:12 2017
From: mraz.martin.dev at gmail.com (Martin M)
Date: Wed, 18 Jan 2017 12:10:12 +0100
Subject: <Swing Dev> swing combobox win7(vista) L&F
Message-ID: <CAN4C5=x8gCsvVS+K-CEGHc3=m27eKD5NN42j7PBacT-US3w==Q@mail.gmail.com>

Hi guys,

I do not want to spam, but I have one little contribution and I do not know
who is the right person for this.
I have corrected win7 (or vista) swing combobox to look like native win7
combobox, but I do not know how to make my changes be part of java SE. Or
is this still an issue? Because I found bug report e.g. nr. JDK-6490753
<https://bugs.openjdk.java.net/browse/JDK-6490753> discussing about this,
but it is 10 years old.

br,
Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20170118/27bd41c2/attachment.html>

From alexandr.scherbatiy at oracle.com  Wed Jan 18 15:15:16 2017
From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy)
Date: Wed, 18 Jan 2017 18:15:16 +0300
Subject: <Swing Dev> <AWT Dev> [9] Review Request: 8143077 Deprecate
 InputEvent._MASK in favor of InputEvent._DOWN_MASK
In-Reply-To: <0CC8F46C-C873-4617-B4E4-F2E9BA3F4360@oracle.com>
References: <f0aa606b-0303-0f38-ff8b-f6e3e357d73f@oracle.com>
	<f4c6a886-da81-1963-9877-f64aa83f0108@oracle.com>
	<f7d4d89b-527c-6e09-e551-36426092559a@oracle.com>
	<2f37ee44-82c5-b544-f0d9-15b104eee727@oracle.com>
	<f64fd14a-c99f-6dae-0d99-b730c6afcf48@oracle.com>
	<3b24bb44-246f-a5e9-fc06-eaf3aff69aed@oracle.com>
	<b766f536-dbcd-3788-918e-5e99427f162b@oracle.com>
	<0e185822-ff1b-2041-baca-d5491ce2e4b8@oracle.com>
	<aaa011cc-6fe5-e7fe-ae03-b7cc1c017c39@oracle.com>
	<5888a670-6fc3-764c-c3cf-6703744b0d27@oracle.com>
	<5bda0f8a-5dfb-7356-5942-015fc27d6b07@oracle.com>
	<255c4e87-b58c-1d4d-30ca-97d1d9a710d0@oracle.com>
	<750f4ba6-5dea-7fb0-c7c1-c207d5cd2912@oracle.com>
	<f5659e98-9034-0b52-816b-b382c404069e@oracle.com>
	<241007aa-5fdb-d6a6-f1f8-2eb83433ea69@oracle.com>
	<027efb5a-666e-debe-cd03-bccb25e7a4e5@oracle.com>
	<bc006214-ac0a-ca0e-7041-f586cf7cb910@oracle.com>
	<622010F8-1BD8-42D9-926A-D7F12C893949@oracle.com>
	<0CC8F46C-C873-4617-B4E4-F2E9BA3F4360@oracle.com>
Message-ID: <b47316a9-996b-d5d5-b5ad-807855b14494@oracle.com>


The fix looks good to me.

Thanks,
Alexandr.

On 12/19/2016 10:29 PM, Sergey Bylokhov wrote:
>
>> 19 ???. 2016 ?., ? 22:28, Sergey Bylokhov <Sergey.Bylokhov at oracle.com 
>> <mailto:Sergey.Bylokhov at oracle.com>> ???????(?):
>>
>> Hello.
>> Please review an updated version of the fix.
>>  - The comments are updated.
>> Two additional public api are deprecated:
>>  - KeyEvent.getKeyModifiersText()
>>  - AWTEvent(Event event)
>>
>> Note that I have to add @SuppressWarnings("deprecation?) in places 
>> where the old API is used, because the option which ignores this 
>> warning was removed from the makefile. We will need to fix all of 
>> them one by one in jdk10, I?ll file a CR for this.
>
> Ouch the link is:
> http://cr.openjdk.java.net/~serb/8143077/webrev.04/ 
> <http://cr.openjdk.java.net/%7Eserb/8143077/webrev.04/>
>
>>
>>> On 10/26/2016 6:43 PM, Sergey Bylokhov wrote:
>>>> On 25.10.16 18:46, Semyon Sadetsky wrote:
>>>>>> I wonder why he should decide that the old code can be "simply
>>>>>> replaced" by the new one? I suppose that at least he should read the
>>>>>> specification of the new extended API. There is no notion that this
>>>>>> api is replaced by the new one, there is a recommendation that 
>>>>>> the new
>>>>>> one should be used instead.
>>>>> After reading such recommendation it's hard to conclude that one 
>>>>> "should
>>>>> read the specification of the new extended API". Even "@see" tag
>>>>> pointing to the extended API is not provided (I'm not even mentioning
>>>>> the warning that the extended API may be nonequivalent replacement is
>>>>> absent). I read this recommendation as it is: replace one constant 
>>>>> with
>>>>> another, no side effects expected.
>>>>
>>>> Good to know that you don't read the specification of the methods 
>>>> before using. So what is your proposal? Should I add a notion that 
>>>> these extendent constants contains different int values, and if the 
>>>> user depends from them in some way then he should not replace the 
>>>> old one to the new one? Or what @see reference should be added from 
>>>> some fields to another?
>>> The proposal is the same to notify user that he/she should not only 
>>> replace the constant but start to use another API. It's up to you 
>>> how to formulate this. If I did this in minimalistic way I would write:
>>>
>>> @deprecated It is recommended that SHIFT_DOWN_MASK and {@link 
>>> getModifiersEx()} be used instead.
>>>>
>>>>>>
>>>>>>>> We already have a notions that these "extended modifier constant"
>>>>>>>> should be used in the constructor of InputEvent and moreover in 
>>>>>>>> spec
>>>>>>>> of getModifiersEx() we have an additional examples how to use this
>>>>>>>> constants. This is why we will have a reference from old 
>>>>>>>> constans to
>>>>>>>> the new, and from getModifiers() to the getModifiersEx();
>>
>

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

From alexandr.scherbatiy at oracle.com  Wed Jan 18 15:38:02 2017
From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy)
Date: Wed, 18 Jan 2017 18:38:02 +0300
Subject: <Swing Dev> swing combobox win7(vista) L&F
In-Reply-To: <CAN4C5=x8gCsvVS+K-CEGHc3=m27eKD5NN42j7PBacT-US3w==Q@mail.gmail.com>
References: <CAN4C5=x8gCsvVS+K-CEGHc3=m27eKD5NN42j7PBacT-US3w==Q@mail.gmail.com>
Message-ID: <1c4dd01d-9266-6c6f-e755-98edb8aee882@oracle.com>

On 1/18/2017 2:10 PM, Martin M wrote:
> Hi guys,
>
> I do not want to spam, but I have one little contribution and I do not 
> know who is the right person for this.
> I have corrected win7 (or vista) swing combobox to look like native 
> win7 combobox, but I do not know how to make my changes be part of 
> java SE. Or is this still an issue? Because I found bug report e.g. 
> nr. JDK-6490753 
> <https://bugs.openjdk.java.net/browse/JDK-6490753> discussing about 
> this, but it is 10 years old.
   You could use the webrev [1] to generate the directory with changes, 
zip it and send it to the review.
   Make sure that that you use the latest JDK 9 client repository [2]
   The email's subject  format should be:
     [9] Review request for bug-id bug-summary

   It is also required to sign the OCA [3] agreement.

   [1] http://openjdk.java.net/guide/webrevHelp.html
   [2] http://hg.openjdk.java.net/jdk9/client
   [3] http://www.oracle.com/technetwork/community/oca-486395.html

   Thanks,
   Alexandr.
>
> br,
> Martin

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

From alexandr.scherbatiy at oracle.com  Thu Jan 19 10:32:29 2017
From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy)
Date: Thu, 19 Jan 2017 13:32:29 +0300
Subject: <Swing Dev> 8172509: [TEST_BUG] [macosx] Failure of the new test
 java/awt/Focus/FocusTraversalPolicy/ButtonGroupLayoutTraversal/ButtonGroupLayoutTraversalTest.java
In-Reply-To: <2534C016-76D2-40AB-BDD7-0078F88ECA5E@oracle.com>
References: <BF782AB0-2551-4FA7-BB41-CD63E4A30048@oracle.com>
	<7082ba94-5034-0f37-637a-e58e86562acb@oracle.com>
	<FF6AD8C6-A37E-4660-AC62-52D40CC684EB@oracle.com>
	<bcc124da-958e-1bb5-39d3-35493738fd82@oracle.com>
	<3206B166-1389-4D45-91FF-F05941659088@oracle.com>
	<F5A57DFA-9EE4-43D7-B360-739C17A1AFB2@oracle.com>
	<624B0CB9-C8EA-4220-8E3A-C9F308E1B63D@oracle.com>
	<2534C016-76D2-40AB-BDD7-0078F88ECA5E@oracle.com>
Message-ID: <f2c04319-2b67-f655-782c-c48d602d4e82@oracle.com>

The fix looks good to me.

Thanks,
Alexandr.

On 1/18/2017 8:39 PM, Sergey Bylokhov wrote:
>
>> 17 ???. 2017 ?., ? 23:44, Avik Niyogi <avik.niyogi at oracle.com 
>> <mailto:avik.niyogi at oracle.com>> ???????(?):
>>
>>
>>> On 17-Jan-2017, at 9:23 pm, Sergey Bylokhov 
>>> <sergey.bylokhov at oracle.com <mailto:sergey.bylokhov at oracle.com>> wrote:
>>>
>>> Hi, Avik.
>>>>
>>>> In Nimbus and Aqua LAF, for focus traversal, keybindings do not 
>>>> existing only arrow keys would work within ungrouped radio buttons 
>>>> but not within grouped radio button groups. Also, verified Aqua LAF 
>>>> with native application on MacBook. So to test this focus 
>>>> traversal, it works only in LAF which do not use Aqua. I was 
>>>> informed last time a similar bug was fixed about this behaviour 
>>>> regarding Nimbus LAF as well and was confirmed by me by testing it.
>>>
>>> Can you please clarify what bug was fixed in nimbus which was 
>>> confirmed by you.
>> HI Sergey,
>> It was not a bug fixed in Nimbus, it was a test case fixed to include 
>> Nimbus behaviour along with Aqua LAF as mentioned by you in the 
>> review for bug ID: 8167160
>>  Please find the copied content of the mail chain for that bug ID below:
>
> Thanks. looks fine.
>
>>
>>
>> *+1
>>
>>
>> On 11/23/2016 7:52 PM, Sergey Bylokhov wrote:
>> *
>>> *On 22.11.16 8:49, Avik Niyogi wrote:
>>> *
>>>> *Hi All,
>>>> Please review the code changes made as suggested by reviewers for JDK9
>>>> as available for perusal in the link below:
>>>> http://cr.openjdk.java.net/~aniyogi/8167160/webrev.02/ 
>>>> <http://cr.openjdk.java.net/%7Eaniyogi/8167160/webrev.02/>
>>>> Change note: Instead of rethrow of a RuntimeException, used
>>>> printStackTrace()
>>>> *
>>> *
>>> +1
>>>
>>> *
>>>> *
>>>> With Regards,
>>>> Avik Niyogi
>>>>
>>>> *
>>>>> *On 22-Nov-2016, at 4:01 am, Sergey Bylokhov
>>>>> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com> 
>>>>> <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>>>>>
>>>>> Hi, Avik.
>>>>> Is it necessary to use logging in the test?
>>>>> I guess that this code
>>>>> Logger.getLogger(bug8033699.class.getName()).log(Level.SEVERE, 
>>>>> null, ex);
>>>>> can be replaced by rethrow a RuntimeException exception?
>>>>>
>>>>> On 17.11.16 13:45, Avik Niyogi wrote:
>>>>> *
>>>>>> *Hi All,
>>>>>> Please review the code changes made as suggested by reviewers for 
>>>>>> JDK9
>>>>>> as available for perusal in the link below
>>>>>> http://cr.openjdk.java.net/~aniyogi/8167160/webrev.01/ 
>>>>>> <http://cr.openjdk.java.net/%7Eaniyogi/8167160/webrev.01/>
>>>>>> With Regards,
>>>>>> Avik Niyogi
>>>>>>
>>>>>>
>>>>>> *
>>>>>>> *On 14-Nov-2016, at 9:03 pm, Avik Niyogi <avik.niyogi at oracle.com 
>>>>>>> <mailto:avik.niyogi at oracle.com>
>>>>>>> <mailto:avik.niyogi at oracle.com>
>>>>>>> <mailto:avik.niyogi at oracle.com>> wrote:
>>>>>>>
>>>>>>> If I use UIManager.setLookAndFeel() to metalLookAndFeel then it 
>>>>>>> works
>>>>>>> but for default settings on mac it is not working.
>>>>>>>
>>>>>>> *
>>>>>>>> *On 14-Nov-2016, at 8:03 pm, Sergey Bylokhov
>>>>>>>> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>
>>>>>>>> <mailto:Sergey.Bylokhov at oracle.com> 
>>>>>>>> <mailto:Sergey.Bylokhov at oracle.com>>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> On 14.11.16 17:18, Avik Niyogi wrote:
>>>>>>>> *
>>>>>>>>> *I checked with MetalLAF as well. does not seem to work. also, 
>>>>>>>>> tried
>>>>>>>>> with a native Mac app. Does not have any option for radio button
>>>>>>>>> focus traversal.
>>>>>>>>> *
>>>>>>>> *
>>>>>>>> Can you please clarify how you set the L&F for this test? I also
>>>>>>>> checked it and the test passed on the current jdk9-client in 
>>>>>>>> case of
>>>>>>>> "-Dswing.defaultlaf=javax.swing.plaf.metal.MetalLookAndFeel"
>>>>>>>>
>>>>>>>> *
>>>>>>>>> *
>>>>>>>>> *
>>>>>>>>>> *On 14-Nov-2016, at 6:22 pm, Sergey Bylokhov
>>>>>>>>>> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>
>>>>>>>>>> <mailto:Sergey.Bylokhov at oracle.com> 
>>>>>>>>>> <mailto:Sergey.Bylokhov at oracle.com>>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> On 14.11.16 6:43, Avik Niyogi wrote:
>>>>>>>>>> *
>>>>>>>>>>> *This is OS X Specific.
>>>>>>>>>>> *
>>>>>>>>>> *
>>>>>>>>>> Are you sure? I guess the test will pass if will be run using
>>>>>>>>>> MetalLookAndFeel.
>>>>>>>>>>
>>>>>>>>>> *
>>>>>>>>>>>> *On 14-Nov-2016, at 2:18 am, Sergey Bylokhov
>>>>>>>>>>>> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>
>>>>>>>>>>>> <mailto:Sergey.Bylokhov at oracle.com> 
>>>>>>>>>>>> <mailto:Sergey.Bylokhov at oracle.com>>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> On 10.11.16 9:53, Avik Niyogi wrote:
>>>>>>>>>>>> *
>>>>>>>>>>>>> *Arrow buttons for traversing a radio button group is not the
>>>>>>>>>>>>> expected OS X behaviour.
>>>>>>>>>>>>> *
>>>>>>>>>>>> *
>>>>>>>>>>>> This behavior is OSX specific or it is related to the Aqua L&F
>>>>>>>>>>>> which is default on OSX?
>>>>>>>>>>>>
>>>>>>>>>>>> *
>>>>>>>>>>>>> *In OS X in default OS X apps, for radio button focus 
>>>>>>>>>>>>> traversing
>>>>>>>>>>>>> to work, custom actions must be set using System Preferences.
>>>>>>>>>>>>> *
>>>>>>>>>>>>>> *On 09-Nov-2016, at 6:51 pm, Sergey Bylokhov
>>>>>>>>>>>>>> <Sergey.Bylokhov at oracle.com 
>>>>>>>>>>>>>> <mailto:Sergey.Bylokhov at oracle.com> 
>>>>>>>>>>>>>> <mailto:Sergey.Bylokhov at oracle.com>
>>>>>>>>>>>>>> <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 09.11.16 11:06, Avik Niyogi wrote:
>>>>>>>>>>>>>> *
>>>>>>>>>>>>>>> **Bug: https://bugs.openjdk.java.net/browse/JDK-8167160*
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *Webrev: 
>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~aniyogi/8167160/webrev.00/* 
>>>>>>>>>>>>>>> <http://cr.openjdk.java.net/%7Eaniyogi/8167160/webrev.00/*>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *Issue: *The test case :
>>>>>>>>>>>>>>> javax/swing/JRadioButton/8033699/bug8033699.java fails 
>>>>>>>>>>>>>>> on OS X
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *Cause: * The test case does not apply for OS X and should
>>>>>>>>>>>>>>> work for
>>>>>>>>>>>>>>> windows and Linux
>>>>>>>>>>>>>>> *
>>>>>>>>>>>>>> *
>>>>>>>>>>>>>> What is the reason why the test does not work on OSX?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -- 
>>>>>>>>>>>>>> Best regards, Sergey.
>>>>>>>>>>>>>> *
>>>>>>>>>>>>> *
>>>>>>>>>>>>> *
>>>>>>>>>>>> *
>>>>>>>>>>>>
>>>>>>>>>>>> -- 
>>>>>>>>>>>> Best regards, Sergey.
>>>>>>>>>>>> *
>>>>>>>>>>> *
>>>>>>>>>>> *
>>>>>>>>>> *
>>>>>>>>>>
>>>>>>>>>> -- 
>>>>>>>>>> Best regards, Sergey.
>>>>>>>>>> *
>>>>>>>>> *
>>>>>>>>> *
>>>>>>>> *
>>>>>>>>
>>>>>>>> -- 
>>>>>>>> Best regards, Sergey.
>>>>>>>> *
>>>>>>> *
>>>>>>> *
>>>>>> *
>>>>>> *
>>>>> *
>>>>>
>>>>> -- 
>>>>> Best regards, Sergey.*
>>
>>
>>>
>>>>
>>>> With Regards,
>>>> Avik Niyogi
>>>>> On 11-Jan-2017, at 7:38 pm, Alexandr Scherbatiy 
>>>>> <alexandr.scherbatiy at oracle.com 
>>>>> <mailto:alexandr.scherbatiy at oracle.com>> wrote:
>>>>>
>>>>> On 1/11/2017 2:01 PM, Avik Niyogi wrote:
>>>>>> Hi All,
>>>>>> I have addressed the inputs received in the following update. 
>>>>>> Please review the same for JDK 9.
>>>>>> http://cr.openjdk.java.net/~aniyogi/8172509/webrev.01/ 
>>>>>> <http://cr.openjdk.java.net/%7Eaniyogi/8172509/webrev.01/>
>>>>>>
>>>>>> With Regards,
>>>>>> Avik Niyogi
>>>>>>> On 11-Jan-2017, at 4:22 pm, Prasanta Sadhukhan 
>>>>>>> <prasanta.sadhukhan at oracle.com 
>>>>>>> <mailto:prasanta.sadhukhan at oracle.com>> wrote:
>>>>>>>
>>>>>>> I guess we need to throw the exception if changing LaF fails 
>>>>>>> instead of silently consuming it!!
>>>>>>>
>>>>>>> Regards
>>>>>>> Prasanta
>>>>>>> On 1/11/2017 2:16 PM, Avik Niyogi wrote:
>>>>>>>> Hi All,
>>>>>>>>
>>>>>>>> Kindly review the proposed fix for JDK9.
>>>>>>>>
>>>>>>>> *Bug: https://bugs.openjdk.java.net/browse/JDK-8172509*
>>>>>>>> *
>>>>>>>> *
>>>>>>>> *Webrev: http://cr.openjdk.java.net/~aniyogi/8172509/webrev.00/ 
>>>>>>>> <http://cr.openjdk.java.net/%7Eaniyogi/8172509/webrev.00/>*
>>>>>>>> *
>>>>>>>> *
>>>>>>>> *Issue: *The focus traversal policy being tested was incorrect
>>>>>>>>
>>>>>>>> *Cause:* For Aqua and Nimbus, the focus traversal policy used 
>>>>>>>> is different and as this is tested on default LAF, it fails on 
>>>>>>>> Mac OS X
>>>>>   Could you give more details what are the differences between 
>>>>> using the focus traversal policy in Metal, Nimbus and Aqua L&F?
>>>>>
>>>>>   Thanks,
>>>>>   Alexandr.
>>>>>>>>
>>>>>>>> *Fix: *Cross-platform (Metal) LAF is used in case the default 
>>>>>>>> LAF is either Aqua or Nimbus and the focus traversal works in 
>>>>>>>> those cases.
>>>>>>>>
>>>>>>>> With Regards,
>>>>>>>> Avik Niyogi
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

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

From prasanta.sadhukhan at oracle.com  Tue Jan 24 14:16:11 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Tue, 24 Jan 2017 19:46:11 +0530
Subject: <Swing Dev> [9] RFR JDK-7190595: Nimbus: Test6657026 fails
Message-ID: <d37a6387-b485-8fe7-2539-4f220e564dcf@oracle.com>

Hi All,

Please review a fix for an issue where it is seen 
javax/swing/plaf/basic/BasicSplitPaneUI/Test6657026.java fails reporting 
"Shared traversal keys" for Nimbus LaF.

Bug: https://bugs.openjdk.java.net/browse/JDK-7190595
webrev: http://cr.openjdk.java.net/~psadhukhan/7190595/webrev.00/

Issue was "managingFocusForwardTraversalKeys" and 
"managingFocusBackwardTraversalKeys" is a static field in
http://hg.openjdk.java.net/jdk9/client/jdk/file/8270102790e5/src/java.desktop/share/classes/javax/swing/plaf/synth/SynthSplitPaneUI.java#l51
so when JSplitPane is instantiated several times as in this particular 
testcase,
managingFocusForwardTraversalKeys and managingFocusBackwardTraversalKeys 
is NOT null from 2nd time so no keyStroke is added to this Set

so Set is not null but empty.

Now, since keyStrokes is cleared in the testcase between  2 JSplitPane 
instantiation, next time getFocusTraversalKeys(0) is called, it returns 
an empty Set so the test fails.

Proposed fix is to remove the "static" keyword from this 2 Sets so that 
they gets instantiated each time JSplitPane is invoked.
This problem is not present for other LaF like Metal because for those 
LaF, BasicSplitPaneUI is used instead of SynthSplitPaneUI (used only for 
Nimbus) where these fields are not static
[http://hg.openjdk.java.net/jdk9/client/jdk/file/8270102790e5/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicSplitPaneUI.java#l109]
which are removed as per JDK-6657026 [Numerous static security flaws in 
Swing(findbugs)]

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

From prasanta.sadhukhan at oracle.com  Tue Jan 24 14:21:24 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Tue, 24 Jan 2017 19:51:24 +0530
Subject: <Swing Dev> [9] RFR JDK-7190595: Nimbus: Test6657026 fails
In-Reply-To: <d37a6387-b485-8fe7-2539-4f220e564dcf@oracle.com>
References: <d37a6387-b485-8fe7-2539-4f220e564dcf@oracle.com>
Message-ID: <391d750e-314f-2fe5-714e-4ee4b92d44da@oracle.com>



On 1/24/2017 7:46 PM, Prasanta Sadhukhan wrote:
>
> Hi All,
>
> Please review a fix for an issue where it is seen 
> javax/swing/plaf/basic/BasicSplitPaneUI/Test6657026.java fails 
> reporting "Shared traversal keys" for Nimbus LaF.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-7190595
> webrev: http://cr.openjdk.java.net/~psadhukhan/7190595/webrev.00/
>
> Issue was "managingFocusForwardTraversalKeys" and 
> "managingFocusBackwardTraversalKeys" is a static field in
> http://hg.openjdk.java.net/jdk9/client/jdk/file/8270102790e5/src/java.desktop/share/classes/javax/swing/plaf/synth/SynthSplitPaneUI.java#l51
> so when JSplitPane is instantiated several times as in this particular 
> testcase,
> managingFocusForwardTraversalKeys and 
> managingFocusBackwardTraversalKeys is NOT null from 2nd time so no 
> keyStroke is added to this Set
>
http://hg.openjdk.java.net/jdk9/client/jdk/file/8270102790e5/src/java.desktop/share/classes/javax/swing/plaf/synth/SynthSplitPaneUI.java#l102
> so Set is not null but empty.
>
> Now, since keyStrokes is cleared in the testcase between  2 JSplitPane 
> instantiation, next time getFocusTraversalKeys(0) is called, it 
> returns an empty Set so the test fails.
>
> Proposed fix is to remove the "static" keyword from this 2 Sets so 
> that they gets instantiated each time JSplitPane is invoked.
Other LaF (Metal, Motif, Windows etc ) passed with this fix.
> This problem is not present for other LaF like Metal because for those 
> LaF, BasicSplitPaneUI is used instead of SynthSplitPaneUI (used only 
> for Nimbus) where these fields are not static
> [http://hg.openjdk.java.net/jdk9/client/jdk/file/8270102790e5/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicSplitPaneUI.java#l109]
> which are removed as per JDK-6657026 [Numerous static security flaws 
> in Swing(findbugs)]
>
> Regards
> Prasanta

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

From yuri.nesterenko at oracle.com  Thu Jan 26 15:16:47 2017
From: yuri.nesterenko at oracle.com (Yuri Nesterenko)
Date: Thu, 26 Jan 2017 18:16:47 +0300
Subject: <Swing Dev> [9] RFR JDK-7190595: Nimbus: Test6657026 fails
In-Reply-To: <d37a6387-b485-8fe7-2539-4f220e564dcf@oracle.com>
References: <d37a6387-b485-8fe7-2539-4f220e564dcf@oracle.com>
Message-ID: <55f10576-7519-2d55-dd98-d89367cedcef@oracle.com>

Tested it: it works well (pass consistently with patched build
failing consistently with b151).

So, +1

-yan

On 01/24/2017 05:16 PM, Prasanta Sadhukhan wrote:
> Hi All,
>
> Please review a fix for an issue where it is seen
> javax/swing/plaf/basic/BasicSplitPaneUI/Test6657026.java fails reporting
> "Shared traversal keys" for Nimbus LaF.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-7190595
> webrev: http://cr.openjdk.java.net/~psadhukhan/7190595/webrev.00/
>
> Issue was "managingFocusForwardTraversalKeys" and
> "managingFocusBackwardTraversalKeys" is a static field in
> http://hg.openjdk.java.net/jdk9/client/jdk/file/8270102790e5/src/java.desktop/share/classes/javax/swing/plaf/synth/SynthSplitPaneUI.java#l51
> so when JSplitPane is instantiated several times as in this particular
> testcase,
> managingFocusForwardTraversalKeys and managingFocusBackwardTraversalKeys
> is NOT null from 2nd time so no keyStroke is added to this Set
>
> so Set is not null but empty.
>
> Now, since keyStrokes is cleared in the testcase between  2 JSplitPane
> instantiation, next time getFocusTraversalKeys(0) is called, it returns
> an empty Set so the test fails.
>
> Proposed fix is to remove the "static" keyword from this 2 Sets so that
> they gets instantiated each time JSplitPane is invoked.
> This problem is not present for other LaF like Metal because for those
> LaF, BasicSplitPaneUI is used instead of SynthSplitPaneUI (used only for
> Nimbus) where these fields are not static
> [http://hg.openjdk.java.net/jdk9/client/jdk/file/8270102790e5/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicSplitPaneUI.java#l109]
> which are removed as per JDK-6657026 [Numerous static security flaws in
> Swing(findbugs)]
>
> Regards
> Prasanta



From jayathirth.d.v at oracle.com  Fri Jan 27 10:04:20 2017
From: jayathirth.d.v at oracle.com (Jayathirth D V)
Date: Fri, 27 Jan 2017 02:04:20 -0800 (PST)
Subject: <Swing Dev> [9] RFR JDK-7190595: Nimbus: Test6657026 fails
In-Reply-To: <55f10576-7519-2d55-dd98-d89367cedcef@oracle.com>
References: <d37a6387-b485-8fe7-2539-4f220e564dcf@oracle.com>
	<55f10576-7519-2d55-dd98-d89367cedcef@oracle.com>
Message-ID: <6020ae0f-9023-4f10-bfb3-48084657279c@default>

Hi Prasanta,

Looks good to me.
Just change the copyright year of SynthSplitPaneUI.java from 2015 to 2017 before pushing.

Thanks,
Jay

-----Original Message-----
From: Yuri Nesterenko 
Sent: Thursday, January 26, 2017 8:47 PM
To: Prasanta Sadhukhan; Alexandr Scherbatiy; swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [9] RFR JDK-7190595: Nimbus: Test6657026 fails

Tested it: it works well (pass consistently with patched build failing consistently with b151).

So, +1

-yan

On 01/24/2017 05:16 PM, Prasanta Sadhukhan wrote:
> Hi All,
>
> Please review a fix for an issue where it is seen 
> javax/swing/plaf/basic/BasicSplitPaneUI/Test6657026.java fails 
> reporting "Shared traversal keys" for Nimbus LaF.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-7190595
> webrev: http://cr.openjdk.java.net/~psadhukhan/7190595/webrev.00/
>
> Issue was "managingFocusForwardTraversalKeys" and 
> "managingFocusBackwardTraversalKeys" is a static field in
> http://hg.openjdk.java.net/jdk9/client/jdk/file/8270102790e5/src/java.
> desktop/share/classes/javax/swing/plaf/synth/SynthSplitPaneUI.java#l51
> so when JSplitPane is instantiated several times as in this particular 
> testcase, managingFocusForwardTraversalKeys and 
> managingFocusBackwardTraversalKeys
> is NOT null from 2nd time so no keyStroke is added to this Set
>
> so Set is not null but empty.
>
> Now, since keyStrokes is cleared in the testcase between  2 JSplitPane 
> instantiation, next time getFocusTraversalKeys(0) is called, it 
> returns an empty Set so the test fails.
>
> Proposed fix is to remove the "static" keyword from this 2 Sets so 
> that they gets instantiated each time JSplitPane is invoked.
> This problem is not present for other LaF like Metal because for those 
> LaF, BasicSplitPaneUI is used instead of SynthSplitPaneUI (used only 
> for
> Nimbus) where these fields are not static 
> [http://hg.openjdk.java.net/jdk9/client/jdk/file/8270102790e5/src/java
> .desktop/share/classes/javax/swing/plaf/basic/BasicSplitPaneUI.java#l1
> 09] which are removed as per JDK-6657026 [Numerous static security 
> flaws in Swing(findbugs)]
>
> Regards
> Prasanta



From philip.race at oracle.com  Fri Jan 27 18:30:49 2017
From: philip.race at oracle.com (Phil Race)
Date: Fri, 27 Jan 2017 10:30:49 -0800
Subject: <Swing Dev> RFR: 8173409: make setMixingCutoutShape public and
	remove jdk.desktop
Message-ID: <1d677151-a6ac-dc17-a295-29c7bdd54a1c@oracle.com>

Bug: https://bugs.openjdk.java.net/browse/JDK-8173409
Webrev: http://cr.openjdk.java.net/~prr/8173409/

In OpenJDK the jdk.desktop module (not java.desktop) has only one method.
It is the vestige of com.sun.awt.AWTUtilities added in JDK 6 updates.

It provides a way to access to Component.setMixingCutoutShape

the jdk.desktop module was created so that apps could still access it 
without
using --add-exports - although at the expense of a code update.

We'd prefer to eliminate this non-standard API and module before JDK 9
goes final and can do so by making the above method public and standard

As a result jdk.desktop becomes empty and can go away ..

Swing's own internal uses have been updated and should be fully compatible
since the implementation is unchanged.

The existing tests which verify the API are updated to use the public API.
They should pass as well as they ever did ..

I did leave the AWTAccessor code in there for apps that absolutely have 
no way
to recompile to the new API and need to use --add-exports for now.

A CCC will be submitted for this change.

-phil.


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

From mandy.chung at oracle.com  Fri Jan 27 19:54:10 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 27 Jan 2017 11:54:10 -0800
Subject: <Swing Dev> <AWT Dev> RFR: 8173409: make setMixingCutoutShape
	public and remove jdk.desktop
In-Reply-To: <1d677151-a6ac-dc17-a295-29c7bdd54a1c@oracle.com>
References: <1d677151-a6ac-dc17-a295-29c7bdd54a1c@oracle.com>
Message-ID: <B0DC9B0F-0BA9-47AB-82BA-C04D03F59986@oracle.com>


> On Jan 27, 2017, at 10:30 AM, Phil Race <philip.race at oracle.com> wrote:
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8173409 <https://bugs.openjdk.java.net/browse/JDK-8173409>
> Webrev: http://cr.openjdk.java.net/~prr/8173409/ <http://cr.openjdk.java.net/~prr/8173409/>
> 

The part that removes of jdk.desktop looks good.  

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

From guy.abossolo.foh at scientificware.com  Sun Jan 29 08:09:05 2017
From: guy.abossolo.foh at scientificware.com (Abossolo Foh Guy)
Date: Sun, 29 Jan 2017 09:09:05 +0100
Subject: <Swing Dev> Fwd: Re: [PATCH] JDK-7169915 : Swing Table Layout bad
 repaint of the row [REGRESSION] JDK-8133864 : Wrong display,
 when the document I18n properties is true.
Message-ID: <762c3acae093e8002990126d51524b28@scientificware.com>

-------- Message original --------
Objet: Re: <Swing Dev> [PATCH] JDK-7169915 : Swing Table Layout bad 
repaint of the row [REGRESSION] JDK-8133864 : Wrong display, when the 
document I18n properties is true.
Date: 2016-11-05 6:59
De: Abossolo Foh Guy <guy.abossolo.foh at scientificware.com>
?: Semyon Sadetsky

Hello,

I modified your 
test(test/javax/swing/text/TableView/I18nLayoutTest.java) to simulate 
user entries and removals as discribed in my bug reports JDK-7169915 and 
  JDK-7072926.

Rather than test the frame, I used four caret positions : one before, 
one after the table, one in the first and one in the last line of the 
table.
I also test i18n enable and i18n disable.

I think this test could replace the previous test I18nLayoutTest.java.

The test fails before and passes after my fix :

With JDK 8 current release (111) :
When i18n enable, test can't be completed : TableView layout wrong, 
lines overlap, see JDK-8133864.
When i18n disable, TableView layout wrong : Table width change when 
inserts and removes caracters, see JDK-8158209 and JDK-7169915. Before 
Table dx=0.0 After Table dx=28.0

With JDK9 build 142 :
When i18n enable, TableView layout wrong : Table width change when 
inserts and removes caracters, see JDK-8158209 and JDK-7169915. Before 
Table dx=0.0 After Table dx=28.0
When i18n disable, TableView layout wrong : Table width change when 
inserts and removes caracters, see JDK-8158209 and JDK-7169915. Before 
Table dx=0.0 After Table dx=28.0

With JDK9 + fix :
ok

I used the latest JDK forest to build the fix and produce webrev.

This bug occurs only for user keyboard entries, if I use 
JEditorPane.replaceSelection(...) the table layout is correct.

Best regards.
Guy.

---------------------------------------------------------------------------------------------------

Le 2016-09-12 15:39, Semyon Sadetsky a ?crit?:
> Hello,
> 
> The JDK-8133864 seems has no a regression. I found that your test
> works well after it (with corrections I described in JIRA for the
> table frame).
> 
> If TableView layout is still an incorrect for you, please, attach a
> test that fails before and passes after your fix. Test is required for
> any JDK fixes and I didn't find in your webrev.
> 
> --Semyon
> 
> 
> On 9/11/2016 11:34 AM, Abossolo Foh Guy wrote:
>> Hi,
>> 
>> Thank you very much for your great work.
>> But I'm agree and not agree with your conclusion about JDK-8158209 : 
>> "Not an Issue".
>> 
>> I'm agree :
>> I understand your recommendations about the height and the width for 
>> the frame of the trView.
>> I never talked about this problem because frame painting hasn't being 
>> a problem for me.
>> 
>> I'm not agree :
>> I made a mistake in writing the bug JDK-8158209 report : two problems 
>> in the same report.
>> But JDK-7169915 and  JDK-7072926 are really a different problem you 
>> solve in JDK-8158209.
>> In 2012, codebug.java was designed first for these bugs.
>> It is just an update problem, if you follow the steps discribe in 
>> JDK-7169915 and JDK-7072926 and if you read the text\html\tableView 
>> code you can understand my fix.
>> text\html\tableView works (not public) fine and \text\tableView 
>> (public) works bad ? ? ? ?
>> As Victor, don't worry about this fix, I'd just compare the two codes 
>> to built my fix.
>> 
>> In attachment the documents asked by Alexandr about my fix.
>> 
>> Yours faithfully.
>> 
>> ---------------------------------------
>> Hello,
>> 
>>> Could you apply the fix to JDK 9 client repository ...
>> I applied the fix to JDK 9 client repository 
>> http://hg.openjdk.java.net/jdk9/client :
>> 
>> openjdk version "9-internal"
>> OpenJDK Runtime Environment (build 
>> 9-internal+0-2016-05-28-142420.scientificware2016.9devClient)
>> OpenJDK 64-Bit Server VM (build 
>> 9-internal+0-2016-05-28-142420.scientificware2016.9devClient, mixed 
>> mode)
>> 
>>  The webrev and JTreport/JTWork are in attachment. All works fine, 
>> except what is mentioned below.
>> 
>> 
>>> You mentioned that there are artifacts with a table displaying in JDK 
>>> 9.
>> I can't say when it appeared because before your fix, the table size 
>> didn't changed when we insert text and all the text stay on the same 
>> line.
>> But, I have just notice that if, in the I18nLayoutTest.java, you
>> - change the line setUndecorated(true) to setUndecorated(false),
>> - run the program and enlarge the window 2 times larger than the text 
>> size,
>> - all the text come back on the same line.
>> There no such artifacts when i18n is false.
>> 
>> Thanks for your help.
>> 
>> Guy.
>> 
>> --------------------------------------------------------------------------------------------- 
>> Le 2016-05-27 16:53, Alexandr Scherbatiy a ?crit :
>>> The fix should be prepared for the JDK 9 first and only after that be
>>> backported to JDK 8u.
>>> 
>>>  Could you apply the fix to JDK 9 client repository
>>> http://hg.openjdk.java.net/jdk9/client
>>>  and send the webrev of the fix  plus the test (see
>>> http://openjdk.java.net/guide/webrevHelp.html).
>>>  The fix shouldn't contain comments with the old code lines. I 
>>> believe
>>> that references to the bug number are also unnecessary for this case.
>>> 
>>>  You mentioned that there are artifacts with a table displaying in 
>>> JDK
>>> 9. Do they appear only after fix of they also present even without 
>>> the
>>> fix?
>>> 
>>> Thanks,
>>> Alexandr.
>>> 
>>> On 5/27/2016 9:23 AM, Abossolo Foh Guy wrote:
>>>> Hello,
>>>> 
>>>> Please, please ... could someone examine the patch for JDK-8133864 
>>>> that I suggested ? I really need it to implement matrix display in 
>>>> my application. I've spent long time in 2012 to find what was wrong 
>>>> in tableview. I know Victor's comment was not good but you could 
>>>> compare with the tableview implementation in the swing/text/html 
>>>> package which works fine.
>>>> 
>>>> Beware, the display (with java 9 119) for I18nLayoutTest.java is not 
>>>> the same with i18n true (bad) or i18n false (good). With i18n true 
>>>> the table go down.
>>>> 
>>>> Best regards.
>>>> 
>>>> ---------------------------------------------------------------------------------------------------------------------- 
>>>> Hello,
>>>> 
>>>> I built the recent OpenJDK8u and OpenJDK9 sources 
>>>> (openjdk_versions.txt) with the patch shown in the output_diff.txt 
>>>> attachment.
>>>> 
>>>> I applied your patch for JDK-8133864 : Wrong display, when the 
>>>> document I18n properties is true.
>>>> And I applied my patch for JDK-7169915 : Swing Table Layout bad 
>>>> repaint of the row.
>>>> 
>>>> All works fine in OpenJDK8u and the document is well displayed. The 
>>>> table appears as I expected with all its lines and columns 
>>>> (JDK-8133864 solved), size and borders included even if we write 
>>>> some text inside (JDK-7169915 solved). I can modify it as I want.
>>>> 
>>>> But with OpenJDK9, the display of the document is wrong. The table 
>>>> appears as I expected with all its lines and columns (JDK-8133864 
>>>> solved), size and borders included (JDK-7169915 solved) but the 
>>>> entire document display is modified, the table is displayed on a new 
>>>> line. And the document became unuseable, I can't modify it as I 
>>>> want.
>>>> 
>>>> This morning, I ran the same test programme (CodeBug.java in 
>>>> attachment) with the Oracle JDK9 b114 (i.e. OpenJDK9 only with your 
>>>> patch  for JDK-8133864) : The table appears as I expected with all 
>>>> its lines and columns (JDK-8133864 solved) but the size and borders 
>>>> are bad repainted when we write some text inside (JDK-7169915 
>>>> solved). And the document became unuseable too, I can't modify it as 
>>>> I want.
>>>> 
>>>> My conclusion :
>>>> 1- JDK-8133864 is solved with your PATCH.
>>>> 2- JDK-7169915 could be solved with my PATCH.
>>>> 3- There is regression between JDK8 and JDK9 may be in the Views 
>>>> arrangement.
>>>> 
>>>> Best regards.
>>>> 
>>>> ---------------------------------------------------------------------------------------------------------------------- 
>>>> Hello,
>>>> 
>>>> Could you apply the modification I suggested 4 years ago about the 
>>>> Bug : JDK-7169915 : Swing Table Layout bad repaint of the row.
>>>> 
>>>> The test case I had sent in 2012 is the same I used in : JDK-8133864 
>>>> Wrong display, when the document I18n properties is true.
>>>> 
>>>> A version of this test (called I18nLayoutTest.java) is now candidate 
>>>> as part of tests for JDK 9 (/test/javax/swing/text/TableView/)
>>>> 
>>>> Yours faithfully.
>>>> 
>>>> 
>> 

-- 
Abossolo Foh Guy
71 rue Guy de Maupassant
69500 Bron

06 87 01 82 27
04 72 81 89 46
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tableview_webrev.zip
Type: application/zip
Size: 115086 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20170129/91666472/tableview_webrev.zip>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TableViewLayoutTest.java.zip
Type: application/zip
Size: 4170 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20170129/91666472/TableViewLayoutTest.java.zip>

From sergey.bylokhov at oracle.com  Tue Jan 31 08:28:23 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 31 Jan 2017 11:28:23 +0300
Subject: <Swing Dev> RFR: 8173409: make setMixingCutoutShape public and
 remove jdk.desktop
In-Reply-To: <1d677151-a6ac-dc17-a295-29c7bdd54a1c@oracle.com>
References: <1d677151-a6ac-dc17-a295-29c7bdd54a1c@oracle.com>
Message-ID: <B76D3F6B-B5A2-42E6-9A4E-3BD9D951F3F0@oracle.com>

Looks fine.

> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8173409 <https://bugs.openjdk.java.net/browse/JDK-8173409>
> Webrev: http://cr.openjdk.java.net/~prr/8173409/ <http://cr.openjdk.java.net/~prr/8173409/>
> 
> In OpenJDK the jdk.desktop module (not java.desktop) has only one method.
> It is the vestige of com.sun.awt.AWTUtilities added in JDK 6 updates.
> 
> It provides a way to access to Component.setMixingCutoutShape
> 
> the jdk.desktop module was created so that apps could still access it without
> using --add-exports - although at the expense of a code update.
> 
> We'd prefer to eliminate this non-standard API and module before JDK 9
> goes final and can do so by making the above method public and standard
> 
> As a result jdk.desktop becomes empty and can go away ..
> 
> Swing's own internal uses have been updated and should be fully compatible
> since the implementation is unchanged.
> 
> The existing tests which verify the API are updated to use the public API.
> They should pass as well as they ever did ..
> 
> I did leave the AWTAccessor code in there for apps that absolutely have no way
> to recompile to the new API and need to use --add-exports for now.
> 
> A CCC will be submitted for this change.
> 
> -phil.
> 
> 

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