From pankaj.b.bansal at oracle.com  Tue Jan  2 10:07:18 2018
From: pankaj.b.bansal at oracle.com (Pankaj Bansal)
Date: Tue, 2 Jan 2018 02:07:18 -0800 (PST)
Subject: <Swing Dev> [11] Review Request: JDK-5076761 :
 JList.setSelectedValue(null, ...) doesn't do anything
Message-ID: <417f68fe-4565-40b1-b360-e6ff9e18dd33@default>

Hi All,

 

Please review the fix for JDK 11.

 

Bug:

https://bugs.openjdk.java.net/browse/JDK-5076761

 

Webrev:

http://cr.openjdk.java.net/~pbansal/5076761/webrev.00/

 

Issue:

When setSelectedValue is called on JList with null object, it should clear all selection. But it is not doing anything.

 

Fix:

In setSelectedValue if the object is null, the setSelectedIndex is called with -1. but this does not clear the selection. We should be calling clearSelection instead of SetSelectedIndex.

 

Regards,

Pankaj Bansal

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

From krishna.addepalli at oracle.com  Tue Jan  2 11:01:19 2018
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Tue, 2 Jan 2018 03:01:19 -0800 (PST)
Subject: <Swing Dev> [10][11][JDK-8194044] Regression manual Test
 javax/swing/JFileChooser/8067660/FileChooserTest.java fails
Message-ID: <91a8f44e-a18c-43f5-96b8-ab310399c348@default>

Hi All,

 

Please review a fix for bug:

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

Webrev: http://cr.openjdk.java.net/~kaddepalli/8194044/webrev00/

 

This was caused due to the fix for JDK-8175015, in which the line 446  in Win32ShellFolderManager2.java was changed from "getDrives()" to Win32ShellFolder2.listRoots().

While the earlier function returns an object of Win32ShellFolder2, the latter returns an array of Files. 

The condition on line 450: "return (sf.isFileSystem()&&sf.parent != null && sf.parent.equals(Win32ShellFolder2.listRoots())" was returning false because of the wrong object being passed. Earlier it was a Win32ShellFolder2 object, and the comparision was done properly, but with the changes, the equals fucnction was receiving a file array object, and hence it was immediately returning false, leading to the problem of empty strings being shown for Root drives.

The fix is to replace "Win32ShellFolder2.listRoots()" with "getDrives()" function. With this fix, the regression is addressed, as well as the original JDK-8175015 which was a memory leak issue.

 

Thanks,

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

From semyon.sadetsky at oracle.com  Tue Jan  2 18:00:53 2018
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Tue, 2 Jan 2018 10:00:53 -0800
Subject: <Swing Dev> Swing dev>[10] Review request for JDK-8189253:
 [macos] JPopupMenu is inadvertently shown when using setComponentPopupMenu
In-Reply-To: <C77A97FC-2163-455F-847D-C590D3B5D522@oracle.com>
References: <E1445698-445B-4542-98C1-1D82A4A182C9@oracle.com>
 <4ed5cbcf-c1f7-f615-6404-ebe13c47b8da@oracle.com>
 <C77A97FC-2163-455F-847D-C590D3B5D522@oracle.com>
Message-ID: <bcd060d3-4553-55f5-4fee-b22d6313426e@oracle.com>

Hi Manajit,

JDK-8080729 bug was Mac OS specific issue and its fix changed the Mac OS 
code only. Nevertheless you are suggesting to fix the regression in 
generic code. This need to be explained somehow.

--Semyon

On 12/25/2017 02:42 AM, Manajit Halder wrote:
> Hi Semyon,
>
> Regression is cause by JDK-8080729 
> <https://bugs.openjdk.java.net/browse/JDK-8080729>. The fix can?t be 
> reversed since it is the?choice between addChildWindow or orderWindow. 
> Went through code flow related to the issue but?didn?t find any other 
> better place in code to handle this issue. The best way to fix the 
> issue would be to avoid retargeting of events (MOUSE_ENTER and 
> MOUSE_EXIT) between MOUSE_PRESS and MOUSE_RELEASE on the parent window 
> (when the mouse is actually on the child window). Therefore request 
> you to review the webrev.00.
>
> Regards,
> Manajit
>
>> On 08-Dec-2017, at 9:55 PM, semyon.sadetsky at oracle.com 
>> <mailto:semyon.sadetsky at oracle.com> wrote:
>>
>> Hi Manajit,
>>
>> Can you provide information which fix caused the regression?
>>
>> --Semyon
>>
>>
>> On 12/8/17 5:53 AM, Manajit Halder wrote:
>>> Hi All,
>>>
>>> Kindly review the following Swing fix.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8189253
>>> Webrev: http://cr.openjdk.java.net/~mhalder/8189253/webrev.00/ 
>>> <http://cr.openjdk.java.net/%7Emhalder/8189253/webrev.00/>
>>>
>>> Cause:
>>> Issue was due to retargeting of mouse enter exit events.
>>> MOUSE_ENTER and MOUSE_EXIT events were sent on the parent window 
>>> (JFrame) in between MOUSE_PRESS and MOUSE_RELEASE events on the 
>>> modeless JDialog.
>>>
>>> Fix:
>>> Retargeting of events is not done in-between MOUSE_PRESS and 
>>> MOUSE_RELEASE.
>>>
>>> Regards,
>>> Manajit
>>>
>>
>

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

From Sergey.Bylokhov at oracle.com  Tue Jan  2 21:46:42 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 2 Jan 2018 13:46:42 -0800
Subject: <Swing Dev> [10] Review Request: 8193673 Regression manual Test
 javax/swing/JFileChooser/6515169/bug6515169.java fails
Message-ID: <43f47411-b9e6-0aff-3bbd-c6e1a0690336@oracle.com>

Hello.
Please review the fix for jdk10. The fix will be pushed to:
http://hg.openjdk.java.net/jdk/jdk10

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

The fix for JDK-8189656[1] missed an update of Gensrc-java.desktop.gmk 
which compiles the property files for windows L&F.

[1] https://bugs.openjdk.java.net/browse/JDK-8189656

-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Tue Jan  2 22:01:00 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 2 Jan 2018 14:01:00 -0800
Subject: <Swing Dev> [11] Review Request: JDK-5076761 :
 JList.setSelectedValue(null, ...) doesn't do anything
In-Reply-To: <417f68fe-4565-40b1-b360-e6ff9e18dd33@default>
References: <417f68fe-4565-40b1-b360-e6ff9e18dd33@default>
Message-ID: <da38a552-d357-b86d-399e-ba1b90fca79f@oracle.com>

Hi, Pankaj.
The fix looks fine, but I suggest to update the spec as well and 
describe the behavior if "null" value is passed.

On 02/01/2018 02:07, Pankaj Bansal wrote:
> Hi All,
> 
> Please review the fix for JDK 11.
> 
> Bug:
> 
> https://bugs.openjdk.java.net/browse/JDK-5076761
> 
> Webrev:
> 
> http://cr.openjdk.java.net/~pbansal/5076761/webrev.00/
> 
> Issue:
> 
> When setSelectedValue is called on JList with null object, it should 
> clear all selection. But it is not doing anything.
> 
> Fix:
> 
> In setSelectedValue if the object is null, the setSelectedIndex is 
> called with -1. but this does not clear the selection. We should be 
> calling clearSelection instead of SetSelectedIndex.
> 
> Regards,
> 
> Pankaj Bansal
> 


-- 
Best regards, Sergey.


From prasanta.sadhukhan at oracle.com  Wed Jan  3 05:21:16 2018
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Wed, 3 Jan 2018 10:51:16 +0530
Subject: <Swing Dev> [10] Review Request: 8193673 Regression manual Test
 javax/swing/JFileChooser/6515169/bug6515169.java fails
In-Reply-To: <43f47411-b9e6-0aff-3bbd-c6e1a0690336@oracle.com>
References: <43f47411-b9e6-0aff-3bbd-c6e1a0690336@oracle.com>
Message-ID: <8f3a8355-1d8d-d353-cf03-eefa12d40c32@oracle.com>

Fix looks fine. For test, is it required to explicitly set the l&f, I 
guess we should check for installed l&f for a particular platform and 
not unnecessarily check for Aqua & Gtk in windows?

Regards
Prasanta
On 1/3/2018 3:16 AM, Sergey Bylokhov wrote:
> Hello.
> Please review the fix for jdk10. The fix will be pushed to:
> http://hg.openjdk.java.net/jdk/jdk10
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8193673
> Webrev can be found at: 
> http://cr.openjdk.java.net/~serb/8193673/webrev.00
>
> The fix for JDK-8189656[1] missed an update of Gensrc-java.desktop.gmk 
> which compiles the property files for windows L&F.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8189656
>



From prasanta.sadhukhan at oracle.com  Wed Jan  3 05:56:56 2018
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Wed, 3 Jan 2018 11:26:56 +0530
Subject: <Swing Dev> [10][11][JDK-8194044] Regression manual Test
 javax/swing/JFileChooser/8067660/FileChooserTest.java fails
In-Reply-To: <91a8f44e-a18c-43f5-96b8-ab310399c348@default>
References: <91a8f44e-a18c-43f5-96b8-ab310399c348@default>
Message-ID: <fb48167a-d960-f5c9-ad2e-92199ee47a39@oracle.com>

Fix looks fine. But I guess, it is possible to add a automated 
regression test to it utilising isFileSystemRoot().

Regards
Prasanta
On 1/2/2018 4:31 PM, Krishna Addepalli wrote:
>
> Hi All,
>
> Please review a fix for bug:
>
> Bug: JDK-8194044 : https://bugs.openjdk.java.net/browse/JDK-8194044
>
> Webrev: http://cr.openjdk.java.net/~kaddepalli/8194044/webrev00/ 
> <http://cr.openjdk.java.net/%7Ekaddepalli/8194044/webrev00/>
>
> This was caused due to the fix for JDK-8175015, in which the line 446 
> ?in Win32ShellFolderManager2.java was changed from ?getDrives()? to 
> Win32ShellFolder2.listRoots().
>
> While the earlier function returns an object of Win32ShellFolder2, the 
> latter returns an array of Files.
>
> The condition on line 450: ?return (sf.isFileSystem()&&sf.parent != 
> null && sf.parent.equals(Win32ShellFolder2.listRoots())? was returning 
> false because of the wrong object being passed. Earlier it was a 
> Win32ShellFolder2 object, and the comparision was done properly, but 
> with the changes, the equals fucnction was receiving a file array 
> object, and hence it was immediately returning false, leading to the 
> problem of empty strings being shown for Root drives.
>
> The fix is to replace ?Win32ShellFolder2.listRoots()? with 
> ?getDrives()? function. With this fix, the regression is addressed, as 
> well as the original JDK-8175015 which was a memory leak issue.
>
> Thanks,
>
> Krishna
>

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

From Sergey.Bylokhov at oracle.com  Wed Jan  3 06:38:33 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 2 Jan 2018 22:38:33 -0800
Subject: <Swing Dev> [10] Review Request: 8193673 Regression manual Test
 javax/swing/JFileChooser/6515169/bug6515169.java fails
In-Reply-To: <8f3a8355-1d8d-d353-cf03-eefa12d40c32@oracle.com>
References: <43f47411-b9e6-0aff-3bbd-c6e1a0690336@oracle.com>
 <8f3a8355-1d8d-d353-cf03-eefa12d40c32@oracle.com>
Message-ID: <e8ba6845-7f67-85cb-fd69-3cfeb98475a4@oracle.com>

This test may be executed in the headless mode when the GTK l&f is 
installed but not supported. So it will be necessary to check that L&F 
is installed and supported, or to blindly set it and move to the next in 
case of exceptions. So I implements a second case since it is simpler.

On 02/01/2018 21:21, Prasanta Sadhukhan wrote:
> Fix looks fine. For test, is it required to explicitly set the l&f, I 
> guess we should check for installed l&f for a particular platform and 
> not unnecessarily check for Aqua & Gtk in windows?
> 
> Regards
> Prasanta
> On 1/3/2018 3:16 AM, Sergey Bylokhov wrote:
>> Hello.
>> Please review the fix for jdk10. The fix will be pushed to:
>> http://hg.openjdk.java.net/jdk/jdk10
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8193673
>> Webrev can be found at: 
>> http://cr.openjdk.java.net/~serb/8193673/webrev.00
>>
>> The fix for JDK-8189656[1] missed an update of Gensrc-java.desktop.gmk 
>> which compiles the property files for windows L&F.
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8189656
>>
> 


-- 
Best regards, Sergey.


From pankaj.b.bansal at oracle.com  Wed Jan  3 07:26:51 2018
From: pankaj.b.bansal at oracle.com (Pankaj Bansal)
Date: Tue, 2 Jan 2018 23:26:51 -0800 (PST)
Subject: <Swing Dev> [11] Review Request: JDK-5076761 :
 JList.setSelectedValue(null, ...) doesn't do anything
In-Reply-To: <da38a552-d357-b86d-399e-ba1b90fca79f@oracle.com>
References: <417f68fe-4565-40b1-b360-e6ff9e18dd33@default>
 <da38a552-d357-b86d-399e-ba1b90fca79f@oracle.com>
Message-ID: <d1d36b2a-1ca9-44ea-8e50-a819a20b7980@default>

Hi Sergey,

Thanks for the review.

I have made the suggested changes. Please have a look.
webrev: http://cr.openjdk.java.net/~pbansal/5076761/webrev.01/

Regards,
Pankaj Bansal


-----Original Message-----
From: Sergey Bylokhov 
Sent: Wednesday, January 3, 2018 3:31 AM
To: Pankaj Bansal; swing-dev at openjdk.java.net; Prasanta Sadhukhan
Subject: Re: [11] Review Request: JDK-5076761 : JList.setSelectedValue(null, ...) doesn't do anything

Hi, Pankaj.
The fix looks fine, but I suggest to update the spec as well and describe the behavior if "null" value is passed.

On 02/01/2018 02:07, Pankaj Bansal wrote:
> Hi All,
> 
> Please review the fix for JDK 11.
> 
> Bug:
> 
> https://bugs.openjdk.java.net/browse/JDK-5076761
> 
> Webrev:
> 
> http://cr.openjdk.java.net/~pbansal/5076761/webrev.00/
> 
> Issue:
> 
> When setSelectedValue is called on JList with null object, it should 
> clear all selection. But it is not doing anything.
> 
> Fix:
> 
> In setSelectedValue if the object is null, the setSelectedIndex is 
> called with -1. but this does not clear the selection. We should be 
> calling clearSelection instead of SetSelectedIndex.
> 
> Regards,
> 
> Pankaj Bansal
> 


--
Best regards, Sergey.


From erik.joelsson at oracle.com  Wed Jan  3 08:15:57 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 3 Jan 2018 09:15:57 +0100
Subject: <Swing Dev> [10] Review Request: 8193673 Regression manual Test
 javax/swing/JFileChooser/6515169/bug6515169.java fails
In-Reply-To: <43f47411-b9e6-0aff-3bbd-c6e1a0690336@oracle.com>
References: <43f47411-b9e6-0aff-3bbd-c6e1a0690336@oracle.com>
Message-ID: <1e6c1b17-02f2-8f13-6675-f8393815273b@oracle.com>

Looks good.

/Erik


On 2018-01-02 22:46, Sergey Bylokhov wrote:
> Hello.
> Please review the fix for jdk10. The fix will be pushed to:
> http://hg.openjdk.java.net/jdk/jdk10
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8193673
> Webrev can be found at: 
> http://cr.openjdk.java.net/~serb/8193673/webrev.00
>
> The fix for JDK-8189656[1] missed an update of Gensrc-java.desktop.gmk 
> which compiles the property files for windows L&F.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8189656
>



From krishna.addepalli at oracle.com  Wed Jan  3 11:43:26 2018
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Wed, 3 Jan 2018 03:43:26 -0800 (PST)
Subject: <Swing Dev> [10][11][JDK-8194044] Regression manual Test
 javax/swing/JFileChooser/8067660/FileChooserTest.java fails
In-Reply-To: <fb48167a-d960-f5c9-ad2e-92199ee47a39@oracle.com>
References: <91a8f44e-a18c-43f5-96b8-ab310399c348@default>
 <fb48167a-d960-f5c9-ad2e-92199ee47a39@oracle.com>
Message-ID: <db9ba389-e151-4307-9fd1-e30adcf93234@default>

Thanks for the review Prasanta. However, I don't see a point to write a test case for isFileSystemRoot(), since, it is not going to fail on any (older/newer) java versions, and it was only introduced because of the fix for JDK-8175015.

Let me know if you think otherwise.

 

Regards,

Krishna

From: Prasanta Sadhukhan 
Sent: Wednesday, January 3, 2018 11:27 AM
To: Krishna Addepalli <krishna.addepalli at oracle.com>; swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10][11][JDK-8194044] Regression manual Test javax/swing/JFileChooser/8067660/FileChooserTest.java fails

 

Fix looks fine. But I guess, it is possible to add a automated regression test to it utilising isFileSystemRoot().

Regards
Prasanta

On 1/2/2018 4:31 PM, Krishna Addepalli wrote:

Hi All,

 

Please review a fix for bug:

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

Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Ekaddepalli/8194044/webrev00/"http://cr.openjdk.java.net/~kaddepalli/8194044/webrev00/

 

This was caused due to the fix for JDK-8175015, in which the line 446  in Win32ShellFolderManager2.java was changed from "getDrives()" to Win32ShellFolder2.listRoots().

While the earlier function returns an object of Win32ShellFolder2, the latter returns an array of Files. 

The condition on line 450: "return (sf.isFileSystem()&&sf.parent != null && sf.parent.equals(Win32ShellFolder2.listRoots())" was returning false because of the wrong object being passed. Earlier it was a Win32ShellFolder2 object, and the comparision was done properly, but with the changes, the equals fucnction was receiving a file array object, and hence it was immediately returning false, leading to the problem of empty strings being shown for Root drives.

The fix is to replace "Win32ShellFolder2.listRoots()" with "getDrives()" function. With this fix, the regression is addressed, as well as the original JDK-8175015 which was a memory leak issue.

 

Thanks,

Krishna

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

From pankaj.b.bansal at oracle.com  Wed Jan  3 11:53:01 2018
From: pankaj.b.bansal at oracle.com (Pankaj Bansal)
Date: Wed, 3 Jan 2018 03:53:01 -0800 (PST)
Subject: <Swing Dev> [10] Review Request: JDK-7108280 :
 JList.getSelectedValuesList fails if JList.setSelectionInterval larger than
 list
In-Reply-To: <CAM6ZMz9qoiJQYDA_PMShafiZHbyGB3s5wHWAyZ6HXag=t6qwUQ@mail.gmail.com>
References: <36332afd-a4fb-4760-8919-211e91520bc3@default>
 <e4bc267e-c2c0-4a91-a835-35ff59b37ae8@default>
 <47487c2a-6e8f-fb35-cd70-3c8c7213e79b@oracle.com>
 <CAM6ZMz-n4tdYVich=_aJgwhKVD_z7Mog=v1CKeaAGnsM5yU=uw@mail.gmail.com>
 <9e468958-5ae9-4696-897f-ab4c65f4bbda@default>
 <CAM6ZMz9qoiJQYDA_PMShafiZHbyGB3s5wHWAyZ6HXag=t6qwUQ@mail.gmail.com>
Message-ID: <d88047c7-33cd-465b-ab6e-fbf7f2612baf@default>

Hi Sergey,

I have made the changes you suggested for this bug. Please have a look.
Webrev: http://cr.openjdk.java.net/~pbansal/7108280/webrev.01/

I checked classes like JList,  JTable which use DefaultListSelectionModel to find the methods where DataModel and ListSelectionModel are used together.
In JList, getSelectedValues, getSelectedValuesList and getSelectedValue are three APIs. I have made changes to these APIs.
In JTable, I could not find any API which uses both DataModel and ListSelectionModel together. 

Hi Andrej,
We cannot change the set methods (setSelectionInterval and addSelectionInterval) here as they will break backward compatibility. Someone can also set a custom ListSelectionModel which may cause exception in get(getSelectedValues, getSelectedValuesList and getSelectedValue) methods. So we will have to make changes to get methods only. In JTable, these exceptions don?t because of the above mentioned reasons. But these exceptions can happen in JList and we can't leave the code unchanged.


Regards,
Pankaj Bansal

-----Original Message-----
From: Andrej Golovnin [mailto:andrej.golovnin at gmail.com] 
Sent: Friday, December 8, 2017 1:10 PM
To: Pankaj Bansal
Cc: Sergey Bylokhov; Jayathirth D V; swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10] Review Request: JDK-7108280 : JList.getSelectedValuesList fails if JList.setSelectionInterval larger than list

Hi all,

there is one more option:

4. Close the issue as "won't fix" and suggest the reporter to fix his code.

Option 3 may not break any existing application. But it may hide bugs in applications because in my opinion setting a wrong selection interval is a bug.

Just my 2 cents.

Best regards,
Andrej Golovnin

On Fri, Dec 8, 2017 at 8:13 AM, Pankaj Bansal <pankaj.b.bansal at oracle.com> wrote:
> Hi All,
>
> Thank you for your reviews.
>
> I think we need to finalize on where to make changes, before going any 
> further . We have following few options
>
> 1. Change setSelectionInterval and addSelectionInterval to throw Exception: Make change to these functions to throw IllegalArgumentException when the interval is out of range. This is looks correct as it does not make sense to set selection out of bounds of the list. This also makes the JList more compatible with the JTable. But this will break 2 jck tests which expect the out of bound selection to be allowed. Also this can break existing applications which are setting the wrong selection and expecting it not to throw an exception. Also someone can still set the wrong selection by setting the selection directly on SelectionModel instead of calling it on JList.
>
> 2. Change setSelectionInterval and addSelectionInterval to just return without exception: Make changes to these function to just return if the interval is out of bound. But this will also break the same 2 jck tests and may break existing applications.
>
> 3. Change the getSelectedValues and getSelectedValuesList: Make changes to these functions to check the selection and return the selected objects. If the selection is out of bound, return an empty List or partial List depending on the selection interval, instead of throwing the ArrayIndexOutOfBoundsException.
>
> Option 1 stops someone from setting the wrong selection in the first place and find bugs in case someone tries to set wrong selection. But it may break existing application and can still cause ArrayIndexOutOfBoundsException is someone is setting wrong selection on SelectionModel instead of going through JList.
> Option 3 does not seem to break any existing application and looks immune to ArrayIndexOutOfBoundsException in getMethods. So maybe this is correct way.
>
>
> Regards,
> Pankaj Bansal
>
>
>
>
> -----Original Message-----
> From: Andrej Golovnin [mailto:andrej.golovnin at gmail.com]
> Sent: Wednesday, December 6, 2017 2:00 PM
> To: Sergey Bylokhov
> Cc: Jayathirth D V; Pankaj Bansal; swing-dev at openjdk.java.net; Semyon 
> Sadetsky
> Subject: Re: <Swing Dev> [10] Review Request: JDK-7108280 : 
> JList.getSelectedValuesList fails if JList.setSelectionInterval larger 
> than list
>
> Hi all,
>
> as a long Swing user I would like to vote against the proposed changes. The fact is that the #setSelectionInterval and #addSelectionInterval methods of the JList class exist in this form for a very long time and any change in the behaviour of this methods may break existing applications.
>
> Technically this methods should throw an IllegalArgumentException when the arguments are out of bounds. For example the #setRowSelectionInterval and #addRowSelectionInterval methods of the JTable class throw an IllegalArgumentException.
>
> I think you should ask someone from the Java core team who has deeper understanding, when a change is backward compatible and when not, if it is OK to add a check to this methods and throw an IllegalArgumentException when the arguments are out of bounds. If it is not OK, then you can improve at least the JavaDocs of this methods and explain in the JavaDocs that the arguments must be in the bounds of the current ListModel.
>
> I would also not change the behaviour of JList#getSelectedValuesList.
> The current behaviour, i.g. throwing the ArrayIndexOutOfBoundsException, helps me to find bugs in applications.
> For me setting a wrong selection interval is a bug.
>
> Best regards,
> Andrej Golovnin
>
> On Tue, Dec 5, 2017 at 11:29 PM, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
>> Hello.
>> On 01/12/2017 02:47, Jayathirth D V wrote:
>>>
>>> As you have mentioned I also feel that adding check in
>>> setSelectionInterval() or addSelectionInterval() would be a good approach.
>>> Since I am not aware of swing component code I will leave this 
>>> decision to others.
>>
>>
>> I also have no preference where to change this. If we will change
>> setSelectionInterval()/addSelectionInterval() then we will need to 
>> update selection model on every change of datamodel. But if we decide 
>> like in the current fix to change the get methods, then we will need 
>> to verify all places where we use datamodel and selection model:
>> for example JList.getSelectedValue() and others.
>> Also we should check other classes which use the same selection model 
>> like JTable.
>>
>>>
>>> Regarding http://cr.openjdk.java.net/~pbansal/7108280/webrev.002/:
>>>
>>> May be we are not handling the case where validateLeadIndex() fails 
>>> and we don?t set selection interval and it is resulting in JCK test 
>>> fail. If you can share what is behavior of JCK test failure after 
>>> your change it would be helpful.
>>>
>>>                  Also specification of setSelectionInterval() or
>>> addSelectionInterval() mentions that ?{@code anchor} doesn't have to 
>>> be less than or equal to {@code lead}?. So while validating 
>>> arguments for
>>> setSelectionInterval() or addSelectionInterval() I think we should 
>>> verify the value of anchor first and then check the value of (anchor
>>> + lead) instead of just checking whether lead < size.
>>>
>>> Thanks,
>>>
>>> Jay
>>>
>>> *From:* Pankaj Bansal
>>> *Sent:* Friday, December 01, 2017 3:02 PM
>>> *To:* swing-dev at openjdk.java.net; Sergey Bylokhov; Semyon Sadetsky
>>> *Subject:* <Swing Dev> [10] Review Request: JDK-7108280 :
>>> JList.getSelectedValuesList fails if JList.setSelectionInterval 
>>> larger than list
>>>
>>> Hi All,
>>>
>>> Please review the fix.
>>>
>>> Bug:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-7108280
>>>
>>> Webrev:
>>>
>>> http://cr.openjdk.java.net/~pbansal/7108280/webrev.00/
>>>
>>> Issue:
>>>
>>> JList.getSelectedValuesList crashes if the 
>>> JList.setSelectionInterval or JList.addSelectionInterval had been 
>>> called earlier with interval having lead greater than the size of 
>>> List
>>>
>>> Fix:
>>>
>>> Made changes in JList.getSelectedValuesList to check the if the max 
>>> selection index is greater than the actual size of the List. If yes, 
>>> the max is changed to last element index of List.
>>>
>>> Note:
>>>
>>> It makes sense to change the behavior of JList.setSelectionInterval 
>>> or JList.addSelectionInterval to not allow to set the selection with 
>>> interval having indices not present in the list. But it will change 
>>> the behavior of this API and will result in failure of 2 JCK tests.
>>>
>>> Also, we will still have to put checks inside the 
>>> JList.getSelectedValuesList as the selection can be changed by 
>>> setting selection interval on DefualtListSelectionModel and there is 
>>> no way to check if the supplied interval range actually exist in the 
>>> List inside DefualtListSelectionModel.
>>>
>>> If changing the JList.setSelectionInterval or 
>>> JList.addSelectionInterval is possible, the potential fix can be following webrev.
>>>
>>> http://cr.openjdk.java.net/~pbansal/7108280/webrev.002/
>>>
>>> Regards,
>>>
>>> Pankaj Bansal
>>>
>>
>>
>> --
>> Best regards, Sergey.


From prasanta.sadhukhan at oracle.com  Thu Jan  4 05:23:46 2018
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Thu, 4 Jan 2018 10:53:46 +0530
Subject: <Swing Dev> [10][11][JDK-8194044] Regression manual Test
 javax/swing/JFileChooser/8067660/FileChooserTest.java fails
In-Reply-To: <db9ba389-e151-4307-9fd1-e30adcf93234@default>
References: <91a8f44e-a18c-43f5-96b8-ab310399c348@default>
 <fb48167a-d960-f5c9-ad2e-92199ee47a39@oracle.com>
 <db9ba389-e151-4307-9fd1-e30adcf93234@default>
Message-ID: <9471d86d-c59b-53b9-0b6c-4c2a9b8555a7@oracle.com>

A regression test is added to prove that before your fix, java was 
failing and after your fix is applied, it is passing so it is not 
related to older/newer java versions. I saw we already have 
test/jdk/javax/swing/JFileChooser/6945316/bug6945316.java which tests 
isFileSystemRoot. Maybe, we can do something similar if it's not too 
much of a task.

Regards
Prasanta
On 1/3/2018 5:13 PM, Krishna Addepalli wrote:
>
> Thanks for the review Prasanta. However, I don?t see a point to write 
> a test case for isFileSystemRoot(), since, it is not going to fail on 
> any (older/newer) java versions, and it was only introduced because of 
> the fix for JDK-8175015.
>
> Let me know if you think otherwise.
>
> Regards,
>
> Krishna
>
> *From:*Prasanta Sadhukhan
> *Sent:* Wednesday, January 3, 2018 11:27 AM
> *To:* Krishna Addepalli <krishna.addepalli at oracle.com>; 
> swing-dev at openjdk.java.net
> *Subject:* Re: <Swing Dev> [10][11][JDK-8194044] Regression manual 
> Test javax/swing/JFileChooser/8067660/FileChooserTest.java fails
>
> Fix looks fine. But I guess, it is possible to add a automated 
> regression test to it utilising isFileSystemRoot().
>
> Regards
> Prasanta
>
> On 1/2/2018 4:31 PM, Krishna Addepalli wrote:
>
>     Hi All,
>
>     Please review a fix for bug:
>
>     Bug: JDK-8194044 : https://bugs.openjdk.java.net/browse/JDK-8194044
>
>     Webrev: http://cr.openjdk.java.net/~kaddepalli/8194044/webrev00/
>     <http://cr.openjdk.java.net/%7Ekaddepalli/8194044/webrev00/>
>
>     This was caused due to the fix for JDK-8175015, in which the line
>     446 ?in Win32ShellFolderManager2.java was changed from
>     ?getDrives()? to Win32ShellFolder2.listRoots().
>
>     While the earlier function returns an object of Win32ShellFolder2,
>     the latter returns an array of Files.
>
>     The condition on line 450: ?return (sf.isFileSystem()&&sf.parent
>     != null && sf.parent.equals(Win32ShellFolder2.listRoots())? was
>     returning false because of the wrong object being passed. Earlier
>     it was a Win32ShellFolder2 object, and the comparision was done
>     properly, but with the changes, the equals fucnction was receiving
>     a file array object, and hence it was immediately returning false,
>     leading to the problem of empty strings being shown for Root drives.
>
>     The fix is to replace ?Win32ShellFolder2.listRoots()? with
>     ?getDrives()? function. With this fix, the regression is
>     addressed, as well as the original JDK-8175015 which was a memory
>     leak issue.
>
>     Thanks,
>
>     Krishna
>

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

From prasanta.sadhukhan at oracle.com  Thu Jan  4 10:33:52 2018
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Thu, 4 Jan 2018 16:03:52 +0530
Subject: <Swing Dev> [11] RFR JDK-8191106: Nimbus LookAndFeel does not apply
 keys FileChooser.directoryOpenButtonText/ToolTipText to JFileChooser
Message-ID: <cba5c211-bc50-9e81-0141-1c0460b80070@oracle.com>

Hi All,

Please review a fix for Nimbus L&F where it is seen that
When you select a directory in a JFileChooser dialog, the text and 
tooltip of the "approve" button is not changing to the values of 
UIManager keys FileChooser.directoryOpenButtonText and 
FileChooser.directoryOpenButtonToolTipText and remain same as it was 
before directory is selected.
It changes for Metal and windows l&f.

This is because when directory is selected 
BasicFileChooserUI#valueChanged() calls setDirectorySelected() but it's 
not implemented for nimbus l&f and it uses default implementation of 
BasicFileChooser.
For Metal & Windows, this method is overridden to change the approve 
button text to FileChooser.directoryOpenButtonText.
Propsosed fix is to override this method for Nimbus L&f and set the 
approve button text to FileChooser.directoryOpenButtonText.

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

Regards
Prasanta



From semyon.sadetsky at oracle.com  Thu Jan  4 16:04:48 2018
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Thu, 4 Jan 2018 08:04:48 -0800
Subject: <Swing Dev> [11] RFR JDK-8191106: Nimbus LookAndFeel does not
 apply keys FileChooser.directoryOpenButtonText/ToolTipText to JFileChooser
In-Reply-To: <cba5c211-bc50-9e81-0141-1c0460b80070@oracle.com>
References: <cba5c211-bc50-9e81-0141-1c0460b80070@oracle.com>
Message-ID: <cba7509f-ab9c-894c-c5dd-06145b5ac112@oracle.com>

Hi Prasanta,

Since all those L&F's now have the same implementation of the method 
maybe it worth to push it down to the basic class?

--Semyon

On 01/04/2018 02:33 AM, Prasanta Sadhukhan wrote:
> Hi All,
>
> Please review a fix for Nimbus L&F where it is seen that
> When you select a directory in a JFileChooser dialog, the text and 
> tooltip of the "approve" button is not changing to the values of 
> UIManager keys FileChooser.directoryOpenButtonText and 
> FileChooser.directoryOpenButtonToolTipText and remain same as it was 
> before directory is selected.
> It changes for Metal and windows l&f.
>
> This is because when directory is selected 
> BasicFileChooserUI#valueChanged() calls setDirectorySelected() but 
> it's not implemented for nimbus l&f and it uses default implementation 
> of BasicFileChooser.
> For Metal & Windows, this method is overridden to change the approve 
> button text to FileChooser.directoryOpenButtonText.
> Propsosed fix is to override this method for Nimbus L&f and set the 
> approve button text to FileChooser.directoryOpenButtonText.
>
> Bug:https://bugs.openjdk.java.net/browse/JDK-8191106
> webrev: http://cr.openjdk.java.net/~psadhukhan/8191106/webrev.00/
>
> Regards
> Prasanta
>



From manajit.halder at oracle.com  Thu Jan  4 18:22:44 2018
From: manajit.halder at oracle.com (Manajit Halder)
Date: Thu, 4 Jan 2018 23:52:44 +0530
Subject: <Swing Dev> Swing dev>[10] Review request for JDK-8189253:
 [macos] JPopupMenu is inadvertently shown when using setComponentPopupMenu
In-Reply-To: <bcd060d3-4553-55f5-4fee-b22d6313426e@oracle.com>
References: <E1445698-445B-4542-98C1-1D82A4A182C9@oracle.com>
 <4ed5cbcf-c1f7-f615-6404-ebe13c47b8da@oracle.com>
 <C77A97FC-2163-455F-847D-C590D3B5D522@oracle.com>
 <bcd060d3-4553-55f5-4fee-b22d6313426e@oracle.com>
Message-ID: <F10C8291-1722-4618-B2B5-C2DB14E7486C@oracle.com>

Hi Semyon,

Fix for issue JDK-8080729 <https://bugs.openjdk.java.net/browse/JDK-8080729> has caused this regression due to changes in method setVisible(boolean visible) in file CPlatformWindow.java
orderWindow is causing the issue here, if we revert to addChildWindow then the issue is not observed but then the fix for issue JDK-8080729 fails.
Before this change the child window used to be added on to the parent as shown below in the commented code. But after the change child window is ordered above the parent.

Below code causes the regression:

CWrapper.NSWindow.orderWindow(ptr, CWrapper.NSWindow.NSWindowAbove, ownerPtr);
//CWrapper.NSWindow.addChildWindow(ownerPtr, ptr, CWrapper.NSWindow.NSWindowAbove);

Debugging further I found that if we use orderWindow then the new window is considered as new graphics device in the method notifyReshape in LWWindowPeer.java (the method updateGraphicsDevice() returns true) and is the difference between using orderWindow and addChildWindow.

Since the option to add child window is between choosing oderWindow and addChildWindow we don?t have any option to do the fix in the Mac OS native code.

Regards,
Manajit


> On 02-Jan-2018, at 11:30 PM, Semyon Sadetsky <semyon.sadetsky at oracle.com> wrote:
> 
> Hi Manajit,
> 
> JDK-8080729 bug was Mac OS specific issue and its fix changed the Mac OS code only. Nevertheless you are suggesting to fix the regression in generic code. This need to be explained somehow.
> 
> --Semyon
> On 12/25/2017 02:42 AM, Manajit Halder wrote:
>> Hi Semyon,
>> 
>> Regression is cause by JDK-8080729 <https://bugs.openjdk.java.net/browse/JDK-8080729>. The fix can?t be reversed since it is the choice between addChildWindow or orderWindow. Went through code flow related to the issue but didn?t find any other better place in code to handle this issue. The best way to fix the issue would be to avoid retargeting of events (MOUSE_ENTER and MOUSE_EXIT) between MOUSE_PRESS and MOUSE_RELEASE on the parent window (when the mouse is actually on the child window). Therefore request you to review the webrev.00.
>> 
>> Regards,
>> Manajit
>> 
>>> On 08-Dec-2017, at 9:55 PM, semyon.sadetsky at oracle.com <mailto:semyon.sadetsky at oracle.com> wrote:
>>> 
>>> Hi Manajit,
>>> 
>>> Can you provide information which fix caused the regression?
>>> 
>>> --Semyon
>>> 
>>> On 12/8/17 5:53 AM, Manajit Halder wrote:
>>>> Hi All,
>>>> 
>>>> Kindly review the following Swing fix.
>>>> 
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8189253 <https://bugs.openjdk.java.net/browse/JDK-8189253>
>>>> Webrev: http://cr.openjdk.java.net/~mhalder/8189253/webrev.00/ <http://cr.openjdk.java.net/%7Emhalder/8189253/webrev.00/>
>>>> 
>>>> Cause: 
>>>> 	Issue was due to retargeting of mouse enter exit events. 
>>>> 	MOUSE_ENTER and MOUSE_EXIT events were sent on the parent window (JFrame) in between MOUSE_PRESS and MOUSE_RELEASE events on the modeless JDialog.
>>>> 
>>>> Fix:
>>>> 	Retargeting of events is not done in-between MOUSE_PRESS and MOUSE_RELEASE.
>>>> 
>>>> Regards,
>>>> Manajit
>>>> 
>>> 
>> 
> 

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

From Sergey.Bylokhov at oracle.com  Fri Jan  5 00:54:25 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 4 Jan 2018 16:54:25 -0800
Subject: <Swing Dev> [11] Review Request: JDK-5076761 :
 JList.setSelectedValue(null, ...) doesn't do anything
In-Reply-To: <d1d36b2a-1ca9-44ea-8e50-a819a20b7980@default>
References: <417f68fe-4565-40b1-b360-e6ff9e18dd33@default>
 <da38a552-d357-b86d-399e-ba1b90fca79f@oracle.com>
 <d1d36b2a-1ca9-44ea-8e50-a819a20b7980@default>
Message-ID: <5fd4cbc3-5af0-bbc4-c2d4-acb13ab0232d@oracle.com>

Looks fine.
Please change the dates in the test header before the push. Note that 
you need to create a CSR request for the spec update.

On 02/01/2018 23:26, Pankaj Bansal wrote:
> Hi Sergey,
> 
> Thanks for the review.
> 
> I have made the suggested changes. Please have a look.
> webrev: http://cr.openjdk.java.net/~pbansal/5076761/webrev.01/
> 
> Regards,
> Pankaj Bansal
> 
> 
> -----Original Message-----
> From: Sergey Bylokhov
> Sent: Wednesday, January 3, 2018 3:31 AM
> To: Pankaj Bansal; swing-dev at openjdk.java.net; Prasanta Sadhukhan
> Subject: Re: [11] Review Request: JDK-5076761 : JList.setSelectedValue(null, ...) doesn't do anything
> 
> Hi, Pankaj.
> The fix looks fine, but I suggest to update the spec as well and describe the behavior if "null" value is passed.
> 
> On 02/01/2018 02:07, Pankaj Bansal wrote:
>> Hi All,
>>
>> Please review the fix for JDK 11.
>>
>> Bug:
>>
>> https://bugs.openjdk.java.net/browse/JDK-5076761
>>
>> Webrev:
>>
>> http://cr.openjdk.java.net/~pbansal/5076761/webrev.00/
>>
>> Issue:
>>
>> When setSelectedValue is called on JList with null object, it should
>> clear all selection. But it is not doing anything.
>>
>> Fix:
>>
>> In setSelectedValue if the object is null, the setSelectedIndex is
>> called with -1. but this does not clear the selection. We should be
>> calling clearSelection instead of SetSelectedIndex.
>>
>> Regards,
>>
>> Pankaj Bansal
>>
> 
> 
> --
> Best regards, Sergey.
> 


-- 
Best regards, Sergey.


From semyon.sadetsky at oracle.com  Fri Jan  5 01:28:52 2018
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Thu, 4 Jan 2018 17:28:52 -0800
Subject: <Swing Dev> [11] Review Request: JDK-5076761 :
 JList.setSelectedValue(null, ...) doesn't do anything
In-Reply-To: <d1d36b2a-1ca9-44ea-8e50-a819a20b7980@default>
References: <417f68fe-4565-40b1-b360-e6ff9e18dd33@default>
 <da38a552-d357-b86d-399e-ba1b90fca79f@oracle.com>
 <d1d36b2a-1ca9-44ea-8e50-a819a20b7980@default>
Message-ID: <6e0afc35-f779-7801-cfea-d0416f322db4@oracle.com>

Hi Pankaj,

Can JList contain null value?

--Semyon


On 01/02/2018 11:26 PM, Pankaj Bansal wrote:
> Hi Sergey,
>
> Thanks for the review.
>
> I have made the suggested changes. Please have a look.
> webrev: http://cr.openjdk.java.net/~pbansal/5076761/webrev.01/
>
> Regards,
> Pankaj Bansal
>
>
> -----Original Message-----
> From: Sergey Bylokhov
> Sent: Wednesday, January 3, 2018 3:31 AM
> To: Pankaj Bansal; swing-dev at openjdk.java.net; Prasanta Sadhukhan
> Subject: Re: [11] Review Request: JDK-5076761 : JList.setSelectedValue(null, ...) doesn't do anything
>
> Hi, Pankaj.
> The fix looks fine, but I suggest to update the spec as well and describe the behavior if "null" value is passed.
>
> On 02/01/2018 02:07, Pankaj Bansal wrote:
>> Hi All,
>>
>> Please review the fix for JDK 11.
>>
>> Bug:
>>
>> https://bugs.openjdk.java.net/browse/JDK-5076761
>>
>> Webrev:
>>
>> http://cr.openjdk.java.net/~pbansal/5076761/webrev.00/
>>
>> Issue:
>>
>> When setSelectedValue is called on JList with null object, it should
>> clear all selection. But it is not doing anything.
>>
>> Fix:
>>
>> In setSelectedValue if the object is null, the setSelectedIndex is
>> called with -1. but this does not clear the selection. We should be
>> calling clearSelection instead of SetSelectedIndex.
>>
>> Regards,
>>
>> Pankaj Bansal
>>
>
> --
> Best regards, Sergey.



From semyon.sadetsky at oracle.com  Fri Jan  5 01:38:48 2018
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Thu, 4 Jan 2018 17:38:48 -0800
Subject: <Swing Dev> Swing dev>[10] Review request for JDK-8189253:
 [macos] JPopupMenu is inadvertently shown when using setComponentPopupMenu
In-Reply-To: <F10C8291-1722-4618-B2B5-C2DB14E7486C@oracle.com>
References: <E1445698-445B-4542-98C1-1D82A4A182C9@oracle.com>
 <4ed5cbcf-c1f7-f615-6404-ebe13c47b8da@oracle.com>
 <C77A97FC-2163-455F-847D-C590D3B5D522@oracle.com>
 <bcd060d3-4553-55f5-4fee-b22d6313426e@oracle.com>
 <F10C8291-1722-4618-B2B5-C2DB14E7486C@oracle.com>
Message-ID: <f7627a88-4d81-7105-59a0-fdf6872b62f2@oracle.com>

Hi Manajit,

I could reproduce similar behaviour on Linux when mouse is dragged to 
another component with the left button pressed and then the right button 
is immediately? pressed. The popup is triggered by the same logic 
despite it isn't configured for the component.

--Semyon

On 01/04/2018 10:22 AM, Manajit Halder wrote:
> Hi Semyon,
>
> Fix for issue JDK-8080729 
> <https://bugs.openjdk.java.net/browse/JDK-8080729> has caused this 
> regression due to changes in method setVisible(boolean visible) in 
> file CPlatformWindow.java
> orderWindow is causing the issue here, if we revert to addChildWindow 
> then the issue is not observed but then the fix for issue JDK-8080729 
> fails.
> Before this change the child window used to be added on to the parent 
> as shown below in the commented code. But after the change child 
> window is ordered above the parent.
>
> Below code causes the regression:
>
> *CWrapper.NSWindow.orderWindow(ptr, CWrapper.NSWindow.NSWindowAbove, 
> ownerPtr);*
> *//CWrapper.NSWindow.addChildWindow(ownerPtr, ptr, 
> CWrapper.NSWindow.NSWindowAbove);*
>
> Debugging further I found that if we use orderWindow then the new 
> window is considered as new graphics device in the method 
> notifyReshape in LWWindowPeer.java (the method updateGraphicsDevice() 
> returns true) and is the difference between using orderWindow and 
> addChildWindow.
>
> Since the option to add child window is between choosing oderWindow 
> and addChildWindow we don?t have any option to do the fix in the Mac 
> OS native code.
>
> Regards,
> Manajit
>
>
>> On 02-Jan-2018, at 11:30 PM, Semyon Sadetsky 
>> <semyon.sadetsky at oracle.com <mailto:semyon.sadetsky at oracle.com>> wrote:
>>
>> Hi Manajit,
>>
>> JDK-8080729 bug was Mac OS specific issue and its fix changed the Mac 
>> OS code only. Nevertheless you are suggesting to fix the regression 
>> in generic code. This need to be explained somehow.
>>
>> --Semyon
>>
>> On 12/25/2017 02:42 AM, Manajit Halder wrote:
>>> Hi Semyon,
>>>
>>> Regression is cause by JDK-8080729 
>>> <https://bugs.openjdk.java.net/browse/JDK-8080729>. The fix can?t be 
>>> reversed since it is the?choice between addChildWindow or 
>>> orderWindow. Went through code flow related to the issue but?didn?t 
>>> find any other better place in code to handle this issue. The best 
>>> way to fix the issue would be to avoid retargeting of events 
>>> (MOUSE_ENTER and MOUSE_EXIT) between MOUSE_PRESS and MOUSE_RELEASE 
>>> on the parent window (when the mouse is actually on the child 
>>> window). Therefore request you to review the webrev.00.
>>>
>>> Regards,
>>> Manajit
>>>
>>>> On 08-Dec-2017, at 9:55 PM, semyon.sadetsky at oracle.com 
>>>> <mailto:semyon.sadetsky at oracle.com> wrote:
>>>>
>>>> Hi Manajit,
>>>>
>>>> Can you provide information which fix caused the regression?
>>>>
>>>> --Semyon
>>>>
>>>>
>>>> On 12/8/17 5:53 AM, Manajit Halder wrote:
>>>>> Hi All,
>>>>>
>>>>> Kindly review the following Swing fix.
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8189253
>>>>> Webrev: http://cr.openjdk.java.net/~mhalder/8189253/webrev.00/ 
>>>>> <http://cr.openjdk.java.net/%7Emhalder/8189253/webrev.00/>
>>>>>
>>>>> Cause:
>>>>> Issue was due to retargeting of mouse enter exit events.
>>>>> MOUSE_ENTER and MOUSE_EXIT events were sent on the parent window 
>>>>> (JFrame) in between MOUSE_PRESS and MOUSE_RELEASE events on the 
>>>>> modeless JDialog.
>>>>>
>>>>> Fix:
>>>>> Retargeting of events is not done in-between MOUSE_PRESS and 
>>>>> MOUSE_RELEASE.
>>>>>
>>>>> Regards,
>>>>> Manajit
>>>>>
>>>>
>>>
>>
>

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

From reinhard.pointner at gmail.com  Thu Jan  4 11:12:48 2018
From: reinhard.pointner at gmail.com (Reinhard Pointner)
Date: Thu, 4 Jan 2018 12:12:48 +0100
Subject: <Swing Dev> Review Request: JDK-8189938: Support Java 9 Swing
 applications on the Microsoft Store
Message-ID: <CAFUKpKC-yXWe30TWEAyPH=P1nawssVRtEbodPaiL0Rwy32aiUw@mail.gmail.com>

Hi all,

There's some strange but major issues with deploying Java 9 Swing apps on
the Microsoft Store. I understand that this might not be a priority for the
JDK team, but having the option of selling Java 9 based Swing applications
on the Microsoft Store would be really good for developers.

Exception in thread "Swing-Shell" java.lang.InternalError: Could not
initialize COM: HRESULT=0x80010106

https://bugs.openjdk.java.net/browse/JDK-8189938

Best regards,
Reinhard Pointner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20180104/98e6b290/attachment.html>

From prasanta.sadhukhan at oracle.com  Fri Jan  5 06:05:23 2018
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Fri, 5 Jan 2018 11:35:23 +0530
Subject: <Swing Dev> [11] RFR JDK-8191106: Nimbus LookAndFeel does not
 apply keys FileChooser.directoryOpenButtonText/ToolTipText to JFileChooser
In-Reply-To: <cba7509f-ab9c-894c-c5dd-06145b5ac112@oracle.com>
References: <cba5c211-bc50-9e81-0141-1c0460b80070@oracle.com>
 <cba7509f-ab9c-894c-c5dd-06145b5ac112@oracle.com>
Message-ID: <f28aa56c-af7a-e5c4-d5c9-d0efca19457a@oracle.com>

Hi Semyon,

It's not exactly the same. For Metal, we do not set mnemonic, not sure 
if that is intentional, so did not push it down to basic class.

Regards
Prasanta
On 1/4/2018 9:34 PM, Semyon Sadetsky wrote:
> Hi Prasanta,
>
> Since all those L&F's now have the same implementation of the method 
> maybe it worth to push it down to the basic class?
>
> --Semyon
>
> On 01/04/2018 02:33 AM, Prasanta Sadhukhan wrote:
>> Hi All,
>>
>> Please review a fix for Nimbus L&F where it is seen that
>> When you select a directory in a JFileChooser dialog, the text and 
>> tooltip of the "approve" button is not changing to the values of 
>> UIManager keys FileChooser.directoryOpenButtonText and 
>> FileChooser.directoryOpenButtonToolTipText and remain same as it was 
>> before directory is selected.
>> It changes for Metal and windows l&f.
>>
>> This is because when directory is selected 
>> BasicFileChooserUI#valueChanged() calls setDirectorySelected() but 
>> it's not implemented for nimbus l&f and it uses default 
>> implementation of BasicFileChooser.
>> For Metal & Windows, this method is overridden to change the approve 
>> button text to FileChooser.directoryOpenButtonText.
>> Propsosed fix is to override this method for Nimbus L&f and set the 
>> approve button text to FileChooser.directoryOpenButtonText.
>>
>> Bug:https://bugs.openjdk.java.net/browse/JDK-8191106
>> webrev: http://cr.openjdk.java.net/~psadhukhan/8191106/webrev.00/
>>
>> Regards
>> Prasanta
>>
>



From pankaj.b.bansal at oracle.com  Fri Jan  5 10:15:00 2018
From: pankaj.b.bansal at oracle.com (Pankaj Bansal)
Date: Fri, 5 Jan 2018 02:15:00 -0800 (PST)
Subject: <Swing Dev> [11] Review Request: JDK-5076761 :
 JList.setSelectedValue(null, ...) doesn't do anything
In-Reply-To: <6e0afc35-f779-7801-cfea-d0416f322db4@oracle.com>
References: <417f68fe-4565-40b1-b360-e6ff9e18dd33@default>
 <da38a552-d357-b86d-399e-ba1b90fca79f@oracle.com>
 <d1d36b2a-1ca9-44ea-8e50-a819a20b7980@default>
 <6e0afc35-f779-7801-cfea-d0416f322db4@oracle.com>
Message-ID: <e59b096d-a4ed-4ac8-ad0e-a891ac8fab0b@default>

Hi Semyon/Sergey,

Yes, JList can contain null elements as it can be added to data model. I think this changes a lot in this bug. I think the selection needs to be cleared when the object passed is not present in the list, irrespective of it being null or not. I have made code changes. Please have a look. 

Webrev: http://cr.openjdk.java.net/~pbansal/5076761/webrev.02/

Regards,
Pankaj Bansal

-----Original Message-----
From: Semyon Sadetsky 
Sent: Friday, January 5, 2018 6:59 AM
To: Pankaj Bansal; swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [11] Review Request: JDK-5076761 : JList.setSelectedValue(null, ...) doesn't do anything

Hi Pankaj,

Can JList contain null value?

--Semyon


On 01/02/2018 11:26 PM, Pankaj Bansal wrote:
> Hi Sergey,
>
> Thanks for the review.
>
> I have made the suggested changes. Please have a look.
> webrev: http://cr.openjdk.java.net/~pbansal/5076761/webrev.01/
>
> Regards,
> Pankaj Bansal
>
>
> -----Original Message-----
> From: Sergey Bylokhov
> Sent: Wednesday, January 3, 2018 3:31 AM
> To: Pankaj Bansal; swing-dev at openjdk.java.net; Prasanta Sadhukhan
> Subject: Re: [11] Review Request: JDK-5076761 : 
> JList.setSelectedValue(null, ...) doesn't do anything
>
> Hi, Pankaj.
> The fix looks fine, but I suggest to update the spec as well and describe the behavior if "null" value is passed.
>
> On 02/01/2018 02:07, Pankaj Bansal wrote:
>> Hi All,
>>
>> Please review the fix for JDK 11.
>>
>> Bug:
>>
>> https://bugs.openjdk.java.net/browse/JDK-5076761
>>
>> Webrev:
>>
>> http://cr.openjdk.java.net/~pbansal/5076761/webrev.00/
>>
>> Issue:
>>
>> When setSelectedValue is called on JList with null object, it should 
>> clear all selection. But it is not doing anything.
>>
>> Fix:
>>
>> In setSelectedValue if the object is null, the setSelectedIndex is 
>> called with -1. but this does not clear the selection. We should be 
>> calling clearSelection instead of SetSelectedIndex.
>>
>> Regards,
>>
>> Pankaj Bansal
>>
>
> --
> Best regards, Sergey.



From andrej.golovnin at gmail.com  Fri Jan  5 11:03:21 2018
From: andrej.golovnin at gmail.com (Andrej Golovnin)
Date: Fri, 5 Jan 2018 12:03:21 +0100
Subject: <Swing Dev> [11] Review Request: JDK-5076761 :
 JList.setSelectedValue(null, ...) doesn't do anything
In-Reply-To: <e59b096d-a4ed-4ac8-ad0e-a891ac8fab0b@default>
References: <417f68fe-4565-40b1-b360-e6ff9e18dd33@default>
 <da38a552-d357-b86d-399e-ba1b90fca79f@oracle.com>
 <d1d36b2a-1ca9-44ea-8e50-a819a20b7980@default>
 <6e0afc35-f779-7801-cfea-d0416f322db4@oracle.com>
 <e59b096d-a4ed-4ac8-ad0e-a891ac8fab0b@default>
Message-ID: <CAM6ZMz-daF2SvBj_zTMDJu2WJ8KvD07jtUzFQJDdLVGYo5o++w@mail.gmail.com>

Hi Pankaj,

> Webrev: http://cr.openjdk.java.net/~pbansal/5076761/webrev.02/

src/java.desktop/share/classes/javax/swing/JList.java

You can simplify the code in lines

2373         if((anObject == selectedValue) ||
2374                 (anObject != null && anObject.equals(selectedValue))) {

and

2383                 if ((anObject == object) ||
2384                         anObject!= null && anObject.equals(object)) {

by using Objects.equals(Object, Object):

And please add spaces in the line 2379 where needed (see
http://cr.openjdk.java.net/~alundblad/styleguide/index-v6.html#toc-whitespace
for details).

Best regards,
Andrej Golovnin


From pankaj.b.bansal at oracle.com  Fri Jan  5 11:57:58 2018
From: pankaj.b.bansal at oracle.com (Pankaj Bansal)
Date: Fri, 5 Jan 2018 03:57:58 -0800 (PST)
Subject: <Swing Dev> [11] Review Request: JDK-5076761 :
 JList.setSelectedValue(null, ...) doesn't do anything
In-Reply-To: <CAM6ZMz-daF2SvBj_zTMDJu2WJ8KvD07jtUzFQJDdLVGYo5o++w@mail.gmail.com>
References: <417f68fe-4565-40b1-b360-e6ff9e18dd33@default>
 <da38a552-d357-b86d-399e-ba1b90fca79f@oracle.com>
 <d1d36b2a-1ca9-44ea-8e50-a819a20b7980@default>
 <6e0afc35-f779-7801-cfea-d0416f322db4@oracle.com>
 <e59b096d-a4ed-4ac8-ad0e-a891ac8fab0b@default>
 <CAM6ZMz-daF2SvBj_zTMDJu2WJ8KvD07jtUzFQJDdLVGYo5o++w@mail.gmail.com>
Message-ID: <cc8ac65e-a2fa-4282-b0d2-2ab564f854e1@default>

Hi Andrej,

Thanks for the review.

I have made changes according to your suggestions. Please have a look.
Webrev: http://cr.openjdk.java.net/~pbansal/5076761/webrev.03/

Regards,
Pankaj Bansal

-----Original Message-----
From: Andrej Golovnin [mailto:andrej.golovnin at gmail.com] 
Sent: Friday, January 5, 2018 4:33 PM
To: Pankaj Bansal
Cc: Semyon Sadetsky; swing-dev at openjdk.java.net; Sergey Bylokhov
Subject: Re: <Swing Dev> [11] Review Request: JDK-5076761 : JList.setSelectedValue(null, ...) doesn't do anything

Hi Pankaj,

> Webrev: http://cr.openjdk.java.net/~pbansal/5076761/webrev.02/

src/java.desktop/share/classes/javax/swing/JList.java

You can simplify the code in lines

2373         if((anObject == selectedValue) ||
2374                 (anObject != null && anObject.equals(selectedValue))) {

and

2383                 if ((anObject == object) ||
2384                         anObject!= null && anObject.equals(object)) {

by using Objects.equals(Object, Object):

And please add spaces in the line 2379 where needed (see http://cr.openjdk.java.net/~alundblad/styleguide/index-v6.html#toc-whitespace
for details).

Best regards,
Andrej Golovnin


From pankaj.b.bansal at oracle.com  Fri Jan  5 12:16:03 2018
From: pankaj.b.bansal at oracle.com (Pankaj Bansal)
Date: Fri, 5 Jan 2018 04:16:03 -0800 (PST)
Subject: <Swing Dev> [11] Review Request: JDK-6257207 :
 JTable.getDefaultEditor throws undocumented NullPointerException
Message-ID: <6fe0e41d-ad6b-498c-b3f5-3da202b6c6f3@default>

Hi All,

 

Please review the fix for JDK 11.

 

Bug:

https://bugs.openjdk.java.net/browse/JDK-6257207

 

Webrev:

http://cr.openjdk.java.net/~pbansal/6257207/webrev.00/

 

Issue:

JTable.getDefaultEditor can throw a NullPointerException.

 

Fix:

While creating JTable, when data model is set by calling SetModel function, SetModel function throws TableChanged event. Now if client code has subclassed the JTable and is listening to TableChanged events, client can try to use DefaultEditor, which causes problem as it has not been initialized as of now. Moved the call to initializeLocalVars above setModel call. 

 

Regards,

Pankaj Bansal

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

From andrej.golovnin at gmail.com  Fri Jan  5 13:19:22 2018
From: andrej.golovnin at gmail.com (Andrej Golovnin)
Date: Fri, 5 Jan 2018 14:19:22 +0100
Subject: <Swing Dev> [11] Review Request: JDK-6257207 :
 JTable.getDefaultEditor throws undocumented NullPointerException
In-Reply-To: <6fe0e41d-ad6b-498c-b3f5-3da202b6c6f3@default>
References: <6fe0e41d-ad6b-498c-b3f5-3da202b6c6f3@default>
Message-ID: <CAM6ZMz8vVzu7rmnh6WaiSEF7sb-QjRhODfMQ_q+1jyjzf2=o8A@mail.gmail.com>

Hi Pankaj,

your change may break existing applications. Suppose that someone has
created a sub-class of JTable and has overridden the
#initializeLocalVars()-method and tries to access the table model in
this model. Before your change the application works and after your
change the application would throw NPE.

Best regards,
Andrej Golovnin

On Fri, Jan 5, 2018 at 1:16 PM, Pankaj Bansal
<pankaj.b.bansal at oracle.com> wrote:
> Hi All,
>
>
>
> Please review the fix for JDK 11.
>
>
>
> Bug:
>
> https://bugs.openjdk.java.net/browse/JDK-6257207
>
>
>
> Webrev:
>
> http://cr.openjdk.java.net/~pbansal/6257207/webrev.00/
>
>
>
> Issue:
>
> JTable.getDefaultEditor can throw a NullPointerException.
>
>
>
> Fix:
>
> While creating JTable, when data model is set by calling SetModel function,
> SetModel function throws TableChanged event. Now if client code has
> subclassed the JTable and is listening to TableChanged events, client can
> try to use DefaultEditor, which causes problem as it has not been
> initialized as of now. Moved the call to initializeLocalVars above setModel
> call.
>
>
>
> Regards,
>
> Pankaj Bansal
>
>


From andrej.golovnin at gmail.com  Fri Jan  5 13:21:38 2018
From: andrej.golovnin at gmail.com (Andrej Golovnin)
Date: Fri, 5 Jan 2018 14:21:38 +0100
Subject: <Swing Dev> [11] Review Request: JDK-5076761 :
 JList.setSelectedValue(null, ...) doesn't do anything
In-Reply-To: <cc8ac65e-a2fa-4282-b0d2-2ab564f854e1@default>
References: <417f68fe-4565-40b1-b360-e6ff9e18dd33@default>
 <da38a552-d357-b86d-399e-ba1b90fca79f@oracle.com>
 <d1d36b2a-1ca9-44ea-8e50-a819a20b7980@default>
 <6e0afc35-f779-7801-cfea-d0416f322db4@oracle.com>
 <e59b096d-a4ed-4ac8-ad0e-a891ac8fab0b@default>
 <CAM6ZMz-daF2SvBj_zTMDJu2WJ8KvD07jtUzFQJDdLVGYo5o++w@mail.gmail.com>
 <cc8ac65e-a2fa-4282-b0d2-2ab564f854e1@default>
Message-ID: <CAM6ZMz_9LDQttV+OJFybUYk9rjvAoXaqtUmMbCi9N=N1wqn4NQ@mail.gmail.com>

Hi Pankaj,

> Webrev: http://cr.openjdk.java.net/~pbansal/5076761/webrev.03/

src/java.desktop/share/classes/javax/swing/JList.java

2379             for(i = 0, c = dm.getSize(); i < c; i++) {

There should be a space after "for". Otherwise looks good. Thanks!

Best regards,
Andrej Golovnin


From pankaj.b.bansal at oracle.com  Fri Jan  5 14:09:44 2018
From: pankaj.b.bansal at oracle.com (Pankaj Bansal)
Date: Fri, 5 Jan 2018 06:09:44 -0800 (PST)
Subject: <Swing Dev> [11] Review Request: JDK-5076761 :
 JList.setSelectedValue(null, ...) doesn't do anything
In-Reply-To: <CAM6ZMz_9LDQttV+OJFybUYk9rjvAoXaqtUmMbCi9N=N1wqn4NQ@mail.gmail.com>
References: <417f68fe-4565-40b1-b360-e6ff9e18dd33@default>
 <da38a552-d357-b86d-399e-ba1b90fca79f@oracle.com>
 <d1d36b2a-1ca9-44ea-8e50-a819a20b7980@default>
 <6e0afc35-f779-7801-cfea-d0416f322db4@oracle.com>
 <e59b096d-a4ed-4ac8-ad0e-a891ac8fab0b@default>
 <CAM6ZMz-daF2SvBj_zTMDJu2WJ8KvD07jtUzFQJDdLVGYo5o++w@mail.gmail.com>
 <cc8ac65e-a2fa-4282-b0d2-2ab564f854e1@default>
 <CAM6ZMz_9LDQttV+OJFybUYk9rjvAoXaqtUmMbCi9N=N1wqn4NQ@mail.gmail.com>
Message-ID: <a89e63e4-b5ac-4700-bfed-ae2d8d2a3f4e@default>

Hi Andrej,

Sorry I missed this small thing. Following is the new webrev
webrev: http://cr.openjdk.java.net/~pbansal/5076761/webrev.04/

Regards,
Pankaj Bansal

-----Original Message-----
From: Andrej Golovnin [mailto:andrej.golovnin at gmail.com] 
Sent: Friday, January 5, 2018 6:52 PM
To: Pankaj Bansal
Cc: Semyon Sadetsky; swing-dev at openjdk.java.net; Sergey Bylokhov
Subject: Re: <Swing Dev> [11] Review Request: JDK-5076761 : JList.setSelectedValue(null, ...) doesn't do anything

Hi Pankaj,

> Webrev: http://cr.openjdk.java.net/~pbansal/5076761/webrev.03/

src/java.desktop/share/classes/javax/swing/JList.java

2379             for(i = 0, c = dm.getSize(); i < c; i++) {

There should be a space after "for". Otherwise looks good. Thanks!

Best regards,
Andrej Golovnin


From semyon.sadetsky at oracle.com  Fri Jan  5 14:58:14 2018
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Fri, 5 Jan 2018 06:58:14 -0800
Subject: <Swing Dev> [11] Review Request: JDK-5076761 :
 JList.setSelectedValue(null, ...) doesn't do anything
In-Reply-To: <a89e63e4-b5ac-4700-bfed-ae2d8d2a3f4e@default>
References: <417f68fe-4565-40b1-b360-e6ff9e18dd33@default>
 <da38a552-d357-b86d-399e-ba1b90fca79f@oracle.com>
 <d1d36b2a-1ca9-44ea-8e50-a819a20b7980@default>
 <6e0afc35-f779-7801-cfea-d0416f322db4@oracle.com>
 <e59b096d-a4ed-4ac8-ad0e-a891ac8fab0b@default>
 <CAM6ZMz-daF2SvBj_zTMDJu2WJ8KvD07jtUzFQJDdLVGYo5o++w@mail.gmail.com>
 <cc8ac65e-a2fa-4282-b0d2-2ab564f854e1@default>
 <CAM6ZMz_9LDQttV+OJFybUYk9rjvAoXaqtUmMbCi9N=N1wqn4NQ@mail.gmail.com>
 <a89e63e4-b5ac-4700-bfed-ae2d8d2a3f4e@default>
Message-ID: <c52011f6-75ac-7276-7a3d-bed9cadd2810@oracle.com>

Hi Pankaj,

Note that before the selection was never cleared if the object is not 
found and the DefaultListSelecetionModel is used. This may cause 
compatibility issue in old applications.

Since the clearing selection behavior is now mentioned in 
setSelectedValue() javadoc it should be also clarified for

setSelectedIndex()
setSelectedIndices()
setSelectionInterval()

and their implementation may need to be changed as well to be consistent.

--Semyon

On 01/05/2018 06:09 AM, Pankaj Bansal wrote:
> Hi Andrej,
>
> Sorry I missed this small thing. Following is the new webrev
> webrev: http://cr.openjdk.java.net/~pbansal/5076761/webrev.04/
>
> Regards,
> Pankaj Bansal
>
> -----Original Message-----
> From: Andrej Golovnin [mailto:andrej.golovnin at gmail.com]
> Sent: Friday, January 5, 2018 6:52 PM
> To: Pankaj Bansal
> Cc: Semyon Sadetsky; swing-dev at openjdk.java.net; Sergey Bylokhov
> Subject: Re: <Swing Dev> [11] Review Request: JDK-5076761 : JList.setSelectedValue(null, ...) doesn't do anything
>
> Hi Pankaj,
>
>> Webrev: http://cr.openjdk.java.net/~pbansal/5076761/webrev.03/
> src/java.desktop/share/classes/javax/swing/JList.java
>
> 2379             for(i = 0, c = dm.getSize(); i < c; i++) {
>
> There should be a space after "for". Otherwise looks good. Thanks!
>
> Best regards,
> Andrej Golovnin



From Sergey.Bylokhov at oracle.com  Sat Jan  6 00:25:00 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 5 Jan 2018 16:25:00 -0800
Subject: <Swing Dev> [11] Review Request: JDK-5076761 :
 JList.setSelectedValue(null, ...) doesn't do anything
In-Reply-To: <e59b096d-a4ed-4ac8-ad0e-a891ac8fab0b@default>
References: <417f68fe-4565-40b1-b360-e6ff9e18dd33@default>
 <da38a552-d357-b86d-399e-ba1b90fca79f@oracle.com>
 <d1d36b2a-1ca9-44ea-8e50-a819a20b7980@default>
 <6e0afc35-f779-7801-cfea-d0416f322db4@oracle.com>
 <e59b096d-a4ed-4ac8-ad0e-a891ac8fab0b@default>
Message-ID: <010ef445-754d-520d-c78b-c87dd98ee8dd@oracle.com>

I doubt that support of null values in the data model is intentional 
because JList is "A component that displays a list of *objects* and 
allows the user to select one or more items."

The null behavior was not specified and work in most cases because some 
of the getXXX methods in ListModel sub-classes and JList have a special 
meaning of null:

JList.getSelectedValue(): Returns {@code null} if there is no selection.
ListModel.getElementAt(int index): In most cases implemented to return 
null if index is incorrect.

Similar method TableModel.getValueAt(int,int) is also usually 
implemented to return null if value is not found or some error occured.

JComboBox.setSelectedItem(): use <code>null</code> to clear the selection
ComboBoxModel.setSelectedItem(): <code>null</code> to clear the selection
ComboBoxModel.getSelectedItem(): <code>null</code> if there is no selection

So I suggest to follow initial intention here, because it is too late to 
add validation of the values.
  - The null value in get() will mean no-selection.
  - The null value passed to set() will clear selection.

On 05/01/2018 02:15, Pankaj Bansal wrote:
> Hi Semyon/Sergey,
> 
> Yes, JList can contain null elements as it can be added to data model. I think this changes a lot in this bug. I think the selection needs to be cleared when the object passed is not present in the list, irrespective of it being null or not. I have made code changes. Please have a look.
> 
> Webrev: http://cr.openjdk.java.net/~pbansal/5076761/webrev.02/
> 
> Regards,
> Pankaj Bansal
> 
> -----Original Message-----
> From: Semyon Sadetsky
> Sent: Friday, January 5, 2018 6:59 AM
> To: Pankaj Bansal; swing-dev at openjdk.java.net
> Subject: Re: <Swing Dev> [11] Review Request: JDK-5076761 : JList.setSelectedValue(null, ...) doesn't do anything
> 
> Hi Pankaj,
> 
> Can JList contain null value?
> 
> --Semyon
> 
> 
> On 01/02/2018 11:26 PM, Pankaj Bansal wrote:
>> Hi Sergey,
>>
>> Thanks for the review.
>>
>> I have made the suggested changes. Please have a look.
>> webrev: http://cr.openjdk.java.net/~pbansal/5076761/webrev.01/
>>
>> Regards,
>> Pankaj Bansal
>>
>>
>> -----Original Message-----
>> From: Sergey Bylokhov
>> Sent: Wednesday, January 3, 2018 3:31 AM
>> To: Pankaj Bansal; swing-dev at openjdk.java.net; Prasanta Sadhukhan
>> Subject: Re: [11] Review Request: JDK-5076761 :
>> JList.setSelectedValue(null, ...) doesn't do anything
>>
>> Hi, Pankaj.
>> The fix looks fine, but I suggest to update the spec as well and describe the behavior if "null" value is passed.
>>
>> On 02/01/2018 02:07, Pankaj Bansal wrote:
>>> Hi All,
>>>
>>> Please review the fix for JDK 11.
>>>
>>> Bug:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-5076761
>>>
>>> Webrev:
>>>
>>> http://cr.openjdk.java.net/~pbansal/5076761/webrev.00/
>>>
>>> Issue:
>>>
>>> When setSelectedValue is called on JList with null object, it should
>>> clear all selection. But it is not doing anything.
>>>
>>> Fix:
>>>
>>> In setSelectedValue if the object is null, the setSelectedIndex is
>>> called with -1. but this does not clear the selection. We should be
>>> calling clearSelection instead of SetSelectedIndex.
>>>
>>> Regards,
>>>
>>> Pankaj Bansal
>>>
>>
>> --
>> Best regards, Sergey.
> 


-- 
Best regards, Sergey.


From semyon.sadetsky at oracle.com  Sat Jan  6 02:01:34 2018
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Fri, 5 Jan 2018 18:01:34 -0800
Subject: <Swing Dev> [11] Review Request: JDK-5076761 :
 JList.setSelectedValue(null, ...) doesn't do anything
In-Reply-To: <010ef445-754d-520d-c78b-c87dd98ee8dd@oracle.com>
References: <417f68fe-4565-40b1-b360-e6ff9e18dd33@default>
 <da38a552-d357-b86d-399e-ba1b90fca79f@oracle.com>
 <d1d36b2a-1ca9-44ea-8e50-a819a20b7980@default>
 <6e0afc35-f779-7801-cfea-d0416f322db4@oracle.com>
 <e59b096d-a4ed-4ac8-ad0e-a891ac8fab0b@default>
 <010ef445-754d-520d-c78b-c87dd98ee8dd@oracle.com>
Message-ID: <fced1c2d-592a-f358-52dd-775b079d0d5f@oracle.com>

Can you explain what is wrong with the suggested? approach?? It is 
flexible to handle both null and non-null containing JList.


On 01/05/2018 04:25 PM, Sergey Bylokhov wrote:
> I doubt that support of null values in the data model is intentional 
> because JList is "A component that displays a list of *objects* and 
> allows the user to select one or more items."
>
> The null behavior was not specified and work in most cases because 
> some of the getXXX methods in ListModel sub-classes and JList have a 
> special meaning of null:
>
> JList.getSelectedValue(): Returns {@code null} if there is no selection.
> ListModel.getElementAt(int index): In most cases implemented to return 
> null if index is incorrect.
>
> Similar method TableModel.getValueAt(int,int) is also usually 
> implemented to return null if value is not found or some error occured.
>
> JComboBox.setSelectedItem(): use <code>null</code> to clear the selection
> ComboBoxModel.setSelectedItem(): <code>null</code> to clear the selection
> ComboBoxModel.getSelectedItem(): <code>null</code> if there is no 
> selection
>
> So I suggest to follow initial intention here, because it is too late 
> to add validation of the values.
> ?- The null value in get() will mean no-selection.
> ?- The null value passed to set() will clear selection.
>
> On 05/01/2018 02:15, Pankaj Bansal wrote:
>> Hi Semyon/Sergey,
>>
>> Yes, JList can contain null elements as it can be added to data 
>> model. I think this changes a lot in this bug. I think the selection 
>> needs to be cleared when the object passed is not present in the 
>> list, irrespective of it being null or not. I have made code changes. 
>> Please have a look.
>>
>> Webrev: http://cr.openjdk.java.net/~pbansal/5076761/webrev.02/
>>
>> Regards,
>> Pankaj Bansal
>>
>> -----Original Message-----
>> From: Semyon Sadetsky
>> Sent: Friday, January 5, 2018 6:59 AM
>> To: Pankaj Bansal; swing-dev at openjdk.java.net
>> Subject: Re: <Swing Dev> [11] Review Request: JDK-5076761 : 
>> JList.setSelectedValue(null, ...) doesn't do anything
>>
>> Hi Pankaj,
>>
>> Can JList contain null value?
>>
>> --Semyon
>>
>>
>> On 01/02/2018 11:26 PM, Pankaj Bansal wrote:
>>> Hi Sergey,
>>>
>>> Thanks for the review.
>>>
>>> I have made the suggested changes. Please have a look.
>>> webrev: http://cr.openjdk.java.net/~pbansal/5076761/webrev.01/
>>>
>>> Regards,
>>> Pankaj Bansal
>>>
>>>
>>> -----Original Message-----
>>> From: Sergey Bylokhov
>>> Sent: Wednesday, January 3, 2018 3:31 AM
>>> To: Pankaj Bansal; swing-dev at openjdk.java.net; Prasanta Sadhukhan
>>> Subject: Re: [11] Review Request: JDK-5076761 :
>>> JList.setSelectedValue(null, ...) doesn't do anything
>>>
>>> Hi, Pankaj.
>>> The fix looks fine, but I suggest to update the spec as well and 
>>> describe the behavior if "null" value is passed.
>>>
>>> On 02/01/2018 02:07, Pankaj Bansal wrote:
>>>> Hi All,
>>>>
>>>> Please review the fix for JDK 11.
>>>>
>>>> Bug:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-5076761
>>>>
>>>> Webrev:
>>>>
>>>> http://cr.openjdk.java.net/~pbansal/5076761/webrev.00/
>>>>
>>>> Issue:
>>>>
>>>> When setSelectedValue is called on JList with null object, it should
>>>> clear all selection. But it is not doing anything.
>>>>
>>>> Fix:
>>>>
>>>> In setSelectedValue if the object is null, the setSelectedIndex is
>>>> called with -1. but this does not clear the selection. We should be
>>>> calling clearSelection instead of SetSelectedIndex.
>>>>
>>>> Regards,
>>>>
>>>> Pankaj Bansal
>>>>
>>>
>>> -- 
>>> Best regards, Sergey.
>>
>
>



From Sergey.Bylokhov at oracle.com  Sat Jan  6 06:16:22 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 5 Jan 2018 22:16:22 -0800
Subject: <Swing Dev> [11] Review Request: JDK-5076761 :
 JList.setSelectedValue(null, ...) doesn't do anything
In-Reply-To: <fced1c2d-592a-f358-52dd-775b079d0d5f@oracle.com>
References: <417f68fe-4565-40b1-b360-e6ff9e18dd33@default>
 <da38a552-d357-b86d-399e-ba1b90fca79f@oracle.com>
 <d1d36b2a-1ca9-44ea-8e50-a819a20b7980@default>
 <6e0afc35-f779-7801-cfea-d0416f322db4@oracle.com>
 <e59b096d-a4ed-4ac8-ad0e-a891ac8fab0b@default>
 <010ef445-754d-520d-c78b-c87dd98ee8dd@oracle.com>
 <fced1c2d-592a-f358-52dd-775b079d0d5f@oracle.com>
Message-ID: <16167828-181b-60ca-c7c7-2f810f43cd88@oracle.com>

On 05/01/2018 18:01, Semyon Sadetsky wrote:
> Can you explain what is wrong with the suggested? approach?? It is 
> flexible to handle both null and non-null containing JList.

Because it is wrong direction try to support some approach which is 
undefined behavior. The null has a special meaning in 
JList.getSelectedValue/setSelectedValue() as well as in a few other 
methods mentioned below. The usage of unspecified null values may result 
in a run time exception either immediately or at some later time.

> 
> On 01/05/2018 04:25 PM, Sergey Bylokhov wrote:
>> I doubt that support of null values in the data model is intentional 
>> because JList is "A component that displays a list of *objects* and 
>> allows the user to select one or more items."
>>
>> The null behavior was not specified and work in most cases because 
>> some of the getXXX methods in ListModel sub-classes and JList have a 
>> special meaning of null:
>>
>> JList.getSelectedValue(): Returns {@code null} if there is no selection.
>> ListModel.getElementAt(int index): In most cases implemented to return 
>> null if index is incorrect.
>>
>> Similar method TableModel.getValueAt(int,int) is also usually 
>> implemented to return null if value is not found or some error occured.
>>
>> JComboBox.setSelectedItem(): use <code>null</code> to clear the selection
>> ComboBoxModel.setSelectedItem(): <code>null</code> to clear the selection
>> ComboBoxModel.getSelectedItem(): <code>null</code> if there is no 
>> selection
>>
>> So I suggest to follow initial intention here, because it is too late 
>> to add validation of the values.
>> ?- The null value in get() will mean no-selection.
>> ?- The null value passed to set() will clear selection.
>>
>> On 05/01/2018 02:15, Pankaj Bansal wrote:
>>> Hi Semyon/Sergey,
>>>
>>> Yes, JList can contain null elements as it can be added to data 
>>> model. I think this changes a lot in this bug. I think the selection 
>>> needs to be cleared when the object passed is not present in the 
>>> list, irrespective of it being null or not. I have made code changes. 
>>> Please have a look.
>>>
>>> Webrev: http://cr.openjdk.java.net/~pbansal/5076761/webrev.02/
>>>
>>> Regards,
>>> Pankaj Bansal
>>>
>>> -----Original Message-----
>>> From: Semyon Sadetsky
>>> Sent: Friday, January 5, 2018 6:59 AM
>>> To: Pankaj Bansal; swing-dev at openjdk.java.net
>>> Subject: Re: <Swing Dev> [11] Review Request: JDK-5076761 : 
>>> JList.setSelectedValue(null, ...) doesn't do anything
>>>
>>> Hi Pankaj,
>>>
>>> Can JList contain null value?
>>>
>>> --Semyon
>>>
>>>
>>> On 01/02/2018 11:26 PM, Pankaj Bansal wrote:
>>>> Hi Sergey,
>>>>
>>>> Thanks for the review.
>>>>
>>>> I have made the suggested changes. Please have a look.
>>>> webrev: http://cr.openjdk.java.net/~pbansal/5076761/webrev.01/
>>>>
>>>> Regards,
>>>> Pankaj Bansal
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Sergey Bylokhov
>>>> Sent: Wednesday, January 3, 2018 3:31 AM
>>>> To: Pankaj Bansal; swing-dev at openjdk.java.net; Prasanta Sadhukhan
>>>> Subject: Re: [11] Review Request: JDK-5076761 :
>>>> JList.setSelectedValue(null, ...) doesn't do anything
>>>>
>>>> Hi, Pankaj.
>>>> The fix looks fine, but I suggest to update the spec as well and 
>>>> describe the behavior if "null" value is passed.
>>>>
>>>> On 02/01/2018 02:07, Pankaj Bansal wrote:
>>>>> Hi All,
>>>>>
>>>>> Please review the fix for JDK 11.
>>>>>
>>>>> Bug:
>>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-5076761
>>>>>
>>>>> Webrev:
>>>>>
>>>>> http://cr.openjdk.java.net/~pbansal/5076761/webrev.00/
>>>>>
>>>>> Issue:
>>>>>
>>>>> When setSelectedValue is called on JList with null object, it should
>>>>> clear all selection. But it is not doing anything.
>>>>>
>>>>> Fix:
>>>>>
>>>>> In setSelectedValue if the object is null, the setSelectedIndex is
>>>>> called with -1. but this does not clear the selection. We should be
>>>>> calling clearSelection instead of SetSelectedIndex.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Pankaj Bansal
>>>>>
>>>>
>>>> -- 
>>>> Best regards, Sergey.
>>>
>>
>>
> 


-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Sat Jan  6 07:30:44 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 5 Jan 2018 23:30:44 -0800
Subject: <Swing Dev> [11] RFR JDK-8191106: Nimbus LookAndFeel does not
 apply keys FileChooser.directoryOpenButtonText/ToolTipText to JFileChooser
In-Reply-To: <f28aa56c-af7a-e5c4-d5c9-d0efca19457a@oracle.com>
References: <cba5c211-bc50-9e81-0141-1c0460b80070@oracle.com>
 <cba7509f-ab9c-894c-c5dd-06145b5ac112@oracle.com>
 <f28aa56c-af7a-e5c4-d5c9-d0efca19457a@oracle.com>
Message-ID: <01ecf34a-cc73-1e20-09c2-585e24a04be7@oracle.com>

On 04/01/2018 22:05, Prasanta Sadhukhan wrote:
> Hi Semyon,
> 
> It's not exactly the same. For Metal, we do not set mnemonic, not sure 
> if that is intentional, so did not push it down to basic class.

They were intentionally dropped: 
https://bugs.openjdk.java.net/browse/JDK-8080628

> 
> Regards
> Prasanta
> On 1/4/2018 9:34 PM, Semyon Sadetsky wrote:
>> Hi Prasanta,
>>
>> Since all those L&F's now have the same implementation of the method 
>> maybe it worth to push it down to the basic class?
>>
>> --Semyon
>>
>> On 01/04/2018 02:33 AM, Prasanta Sadhukhan wrote:
>>> Hi All,
>>>
>>> Please review a fix for Nimbus L&F where it is seen that
>>> When you select a directory in a JFileChooser dialog, the text and 
>>> tooltip of the "approve" button is not changing to the values of 
>>> UIManager keys FileChooser.directoryOpenButtonText and 
>>> FileChooser.directoryOpenButtonToolTipText and remain same as it was 
>>> before directory is selected.
>>> It changes for Metal and windows l&f.
>>>
>>> This is because when directory is selected 
>>> BasicFileChooserUI#valueChanged() calls setDirectorySelected() but 
>>> it's not implemented for nimbus l&f and it uses default 
>>> implementation of BasicFileChooser.
>>> For Metal & Windows, this method is overridden to change the approve 
>>> button text to FileChooser.directoryOpenButtonText.
>>> Propsosed fix is to override this method for Nimbus L&f and set the 
>>> approve button text to FileChooser.directoryOpenButtonText.
>>>
>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8191106
>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8191106/webrev.00/
>>>
>>> Regards
>>> Prasanta
>>>
>>
> 


-- 
Best regards, Sergey.


From pankaj.b.bansal at oracle.com  Sun Jan  7 08:25:27 2018
From: pankaj.b.bansal at oracle.com (Pankaj Bansal)
Date: Sun, 7 Jan 2018 00:25:27 -0800 (PST)
Subject: <Swing Dev> [11] Review Request: JDK-5076761 :
 JList.setSelectedValue(null, ...) doesn't do anything
In-Reply-To: <16167828-181b-60ca-c7c7-2f810f43cd88@oracle.com>
References: <417f68fe-4565-40b1-b360-e6ff9e18dd33@default>
 <da38a552-d357-b86d-399e-ba1b90fca79f@oracle.com>
 <d1d36b2a-1ca9-44ea-8e50-a819a20b7980@default>
 <6e0afc35-f779-7801-cfea-d0416f322db4@oracle.com>
 <e59b096d-a4ed-4ac8-ad0e-a891ac8fab0b@default>
 <010ef445-754d-520d-c78b-c87dd98ee8dd@oracle.com>
 <fced1c2d-592a-f358-52dd-775b079d0d5f@oracle.com>
 <16167828-181b-60ca-c7c7-2f810f43cd88@oracle.com>
Message-ID: <cf5adf58-ecc2-4d9d-a538-87f2c3b80eef@default>

Hi Sergey/Semyon,

>> So I suggest to follow initial intention here, because it is too late 
>> to add validation of the values.
>>  - The null value in get() will mean no-selection.
>>  - The null value passed to set() will clear selection.
So I assume we are going with our initial approach. 


<<Looks fine.
<<Please change the dates in the test header before the push. Note that you need to create a CSR request for the spec update.
The code changes are in following webrev. I have made the changes in dates in test header. I will raise a CSR.
Webrev: http://cr.openjdk.java.net/~pbansal/5076761/webrev.05/


Regards,
Pankaj Bansal

-----Original Message-----
From: Sergey Bylokhov 
Sent: Saturday, January 6, 2018 11:46 AM
To: Semyon Sadetsky; Pankaj Bansal; swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [11] Review Request: JDK-5076761 : JList.setSelectedValue(null, ...) doesn't do anything

On 05/01/2018 18:01, Semyon Sadetsky wrote:
> Can you explain what is wrong with the suggested? approach?? It is 
> flexible to handle both null and non-null containing JList.

Because it is wrong direction try to support some approach which is undefined behavior. The null has a special meaning in
JList.getSelectedValue/setSelectedValue() as well as in a few other methods mentioned below. The usage of unspecified null values may result in a run time exception either immediately or at some later time.

> 
> On 01/05/2018 04:25 PM, Sergey Bylokhov wrote:
>> I doubt that support of null values in the data model is intentional 
>> because JList is "A component that displays a list of *objects* and 
>> allows the user to select one or more items."
>>
>> The null behavior was not specified and work in most cases because 
>> some of the getXXX methods in ListModel sub-classes and JList have a 
>> special meaning of null:
>>
>> JList.getSelectedValue(): Returns {@code null} if there is no selection.
>> ListModel.getElementAt(int index): In most cases implemented to 
>> return null if index is incorrect.
>>
>> Similar method TableModel.getValueAt(int,int) is also usually 
>> implemented to return null if value is not found or some error occured.
>>
>> JComboBox.setSelectedItem(): use <code>null</code> to clear the 
>> selection
>> ComboBoxModel.setSelectedItem(): <code>null</code> to clear the 
>> selection
>> ComboBoxModel.getSelectedItem(): <code>null</code> if there is no 
>> selection
>>
>> So I suggest to follow initial intention here, because it is too late 
>> to add validation of the values.
>> ?- The null value in get() will mean no-selection.
>> ?- The null value passed to set() will clear selection.
>>
>> On 05/01/2018 02:15, Pankaj Bansal wrote:
>>> Hi Semyon/Sergey,
>>>
>>> Yes, JList can contain null elements as it can be added to data 
>>> model. I think this changes a lot in this bug. I think the selection 
>>> needs to be cleared when the object passed is not present in the 
>>> list, irrespective of it being null or not. I have made code changes.
>>> Please have a look.
>>>
>>> Webrev: http://cr.openjdk.java.net/~pbansal/5076761/webrev.02/
>>>
>>> Regards,
>>> Pankaj Bansal
>>>
>>> -----Original Message-----
>>> From: Semyon Sadetsky
>>> Sent: Friday, January 5, 2018 6:59 AM
>>> To: Pankaj Bansal; swing-dev at openjdk.java.net
>>> Subject: Re: <Swing Dev> [11] Review Request: JDK-5076761 : 
>>> JList.setSelectedValue(null, ...) doesn't do anything
>>>
>>> Hi Pankaj,
>>>
>>> Can JList contain null value?
>>>
>>> --Semyon
>>>
>>>
>>> On 01/02/2018 11:26 PM, Pankaj Bansal wrote:
>>>> Hi Sergey,
>>>>
>>>> Thanks for the review.
>>>>
>>>> I have made the suggested changes. Please have a look.
>>>> webrev: http://cr.openjdk.java.net/~pbansal/5076761/webrev.01/
>>>>
>>>> Regards,
>>>> Pankaj Bansal
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Sergey Bylokhov
>>>> Sent: Wednesday, January 3, 2018 3:31 AM
>>>> To: Pankaj Bansal; swing-dev at openjdk.java.net; Prasanta Sadhukhan
>>>> Subject: Re: [11] Review Request: JDK-5076761 :
>>>> JList.setSelectedValue(null, ...) doesn't do anything
>>>>
>>>> Hi, Pankaj.
>>>> The fix looks fine, but I suggest to update the spec as well and 
>>>> describe the behavior if "null" value is passed.
>>>>
>>>> On 02/01/2018 02:07, Pankaj Bansal wrote:
>>>>> Hi All,
>>>>>
>>>>> Please review the fix for JDK 11.
>>>>>
>>>>> Bug:
>>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-5076761
>>>>>
>>>>> Webrev:
>>>>>
>>>>> http://cr.openjdk.java.net/~pbansal/5076761/webrev.00/
>>>>>
>>>>> Issue:
>>>>>
>>>>> When setSelectedValue is called on JList with null object, it 
>>>>> should clear all selection. But it is not doing anything.
>>>>>
>>>>> Fix:
>>>>>
>>>>> In setSelectedValue if the object is null, the setSelectedIndex is 
>>>>> called with -1. but this does not clear the selection. We should 
>>>>> be calling clearSelection instead of SetSelectedIndex.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Pankaj Bansal
>>>>>
>>>>
>>>> --
>>>> Best regards, Sergey.
>>>
>>
>>
> 


--
Best regards, Sergey.


From manajit.halder at oracle.com  Mon Jan  8 09:40:44 2018
From: manajit.halder at oracle.com (Manajit Halder)
Date: Mon, 8 Jan 2018 15:10:44 +0530
Subject: <Swing Dev> Swing dev>[10] Review request for JDK-8189253:
 [macos] JPopupMenu is inadvertently shown when using setComponentPopupMenu
In-Reply-To: <f7627a88-4d81-7105-59a0-fdf6872b62f2@oracle.com>
References: <E1445698-445B-4542-98C1-1D82A4A182C9@oracle.com>
 <4ed5cbcf-c1f7-f615-6404-ebe13c47b8da@oracle.com>
 <C77A97FC-2163-455F-847D-C590D3B5D522@oracle.com>
 <bcd060d3-4553-55f5-4fee-b22d6313426e@oracle.com>
 <F10C8291-1722-4618-B2B5-C2DB14E7486C@oracle.com>
 <f7627a88-4d81-7105-59a0-fdf6872b62f2@oracle.com>
Message-ID: <BE2F9413-3948-4BCF-A52D-F18E46AD7834@oracle.com>

Hi Semyon,

I could not reproduce the behaviour on Mac as on Mac this operation is not possible and hence it won?t be a problem on Mac. It is not possible to press the right button or the left button when the other button is already pressed using both Mouse provided by Apple and Track pad. Once the left button is pressed it need to be release to press the right button and vice versa. 

Thanks,
Manajit

> On 05-Jan-2018, at 7:08 AM, Semyon Sadetsky <semyon.sadetsky at oracle.com> wrote:
> 
> Hi Manajit,
> 
> I could reproduce similar behaviour on Linux when mouse is dragged to another component with the left button pressed and then the right button is immediately  pressed. The popup is triggered by the same logic despite it isn't configured for the component. 
> --Semyon
> 
> On 01/04/2018 10:22 AM, Manajit Halder wrote:
>> Hi Semyon,
>> 
>> Fix for issue JDK-8080729 <https://bugs.openjdk.java.net/browse/JDK-8080729> has caused this regression due to changes in method setVisible(boolean visible) in file CPlatformWindow.java
>> orderWindow is causing the issue here, if we revert to addChildWindow then the issue is not observed but then the fix for issue JDK-8080729 fails.
>> Before this change the child window used to be added on to the parent as shown below in the commented code. But after the change child window is ordered above the parent.
>> 
>> Below code causes the regression:
>> 
>> CWrapper.NSWindow.orderWindow(ptr, CWrapper.NSWindow.NSWindowAbove, ownerPtr);
>> //CWrapper.NSWindow.addChildWindow(ownerPtr, ptr, CWrapper.NSWindow.NSWindowAbove);
>> 
>> Debugging further I found that if we use orderWindow then the new window is considered as new graphics device in the method notifyReshape in LWWindowPeer.java (the method updateGraphicsDevice() returns true) and is the difference between using orderWindow and addChildWindow.
>> 
>> Since the option to add child window is between choosing oderWindow and addChildWindow we don?t have any option to do the fix in the Mac OS native code.
>> 
>> Regards,
>> Manajit
>> 
>> 
>>> On 02-Jan-2018, at 11:30 PM, Semyon Sadetsky <semyon.sadetsky at oracle.com <mailto:semyon.sadetsky at oracle.com>> wrote:
>>> 
>>> Hi Manajit,
>>> 
>>> JDK-8080729 bug was Mac OS specific issue and its fix changed the Mac OS code only. Nevertheless you are suggesting to fix the regression in generic code. This need to be explained somehow.
>>> 
>>> --Semyon
>>> On 12/25/2017 02:42 AM, Manajit Halder wrote:
>>>> Hi Semyon,
>>>> 
>>>> Regression is cause by JDK-8080729 <https://bugs.openjdk.java.net/browse/JDK-8080729>. The fix can?t be reversed since it is the choice between addChildWindow or orderWindow. Went through code flow related to the issue but didn?t find any other better place in code to handle this issue. The best way to fix the issue would be to avoid retargeting of events (MOUSE_ENTER and MOUSE_EXIT) between MOUSE_PRESS and MOUSE_RELEASE on the parent window (when the mouse is actually on the child window). Therefore request you to review the webrev.00.
>>>> 
>>>> Regards,
>>>> Manajit
>>>> 
>>>>> On 08-Dec-2017, at 9:55 PM, semyon.sadetsky at oracle.com <mailto:semyon.sadetsky at oracle.com> wrote:
>>>>> 
>>>>> Hi Manajit,
>>>>> 
>>>>> Can you provide information which fix caused the regression?
>>>>> 
>>>>> --Semyon
>>>>> 
>>>>> On 12/8/17 5:53 AM, Manajit Halder wrote:
>>>>>> Hi All,
>>>>>> 
>>>>>> Kindly review the following Swing fix.
>>>>>> 
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8189253 <https://bugs.openjdk.java.net/browse/JDK-8189253>
>>>>>> Webrev: http://cr.openjdk.java.net/~mhalder/8189253/webrev.00/ <http://cr.openjdk.java.net/%7Emhalder/8189253/webrev.00/>
>>>>>> 
>>>>>> Cause: 
>>>>>> 	Issue was due to retargeting of mouse enter exit events. 
>>>>>> 	MOUSE_ENTER and MOUSE_EXIT events were sent on the parent window (JFrame) in between MOUSE_PRESS and MOUSE_RELEASE events on the modeless JDialog.
>>>>>> 
>>>>>> Fix:
>>>>>> 	Retargeting of events is not done in-between MOUSE_PRESS and MOUSE_RELEASE.
>>>>>> 
>>>>>> Regards,
>>>>>> Manajit
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 

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

From semyon.sadetsky at oracle.com  Mon Jan  8 16:25:44 2018
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Mon, 8 Jan 2018 08:25:44 -0800
Subject: <Swing Dev> [11] Review Request: JDK-5076761 :
 JList.setSelectedValue(null, ...) doesn't do anything
In-Reply-To: <16167828-181b-60ca-c7c7-2f810f43cd88@oracle.com>
References: <417f68fe-4565-40b1-b360-e6ff9e18dd33@default>
 <da38a552-d357-b86d-399e-ba1b90fca79f@oracle.com>
 <d1d36b2a-1ca9-44ea-8e50-a819a20b7980@default>
 <6e0afc35-f779-7801-cfea-d0416f322db4@oracle.com>
 <e59b096d-a4ed-4ac8-ad0e-a891ac8fab0b@default>
 <010ef445-754d-520d-c78b-c87dd98ee8dd@oracle.com>
 <fced1c2d-592a-f358-52dd-775b079d0d5f@oracle.com>
 <16167828-181b-60ca-c7c7-2f810f43cd88@oracle.com>
Message-ID: <70ad5094-e10d-65ba-f507-0d79f987a2b6@oracle.com>

On 01/05/2018 10:16 PM, Sergey Bylokhov wrote:

> On 05/01/2018 18:01, Semyon Sadetsky wrote:
>> Can you explain what is wrong with the suggested? approach?? It is 
>> flexible to handle both null and non-null containing JList.
>
> Because it is wrong direction try to support some approach which is 
> undefined behavior. The null has a special meaning in 
> JList.getSelectedValue/setSelectedValue() as well as in a few other 
> methods mentioned below. The usage of unspecified null values may 
> result in a run time exception either immediately or at some later time.
I didn't find any spec that mentions null as a special value as well as 
any pointer that JList couldn't contain null.
getSelectedValue() may not be an indicator because there are several 
replacements setSelectedIndex(), setSelectedIndices(), 
getSelectedValues(), getSelectedValuesList() which supports null.
Other components are unrelated.
>
>>
>> On 01/05/2018 04:25 PM, Sergey Bylokhov wrote:
>>> I doubt that support of null values in the data model is intentional 
>>> because JList is "A component that displays a list of *objects* and 
>>> allows the user to select one or more items."
>>>
>>> The null behavior was not specified and work in most cases because 
>>> some of the getXXX methods in ListModel sub-classes and JList have a 
>>> special meaning of null:
>>>
>>> JList.getSelectedValue(): Returns {@code null} if there is no 
>>> selection.
>>> ListModel.getElementAt(int index): In most cases implemented to 
>>> return null if index is incorrect.
>>>
>>> Similar method TableModel.getValueAt(int,int) is also usually 
>>> implemented to return null if value is not found or some error occured.
>>>
>>> JComboBox.setSelectedItem(): use <code>null</code> to clear the 
>>> selection
>>> ComboBoxModel.setSelectedItem(): <code>null</code> to clear the 
>>> selection
>>> ComboBoxModel.getSelectedItem(): <code>null</code> if there is no 
>>> selection
>>>
>>> So I suggest to follow initial intention here, because it is too 
>>> late to add validation of the values.
>>> ?- The null value in get() will mean no-selection.
>>> ?- The null value passed to set() will clear selection.
>>>
>>> On 05/01/2018 02:15, Pankaj Bansal wrote:
>>>> Hi Semyon/Sergey,
>>>>
>>>> Yes, JList can contain null elements as it can be added to data 
>>>> model. I think this changes a lot in this bug. I think the 
>>>> selection needs to be cleared when the object passed is not present 
>>>> in the list, irrespective of it being null or not. I have made code 
>>>> changes. Please have a look.
>>>>
>>>> Webrev: http://cr.openjdk.java.net/~pbansal/5076761/webrev.02/
>>>>
>>>> Regards,
>>>> Pankaj Bansal
>>>>
>>>> -----Original Message-----
>>>> From: Semyon Sadetsky
>>>> Sent: Friday, January 5, 2018 6:59 AM
>>>> To: Pankaj Bansal; swing-dev at openjdk.java.net
>>>> Subject: Re: <Swing Dev> [11] Review Request: JDK-5076761 : 
>>>> JList.setSelectedValue(null, ...) doesn't do anything
>>>>
>>>> Hi Pankaj,
>>>>
>>>> Can JList contain null value?
>>>>
>>>> --Semyon
>>>>
>>>>
>>>> On 01/02/2018 11:26 PM, Pankaj Bansal wrote:
>>>>> Hi Sergey,
>>>>>
>>>>> Thanks for the review.
>>>>>
>>>>> I have made the suggested changes. Please have a look.
>>>>> webrev: http://cr.openjdk.java.net/~pbansal/5076761/webrev.01/
>>>>>
>>>>> Regards,
>>>>> Pankaj Bansal
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Sergey Bylokhov
>>>>> Sent: Wednesday, January 3, 2018 3:31 AM
>>>>> To: Pankaj Bansal; swing-dev at openjdk.java.net; Prasanta Sadhukhan
>>>>> Subject: Re: [11] Review Request: JDK-5076761 :
>>>>> JList.setSelectedValue(null, ...) doesn't do anything
>>>>>
>>>>> Hi, Pankaj.
>>>>> The fix looks fine, but I suggest to update the spec as well and 
>>>>> describe the behavior if "null" value is passed.
>>>>>
>>>>> On 02/01/2018 02:07, Pankaj Bansal wrote:
>>>>>> Hi All,
>>>>>>
>>>>>> Please review the fix for JDK 11.
>>>>>>
>>>>>> Bug:
>>>>>>
>>>>>> https://bugs.openjdk.java.net/browse/JDK-5076761
>>>>>>
>>>>>> Webrev:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~pbansal/5076761/webrev.00/
>>>>>>
>>>>>> Issue:
>>>>>>
>>>>>> When setSelectedValue is called on JList with null object, it should
>>>>>> clear all selection. But it is not doing anything.
>>>>>>
>>>>>> Fix:
>>>>>>
>>>>>> In setSelectedValue if the object is null, the setSelectedIndex is
>>>>>> called with -1. but this does not clear the selection. We should be
>>>>>> calling clearSelection instead of SetSelectedIndex.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Pankaj Bansal
>>>>>>
>>>>>
>>>>> -- 
>>>>> Best regards, Sergey.
>>>>
>>>
>>>
>>
>
>



From semyon.sadetsky at oracle.com  Mon Jan  8 16:36:43 2018
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Mon, 8 Jan 2018 08:36:43 -0800
Subject: <Swing Dev> Swing dev>[10] Review request for JDK-8189253:
 [macos] JPopupMenu is inadvertently shown when using setComponentPopupMenu
In-Reply-To: <BE2F9413-3948-4BCF-A52D-F18E46AD7834@oracle.com>
References: <E1445698-445B-4542-98C1-1D82A4A182C9@oracle.com>
 <4ed5cbcf-c1f7-f615-6404-ebe13c47b8da@oracle.com>
 <C77A97FC-2163-455F-847D-C590D3B5D522@oracle.com>
 <bcd060d3-4553-55f5-4fee-b22d6313426e@oracle.com>
 <F10C8291-1722-4618-B2B5-C2DB14E7486C@oracle.com>
 <f7627a88-4d81-7105-59a0-fdf6872b62f2@oracle.com>
 <BE2F9413-3948-4BCF-A52D-F18E46AD7834@oracle.com>
Message-ID: <6724f7b1-94c0-742b-081b-47dde62426b3@oracle.com>

Hi Manajit,

Still didn't get why are you limited to Mac platform? only while you 
change updates generic code. Why mouse provided by Apple matters here?

--Semyon


On 01/08/2018 01:40 AM, Manajit Halder wrote:
> Hi Semyon,
>
> I could not reproduce the behaviour on Mac as on Mac this operation is 
> not possible and hence it won?t be a problem on Mac. It is not 
> possible to press the right button or the left button when the other 
> button is already pressed using both Mouse provided by Apple and Track 
> pad. Once the left button is pressed it need to be release to press 
> the right button and vice versa.
>
> Thanks,
> Manajit
>
>> On 05-Jan-2018, at 7:08 AM, Semyon Sadetsky 
>> <semyon.sadetsky at oracle.com <mailto:semyon.sadetsky at oracle.com>> wrote:
>>
>> Hi Manajit,
>>
>> I could reproduce similar behaviour on Linux when mouse is dragged to 
>> another component with the left button pressed and then the right 
>> button is immediately? pressed. The popup is triggered by the same 
>> logic despite it isn't configured for the component.
>>
>> --Semyon
>>
>> On 01/04/2018 10:22 AM, Manajit Halder wrote:
>>> Hi Semyon,
>>>
>>> Fix for issue JDK-8080729 
>>> <https://bugs.openjdk.java.net/browse/JDK-8080729> has caused this 
>>> regression due to changes in method setVisible(boolean visible) in 
>>> file CPlatformWindow.java
>>> orderWindow is causing the issue here, if we revert to 
>>> addChildWindow then the issue is not observed but then the fix for 
>>> issue JDK-8080729 fails.
>>> Before this change the child window used to be added on to the 
>>> parent as shown below in the commented code. But after the change 
>>> child window is ordered above the parent.
>>>
>>> Below code causes the regression:
>>>
>>> *CWrapper.NSWindow.orderWindow(ptr, CWrapper.NSWindow.NSWindowAbove, 
>>> ownerPtr);*
>>> *//CWrapper.NSWindow.addChildWindow(ownerPtr, ptr, 
>>> CWrapper.NSWindow.NSWindowAbove);*
>>>
>>> Debugging further I found that if we use orderWindow then the new 
>>> window is considered as new graphics device in the method 
>>> notifyReshape in LWWindowPeer.java (the method 
>>> updateGraphicsDevice() returns true) and is the difference between 
>>> using orderWindow and addChildWindow.
>>>
>>> Since the option to add child window is between choosing oderWindow 
>>> and addChildWindow we don?t have any option to do the fix in the Mac 
>>> OS native code.
>>>
>>> Regards,
>>> Manajit
>>>
>>>
>>>> On 02-Jan-2018, at 11:30 PM, Semyon Sadetsky 
>>>> <semyon.sadetsky at oracle.com <mailto:semyon.sadetsky at oracle.com>> wrote:
>>>>
>>>> Hi Manajit,
>>>>
>>>> JDK-8080729 bug was Mac OS specific issue and its fix changed the 
>>>> Mac OS code only. Nevertheless you are suggesting to fix the 
>>>> regression in generic code. This need to be explained somehow.
>>>>
>>>> --Semyon
>>>>
>>>> On 12/25/2017 02:42 AM, Manajit Halder wrote:
>>>>> Hi Semyon,
>>>>>
>>>>> Regression is cause by JDK-8080729 
>>>>> <https://bugs.openjdk.java.net/browse/JDK-8080729>. The fix can?t 
>>>>> be reversed since it is the?choice between addChildWindow or 
>>>>> orderWindow. Went through code flow related to the issue 
>>>>> but?didn?t find any other better place in code to handle this 
>>>>> issue. The best way to fix the issue would be to avoid retargeting 
>>>>> of events (MOUSE_ENTER and MOUSE_EXIT) between MOUSE_PRESS and 
>>>>> MOUSE_RELEASE on the parent window (when the mouse is actually on 
>>>>> the child window). Therefore request you to review the webrev.00.
>>>>>
>>>>> Regards,
>>>>> Manajit
>>>>>
>>>>>> On 08-Dec-2017, at 9:55 PM, semyon.sadetsky at oracle.com 
>>>>>> <mailto:semyon.sadetsky at oracle.com> wrote:
>>>>>>
>>>>>> Hi Manajit,
>>>>>>
>>>>>> Can you provide information which fix caused the regression?
>>>>>>
>>>>>> --Semyon
>>>>>>
>>>>>>
>>>>>> On 12/8/17 5:53 AM, Manajit Halder wrote:
>>>>>>> Hi All,
>>>>>>>
>>>>>>> Kindly review the following Swing fix.
>>>>>>>
>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8189253
>>>>>>> Webrev: http://cr.openjdk.java.net/~mhalder/8189253/webrev.00/ 
>>>>>>> <http://cr.openjdk.java.net/%7Emhalder/8189253/webrev.00/>
>>>>>>>
>>>>>>> Cause:
>>>>>>> Issue was due to retargeting of mouse enter exit events.
>>>>>>> MOUSE_ENTER and MOUSE_EXIT events were sent on the parent window 
>>>>>>> (JFrame) in between MOUSE_PRESS and MOUSE_RELEASE events on the 
>>>>>>> modeless JDialog.
>>>>>>>
>>>>>>> Fix:
>>>>>>> Retargeting of events is not done in-between MOUSE_PRESS and 
>>>>>>> MOUSE_RELEASE.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Manajit
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

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

From krishna.addepalli at oracle.com  Tue Jan  9 09:00:12 2018
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Tue, 9 Jan 2018 01:00:12 -0800 (PST)
Subject: <Swing Dev> [10][11][JDK-8194044] Regression manual Test
 javax/swing/JFileChooser/8067660/FileChooserTest.java fails
In-Reply-To: <9471d86d-c59b-53b9-0b6c-4c2a9b8555a7@oracle.com>
References: <91a8f44e-a18c-43f5-96b8-ab310399c348@default>
 <fb48167a-d960-f5c9-ad2e-92199ee47a39@oracle.com>
 <db9ba389-e151-4307-9fd1-e30adcf93234@default>
 <9471d86d-c59b-53b9-0b6c-4c2a9b8555a7@oracle.com>
Message-ID: <c5b84c78-b7c9-4ff8-afc6-b3d05f47c30c@default>

Hi Prasanta,Sergey,

 

I have added a testcase along with the changes and created a new webrev : http://cr.openjdk.java.net/~kaddepalli/8194044/webrev01/

 

Please review this and provide your comments.

 

Thanks,

Krishna

 

From: Prasanta Sadhukhan 
Sent: Thursday, January 4, 2018 10:54 AM
To: Krishna Addepalli <krishna.addepalli at oracle.com>; swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10][11][JDK-8194044] Regression manual Test javax/swing/JFileChooser/8067660/FileChooserTest.java fails

 

A regression test is added to prove that before your fix, java was failing and after your fix is applied, it is passing so it is not related to older/newer java versions. I saw we already have test/jdk/javax/swing/JFileChooser/6945316/bug6945316.java which tests isFileSystemRoot. Maybe, we can do something similar if it's not too much of a task.

Regards
Prasanta

On 1/3/2018 5:13 PM, Krishna Addepalli wrote:

Thanks for the review Prasanta. However, I don't see a point to write a test case for isFileSystemRoot(), since, it is not going to fail on any (older/newer) java versions, and it was only introduced because of the fix for JDK-8175015.

Let me know if you think otherwise.

 

Regards,

Krishna

From: Prasanta Sadhukhan 
Sent: Wednesday, January 3, 2018 11:27 AM
To: Krishna Addepalli HYPERLINK "mailto:krishna.addepalli at oracle.com"<krishna.addepalli at oracle.com>; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10][11][JDK-8194044] Regression manual Test javax/swing/JFileChooser/8067660/FileChooserTest.java fails

 

Fix looks fine. But I guess, it is possible to add a automated regression test to it utilising isFileSystemRoot().

Regards
Prasanta

On 1/2/2018 4:31 PM, Krishna Addepalli wrote:

Hi All,

 

Please review a fix for bug:

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

Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Ekaddepalli/8194044/webrev00/"http://cr.openjdk.java.net/~kaddepalli/8194044/webrev00/

 

This was caused due to the fix for JDK-8175015, in which the line 446  in Win32ShellFolderManager2.java was changed from "getDrives()" to Win32ShellFolder2.listRoots().

While the earlier function returns an object of Win32ShellFolder2, the latter returns an array of Files. 

The condition on line 450: "return (sf.isFileSystem()&&sf.parent != null && sf.parent.equals(Win32ShellFolder2.listRoots())" was returning false because of the wrong object being passed. Earlier it was a Win32ShellFolder2 object, and the comparision was done properly, but with the changes, the equals fucnction was receiving a file array object, and hence it was immediately returning false, leading to the problem of empty strings being shown for Root drives.

The fix is to replace "Win32ShellFolder2.listRoots()" with "getDrives()" function. With this fix, the regression is addressed, as well as the original JDK-8175015 which was a memory leak issue.

 

Thanks,

Krishna

 

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

From jayathirth.d.v at oracle.com  Wed Jan 10 10:45:41 2018
From: jayathirth.d.v at oracle.com (Jayathirth D V)
Date: Wed, 10 Jan 2018 02:45:41 -0800 (PST)
Subject: <Swing Dev> [10][11][JDK-8194044] Regression manual Test
 javax/swing/JFileChooser/8067660/FileChooserTest.java fails
In-Reply-To: <c5b84c78-b7c9-4ff8-afc6-b3d05f47c30c@default>
References: <91a8f44e-a18c-43f5-96b8-ab310399c348@default>
 <fb48167a-d960-f5c9-ad2e-92199ee47a39@oracle.com>
 <db9ba389-e151-4307-9fd1-e30adcf93234@default>
 <9471d86d-c59b-53b9-0b6c-4c2a9b8555a7@oracle.com>
 <c5b84c78-b7c9-4ff8-afc6-b3d05f47c30c@default>
Message-ID: <d4cb6190-f03c-4c68-95aa-12fb07e7e89e@default>

Hi Krishna,

 

Please find my inputs:

 

Test case needs to be updated with minor changes:

 

1)      Copyright information needs to be added at the start of test file.

2)      Jtreg test summary needs to be updated to mention what the test is trying to achieve instead of JBS bug title.

3)      Also since this test is specific to Windows we can remove the OS test code present in test case with Jtreg @requires flag:

 

Instead of using the below code we can use @requires (os.family == "windows")

 

            if (OSInfo.getOSType() != OSInfo.OSType.WINDOWS) {

                                         System.out.println("The test is suitable only for Windows OS. Skipped.");

                                         return;

                    }

4)      For multiline comments at Line no 1 & 26 in test case please update the comment syntax to use :

/*

 *

 *

 */

 

Thanks,

Jay

 

From: Krishna Addepalli 
Sent: Tuesday, January 09, 2018 2:30 PM
To: Prasanta Sadhukhan; swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10][11][JDK-8194044] Regression manual Test javax/swing/JFileChooser/8067660/FileChooserTest.java fails

 

Hi Prasanta,Sergey,

 

I have added a testcase along with the changes and created a new webrev : http://cr.openjdk.java.net/~kaddepalli/8194044/webrev01/

 

Please review this and provide your comments.

 

Thanks,

Krishna

 

From: Prasanta Sadhukhan 
Sent: Thursday, January 4, 2018 10:54 AM
To: Krishna Addepalli <HYPERLINK "mailto:krishna.addepalli at oracle.com"krishna.addepalli at oracle.com>; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10][11][JDK-8194044] Regression manual Test javax/swing/JFileChooser/8067660/FileChooserTest.java fails

 

A regression test is added to prove that before your fix, java was failing and after your fix is applied, it is passing so it is not related to older/newer java versions. I saw we already have test/jdk/javax/swing/JFileChooser/6945316/bug6945316.java which tests isFileSystemRoot. Maybe, we can do something similar if it's not too much of a task.

Regards
Prasanta

On 1/3/2018 5:13 PM, Krishna Addepalli wrote:

Thanks for the review Prasanta. However, I don't see a point to write a test case for isFileSystemRoot(), since, it is not going to fail on any (older/newer) java versions, and it was only introduced because of the fix for JDK-8175015.

Let me know if you think otherwise.

 

Regards,

Krishna

From: Prasanta Sadhukhan 
Sent: Wednesday, January 3, 2018 11:27 AM
To: Krishna Addepalli HYPERLINK "mailto:krishna.addepalli at oracle.com"<krishna.addepalli at oracle.com>; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10][11][JDK-8194044] Regression manual Test javax/swing/JFileChooser/8067660/FileChooserTest.java fails

 

Fix looks fine. But I guess, it is possible to add a automated regression test to it utilising isFileSystemRoot().

Regards
Prasanta

On 1/2/2018 4:31 PM, Krishna Addepalli wrote:

Hi All,

 

Please review a fix for bug:

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

Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Ekaddepalli/8194044/webrev00/"http://cr.openjdk.java.net/~kaddepalli/8194044/webrev00/

 

This was caused due to the fix for JDK-8175015, in which the line 446  in Win32ShellFolderManager2.java was changed from "getDrives()" to Win32ShellFolder2.listRoots().

While the earlier function returns an object of Win32ShellFolder2, the latter returns an array of Files. 

The condition on line 450: "return (sf.isFileSystem()&&sf.parent != null && sf.parent.equals(Win32ShellFolder2.listRoots())" was returning false because of the wrong object being passed. Earlier it was a Win32ShellFolder2 object, and the comparision was done properly, but with the changes, the equals fucnction was receiving a file array object, and hence it was immediately returning false, leading to the problem of empty strings being shown for Root drives.

The fix is to replace "Win32ShellFolder2.listRoots()" with "getDrives()" function. With this fix, the regression is addressed, as well as the original JDK-8175015 which was a memory leak issue.

 

Thanks,

Krishna

 

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

From krishna.addepalli at oracle.com  Wed Jan 10 12:29:35 2018
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Wed, 10 Jan 2018 04:29:35 -0800 (PST)
Subject: <Swing Dev> [10][11][JDK-8194044] Regression manual Test
 javax/swing/JFileChooser/8067660/FileChooserTest.java fails
In-Reply-To: <d4cb6190-f03c-4c68-95aa-12fb07e7e89e@default>
References: <91a8f44e-a18c-43f5-96b8-ab310399c348@default>
 <fb48167a-d960-f5c9-ad2e-92199ee47a39@oracle.com>
 <db9ba389-e151-4307-9fd1-e30adcf93234@default>
 <9471d86d-c59b-53b9-0b6c-4c2a9b8555a7@oracle.com>
 <c5b84c78-b7c9-4ff8-afc6-b3d05f47c30c@default>
 <d4cb6190-f03c-4c68-95aa-12fb07e7e89e@default>
Message-ID: <6ce77bb1-d3a6-41b7-a646-2eb0c9e2d042@default>

Hi Jay,

 

Thanks for your time and review. I have incorporated your review comments and created a new webrev here: http://cr.openjdk.java.net/~kaddepalli/8194044/webrev02/

 

Thanks,

Krishna

 

From: Jayathirth D V 
Sent: Wednesday, January 10, 2018 4:16 PM
To: Krishna Addepalli <krishna.addepalli at oracle.com>; swing-dev at openjdk.java.net
Subject: RE: <Swing Dev> [10][11][JDK-8194044] Regression manual Test javax/swing/JFileChooser/8067660/FileChooserTest.java fails

 

Hi Krishna,

 

Please find my inputs:

 

Test case needs to be updated with minor changes:

 

1)      Copyright information needs to be added at the start of test file.

2)      Jtreg test summary needs to be updated to mention what the test is trying to achieve instead of JBS bug title.

3)      Also since this test is specific to Windows we can remove the OS test code present in test case with Jtreg @requires flag:

 

Instead of using the below code we can use @requires (os.family == "windows")

 

            if (OSInfo.getOSType() != OSInfo.OSType.WINDOWS) {

                                         System.out.println("The test is suitable only for Windows OS. Skipped.");

                                         return;

                    }

4)      For multiline comments at Line no 1 & 26 in test case please update the comment syntax to use :

/*

 *

 *

 */

 

Thanks,

Jay

 

From: Krishna Addepalli 
Sent: Tuesday, January 09, 2018 2:30 PM
To: Prasanta Sadhukhan; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10][11][JDK-8194044] Regression manual Test javax/swing/JFileChooser/8067660/FileChooserTest.java fails

 

Hi Prasanta,Sergey,

 

I have added a testcase along with the changes and created a new webrev : http://cr.openjdk.java.net/~kaddepalli/8194044/webrev01/

 

Please review this and provide your comments.

 

Thanks,

Krishna

 

From: Prasanta Sadhukhan 
Sent: Thursday, January 4, 2018 10:54 AM
To: Krishna Addepalli <HYPERLINK "mailto:krishna.addepalli at oracle.com"krishna.addepalli at oracle.com>; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10][11][JDK-8194044] Regression manual Test javax/swing/JFileChooser/8067660/FileChooserTest.java fails

 

A regression test is added to prove that before your fix, java was failing and after your fix is applied, it is passing so it is not related to older/newer java versions. I saw we already have test/jdk/javax/swing/JFileChooser/6945316/bug6945316.java which tests isFileSystemRoot. Maybe, we can do something similar if it's not too much of a task.

Regards
Prasanta

On 1/3/2018 5:13 PM, Krishna Addepalli wrote:

Thanks for the review Prasanta. However, I don't see a point to write a test case for isFileSystemRoot(), since, it is not going to fail on any (older/newer) java versions, and it was only introduced because of the fix for JDK-8175015.

Let me know if you think otherwise.

 

Regards,

Krishna

From: Prasanta Sadhukhan 
Sent: Wednesday, January 3, 2018 11:27 AM
To: Krishna Addepalli HYPERLINK "mailto:krishna.addepalli at oracle.com"<krishna.addepalli at oracle.com>; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10][11][JDK-8194044] Regression manual Test javax/swing/JFileChooser/8067660/FileChooserTest.java fails

 

Fix looks fine. But I guess, it is possible to add a automated regression test to it utilising isFileSystemRoot().

Regards
Prasanta

On 1/2/2018 4:31 PM, Krishna Addepalli wrote:

Hi All,

 

Please review a fix for bug:

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

Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Ekaddepalli/8194044/webrev00/"http://cr.openjdk.java.net/~kaddepalli/8194044/webrev00/

 

This was caused due to the fix for JDK-8175015, in which the line 446  in Win32ShellFolderManager2.java was changed from "getDrives()" to Win32ShellFolder2.listRoots().

While the earlier function returns an object of Win32ShellFolder2, the latter returns an array of Files. 

The condition on line 450: "return (sf.isFileSystem()&&sf.parent != null && sf.parent.equals(Win32ShellFolder2.listRoots())" was returning false because of the wrong object being passed. Earlier it was a Win32ShellFolder2 object, and the comparision was done properly, but with the changes, the equals fucnction was receiving a file array object, and hence it was immediately returning false, leading to the problem of empty strings being shown for Root drives.

The fix is to replace "Win32ShellFolder2.listRoots()" with "getDrives()" function. With this fix, the regression is addressed, as well as the original JDK-8175015 which was a memory leak issue.

 

Thanks,

Krishna

 

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

From jayathirth.d.v at oracle.com  Wed Jan 10 12:47:34 2018
From: jayathirth.d.v at oracle.com (Jayathirth D V)
Date: Wed, 10 Jan 2018 04:47:34 -0800 (PST)
Subject: <Swing Dev> [10][11][JDK-8194044] Regression manual Test
 javax/swing/JFileChooser/8067660/FileChooserTest.java fails
In-Reply-To: <6ce77bb1-d3a6-41b7-a646-2eb0c9e2d042@default>
References: <91a8f44e-a18c-43f5-96b8-ab310399c348@default>
 <fb48167a-d960-f5c9-ad2e-92199ee47a39@oracle.com>
 <db9ba389-e151-4307-9fd1-e30adcf93234@default>
 <9471d86d-c59b-53b9-0b6c-4c2a9b8555a7@oracle.com>
 <c5b84c78-b7c9-4ff8-afc6-b3d05f47c30c@default>
 <d4cb6190-f03c-4c68-95aa-12fb07e7e89e@default>
 <6ce77bb1-d3a6-41b7-a646-2eb0c9e2d042@default>
Message-ID: <a1cb5598-7898-42a1-956e-dac8cef938bd@default>

Hi Krishna,

 

Please find my inputs:

 

1)      There is no need for Starting and Ending year in copyright of test case as it is a new file. Adding just 2018 would be enough. 

2)      Typo in jtreg summary : "Test if" it should be "Tests if".

3)      For multiline comments using /*..*/,  First line should be left empty in a block comment at Line no 24 & 42 and last line of block comment should have proper indentation at Line no 30. Java coding convention for comments : http://www.oracle.com/technetwork/java/codeconventions-141999.html 

 

Thanks,

Jay

 

From: Krishna Addepalli 
Sent: Wednesday, January 10, 2018 6:00 PM
To: Jayathirth D V; swing-dev at openjdk.java.net
Subject: RE: <Swing Dev> [10][11][JDK-8194044] Regression manual Test javax/swing/JFileChooser/8067660/FileChooserTest.java fails

 

Hi Jay,

 

Thanks for your time and review. I have incorporated your review comments and created a new webrev here: http://cr.openjdk.java.net/~kaddepalli/8194044/webrev02/

 

Thanks,

Krishna

 

From: Jayathirth D V 
Sent: Wednesday, January 10, 2018 4:16 PM
To: Krishna Addepalli <HYPERLINK "mailto:krishna.addepalli at oracle.com"krishna.addepalli at oracle.com>; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: RE: <Swing Dev> [10][11][JDK-8194044] Regression manual Test javax/swing/JFileChooser/8067660/FileChooserTest.java fails

 

Hi Krishna,

 

Please find my inputs:

 

Test case needs to be updated with minor changes:

 

1)      Copyright information needs to be added at the start of test file.

2)      Jtreg test summary needs to be updated to mention what the test is trying to achieve instead of JBS bug title.

3)      Also since this test is specific to Windows we can remove the OS test code present in test case with Jtreg @requires flag:

 

Instead of using the below code we can use @requires (os.family == "windows")

 

            if (OSInfo.getOSType() != OSInfo.OSType.WINDOWS) {

                                         System.out.println("The test is suitable only for Windows OS. Skipped.");

                                         return;

                    }

4)      For multiline comments at Line no 1 & 26 in test case please update the comment syntax to use :

/*

 *

 *

 */

 

Thanks,

Jay

 

From: Krishna Addepalli 
Sent: Tuesday, January 09, 2018 2:30 PM
To: Prasanta Sadhukhan; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10][11][JDK-8194044] Regression manual Test javax/swing/JFileChooser/8067660/FileChooserTest.java fails

 

Hi Prasanta,Sergey,

 

I have added a testcase along with the changes and created a new webrev : http://cr.openjdk.java.net/~kaddepalli/8194044/webrev01/

 

Please review this and provide your comments.

 

Thanks,

Krishna

 

From: Prasanta Sadhukhan 
Sent: Thursday, January 4, 2018 10:54 AM
To: Krishna Addepalli <HYPERLINK "mailto:krishna.addepalli at oracle.com"krishna.addepalli at oracle.com>; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10][11][JDK-8194044] Regression manual Test javax/swing/JFileChooser/8067660/FileChooserTest.java fails

 

A regression test is added to prove that before your fix, java was failing and after your fix is applied, it is passing so it is not related to older/newer java versions. I saw we already have test/jdk/javax/swing/JFileChooser/6945316/bug6945316.java which tests isFileSystemRoot. Maybe, we can do something similar if it's not too much of a task.

Regards
Prasanta

On 1/3/2018 5:13 PM, Krishna Addepalli wrote:

Thanks for the review Prasanta. However, I don't see a point to write a test case for isFileSystemRoot(), since, it is not going to fail on any (older/newer) java versions, and it was only introduced because of the fix for JDK-8175015.

Let me know if you think otherwise.

 

Regards,

Krishna

From: Prasanta Sadhukhan 
Sent: Wednesday, January 3, 2018 11:27 AM
To: Krishna Addepalli HYPERLINK "mailto:krishna.addepalli at oracle.com"<krishna.addepalli at oracle.com>; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10][11][JDK-8194044] Regression manual Test javax/swing/JFileChooser/8067660/FileChooserTest.java fails

 

Fix looks fine. But I guess, it is possible to add a automated regression test to it utilising isFileSystemRoot().

Regards
Prasanta

On 1/2/2018 4:31 PM, Krishna Addepalli wrote:

Hi All,

 

Please review a fix for bug:

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

Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Ekaddepalli/8194044/webrev00/"http://cr.openjdk.java.net/~kaddepalli/8194044/webrev00/

 

This was caused due to the fix for JDK-8175015, in which the line 446  in Win32ShellFolderManager2.java was changed from "getDrives()" to Win32ShellFolder2.listRoots().

While the earlier function returns an object of Win32ShellFolder2, the latter returns an array of Files. 

The condition on line 450: "return (sf.isFileSystem()&&sf.parent != null && sf.parent.equals(Win32ShellFolder2.listRoots())" was returning false because of the wrong object being passed. Earlier it was a Win32ShellFolder2 object, and the comparision was done properly, but with the changes, the equals fucnction was receiving a file array object, and hence it was immediately returning false, leading to the problem of empty strings being shown for Root drives.

The fix is to replace "Win32ShellFolder2.listRoots()" with "getDrives()" function. With this fix, the regression is addressed, as well as the original JDK-8175015 which was a memory leak issue.

 

Thanks,

Krishna

 

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

From manajit.halder at oracle.com  Wed Jan 10 13:21:16 2018
From: manajit.halder at oracle.com (Manajit Halder)
Date: Wed, 10 Jan 2018 18:51:16 +0530
Subject: <Swing Dev> Swing dev>[10] Review request for JDK-8189253:
 [macos] JPopupMenu is inadvertently shown when using setComponentPopupMenu
In-Reply-To: <6724f7b1-94c0-742b-081b-47dde62426b3@oracle.com>
References: <E1445698-445B-4542-98C1-1D82A4A182C9@oracle.com>
 <4ed5cbcf-c1f7-f615-6404-ebe13c47b8da@oracle.com>
 <C77A97FC-2163-455F-847D-C590D3B5D522@oracle.com>
 <bcd060d3-4553-55f5-4fee-b22d6313426e@oracle.com>
 <F10C8291-1722-4618-B2B5-C2DB14E7486C@oracle.com>
 <f7627a88-4d81-7105-59a0-fdf6872b62f2@oracle.com>
 <BE2F9413-3948-4BCF-A52D-F18E46AD7834@oracle.com>
 <6724f7b1-94c0-742b-081b-47dde62426b3@oracle.com>
Message-ID: <71FF00F4-C636-435F-B192-DFEBFFBE7945@oracle.com>

Hi Semyon,

I could reproduce the behaviour on Ubuntu. But I am curious to know whether this particular mouse operation is a valid operation?

Thanks,
Manajit

> On 08-Jan-2018, at 10:06 PM, Semyon Sadetsky <semyon.sadetsky at oracle.com> wrote:
> 
> Hi Manajit,
> 
> Still didn't get why are you limited to Mac platform  only while you change updates generic code. Why mouse provided by Apple matters here?
> --Semyon
> 
> On 01/08/2018 01:40 AM, Manajit Halder wrote:
>> Hi Semyon,
>> 
>> I could not reproduce the behaviour on Mac as on Mac this operation is not possible and hence it won?t be a problem on Mac. It is not possible to press the right button or the left button when the other button is already pressed using both Mouse provided by Apple and Track pad. Once the left button is pressed it need to be release to press the right button and vice versa. 
>> 
>> Thanks,
>> Manajit
>> 
>>> On 05-Jan-2018, at 7:08 AM, Semyon Sadetsky <semyon.sadetsky at oracle.com <mailto:semyon.sadetsky at oracle.com>> wrote:
>>> 
>>> Hi Manajit,
>>> 
>>> I could reproduce similar behaviour on Linux when mouse is dragged to another component with the left button pressed and then the right button is immediately  pressed. The popup is triggered by the same logic despite it isn't configured for the component. 
>>> --Semyon
>>> 
>>> On 01/04/2018 10:22 AM, Manajit Halder wrote:
>>>> Hi Semyon,
>>>> 
>>>> Fix for issue JDK-8080729 <https://bugs.openjdk.java.net/browse/JDK-8080729> has caused this regression due to changes in method setVisible(boolean visible) in file CPlatformWindow.java
>>>> orderWindow is causing the issue here, if we revert to addChildWindow then the issue is not observed but then the fix for issue JDK-8080729 fails.
>>>> Before this change the child window used to be added on to the parent as shown below in the commented code. But after the change child window is ordered above the parent.
>>>> 
>>>> Below code causes the regression:
>>>> 
>>>> CWrapper.NSWindow.orderWindow(ptr, CWrapper.NSWindow.NSWindowAbove, ownerPtr);
>>>> //CWrapper.NSWindow.addChildWindow(ownerPtr, ptr, CWrapper.NSWindow.NSWindowAbove);
>>>> 
>>>> Debugging further I found that if we use orderWindow then the new window is considered as new graphics device in the method notifyReshape in LWWindowPeer.java (the method updateGraphicsDevice() returns true) and is the difference between using orderWindow and addChildWindow.
>>>> 
>>>> Since the option to add child window is between choosing oderWindow and addChildWindow we don?t have any option to do the fix in the Mac OS native code.
>>>> 
>>>> Regards,
>>>> Manajit
>>>> 
>>>> 
>>>>> On 02-Jan-2018, at 11:30 PM, Semyon Sadetsky <semyon.sadetsky at oracle.com <mailto:semyon.sadetsky at oracle.com>> wrote:
>>>>> 
>>>>> Hi Manajit,
>>>>> 
>>>>> JDK-8080729 bug was Mac OS specific issue and its fix changed the Mac OS code only. Nevertheless you are suggesting to fix the regression in generic code. This need to be explained somehow.
>>>>> 
>>>>> --Semyon
>>>>> On 12/25/2017 02:42 AM, Manajit Halder wrote:
>>>>>> Hi Semyon,
>>>>>> 
>>>>>> Regression is cause by JDK-8080729 <https://bugs.openjdk.java.net/browse/JDK-8080729>. The fix can?t be reversed since it is the choice between addChildWindow or orderWindow. Went through code flow related to the issue but didn?t find any other better place in code to handle this issue. The best way to fix the issue would be to avoid retargeting of events (MOUSE_ENTER and MOUSE_EXIT) between MOUSE_PRESS and MOUSE_RELEASE on the parent window (when the mouse is actually on the child window). Therefore request you to review the webrev.00.
>>>>>> 
>>>>>> Regards,
>>>>>> Manajit
>>>>>> 
>>>>>>> On 08-Dec-2017, at 9:55 PM, semyon.sadetsky at oracle.com <mailto:semyon.sadetsky at oracle.com> wrote:
>>>>>>> 
>>>>>>> Hi Manajit,
>>>>>>> 
>>>>>>> Can you provide information which fix caused the regression?
>>>>>>> 
>>>>>>> --Semyon
>>>>>>> 
>>>>>>> On 12/8/17 5:53 AM, Manajit Halder wrote:
>>>>>>>> Hi All,
>>>>>>>> 
>>>>>>>> Kindly review the following Swing fix.
>>>>>>>> 
>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8189253 <https://bugs.openjdk.java.net/browse/JDK-8189253>
>>>>>>>> Webrev: http://cr.openjdk.java.net/~mhalder/8189253/webrev.00/ <http://cr.openjdk.java.net/%7Emhalder/8189253/webrev.00/>
>>>>>>>> 
>>>>>>>> Cause: 
>>>>>>>> 	Issue was due to retargeting of mouse enter exit events. 
>>>>>>>> 	MOUSE_ENTER and MOUSE_EXIT events were sent on the parent window (JFrame) in between MOUSE_PRESS and MOUSE_RELEASE events on the modeless JDialog.
>>>>>>>> 
>>>>>>>> Fix:
>>>>>>>> 	Retargeting of events is not done in-between MOUSE_PRESS and MOUSE_RELEASE.
>>>>>>>> 
>>>>>>>> Regards,
>>>>>>>> Manajit
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 

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

From krishna.addepalli at oracle.com  Wed Jan 10 14:46:57 2018
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Wed, 10 Jan 2018 06:46:57 -0800 (PST)
Subject: <Swing Dev> [10][11][JDK-8194044] Regression manual Test
 javax/swing/JFileChooser/8067660/FileChooserTest.java fails
In-Reply-To: <a1cb5598-7898-42a1-956e-dac8cef938bd@default>
References: <91a8f44e-a18c-43f5-96b8-ab310399c348@default>
 <fb48167a-d960-f5c9-ad2e-92199ee47a39@oracle.com>
 <db9ba389-e151-4307-9fd1-e30adcf93234@default>
 <9471d86d-c59b-53b9-0b6c-4c2a9b8555a7@oracle.com>
 <c5b84c78-b7c9-4ff8-afc6-b3d05f47c30c@default>
 <d4cb6190-f03c-4c68-95aa-12fb07e7e89e@default>
 <6ce77bb1-d3a6-41b7-a646-2eb0c9e2d042@default>
 <a1cb5598-7898-42a1-956e-dac8cef938bd@default>
Message-ID: <5da0d56c-ab35-41eb-b4ad-fef5ea6a43d9@default>

Hi Jay,

 

Thanks for the suggestions, and I have created a new webrev here: http://cr.openjdk.java.net/~kaddepalli/8194044/webrev03/

 

However, I don't think Test if is a typo. It can be read as is and still makes sense.

 

Regards,

Krishna

 

From: Jayathirth D V 
Sent: Wednesday, January 10, 2018 6:18 PM
To: Krishna Addepalli <krishna.addepalli at oracle.com>; swing-dev at openjdk.java.net
Subject: RE: <Swing Dev> [10][11][JDK-8194044] Regression manual Test javax/swing/JFileChooser/8067660/FileChooserTest.java fails

 

Hi Krishna,

 

Please find my inputs:

 

1)      There is no need for Starting and Ending year in copyright of test case as it is a new file. Adding just 2018 would be enough. 

2)      Typo in jtreg summary : "Test if" it should be "Tests if".

3)      For multiline comments using /*..*/,  First line should be left empty in a block comment at Line no 24 & 42 and last line of block comment should have proper indentation at Line no 30. Java coding convention for comments : http://www.oracle.com/technetwork/java/codeconventions-141999.html 

 

Thanks,

Jay

 

From: Krishna Addepalli 
Sent: Wednesday, January 10, 2018 6:00 PM
To: Jayathirth D V; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: RE: <Swing Dev> [10][11][JDK-8194044] Regression manual Test javax/swing/JFileChooser/8067660/FileChooserTest.java fails

 

Hi Jay,

 

Thanks for your time and review. I have incorporated your review comments and created a new webrev here: http://cr.openjdk.java.net/~kaddepalli/8194044/webrev02/

 

Thanks,

Krishna

 

From: Jayathirth D V 
Sent: Wednesday, January 10, 2018 4:16 PM
To: Krishna Addepalli <HYPERLINK "mailto:krishna.addepalli at oracle.com"krishna.addepalli at oracle.com>; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: RE: <Swing Dev> [10][11][JDK-8194044] Regression manual Test javax/swing/JFileChooser/8067660/FileChooserTest.java fails

 

Hi Krishna,

 

Please find my inputs:

 

Test case needs to be updated with minor changes:

 

1)      Copyright information needs to be added at the start of test file.

2)      Jtreg test summary needs to be updated to mention what the test is trying to achieve instead of JBS bug title.

3)      Also since this test is specific to Windows we can remove the OS test code present in test case with Jtreg @requires flag:

 

Instead of using the below code we can use @requires (os.family == "windows")

 

            if (OSInfo.getOSType() != OSInfo.OSType.WINDOWS) {

                                         System.out.println("The test is suitable only for Windows OS. Skipped.");

                                         return;

                    }

4)      For multiline comments at Line no 1 & 26 in test case please update the comment syntax to use :

/*

 *

 *

 */

 

Thanks,

Jay

 

From: Krishna Addepalli 
Sent: Tuesday, January 09, 2018 2:30 PM
To: Prasanta Sadhukhan; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10][11][JDK-8194044] Regression manual Test javax/swing/JFileChooser/8067660/FileChooserTest.java fails

 

Hi Prasanta,Sergey,

 

I have added a testcase along with the changes and created a new webrev : http://cr.openjdk.java.net/~kaddepalli/8194044/webrev01/

 

Please review this and provide your comments.

 

Thanks,

Krishna

 

From: Prasanta Sadhukhan 
Sent: Thursday, January 4, 2018 10:54 AM
To: Krishna Addepalli <HYPERLINK "mailto:krishna.addepalli at oracle.com"krishna.addepalli at oracle.com>; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10][11][JDK-8194044] Regression manual Test javax/swing/JFileChooser/8067660/FileChooserTest.java fails

 

A regression test is added to prove that before your fix, java was failing and after your fix is applied, it is passing so it is not related to older/newer java versions. I saw we already have test/jdk/javax/swing/JFileChooser/6945316/bug6945316.java which tests isFileSystemRoot. Maybe, we can do something similar if it's not too much of a task.

Regards
Prasanta

On 1/3/2018 5:13 PM, Krishna Addepalli wrote:

Thanks for the review Prasanta. However, I don't see a point to write a test case for isFileSystemRoot(), since, it is not going to fail on any (older/newer) java versions, and it was only introduced because of the fix for JDK-8175015.

Let me know if you think otherwise.

 

Regards,

Krishna

From: Prasanta Sadhukhan 
Sent: Wednesday, January 3, 2018 11:27 AM
To: Krishna Addepalli HYPERLINK "mailto:krishna.addepalli at oracle.com"<krishna.addepalli at oracle.com>; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10][11][JDK-8194044] Regression manual Test javax/swing/JFileChooser/8067660/FileChooserTest.java fails

 

Fix looks fine. But I guess, it is possible to add a automated regression test to it utilising isFileSystemRoot().

Regards
Prasanta

On 1/2/2018 4:31 PM, Krishna Addepalli wrote:

Hi All,

 

Please review a fix for bug:

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

Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Ekaddepalli/8194044/webrev00/"http://cr.openjdk.java.net/~kaddepalli/8194044/webrev00/

 

This was caused due to the fix for JDK-8175015, in which the line 446  in Win32ShellFolderManager2.java was changed from "getDrives()" to Win32ShellFolder2.listRoots().

While the earlier function returns an object of Win32ShellFolder2, the latter returns an array of Files. 

The condition on line 450: "return (sf.isFileSystem()&&sf.parent != null && sf.parent.equals(Win32ShellFolder2.listRoots())" was returning false because of the wrong object being passed. Earlier it was a Win32ShellFolder2 object, and the comparision was done properly, but with the changes, the equals fucnction was receiving a file array object, and hence it was immediately returning false, leading to the problem of empty strings being shown for Root drives.

The fix is to replace "Win32ShellFolder2.listRoots()" with "getDrives()" function. With this fix, the regression is addressed, as well as the original JDK-8175015 which was a memory leak issue.

 

Thanks,

Krishna

 

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

From semyon.sadetsky at oracle.com  Wed Jan 10 15:41:30 2018
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Wed, 10 Jan 2018 07:41:30 -0800
Subject: <Swing Dev> Swing dev>[10] Review request for JDK-8189253:
 [macos] JPopupMenu is inadvertently shown when using setComponentPopupMenu
In-Reply-To: <71FF00F4-C636-435F-B192-DFEBFFBE7945@oracle.com>
References: <E1445698-445B-4542-98C1-1D82A4A182C9@oracle.com>
 <4ed5cbcf-c1f7-f615-6404-ebe13c47b8da@oracle.com>
 <C77A97FC-2163-455F-847D-C590D3B5D522@oracle.com>
 <bcd060d3-4553-55f5-4fee-b22d6313426e@oracle.com>
 <F10C8291-1722-4618-B2B5-C2DB14E7486C@oracle.com>
 <f7627a88-4d81-7105-59a0-fdf6872b62f2@oracle.com>
 <BE2F9413-3948-4BCF-A52D-F18E46AD7834@oracle.com>
 <6724f7b1-94c0-742b-081b-47dde62426b3@oracle.com>
 <71FF00F4-C636-435F-B192-DFEBFFBE7945@oracle.com>
Message-ID: <5e25040d-fc6f-a859-9484-443a7d1b5365@oracle.com>

Hi Manajit,

Not sure what did you mean under valid. The general approach is user may 
do with the mouse whatever he wants nevertheless UI should not be 
broken. This is just an indication the issue you are trying to fix may 
be a generic one.

--Semyon


On 01/10/2018 05:21 AM, Manajit Halder wrote:
> Hi Semyon,
>
> I could reproduce the behaviour on Ubuntu. But I am curious to know 
> whether this particular mouse operation is a valid operation?
>
> Thanks,
> Manajit
>
>> On 08-Jan-2018, at 10:06 PM, Semyon Sadetsky 
>> <semyon.sadetsky at oracle.com <mailto:semyon.sadetsky at oracle.com>> wrote:
>>
>> Hi Manajit,
>>
>> Still didn't get why are you limited to Mac platform? only while you 
>> change updates generic code. Why mouse provided by Apple matters here?
>>
>> --Semyon
>>
>>
>> On 01/08/2018 01:40 AM, Manajit Halder wrote:
>>> Hi Semyon,
>>>
>>> I could not reproduce the behaviour on Mac as on Mac this operation 
>>> is not possible and hence it won?t be a problem on Mac. It is not 
>>> possible to press the right button or the left button when the other 
>>> button is already pressed using both Mouse provided by Apple and 
>>> Track pad. Once the left button is pressed it need to be release to 
>>> press the right button and vice versa.
>>>
>>> Thanks,
>>> Manajit
>>>
>>>> On 05-Jan-2018, at 7:08 AM, Semyon Sadetsky 
>>>> <semyon.sadetsky at oracle.com <mailto:semyon.sadetsky at oracle.com>> wrote:
>>>>
>>>> Hi Manajit,
>>>>
>>>> I could reproduce similar behaviour on Linux when mouse is dragged 
>>>> to another component with the left button pressed and then the 
>>>> right button is immediately? pressed. The popup is triggered by the 
>>>> same logic despite it isn't configured for the component.
>>>>
>>>> --Semyon
>>>>
>>>> On 01/04/2018 10:22 AM, Manajit Halder wrote:
>>>>> Hi Semyon,
>>>>>
>>>>> Fix for issue JDK-8080729 
>>>>> <https://bugs.openjdk.java.net/browse/JDK-8080729> has caused this 
>>>>> regression due to changes in method setVisible(boolean visible) in 
>>>>> file CPlatformWindow.java
>>>>> orderWindow is causing the issue here, if we revert to 
>>>>> addChildWindow then the issue is not observed but then the fix for 
>>>>> issue JDK-8080729 fails.
>>>>> Before this change the child window used to be added on to the 
>>>>> parent as shown below in the commented code. But after the change 
>>>>> child window is ordered above the parent.
>>>>>
>>>>> Below code causes the regression:
>>>>>
>>>>> *CWrapper.NSWindow.orderWindow(ptr, 
>>>>> CWrapper.NSWindow.NSWindowAbove, ownerPtr);*
>>>>> *//CWrapper.NSWindow.addChildWindow(ownerPtr, ptr, 
>>>>> CWrapper.NSWindow.NSWindowAbove);*
>>>>>
>>>>> Debugging further I found that if we use orderWindow then the new 
>>>>> window is considered as new graphics device in the method 
>>>>> notifyReshape in LWWindowPeer.java (the method 
>>>>> updateGraphicsDevice() returns true) and is the difference between 
>>>>> using orderWindow and addChildWindow.
>>>>>
>>>>> Since the option to add child window is between choosing 
>>>>> oderWindow and addChildWindow we don?t have any option to do the 
>>>>> fix in the Mac OS native code.
>>>>>
>>>>> Regards,
>>>>> Manajit
>>>>>
>>>>>
>>>>>> On 02-Jan-2018, at 11:30 PM, Semyon Sadetsky 
>>>>>> <semyon.sadetsky at oracle.com <mailto:semyon.sadetsky at oracle.com>> 
>>>>>> wrote:
>>>>>>
>>>>>> Hi Manajit,
>>>>>>
>>>>>> JDK-8080729 bug was Mac OS specific issue and its fix changed the 
>>>>>> Mac OS code only. Nevertheless you are suggesting to fix the 
>>>>>> regression in generic code. This need to be explained somehow.
>>>>>>
>>>>>> --Semyon
>>>>>>
>>>>>> On 12/25/2017 02:42 AM, Manajit Halder wrote:
>>>>>>> Hi Semyon,
>>>>>>>
>>>>>>> Regression is cause by JDK-8080729 
>>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8080729>. The fix 
>>>>>>> can?t be reversed since it is the?choice between addChildWindow 
>>>>>>> or orderWindow. Went through code flow related to the issue 
>>>>>>> but?didn?t find any other better place in code to handle this 
>>>>>>> issue. The best way to fix the issue would be to avoid 
>>>>>>> retargeting of events (MOUSE_ENTER and MOUSE_EXIT) between 
>>>>>>> MOUSE_PRESS and MOUSE_RELEASE on the parent window (when the 
>>>>>>> mouse is actually on the child window). Therefore request you to 
>>>>>>> review the webrev.00.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Manajit
>>>>>>>
>>>>>>>> On 08-Dec-2017, at 9:55 PM, semyon.sadetsky at oracle.com 
>>>>>>>> <mailto:semyon.sadetsky at oracle.com> wrote:
>>>>>>>>
>>>>>>>> Hi Manajit,
>>>>>>>>
>>>>>>>> Can you provide information which fix caused the regression?
>>>>>>>>
>>>>>>>> --Semyon
>>>>>>>>
>>>>>>>>
>>>>>>>> On 12/8/17 5:53 AM, Manajit Halder wrote:
>>>>>>>>> Hi All,
>>>>>>>>>
>>>>>>>>> Kindly review the following Swing fix.
>>>>>>>>>
>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8189253
>>>>>>>>> Webrev: http://cr.openjdk.java.net/~mhalder/8189253/webrev.00/ 
>>>>>>>>> <http://cr.openjdk.java.net/%7Emhalder/8189253/webrev.00/>
>>>>>>>>>
>>>>>>>>> Cause:
>>>>>>>>> Issue was due to retargeting of mouse enter exit events.
>>>>>>>>> MOUSE_ENTER and MOUSE_EXIT events were sent on the parent 
>>>>>>>>> window (JFrame) in between MOUSE_PRESS and MOUSE_RELEASE 
>>>>>>>>> events on the modeless JDialog.
>>>>>>>>>
>>>>>>>>> Fix:
>>>>>>>>> Retargeting of events is not done in-between MOUSE_PRESS and 
>>>>>>>>> MOUSE_RELEASE.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Manajit
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

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

From jayathirth.d.v at oracle.com  Wed Jan 10 15:57:58 2018
From: jayathirth.d.v at oracle.com (Jayathirth D V)
Date: Wed, 10 Jan 2018 07:57:58 -0800 (PST)
Subject: <Swing Dev> [10][11][JDK-8194044] Regression manual Test
 javax/swing/JFileChooser/8067660/FileChooserTest.java fails
In-Reply-To: <5da0d56c-ab35-41eb-b4ad-fef5ea6a43d9@default>
References: <91a8f44e-a18c-43f5-96b8-ab310399c348@default>
 <fb48167a-d960-f5c9-ad2e-92199ee47a39@oracle.com>
 <db9ba389-e151-4307-9fd1-e30adcf93234@default>
 <9471d86d-c59b-53b9-0b6c-4c2a9b8555a7@oracle.com>
 <c5b84c78-b7c9-4ff8-afc6-b3d05f47c30c@default>
 <d4cb6190-f03c-4c68-95aa-12fb07e7e89e@default>
 <6ce77bb1-d3a6-41b7-a646-2eb0c9e2d042@default>
 <a1cb5598-7898-42a1-956e-dac8cef938bd@default>
 <5da0d56c-ab35-41eb-b4ad-fef5ea6a43d9@default>
Message-ID: <33acfa5b-bc66-4b95-a2d0-e7f9a5a0a186@default>

Hi Krishna,

 

Changes are fine.

 

Thanks,

Jay

 

From: Krishna Addepalli 
Sent: Wednesday, January 10, 2018 8:17 PM
To: Jayathirth D V; swing-dev at openjdk.java.net
Subject: RE: <Swing Dev> [10][11][JDK-8194044] Regression manual Test javax/swing/JFileChooser/8067660/FileChooserTest.java fails

 

Hi Jay,

 

Thanks for the suggestions, and I have created a new webrev here: http://cr.openjdk.java.net/~kaddepalli/8194044/webrev03/

 

However, I don't think Test if is a typo. It can be read as is and still makes sense.

 

Regards,

Krishna

 

From: Jayathirth D V 
Sent: Wednesday, January 10, 2018 6:18 PM
To: Krishna Addepalli <HYPERLINK "mailto:krishna.addepalli at oracle.com"krishna.addepalli at oracle.com>; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: RE: <Swing Dev> [10][11][JDK-8194044] Regression manual Test javax/swing/JFileChooser/8067660/FileChooserTest.java fails

 

Hi Krishna,

 

Please find my inputs:

 

1)      There is no need for Starting and Ending year in copyright of test case as it is a new file. Adding just 2018 would be enough. 

2)      Typo in jtreg summary : "Test if" it should be "Tests if".

3)      For multiline comments using /*..*/,  First line should be left empty in a block comment at Line no 24 & 42 and last line of block comment should have proper indentation at Line no 30. Java coding convention for comments : http://www.oracle.com/technetwork/java/codeconventions-141999.html 

 

Thanks,

Jay

 

From: Krishna Addepalli 
Sent: Wednesday, January 10, 2018 6:00 PM
To: Jayathirth D V; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: RE: <Swing Dev> [10][11][JDK-8194044] Regression manual Test javax/swing/JFileChooser/8067660/FileChooserTest.java fails

 

Hi Jay,

 

Thanks for your time and review. I have incorporated your review comments and created a new webrev here: http://cr.openjdk.java.net/~kaddepalli/8194044/webrev02/

 

Thanks,

Krishna

 

From: Jayathirth D V 
Sent: Wednesday, January 10, 2018 4:16 PM
To: Krishna Addepalli <HYPERLINK "mailto:krishna.addepalli at oracle.com"krishna.addepalli at oracle.com>; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: RE: <Swing Dev> [10][11][JDK-8194044] Regression manual Test javax/swing/JFileChooser/8067660/FileChooserTest.java fails

 

Hi Krishna,

 

Please find my inputs:

 

Test case needs to be updated with minor changes:

 

1)      Copyright information needs to be added at the start of test file.

2)      Jtreg test summary needs to be updated to mention what the test is trying to achieve instead of JBS bug title.

3)      Also since this test is specific to Windows we can remove the OS test code present in test case with Jtreg @requires flag:

 

Instead of using the below code we can use @requires (os.family == "windows")

 

            if (OSInfo.getOSType() != OSInfo.OSType.WINDOWS) {

                                         System.out.println("The test is suitable only for Windows OS. Skipped.");

                                         return;

                    }

4)      For multiline comments at Line no 1 & 26 in test case please update the comment syntax to use :

/*

 *

 *

 */

 

Thanks,

Jay

 

From: Krishna Addepalli 
Sent: Tuesday, January 09, 2018 2:30 PM
To: Prasanta Sadhukhan; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10][11][JDK-8194044] Regression manual Test javax/swing/JFileChooser/8067660/FileChooserTest.java fails

 

Hi Prasanta,Sergey,

 

I have added a testcase along with the changes and created a new webrev : http://cr.openjdk.java.net/~kaddepalli/8194044/webrev01/

 

Please review this and provide your comments.

 

Thanks,

Krishna

 

From: Prasanta Sadhukhan 
Sent: Thursday, January 4, 2018 10:54 AM
To: Krishna Addepalli <HYPERLINK "mailto:krishna.addepalli at oracle.com"krishna.addepalli at oracle.com>; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10][11][JDK-8194044] Regression manual Test javax/swing/JFileChooser/8067660/FileChooserTest.java fails

 

A regression test is added to prove that before your fix, java was failing and after your fix is applied, it is passing so it is not related to older/newer java versions. I saw we already have test/jdk/javax/swing/JFileChooser/6945316/bug6945316.java which tests isFileSystemRoot. Maybe, we can do something similar if it's not too much of a task.

Regards
Prasanta

On 1/3/2018 5:13 PM, Krishna Addepalli wrote:

Thanks for the review Prasanta. However, I don't see a point to write a test case for isFileSystemRoot(), since, it is not going to fail on any (older/newer) java versions, and it was only introduced because of the fix for JDK-8175015.

Let me know if you think otherwise.

 

Regards,

Krishna

From: Prasanta Sadhukhan 
Sent: Wednesday, January 3, 2018 11:27 AM
To: Krishna Addepalli HYPERLINK "mailto:krishna.addepalli at oracle.com"<krishna.addepalli at oracle.com>; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10][11][JDK-8194044] Regression manual Test javax/swing/JFileChooser/8067660/FileChooserTest.java fails

 

Fix looks fine. But I guess, it is possible to add a automated regression test to it utilising isFileSystemRoot().

Regards
Prasanta

On 1/2/2018 4:31 PM, Krishna Addepalli wrote:

Hi All,

 

Please review a fix for bug:

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

Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Ekaddepalli/8194044/webrev00/"http://cr.openjdk.java.net/~kaddepalli/8194044/webrev00/

 

This was caused due to the fix for JDK-8175015, in which the line 446  in Win32ShellFolderManager2.java was changed from "getDrives()" to Win32ShellFolder2.listRoots().

While the earlier function returns an object of Win32ShellFolder2, the latter returns an array of Files. 

The condition on line 450: "return (sf.isFileSystem()&&sf.parent != null && sf.parent.equals(Win32ShellFolder2.listRoots())" was returning false because of the wrong object being passed. Earlier it was a Win32ShellFolder2 object, and the comparision was done properly, but with the changes, the equals fucnction was receiving a file array object, and hence it was immediately returning false, leading to the problem of empty strings being shown for Root drives.

The fix is to replace "Win32ShellFolder2.listRoots()" with "getDrives()" function. With this fix, the regression is addressed, as well as the original JDK-8175015 which was a memory leak issue.

 

Thanks,

Krishna

 

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

From semyon.sadetsky at oracle.com  Wed Jan 10 16:58:39 2018
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Wed, 10 Jan 2018 08:58:39 -0800
Subject: <Swing Dev> [10][11][JDK-8194044] Regression manual Test
 javax/swing/JFileChooser/8067660/FileChooserTest.java fails
In-Reply-To: <33acfa5b-bc66-4b95-a2d0-e7f9a5a0a186@default>
References: <91a8f44e-a18c-43f5-96b8-ab310399c348@default>
 <fb48167a-d960-f5c9-ad2e-92199ee47a39@oracle.com>
 <db9ba389-e151-4307-9fd1-e30adcf93234@default>
 <9471d86d-c59b-53b9-0b6c-4c2a9b8555a7@oracle.com>
 <c5b84c78-b7c9-4ff8-afc6-b3d05f47c30c@default>
 <d4cb6190-f03c-4c68-95aa-12fb07e7e89e@default>
 <6ce77bb1-d3a6-41b7-a646-2eb0c9e2d042@default>
 <a1cb5598-7898-42a1-956e-dac8cef938bd@default>
 <5da0d56c-ab35-41eb-b4ad-fef5ea6a43d9@default>
 <33acfa5b-bc66-4b95-a2d0-e7f9a5a0a186@default>
Message-ID: <6471e2e5-de1f-7ebc-3b3b-0703c776857d@oracle.com>

Hi Krishna,

The fix looks good. But I did not understand the test. In my 
understanding it should check that the next is not en empty:

FileSystemView.getFileSystemView().getSystemDisplayName(FileSystemView.getFileSystemView().getShellFolder(new 
File("C:\\")))

And why do you run the test 50 times?

--Semyon

On 1/10/2018 7:57 AM, Jayathirth D V wrote:
>
> Hi Krishna,
>
> Changes are fine.
>
> Thanks,
>
> Jay
>
> *From:*Krishna Addepalli
> *Sent:* Wednesday, January 10, 2018 8:17 PM
> *To:* Jayathirth D V; swing-dev at openjdk.java.net
> *Subject:* RE: <Swing Dev> [10][11][JDK-8194044] Regression manual 
> Test javax/swing/JFileChooser/8067660/FileChooserTest.java fails
>
> Hi Jay,
>
> Thanks for the suggestions, and I have created a new webrev here: 
> http://cr.openjdk.java.net/~kaddepalli/8194044/webrev03/ 
> <http://cr.openjdk.java.net/%7Ekaddepalli/8194044/webrev03/>
>
> However, I don?t think Test if is a typo. It can be read as is and 
> still makes sense.
>
> Regards,
>
> Krishna
>
> *From:*Jayathirth D V
> *Sent:* Wednesday, January 10, 2018 6:18 PM
> *To:* Krishna Addepalli <krishna.addepalli at oracle.com 
> <mailto:krishna.addepalli at oracle.com>>; swing-dev at openjdk.java.net 
> <mailto:swing-dev at openjdk.java.net>
> *Subject:* RE: <Swing Dev> [10][11][JDK-8194044] Regression manual 
> Test javax/swing/JFileChooser/8067660/FileChooserTest.java fails
>
> Hi Krishna,
>
> Please find my inputs:
>
> 1)There is no need for Starting and Ending year in copyright of test 
> case as it is a new file. Adding just 2018 would be enough.
>
> 2)Typo in jtreg summary : ?Test if? it should be ?Tests if?.
>
> 3)For multiline comments using /*..*/,  First line should be left 
> empty in a block comment at Line no 24 & 42 and last line of block 
> comment should have proper indentation at Line no 30. Java coding 
> convention for comments : 
> http://www.oracle.com/technetwork/java/codeconventions-141999.html
>
> Thanks,
>
> Jay
>
> *From:*Krishna Addepalli
> *Sent:* Wednesday, January 10, 2018 6:00 PM
> *To:* Jayathirth D V; swing-dev at openjdk.java.net 
> <mailto:swing-dev at openjdk.java.net>
> *Subject:* RE: <Swing Dev> [10][11][JDK-8194044] Regression manual 
> Test javax/swing/JFileChooser/8067660/FileChooserTest.java fails
>
> Hi Jay,
>
> Thanks for your time and review. I have incorporated your review 
> comments and created a new webrev here: 
> http://cr.openjdk.java.net/~kaddepalli/8194044/webrev02/ 
> <http://cr.openjdk.java.net/%7Ekaddepalli/8194044/webrev02/>
>
> Thanks,
>
> Krishna
>
> *From:*Jayathirth D V
> *Sent:* Wednesday, January 10, 2018 4:16 PM
> *To:* Krishna Addepalli <krishna.addepalli at oracle.com 
> <mailto:krishna.addepalli at oracle.com>>; swing-dev at openjdk.java.net 
> <mailto:swing-dev at openjdk.java.net>
> *Subject:* RE: <Swing Dev> [10][11][JDK-8194044] Regression manual 
> Test javax/swing/JFileChooser/8067660/FileChooserTest.java fails
>
> Hi Krishna,
>
> Please find my inputs:
>
> Test case needs to be updated with minor changes:
>
> 1)Copyright information needs to be added at the start of test file.
>
> 2)Jtreg test summary needs to be updated to mention what the test is 
> trying to achieve instead of JBS bug title.
>
> 3)Also since this test is specific to Windows we can remove the OS 
> test code present in test case with Jtreg @requires flag:
>
> Instead of using the below code we can use @requires (os.family == 
> "windows")
>
>             if (OSInfo.getOSType() != OSInfo.OSType.WINDOWS) {
>
> System.out.println("The test is suitable only for Windows OS. Skipped.");
>
> return;
>
> }
>
> 4)For multiline comments at Line no 1 & 26 in test case please update 
> the comment syntax to use :
>
> /*
>
>  *
>
>  *
>
>  */
>
> Thanks,
>
> Jay
>
> *From:*Krishna Addepalli
> *Sent:* Tuesday, January 09, 2018 2:30 PM
> *To:* Prasanta Sadhukhan; swing-dev at openjdk.java.net 
> <mailto:swing-dev at openjdk.java.net>
> *Subject:* Re: <Swing Dev> [10][11][JDK-8194044] Regression manual 
> Test javax/swing/JFileChooser/8067660/FileChooserTest.java fails
>
> Hi Prasanta,Sergey,
>
> I have added a testcase along with the changes and created a new 
> webrev : http://cr.openjdk.java.net/~kaddepalli/8194044/webrev01/ 
> <http://cr.openjdk.java.net/%7Ekaddepalli/8194044/webrev01/>
>
> Please review this and provide your comments.
>
> Thanks,
>
> Krishna
>
> *From:*Prasanta Sadhukhan
> *Sent:* Thursday, January 4, 2018 10:54 AM
> *To:* Krishna Addepalli <krishna.addepalli at oracle.com 
> <mailto:krishna.addepalli at oracle.com>>; swing-dev at openjdk.java.net 
> <mailto:swing-dev at openjdk.java.net>
> *Subject:* Re: <Swing Dev> [10][11][JDK-8194044] Regression manual 
> Test javax/swing/JFileChooser/8067660/FileChooserTest.java fails
>
> A regression test is added to prove that before your fix, java was 
> failing and after your fix is applied, it is passing so it is not 
> related to older/newer java versions. I saw we already have 
> test/jdk/javax/swing/JFileChooser/6945316/bug6945316.java which tests 
> isFileSystemRoot. Maybe, we can do something similar if it's not too 
> much of a task.
>
> Regards
> Prasanta
>
> On 1/3/2018 5:13 PM, Krishna Addepalli wrote:
>
>     Thanks for the review Prasanta. However, I don?t see a point to
>     write a test case for isFileSystemRoot(), since, it is not going
>     to fail on any (older/newer) java versions, and it was only
>     introduced because of the fix for JDK-8175015.
>
>     Let me know if you think otherwise.
>
>     Regards,
>
>     Krishna
>
>     *From:*Prasanta Sadhukhan
>     *Sent:* Wednesday, January 3, 2018 11:27 AM
>     *To:* Krishna Addepalli <krishna.addepalli at oracle.com>
>     <mailto:krishna.addepalli at oracle.com>; swing-dev at openjdk.java.net
>     <mailto:swing-dev at openjdk.java.net>
>     *Subject:* Re: <Swing Dev> [10][11][JDK-8194044] Regression manual
>     Test javax/swing/JFileChooser/8067660/FileChooserTest.java fails
>
>     Fix looks fine. But I guess, it is possible to add a automated
>     regression test to it utilising isFileSystemRoot().
>
>     Regards
>     Prasanta
>
>     On 1/2/2018 4:31 PM, Krishna Addepalli wrote:
>
>         Hi All,
>
>         Please review a fix for bug:
>
>         Bug: JDK-8194044 :
>         https://bugs.openjdk.java.net/browse/JDK-8194044
>
>         Webrev:
>         http://cr.openjdk.java.net/~kaddepalli/8194044/webrev00/
>         <http://cr.openjdk.java.net/%7Ekaddepalli/8194044/webrev00/>
>
>         This was caused due to the fix for JDK-8175015, in which the
>         line 446  in Win32ShellFolderManager2.java was changed from
>         ?getDrives()? to Win32ShellFolder2.listRoots().
>
>         While the earlier function returns an object of
>         Win32ShellFolder2, the latter returns an array of Files.
>
>         The condition on line 450: ?return
>         (sf.isFileSystem()&&sf.parent != null &&
>         sf.parent.equals(Win32ShellFolder2.listRoots())? was returning
>         false because of the wrong object being passed. Earlier it was
>         a Win32ShellFolder2 object, and the comparision was done
>         properly, but with the changes, the equals fucnction was
>         receiving a file array object, and hence it was immediately
>         returning false, leading to the problem of empty strings being
>         shown for Root drives.
>
>         The fix is to replace ?Win32ShellFolder2.listRoots()? with
>         ?getDrives()? function. With this fix, the regression is
>         addressed, as well as the original JDK-8175015 which was a
>         memory leak issue.
>
>         Thanks,
>
>         Krishna
>

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

From krishna.addepalli at oracle.com  Wed Jan 10 18:10:51 2018
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Wed, 10 Jan 2018 10:10:51 -0800 (PST)
Subject: <Swing Dev> [10][11][JDK-8194044] Regression manual Test
 javax/swing/JFileChooser/8067660/FileChooserTest.java fails
In-Reply-To: <6471e2e5-de1f-7ebc-3b3b-0703c776857d@oracle.com>
References: <91a8f44e-a18c-43f5-96b8-ab310399c348@default>
 <fb48167a-d960-f5c9-ad2e-92199ee47a39@oracle.com>
 <db9ba389-e151-4307-9fd1-e30adcf93234@default>
 <9471d86d-c59b-53b9-0b6c-4c2a9b8555a7@oracle.com>
 <c5b84c78-b7c9-4ff8-afc6-b3d05f47c30c@default>
 <d4cb6190-f03c-4c68-95aa-12fb07e7e89e@default>
 <6ce77bb1-d3a6-41b7-a646-2eb0c9e2d042@default>
 <a1cb5598-7898-42a1-956e-dac8cef938bd@default>
 <5da0d56c-ab35-41eb-b4ad-fef5ea6a43d9@default>
 <33acfa5b-bc66-4b95-a2d0-e7f9a5a0a186@default>
 <6471e2e5-de1f-7ebc-3b3b-0703c776857d@oracle.com>
Message-ID: <4f6e0f77-dd3f-425e-bbeb-b4dead664a2e@default>

Hi Semyon, 

 

The idea was to test the ShellFolder path in the function "Win32ShellFolderManager2.isFileSystemRoot" function, which was being reported as false, before my fix. 

Secondly, "getShellFolder" function is package specific function, so I cannot invoke it directly from outside, so had to get a path to the default folder, and then keep getting the parent directory from there, till I come to root drive i.e "C:\\".

I adapted the code from the test that Prasanta suggested(have test/jdk/javax/swing/JFileChooser/6945316/bug6945316.java) which tests isFileSystemRoot, and simplified it, so left in the loop.

 

Thanks,

Krishna

 

From: Semyon Sadetsky 
Sent: Wednesday, January 10, 2018 10:29 PM
To: Jayathirth D V <jayathirth.d.v at oracle.com>; Krishna Addepalli <krishna.addepalli at oracle.com>; swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10][11][JDK-8194044] Regression manual Test javax/swing/JFileChooser/8067660/FileChooserTest.java fails

 

Hi Krishna,

The fix looks good. But I did not understand the test. In my understanding it should check that the next is not en empty:

FileSystemView.getFileSystemView().getSystemDisplayName(FileSystemView.getFileSystemView().getShellFolder(new File("C:\\")))

And why do you run the test 50 times?

--Semyon

On 1/10/2018 7:57 AM, Jayathirth D V wrote:

Hi Krishna,

 

Changes are fine.

 

Thanks,

Jay

 

From: Krishna Addepalli 
Sent: Wednesday, January 10, 2018 8:17 PM
To: Jayathirth D V; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: RE: <Swing Dev> [10][11][JDK-8194044] Regression manual Test javax/swing/JFileChooser/8067660/FileChooserTest.java fails

 

Hi Jay,

 

Thanks for the suggestions, and I have created a new webrev here: HYPERLINK "http://cr.openjdk.java.net/%7Ekaddepalli/8194044/webrev03/"http://cr.openjdk.java.net/~kaddepalli/8194044/webrev03/

 

However, I don't think Test if is a typo. It can be read as is and still makes sense.

 

Regards,

Krishna

 

From: Jayathirth D V 
Sent: Wednesday, January 10, 2018 6:18 PM
To: Krishna Addepalli <HYPERLINK "mailto:krishna.addepalli at oracle.com"krishna.addepalli at oracle.com>; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: RE: <Swing Dev> [10][11][JDK-8194044] Regression manual Test javax/swing/JFileChooser/8067660/FileChooserTest.java fails

 

Hi Krishna,

 

Please find my inputs:

 

1)      There is no need for Starting and Ending year in copyright of test case as it is a new file. Adding just 2018 would be enough. 

2)      Typo in jtreg summary : "Test if" it should be "Tests if".

3)      For multiline comments using /*..*/,  First line should be left empty in a block comment at Line no 24 & 42 and last line of block comment should have proper indentation at Line no 30. Java coding convention for comments : http://www.oracle.com/technetwork/java/codeconventions-141999.html 

 

Thanks,

Jay

 

From: Krishna Addepalli 
Sent: Wednesday, January 10, 2018 6:00 PM
To: Jayathirth D V; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: RE: <Swing Dev> [10][11][JDK-8194044] Regression manual Test javax/swing/JFileChooser/8067660/FileChooserTest.java fails

 

Hi Jay,

 

Thanks for your time and review. I have incorporated your review comments and created a new webrev here: HYPERLINK "http://cr.openjdk.java.net/%7Ekaddepalli/8194044/webrev02/"http://cr.openjdk.java.net/~kaddepalli/8194044/webrev02/

 

Thanks,

Krishna

 

From: Jayathirth D V 
Sent: Wednesday, January 10, 2018 4:16 PM
To: Krishna Addepalli <HYPERLINK "mailto:krishna.addepalli at oracle.com"krishna.addepalli at oracle.com>; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: RE: <Swing Dev> [10][11][JDK-8194044] Regression manual Test javax/swing/JFileChooser/8067660/FileChooserTest.java fails

 

Hi Krishna,

 

Please find my inputs:

 

Test case needs to be updated with minor changes:

 

1)      Copyright information needs to be added at the start of test file.

2)      Jtreg test summary needs to be updated to mention what the test is trying to achieve instead of JBS bug title.

3)      Also since this test is specific to Windows we can remove the OS test code present in test case with Jtreg @requires flag:

 

Instead of using the below code we can use @requires (os.family == "windows")

 

            if (OSInfo.getOSType() != OSInfo.OSType.WINDOWS) {

                                         System.out.println("The test is suitable only for Windows OS. Skipped.");

                                         return;

                    }

4)      For multiline comments at Line no 1 & 26 in test case please update the comment syntax to use :

/*

 *

 *

 */

 

Thanks,

Jay

 

From: Krishna Addepalli 
Sent: Tuesday, January 09, 2018 2:30 PM
To: Prasanta Sadhukhan; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10][11][JDK-8194044] Regression manual Test javax/swing/JFileChooser/8067660/FileChooserTest.java fails

 

Hi Prasanta,Sergey,

 

I have added a testcase along with the changes and created a new webrev : HYPERLINK "http://cr.openjdk.java.net/%7Ekaddepalli/8194044/webrev01/"http://cr.openjdk.java.net/~kaddepalli/8194044/webrev01/

 

Please review this and provide your comments.

 

Thanks,

Krishna

 

From: Prasanta Sadhukhan 
Sent: Thursday, January 4, 2018 10:54 AM
To: Krishna Addepalli <HYPERLINK "mailto:krishna.addepalli at oracle.com"krishna.addepalli at oracle.com>; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10][11][JDK-8194044] Regression manual Test javax/swing/JFileChooser/8067660/FileChooserTest.java fails

 

A regression test is added to prove that before your fix, java was failing and after your fix is applied, it is passing so it is not related to older/newer java versions. I saw we already have test/jdk/javax/swing/JFileChooser/6945316/bug6945316.java which tests isFileSystemRoot. Maybe, we can do something similar if it's not too much of a task.

Regards
Prasanta

On 1/3/2018 5:13 PM, Krishna Addepalli wrote:

Thanks for the review Prasanta. However, I don't see a point to write a test case for isFileSystemRoot(), since, it is not going to fail on any (older/newer) java versions, and it was only introduced because of the fix for JDK-8175015.

Let me know if you think otherwise.

 

Regards,

Krishna

From: Prasanta Sadhukhan 
Sent: Wednesday, January 3, 2018 11:27 AM
To: Krishna Addepalli HYPERLINK "mailto:krishna.addepalli at oracle.com"<krishna.addepalli at oracle.com>; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10][11][JDK-8194044] Regression manual Test javax/swing/JFileChooser/8067660/FileChooserTest.java fails

 

Fix looks fine. But I guess, it is possible to add a automated regression test to it utilising isFileSystemRoot().

Regards
Prasanta

On 1/2/2018 4:31 PM, Krishna Addepalli wrote:

Hi All,

 

Please review a fix for bug:

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

Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Ekaddepalli/8194044/webrev00/"http://cr.openjdk.java.net/~kaddepalli/8194044/webrev00/

 

This was caused due to the fix for JDK-8175015, in which the line 446  in Win32ShellFolderManager2.java was changed from "getDrives()" to Win32ShellFolder2.listRoots().

While the earlier function returns an object of Win32ShellFolder2, the latter returns an array of Files. 

The condition on line 450: "return (sf.isFileSystem()&&sf.parent != null && sf.parent.equals(Win32ShellFolder2.listRoots())" was returning false because of the wrong object being passed. Earlier it was a Win32ShellFolder2 object, and the comparision was done properly, but with the changes, the equals fucnction was receiving a file array object, and hence it was immediately returning false, leading to the problem of empty strings being shown for Root drives.

The fix is to replace "Win32ShellFolder2.listRoots()" with "getDrives()" function. With this fix, the regression is addressed, as well as the original JDK-8175015 which was a memory leak issue.

 

Thanks,

Krishna

 

 

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

From krishna.addepalli at oracle.com  Fri Jan 12 02:44:45 2018
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Thu, 11 Jan 2018 18:44:45 -0800 (PST)
Subject: <Swing Dev> [10][11][JDK-8194044] Regression manual Test
 javax/swing/JFileChooser/8067660/FileChooserTest.java fails
In-Reply-To: <4f6e0f77-dd3f-425e-bbeb-b4dead664a2e@default>
References: <91a8f44e-a18c-43f5-96b8-ab310399c348@default>
 <fb48167a-d960-f5c9-ad2e-92199ee47a39@oracle.com>
 <db9ba389-e151-4307-9fd1-e30adcf93234@default>
 <9471d86d-c59b-53b9-0b6c-4c2a9b8555a7@oracle.com>
 <c5b84c78-b7c9-4ff8-afc6-b3d05f47c30c@default>
 <d4cb6190-f03c-4c68-95aa-12fb07e7e89e@default>
 <6ce77bb1-d3a6-41b7-a646-2eb0c9e2d042@default>
 <a1cb5598-7898-42a1-956e-dac8cef938bd@default>
 <5da0d56c-ab35-41eb-b4ad-fef5ea6a43d9@default>
 <33acfa5b-bc66-4b95-a2d0-e7f9a5a0a186@default>
 <6471e2e5-de1f-7ebc-3b3b-0703c776857d@oracle.com>
 <4f6e0f77-dd3f-425e-bbeb-b4dead664a2e@default>
Message-ID: <e1dfee4b-a92f-4a63-971d-3d259236e3cb@default>

Hi Semyon,

 

Per our conversation, I have removed the loop, and also added the test for FileSystemView.getSystemDisplayName function as well.

Here is the new webrev: http://cr.openjdk.java.net/~kaddepalli/8194044/webrev04/

 

Thanks,

Krishna

 

From: Krishna Addepalli 
Sent: Wednesday, January 10, 2018 11:41 PM
To: Semyon Sadetsky <semyon.sadetsky at oracle.com>; Jayathirth D V <jayathirth.d.v at oracle.com>; swing-dev at openjdk.java.net
Subject: RE: <Swing Dev> [10][11][JDK-8194044] Regression manual Test javax/swing/JFileChooser/8067660/FileChooserTest.java fails

 

Hi Semyon, 

 

The idea was to test the ShellFolder path in the function "Win32ShellFolderManager2.isFileSystemRoot" function, which was being reported as false, before my fix. 

Secondly, "getShellFolder" function is package specific function, so I cannot invoke it directly from outside, so had to get a path to the default folder, and then keep getting the parent directory from there, till I come to root drive i.e "C:\\".

I adapted the code from the test that Prasanta suggested(have test/jdk/javax/swing/JFileChooser/6945316/bug6945316.java) which tests isFileSystemRoot, and simplified it, so left in the loop.

 

Thanks,

Krishna

 

From: Semyon Sadetsky 
Sent: Wednesday, January 10, 2018 10:29 PM
To: Jayathirth D V <HYPERLINK "mailto:jayathirth.d.v at oracle.com"jayathirth.d.v at oracle.com>; Krishna Addepalli <HYPERLINK "mailto:krishna.addepalli at oracle.com"krishna.addepalli at oracle.com>; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10][11][JDK-8194044] Regression manual Test javax/swing/JFileChooser/8067660/FileChooserTest.java fails

 

Hi Krishna,

The fix looks good. But I did not understand the test. In my understanding it should check that the next is not en empty:

FileSystemView.getFileSystemView().getSystemDisplayName(FileSystemView.getFileSystemView().getShellFolder(new File("C:\\")))

And why do you run the test 50 times?

--Semyon

On 1/10/2018 7:57 AM, Jayathirth D V wrote:

Hi Krishna,

 

Changes are fine.

 

Thanks,

Jay

 

From: Krishna Addepalli 
Sent: Wednesday, January 10, 2018 8:17 PM
To: Jayathirth D V; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: RE: <Swing Dev> [10][11][JDK-8194044] Regression manual Test javax/swing/JFileChooser/8067660/FileChooserTest.java fails

 

Hi Jay,

 

Thanks for the suggestions, and I have created a new webrev here: HYPERLINK "http://cr.openjdk.java.net/%7Ekaddepalli/8194044/webrev03/"http://cr.openjdk.java.net/~kaddepalli/8194044/webrev03/

 

However, I don't think Test if is a typo. It can be read as is and still makes sense.

 

Regards,

Krishna

 

From: Jayathirth D V 
Sent: Wednesday, January 10, 2018 6:18 PM
To: Krishna Addepalli <HYPERLINK "mailto:krishna.addepalli at oracle.com"krishna.addepalli at oracle.com>; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: RE: <Swing Dev> [10][11][JDK-8194044] Regression manual Test javax/swing/JFileChooser/8067660/FileChooserTest.java fails

 

Hi Krishna,

 

Please find my inputs:

 

1)      There is no need for Starting and Ending year in copyright of test case as it is a new file. Adding just 2018 would be enough. 

2)      Typo in jtreg summary : "Test if" it should be "Tests if".

3)      For multiline comments using /*..*/,  First line should be left empty in a block comment at Line no 24 & 42 and last line of block comment should have proper indentation at Line no 30. Java coding convention for comments : http://www.oracle.com/technetwork/java/codeconventions-141999.html 

 

Thanks,

Jay

 

From: Krishna Addepalli 
Sent: Wednesday, January 10, 2018 6:00 PM
To: Jayathirth D V; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: RE: <Swing Dev> [10][11][JDK-8194044] Regression manual Test javax/swing/JFileChooser/8067660/FileChooserTest.java fails

 

Hi Jay,

 

Thanks for your time and review. I have incorporated your review comments and created a new webrev here: HYPERLINK "http://cr.openjdk.java.net/%7Ekaddepalli/8194044/webrev02/"http://cr.openjdk.java.net/~kaddepalli/8194044/webrev02/

 

Thanks,

Krishna

 

From: Jayathirth D V 
Sent: Wednesday, January 10, 2018 4:16 PM
To: Krishna Addepalli <HYPERLINK "mailto:krishna.addepalli at oracle.com"krishna.addepalli at oracle.com>; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: RE: <Swing Dev> [10][11][JDK-8194044] Regression manual Test javax/swing/JFileChooser/8067660/FileChooserTest.java fails

 

Hi Krishna,

 

Please find my inputs:

 

Test case needs to be updated with minor changes:

 

1)      Copyright information needs to be added at the start of test file.

2)      Jtreg test summary needs to be updated to mention what the test is trying to achieve instead of JBS bug title.

3)      Also since this test is specific to Windows we can remove the OS test code present in test case with Jtreg @requires flag:

 

Instead of using the below code we can use @requires (os.family == "windows")

 

            if (OSInfo.getOSType() != OSInfo.OSType.WINDOWS) {

                                         System.out.println("The test is suitable only for Windows OS. Skipped.");

                                         return;

                    }

4)      For multiline comments at Line no 1 & 26 in test case please update the comment syntax to use :

/*

 *

 *

 */

 

Thanks,

Jay

 

From: Krishna Addepalli 
Sent: Tuesday, January 09, 2018 2:30 PM
To: Prasanta Sadhukhan; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10][11][JDK-8194044] Regression manual Test javax/swing/JFileChooser/8067660/FileChooserTest.java fails

 

Hi Prasanta,Sergey,

 

I have added a testcase along with the changes and created a new webrev : HYPERLINK "http://cr.openjdk.java.net/%7Ekaddepalli/8194044/webrev01/"http://cr.openjdk.java.net/~kaddepalli/8194044/webrev01/

 

Please review this and provide your comments.

 

Thanks,

Krishna

 

From: Prasanta Sadhukhan 
Sent: Thursday, January 4, 2018 10:54 AM
To: Krishna Addepalli <HYPERLINK "mailto:krishna.addepalli at oracle.com"krishna.addepalli at oracle.com>; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10][11][JDK-8194044] Regression manual Test javax/swing/JFileChooser/8067660/FileChooserTest.java fails

 

A regression test is added to prove that before your fix, java was failing and after your fix is applied, it is passing so it is not related to older/newer java versions. I saw we already have test/jdk/javax/swing/JFileChooser/6945316/bug6945316.java which tests isFileSystemRoot. Maybe, we can do something similar if it's not too much of a task.

Regards
Prasanta

On 1/3/2018 5:13 PM, Krishna Addepalli wrote:

Thanks for the review Prasanta. However, I don't see a point to write a test case for isFileSystemRoot(), since, it is not going to fail on any (older/newer) java versions, and it was only introduced because of the fix for JDK-8175015.

Let me know if you think otherwise.

 

Regards,

Krishna

From: Prasanta Sadhukhan 
Sent: Wednesday, January 3, 2018 11:27 AM
To: Krishna Addepalli HYPERLINK "mailto:krishna.addepalli at oracle.com"<krishna.addepalli at oracle.com>; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10][11][JDK-8194044] Regression manual Test javax/swing/JFileChooser/8067660/FileChooserTest.java fails

 

Fix looks fine. But I guess, it is possible to add a automated regression test to it utilising isFileSystemRoot().

Regards
Prasanta

On 1/2/2018 4:31 PM, Krishna Addepalli wrote:

Hi All,

 

Please review a fix for bug:

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

Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Ekaddepalli/8194044/webrev00/"http://cr.openjdk.java.net/~kaddepalli/8194044/webrev00/

 

This was caused due to the fix for JDK-8175015, in which the line 446  in Win32ShellFolderManager2.java was changed from "getDrives()" to Win32ShellFolder2.listRoots().

While the earlier function returns an object of Win32ShellFolder2, the latter returns an array of Files. 

The condition on line 450: "return (sf.isFileSystem()&&sf.parent != null && sf.parent.equals(Win32ShellFolder2.listRoots())" was returning false because of the wrong object being passed. Earlier it was a Win32ShellFolder2 object, and the comparision was done properly, but with the changes, the equals fucnction was receiving a file array object, and hence it was immediately returning false, leading to the problem of empty strings being shown for Root drives.

The fix is to replace "Win32ShellFolder2.listRoots()" with "getDrives()" function. With this fix, the regression is addressed, as well as the original JDK-8175015 which was a memory leak issue.

 

Thanks,

Krishna

 

 

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

From semyon.sadetsky at oracle.com  Fri Jan 12 03:07:04 2018
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Thu, 11 Jan 2018 19:07:04 -0800
Subject: <Swing Dev> [10][11][JDK-8194044] Regression manual Test
 javax/swing/JFileChooser/8067660/FileChooserTest.java fails
In-Reply-To: <e1dfee4b-a92f-4a63-971d-3d259236e3cb@default>
References: <91a8f44e-a18c-43f5-96b8-ab310399c348@default>
 <fb48167a-d960-f5c9-ad2e-92199ee47a39@oracle.com>
 <db9ba389-e151-4307-9fd1-e30adcf93234@default>
 <9471d86d-c59b-53b9-0b6c-4c2a9b8555a7@oracle.com>
 <c5b84c78-b7c9-4ff8-afc6-b3d05f47c30c@default>
 <d4cb6190-f03c-4c68-95aa-12fb07e7e89e@default>
 <6ce77bb1-d3a6-41b7-a646-2eb0c9e2d042@default>
 <a1cb5598-7898-42a1-956e-dac8cef938bd@default>
 <5da0d56c-ab35-41eb-b4ad-fef5ea6a43d9@default>
 <33acfa5b-bc66-4b95-a2d0-e7f9a5a0a186@default>
 <6471e2e5-de1f-7ebc-3b3b-0703c776857d@oracle.com>
 <4f6e0f77-dd3f-425e-bbeb-b4dead664a2e@default>
 <e1dfee4b-a92f-4a63-971d-3d259236e3cb@default>
Message-ID: <fe0880a7-ac88-eb4c-0725-bc532638c7f9@oracle.com>

+1

--Semyon


On 01/11/2018 06:44 PM, Krishna Addepalli wrote:
>
> Hi Semyon,
>
> Per our conversation, I have removed the loop, and also added the test 
> for FileSystemView.getSystemDisplayName function as well.
>
> Here is the new webrev: 
> http://cr.openjdk.java.net/~kaddepalli/8194044/webrev04/ 
> <http://cr.openjdk.java.net/%7Ekaddepalli/8194044/webrev04/>
>
> Thanks,
>
> Krishna
>
> *From:*Krishna Addepalli
> *Sent:* Wednesday, January 10, 2018 11:41 PM
> *To:* Semyon Sadetsky <semyon.sadetsky at oracle.com>; Jayathirth D V 
> <jayathirth.d.v at oracle.com>; swing-dev at openjdk.java.net
> *Subject:* RE: <Swing Dev> [10][11][JDK-8194044] Regression manual 
> Test javax/swing/JFileChooser/8067660/FileChooserTest.java fails
>
> Hi Semyon,
>
> The idea was to test the ShellFolder path in the function 
> ?Win32ShellFolderManager2.isFileSystemRoot? function, which was being 
> reported as false, before my fix.
>
> Secondly, ?getShellFolder? function is package specific function, so I 
> cannot invoke it directly from outside, so had to get a path to the 
> default folder, and then keep getting the parent directory from there, 
> till I come to root drive i.e ?C:\\?.
>
> I adapted the code from the test that Prasanta suggested(have 
> test/jdk/javax/swing/JFileChooser/6945316/bug6945316.java) which tests 
> isFileSystemRoot, and simplified it, so left in the loop.
>
> Thanks,
>
> Krishna
>
> *From:*Semyon Sadetsky
> *Sent:* Wednesday, January 10, 2018 10:29 PM
> *To:* Jayathirth D V <jayathirth.d.v at oracle.com 
> <mailto:jayathirth.d.v at oracle.com>>; Krishna Addepalli 
> <krishna.addepalli at oracle.com <mailto:krishna.addepalli at oracle.com>>; 
> swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>
> *Subject:* Re: <Swing Dev> [10][11][JDK-8194044] Regression manual 
> Test javax/swing/JFileChooser/8067660/FileChooserTest.java fails
>
> Hi Krishna,
>
> The fix looks good. But I did not understand the test. In my 
> understanding it should check that the next is not en empty:
>
> FileSystemView.getFileSystemView().getSystemDisplayName(FileSystemView.getFileSystemView().getShellFolder(new 
> File("C:\\")))
>
> And why do you run the test 50 times?
>
> --Semyon
>
> On 1/10/2018 7:57 AM, Jayathirth D V wrote:
>
>     Hi Krishna,
>
>     Changes are fine.
>
>     Thanks,
>
>     Jay
>
>     *From:*Krishna Addepalli
>     *Sent:* Wednesday, January 10, 2018 8:17 PM
>     *To:* Jayathirth D V; swing-dev at openjdk.java.net
>     <mailto:swing-dev at openjdk.java.net>
>     *Subject:* RE: <Swing Dev> [10][11][JDK-8194044] Regression manual
>     Test javax/swing/JFileChooser/8067660/FileChooserTest.java fails
>
>     Hi Jay,
>
>     Thanks for the suggestions, and I have created a new webrev here:
>     http://cr.openjdk.java.net/~kaddepalli/8194044/webrev03/
>     <http://cr.openjdk.java.net/%7Ekaddepalli/8194044/webrev03/>
>
>     However, I don?t think Test if is a typo. It can be read as is and
>     still makes sense.
>
>     Regards,
>
>     Krishna
>
>     *From:*Jayathirth D V
>     *Sent:* Wednesday, January 10, 2018 6:18 PM
>     *To:* Krishna Addepalli <krishna.addepalli at oracle.com
>     <mailto:krishna.addepalli at oracle.com>>; swing-dev at openjdk.java.net
>     <mailto:swing-dev at openjdk.java.net>
>     *Subject:* RE: <Swing Dev> [10][11][JDK-8194044] Regression manual
>     Test javax/swing/JFileChooser/8067660/FileChooserTest.java fails
>
>     Hi Krishna,
>
>     Please find my inputs:
>
>     1)There is no need for Starting and Ending year in copyright of
>     test case as it is a new file. Adding just 2018 would be enough.
>
>     2)Typo in jtreg summary : ?Test if? it should be ?Tests if?.
>
>     3)For multiline comments using /*..*/, ?First line should be left
>     empty in a block comment at Line no 24 & 42 and last line of block
>     comment should have proper indentation at Line no 30. Java coding
>     convention for comments :
>     http://www.oracle.com/technetwork/java/codeconventions-141999.html
>
>     Thanks,
>
>     Jay
>
>     *From:*Krishna Addepalli
>     *Sent:* Wednesday, January 10, 2018 6:00 PM
>     *To:* Jayathirth D V; swing-dev at openjdk.java.net
>     <mailto:swing-dev at openjdk.java.net>
>     *Subject:* RE: <Swing Dev> [10][11][JDK-8194044] Regression manual
>     Test javax/swing/JFileChooser/8067660/FileChooserTest.java fails
>
>     Hi Jay,
>
>     Thanks for your time and review. I have incorporated your review
>     comments and created a new webrev here:
>     http://cr.openjdk.java.net/~kaddepalli/8194044/webrev02/
>     <http://cr.openjdk.java.net/%7Ekaddepalli/8194044/webrev02/>
>
>     Thanks,
>
>     Krishna
>
>     *From:*Jayathirth D V
>     *Sent:* Wednesday, January 10, 2018 4:16 PM
>     *To:* Krishna Addepalli <krishna.addepalli at oracle.com
>     <mailto:krishna.addepalli at oracle.com>>; swing-dev at openjdk.java.net
>     <mailto:swing-dev at openjdk.java.net>
>     *Subject:* RE: <Swing Dev> [10][11][JDK-8194044] Regression manual
>     Test javax/swing/JFileChooser/8067660/FileChooserTest.java fails
>
>     Hi Krishna,
>
>     Please find my inputs:
>
>     Test case needs to be updated with minor changes:
>
>     1)Copyright information needs to be added at the start of test file.
>
>     2)Jtreg test summary needs to be updated to mention what the test
>     is trying to achieve instead of JBS bug title.
>
>     3)Also since this test is specific to Windows we can remove the OS
>     test code present in test case with Jtreg @requires flag:
>
>     Instead of using the below code we can use @requires (os.family ==
>     "windows")
>
>     ??????????? if (OSInfo.getOSType() != OSInfo.OSType.WINDOWS) {
>
>     System.out.println("The test is suitable only for Windows OS.
>     Skipped.");
>
>     return;
>
>     }
>
>     4)For multiline comments at Line no 1 & 26 in test case please
>     update the comment syntax to use :
>
>     /*
>
>     ?*
>
>     ?*
>
>     ?*/
>
>     Thanks,
>
>     Jay
>
>     *From:*Krishna Addepalli
>     *Sent:* Tuesday, January 09, 2018 2:30 PM
>     *To:* Prasanta Sadhukhan; swing-dev at openjdk.java.net
>     <mailto:swing-dev at openjdk.java.net>
>     *Subject:* Re: <Swing Dev> [10][11][JDK-8194044] Regression manual
>     Test javax/swing/JFileChooser/8067660/FileChooserTest.java fails
>
>     Hi Prasanta,Sergey,
>
>     I have added a testcase along with the changes and created a new
>     webrev : http://cr.openjdk.java.net/~kaddepalli/8194044/webrev01/
>     <http://cr.openjdk.java.net/%7Ekaddepalli/8194044/webrev01/>
>
>     Please review this and provide your comments.
>
>     Thanks,
>
>     Krishna
>
>     *From:*Prasanta Sadhukhan
>     *Sent:* Thursday, January 4, 2018 10:54 AM
>     *To:* Krishna Addepalli <krishna.addepalli at oracle.com
>     <mailto:krishna.addepalli at oracle.com>>; swing-dev at openjdk.java.net
>     <mailto:swing-dev at openjdk.java.net>
>     *Subject:* Re: <Swing Dev> [10][11][JDK-8194044] Regression manual
>     Test javax/swing/JFileChooser/8067660/FileChooserTest.java fails
>
>     A regression test is added to prove that before your fix, java was
>     failing and after your fix is applied, it is passing so it is not
>     related to older/newer java versions. I saw we already have
>     test/jdk/javax/swing/JFileChooser/6945316/bug6945316.java which
>     tests isFileSystemRoot. Maybe, we can do something similar if it's
>     not too much of a task.
>
>     Regards
>     Prasanta
>
>     On 1/3/2018 5:13 PM, Krishna Addepalli wrote:
>
>         Thanks for the review Prasanta. However, I don?t see a point
>         to write a test case for isFileSystemRoot(), since, it is not
>         going to fail on any (older/newer) java versions, and it was
>         only introduced because of the fix for JDK-8175015.
>
>         Let me know if you think otherwise.
>
>         Regards,
>
>         Krishna
>
>         *From:*Prasanta Sadhukhan
>         *Sent:* Wednesday, January 3, 2018 11:27 AM
>         *To:* Krishna Addepalli <krishna.addepalli at oracle.com>
>         <mailto:krishna.addepalli at oracle.com>;
>         swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>
>         *Subject:* Re: <Swing Dev> [10][11][JDK-8194044] Regression
>         manual Test
>         javax/swing/JFileChooser/8067660/FileChooserTest.java fails
>
>         Fix looks fine. But I guess, it is possible to add a automated
>         regression test to it utilising isFileSystemRoot().
>
>         Regards
>         Prasanta
>
>         On 1/2/2018 4:31 PM, Krishna Addepalli wrote:
>
>             Hi All,
>
>             Please review a fix for bug:
>
>             Bug: JDK-8194044 :
>             https://bugs.openjdk.java.net/browse/JDK-8194044
>
>             Webrev:
>             http://cr.openjdk.java.net/~kaddepalli/8194044/webrev00/
>             <http://cr.openjdk.java.net/%7Ekaddepalli/8194044/webrev00/>
>
>             This was caused due to the fix for JDK-8175015, in which
>             the line 446 ?in Win32ShellFolderManager2.java was changed
>             from ?getDrives()? to Win32ShellFolder2.listRoots().
>
>             While the earlier function returns an object of
>             Win32ShellFolder2, the latter returns an array of Files.
>
>             The condition on line 450: ?return
>             (sf.isFileSystem()&&sf.parent != null &&
>             sf.parent.equals(Win32ShellFolder2.listRoots())? was
>             returning false because of the wrong object being passed.
>             Earlier it was a Win32ShellFolder2 object, and the
>             comparision was done properly, but with the changes, the
>             equals fucnction was receiving a file array object, and
>             hence it was immediately returning false, leading to the
>             problem of empty strings being shown for Root drives.
>
>             The fix is to replace ?Win32ShellFolder2.listRoots()? with
>             ?getDrives()? function. With this fix, the regression is
>             addressed, as well as the original JDK-8175015 which was a
>             memory leak issue.
>
>             Thanks,
>
>             Krishna
>

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

From manajit.halder at oracle.com  Fri Jan 12 05:34:11 2018
From: manajit.halder at oracle.com (Manajit Halder)
Date: Fri, 12 Jan 2018 11:04:11 +0530
Subject: <Swing Dev> Swing dev>[10] Review request for JDK-8189253:
 [macos] JPopupMenu is inadvertently shown when using setComponentPopupMenu
In-Reply-To: <5e25040d-fc6f-a859-9484-443a7d1b5365@oracle.com>
References: <E1445698-445B-4542-98C1-1D82A4A182C9@oracle.com>
 <4ed5cbcf-c1f7-f615-6404-ebe13c47b8da@oracle.com>
 <C77A97FC-2163-455F-847D-C590D3B5D522@oracle.com>
 <bcd060d3-4553-55f5-4fee-b22d6313426e@oracle.com>
 <F10C8291-1722-4618-B2B5-C2DB14E7486C@oracle.com>
 <f7627a88-4d81-7105-59a0-fdf6872b62f2@oracle.com>
 <BE2F9413-3948-4BCF-A52D-F18E46AD7834@oracle.com>
 <6724f7b1-94c0-742b-081b-47dde62426b3@oracle.com>
 <71FF00F4-C636-435F-B192-DFEBFFBE7945@oracle.com>
 <5e25040d-fc6f-a859-9484-443a7d1b5365@oracle.com>
Message-ID: <E01FF86D-AD17-47DA-B2BB-3077EBF4AB4B@oracle.com>

Hi Semyon,

Thank you for the clarification. I will try to fix the problem in the native code.

Thanks,
Manajit


> On 10-Jan-2018, at 9:11 PM, Semyon Sadetsky <semyon.sadetsky at oracle.com> wrote:
> 
> Hi Manajit,
> 
> Not sure what did you mean under valid. The general approach is user may do with the mouse whatever he wants nevertheless UI should not be broken. This is just an indication the issue you are trying to fix may be a generic one.
> 
> --Semyon
> 
> On 01/10/2018 05:21 AM, Manajit Halder wrote:
>> Hi Semyon,
>> 
>> I could reproduce the behaviour on Ubuntu. But I am curious to know whether this particular mouse operation is a valid operation?
>> 
>> Thanks,
>> Manajit
>> 
>>> On 08-Jan-2018, at 10:06 PM, Semyon Sadetsky <semyon.sadetsky at oracle.com <mailto:semyon.sadetsky at oracle.com>> wrote:
>>> 
>>> Hi Manajit,
>>> 
>>> Still didn't get why are you limited to Mac platform  only while you change updates generic code. Why mouse provided by Apple matters here?
>>> --Semyon
>>> 
>>> On 01/08/2018 01:40 AM, Manajit Halder wrote:
>>>> Hi Semyon,
>>>> 
>>>> I could not reproduce the behaviour on Mac as on Mac this operation is not possible and hence it won?t be a problem on Mac. It is not possible to press the right button or the left button when the other button is already pressed using both Mouse provided by Apple and Track pad. Once the left button is pressed it need to be release to press the right button and vice versa. 
>>>> 
>>>> Thanks,
>>>> Manajit
>>>> 
>>>>> On 05-Jan-2018, at 7:08 AM, Semyon Sadetsky <semyon.sadetsky at oracle.com <mailto:semyon.sadetsky at oracle.com>> wrote:
>>>>> 
>>>>> Hi Manajit,
>>>>> 
>>>>> I could reproduce similar behaviour on Linux when mouse is dragged to another component with the left button pressed and then the right button is immediately  pressed. The popup is triggered by the same logic despite it isn't configured for the component. 
>>>>> --Semyon
>>>>> 
>>>>> On 01/04/2018 10:22 AM, Manajit Halder wrote:
>>>>>> Hi Semyon,
>>>>>> 
>>>>>> Fix for issue JDK-8080729 <https://bugs.openjdk.java.net/browse/JDK-8080729> has caused this regression due to changes in method setVisible(boolean visible) in file CPlatformWindow.java
>>>>>> orderWindow is causing the issue here, if we revert to addChildWindow then the issue is not observed but then the fix for issue JDK-8080729 fails.
>>>>>> Before this change the child window used to be added on to the parent as shown below in the commented code. But after the change child window is ordered above the parent.
>>>>>> 
>>>>>> Below code causes the regression:
>>>>>> 
>>>>>> CWrapper.NSWindow.orderWindow(ptr, CWrapper.NSWindow.NSWindowAbove, ownerPtr);
>>>>>> //CWrapper.NSWindow.addChildWindow(ownerPtr, ptr, CWrapper.NSWindow.NSWindowAbove);
>>>>>> 
>>>>>> Debugging further I found that if we use orderWindow then the new window is considered as new graphics device in the method notifyReshape in LWWindowPeer.java (the method updateGraphicsDevice() returns true) and is the difference between using orderWindow and addChildWindow.
>>>>>> 
>>>>>> Since the option to add child window is between choosing oderWindow and addChildWindow we don?t have any option to do the fix in the Mac OS native code.
>>>>>> 
>>>>>> Regards,
>>>>>> Manajit
>>>>>> 
>>>>>> 
>>>>>>> On 02-Jan-2018, at 11:30 PM, Semyon Sadetsky <semyon.sadetsky at oracle.com <mailto:semyon.sadetsky at oracle.com>> wrote:
>>>>>>> 
>>>>>>> Hi Manajit,
>>>>>>> 
>>>>>>> JDK-8080729 bug was Mac OS specific issue and its fix changed the Mac OS code only. Nevertheless you are suggesting to fix the regression in generic code. This need to be explained somehow.
>>>>>>> 
>>>>>>> --Semyon
>>>>>>> On 12/25/2017 02:42 AM, Manajit Halder wrote:
>>>>>>>> Hi Semyon,
>>>>>>>> 
>>>>>>>> Regression is cause by JDK-8080729 <https://bugs.openjdk.java.net/browse/JDK-8080729>. The fix can?t be reversed since it is the choice between addChildWindow or orderWindow. Went through code flow related to the issue but didn?t find any other better place in code to handle this issue. The best way to fix the issue would be to avoid retargeting of events (MOUSE_ENTER and MOUSE_EXIT) between MOUSE_PRESS and MOUSE_RELEASE on the parent window (when the mouse is actually on the child window). Therefore request you to review the webrev.00.
>>>>>>>> 
>>>>>>>> Regards,
>>>>>>>> Manajit
>>>>>>>> 
>>>>>>>>> On 08-Dec-2017, at 9:55 PM, semyon.sadetsky at oracle.com <mailto:semyon.sadetsky at oracle.com> wrote:
>>>>>>>>> 
>>>>>>>>> Hi Manajit,
>>>>>>>>> 
>>>>>>>>> Can you provide information which fix caused the regression?
>>>>>>>>> 
>>>>>>>>> --Semyon
>>>>>>>>> 
>>>>>>>>> On 12/8/17 5:53 AM, Manajit Halder wrote:
>>>>>>>>>> Hi All,
>>>>>>>>>> 
>>>>>>>>>> Kindly review the following Swing fix.
>>>>>>>>>> 
>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8189253 <https://bugs.openjdk.java.net/browse/JDK-8189253>
>>>>>>>>>> Webrev: http://cr.openjdk.java.net/~mhalder/8189253/webrev.00/ <http://cr.openjdk.java.net/%7Emhalder/8189253/webrev.00/>
>>>>>>>>>> 
>>>>>>>>>> Cause: 
>>>>>>>>>> 	Issue was due to retargeting of mouse enter exit events. 
>>>>>>>>>> 	MOUSE_ENTER and MOUSE_EXIT events were sent on the parent window (JFrame) in between MOUSE_PRESS and MOUSE_RELEASE events on the modeless JDialog.
>>>>>>>>>> 
>>>>>>>>>> Fix:
>>>>>>>>>> 	Retargeting of events is not done in-between MOUSE_PRESS and MOUSE_RELEASE.
>>>>>>>>>> 
>>>>>>>>>> Regards,
>>>>>>>>>> Manajit
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 

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

From Sergey.Bylokhov at oracle.com  Tue Jan 16 17:47:21 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 16 Jan 2018 09:47:21 -0800
Subject: <Swing Dev> [11] Review Request: JDK-5076761 :
 JList.setSelectedValue(null, ...) doesn't do anything
In-Reply-To: <70ad5094-e10d-65ba-f507-0d79f987a2b6@oracle.com>
References: <417f68fe-4565-40b1-b360-e6ff9e18dd33@default>
 <da38a552-d357-b86d-399e-ba1b90fca79f@oracle.com>
 <d1d36b2a-1ca9-44ea-8e50-a819a20b7980@default>
 <6e0afc35-f779-7801-cfea-d0416f322db4@oracle.com>
 <e59b096d-a4ed-4ac8-ad0e-a891ac8fab0b@default>
 <010ef445-754d-520d-c78b-c87dd98ee8dd@oracle.com>
 <fced1c2d-592a-f358-52dd-775b079d0d5f@oracle.com>
 <16167828-181b-60ca-c7c7-2f810f43cd88@oracle.com>
 <70ad5094-e10d-65ba-f507-0d79f987a2b6@oracle.com>
Message-ID: <86bfcff9-e257-ef4f-fc60-e7d32351b1d4@oracle.com>

On 08/01/2018 08:25, Semyon Sadetsky wrote:
>> On 05/01/2018 18:01, Semyon Sadetsky wrote:
>>> Can you explain what is wrong with the suggested? approach?? It is 
>>> flexible to handle both null and non-null containing JList.
>>
>> Because it is wrong direction try to support some approach which is 
>> undefined behavior. The null has a special meaning in 
>> JList.getSelectedValue/setSelectedValue() as well as in a few other 
>> methods mentioned below. The usage of unspecified null values may 
>> result in a run time exception either immediately or at some later time.
> I didn't find any spec that mentions null as a special value

I already listed a methods which use null as an absent of the value. And 
current methods were implemented with this intention.

>  as well as any pointer that JList couldn't contain null.

There are no references to null in the javadoc which means that null is 
unsupported. By default the null value is unsupported, and it can be 
considered as supported only if spec accept that.

> getSelectedValue() may not be an indicator because there are several 
> replacements setSelectedIndex(), setSelectedIndices(), 
> getSelectedValues(), getSelectedValuesList() which supports null.
> Other components are unrelated.
Why JComboBox.setSelectedItem() and JList.setSelectedValue() are 
unrelated? Both are quite similar and have similar logic. Moreover 
JComboBox.setSelectedItem() has much more detailed description which we 
should use as an example.

-- 
Best regards, Sergey.


From pankaj.b.bansal at oracle.com  Wed Jan 17 11:54:27 2018
From: pankaj.b.bansal at oracle.com (Pankaj Bansal)
Date: Wed, 17 Jan 2018 03:54:27 -0800 (PST)
Subject: <Swing Dev> [11] Review Request: JDK-7007967 DefaultRowSorter:
 incorrect sorting due to not updating comparator cache
Message-ID: <cd5205e0-8203-42b5-b3af-1f72aedb5ca5@default>

Hi All,

 

Please review the fix for JDK 11.

 

Bug:

https://bugs.openjdk.java.net/browse/JDK-7007967

 

Webrev:

http://cr.openjdk.java.net/~pbansal/7007967/webrev.00/

 

Issue:

The caching flags like useToString, comparators etc are not always updated in shouldOptimizeChange function. It can cause wrong cache to be used in some cases and produce wrong sorting results. 
 
For example, in the submitted test case, the integer data is added and sorted. This updates the useToString etc cache flags according to the data type provided.  //Sorts 1,2,11 as 1->2->11 (correct).
Then all the data is removed from the model and when the sorter is indicated of this, the cache flags get updated accordingly. Because of this, the useToString is set to true for the column and comparator is set to String Comparator and sorted flag is still true.
Now if Integer data rows are again added one by one, these flags are not updated and it will use the wrong caches of useToString, comparators etc and produce wrong sorting results. //Sorts 1,2,11 as 1->11->2 (Incorrect. The data is sorted according to String representation).

 

 

Fix:

There can be different approaches to solve this issue. In the current approach, changes have been done in shouldOptimizeChange function to call the sort function when first row is added to the model. This will ensure that the cache flags like useToString, comparators are updated according to the data added for the column.

 

Regards,

Pankaj Bansal

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

From semyon.sadetsky at oracle.com  Wed Jan 17 16:41:11 2018
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Wed, 17 Jan 2018 08:41:11 -0800
Subject: <Swing Dev> [11] Review Request: JDK-5076761 :
 JList.setSelectedValue(null, ...) doesn't do anything
In-Reply-To: <86bfcff9-e257-ef4f-fc60-e7d32351b1d4@oracle.com>
References: <417f68fe-4565-40b1-b360-e6ff9e18dd33@default>
 <da38a552-d357-b86d-399e-ba1b90fca79f@oracle.com>
 <d1d36b2a-1ca9-44ea-8e50-a819a20b7980@default>
 <6e0afc35-f779-7801-cfea-d0416f322db4@oracle.com>
 <e59b096d-a4ed-4ac8-ad0e-a891ac8fab0b@default>
 <010ef445-754d-520d-c78b-c87dd98ee8dd@oracle.com>
 <fced1c2d-592a-f358-52dd-775b079d0d5f@oracle.com>
 <16167828-181b-60ca-c7c7-2f810f43cd88@oracle.com>
 <70ad5094-e10d-65ba-f507-0d79f987a2b6@oracle.com>
 <86bfcff9-e257-ef4f-fc60-e7d32351b1d4@oracle.com>
Message-ID: <ea93e634-8743-76a0-d054-b4182201127a@oracle.com>



On 01/16/2018 09:47 AM, Sergey Bylokhov wrote:
> On 08/01/2018 08:25, Semyon Sadetsky wrote:
>>> On 05/01/2018 18:01, Semyon Sadetsky wrote:
>>>> Can you explain what is wrong with the suggested? approach?? It is 
>>>> flexible to handle both null and non-null containing JList.
>>>
>>> Because it is wrong direction try to support some approach which is 
>>> undefined behavior. The null has a special meaning in 
>>> JList.getSelectedValue/setSelectedValue() as well as in a few other 
>>> methods mentioned below. The usage of unspecified null values may 
>>> result in a run time exception either immediately or at some later 
>>> time.
>> I didn't find any spec that mentions null as a special value
>
> I already listed a methods which use null as an absent of the value. 
> And current methods were implemented with this intention.
But JList is fully usable without them.
>
>> ?as well as any pointer that JList couldn't contain null.
>
> There are no references to null in the javadoc which means that null 
> is unsupported. By default the null value is unsupported, and it can 
> be considered as supported only if spec accept that.
That is a good argument that proves that null is not considered as a 
special value.
>
>> getSelectedValue() may not be an indicator because there are several 
>> replacements setSelectedIndex(), setSelectedIndices(), 
>> getSelectedValues(), getSelectedValuesList() which supports null.
>> Other components are unrelated.
> Why JComboBox.setSelectedItem() and JList.setSelectedValue() are 
> unrelated? Both are quite similar and have similar logic. Moreover 
> JComboBox.setSelectedItem() has much more detailed description which 
> we should use as an example.
>
Those are different type of controls. For example, in JComboBox 
setSelectedIndex(-1) clears selection unlike JList. Why you don't 
propose to fix the current issue by making setSelectedIndex(-1) clearing 
selection in JList?
And JComboBox may contain null as well.
If we look at JFX ListView it may also contain null.



From Sergey.Bylokhov at oracle.com  Wed Jan 17 16:53:29 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 17 Jan 2018 08:53:29 -0800
Subject: <Swing Dev> [11] Review Request: JDK-5076761 :
 JList.setSelectedValue(null, ...) doesn't do anything
In-Reply-To: <ea93e634-8743-76a0-d054-b4182201127a@oracle.com>
References: <417f68fe-4565-40b1-b360-e6ff9e18dd33@default>
 <da38a552-d357-b86d-399e-ba1b90fca79f@oracle.com>
 <d1d36b2a-1ca9-44ea-8e50-a819a20b7980@default>
 <6e0afc35-f779-7801-cfea-d0416f322db4@oracle.com>
 <e59b096d-a4ed-4ac8-ad0e-a891ac8fab0b@default>
 <010ef445-754d-520d-c78b-c87dd98ee8dd@oracle.com>
 <fced1c2d-592a-f358-52dd-775b079d0d5f@oracle.com>
 <16167828-181b-60ca-c7c7-2f810f43cd88@oracle.com>
 <70ad5094-e10d-65ba-f507-0d79f987a2b6@oracle.com>
 <86bfcff9-e257-ef4f-fc60-e7d32351b1d4@oracle.com>
 <ea93e634-8743-76a0-d054-b4182201127a@oracle.com>
Message-ID: <69a22f00-fbba-5c51-6070-0455bfe86674@oracle.com>

On 17/01/2018 08:41, Semyon Sadetsky wrote:
>> I already listed a methods which use null as an absent of the value. 
>> And current methods were implemented with this intention.
> But JList is fully usable without them.

No because getSelectedValue() will return null if no elements is selected.

>>
>>> ?as well as any pointer that JList couldn't contain null.
>>
>> There are no references to null in the javadoc which means that null 
>> is unsupported. By default the null value is unsupported, and it can 
>> be considered as supported only if spec accept that.
> That is a good argument that proves that null is not considered as a 
> special value.

What argument? There are no description that null is supported, but 
there are a description that null is used in somecases like 
getSelectedValue().


-- 
Best regards, Sergey.


From pankaj.b.bansal at oracle.com  Thu Jan 18 14:47:54 2018
From: pankaj.b.bansal at oracle.com (Pankaj Bansal)
Date: Thu, 18 Jan 2018 06:47:54 -0800 (PST)
Subject: <Swing Dev> [11] Review Request: JDK-5076761 :
 JList.setSelectedValue(null, ...) doesn't do anything
In-Reply-To: <69a22f00-fbba-5c51-6070-0455bfe86674@oracle.com>
References: <417f68fe-4565-40b1-b360-e6ff9e18dd33@default>
 <da38a552-d357-b86d-399e-ba1b90fca79f@oracle.com>
 <d1d36b2a-1ca9-44ea-8e50-a819a20b7980@default>
 <6e0afc35-f779-7801-cfea-d0416f322db4@oracle.com>
 <e59b096d-a4ed-4ac8-ad0e-a891ac8fab0b@default>
 <010ef445-754d-520d-c78b-c87dd98ee8dd@oracle.com>
 <fced1c2d-592a-f358-52dd-775b079d0d5f@oracle.com>
 <16167828-181b-60ca-c7c7-2f810f43cd88@oracle.com>
 <70ad5094-e10d-65ba-f507-0d79f987a2b6@oracle.com>
 <86bfcff9-e257-ef4f-fc60-e7d32351b1d4@oracle.com>
 <ea93e634-8743-76a0-d054-b4182201127a@oracle.com>
 <69a22f00-fbba-5c51-6070-0455bfe86674@oracle.com>
Message-ID: <d28b5f20-ed72-46bc-9530-04fc3e989f3a@default>

Hi Sergey/Semyon,

I have updated the code to clear selection if the object passed is null. It makes sense to do that as GetSelectedValue returns null if nothing is selected. This makes these two functions compatible in JList.
I think we can deal with clearing selection if the object passed is not present in the JList in some other bug. Present bug only talks about the case when the Object passed in null.

Please share your thoughts on this.

webrev:
http://cr.openjdk.java.net/~pbansal/5076761/webrev.06/

Regards,
Pankaj Bansal

-----Original Message-----
From: Sergey Bylokhov 
Sent: Wednesday, January 17, 2018 10:23 PM
To: Semyon Sadetsky; Pankaj Bansal; swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [11] Review Request: JDK-5076761 : JList.setSelectedValue(null, ...) doesn't do anything

On 17/01/2018 08:41, Semyon Sadetsky wrote:
>> I already listed a methods which use null as an absent of the value. 
>> And current methods were implemented with this intention.
> But JList is fully usable without them.

No because getSelectedValue() will return null if no elements is selected.

>>
>>> ?as well as any pointer that JList couldn't contain null.
>>
>> There are no references to null in the javadoc which means that null 
>> is unsupported. By default the null value is unsupported, and it can 
>> be considered as supported only if spec accept that.
> That is a good argument that proves that null is not considered as a 
> special value.

What argument? There are no description that null is supported, but there are a description that null is used in somecases like getSelectedValue().


--
Best regards, Sergey.


From krishna.addepalli at oracle.com  Thu Jan 18 18:02:15 2018
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Thu, 18 Jan 2018 10:02:15 -0800 (PST)
Subject: <Swing Dev> [11][JDK-8176512][TEST_BUG] add a minimal delay to
 java/awt/Paint/bug8024864.java
Message-ID: <b10d1925-7636-4d32-bd09-2bfea0659fd9@default>

Hi All,

 

Please review a fix for 

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

Webrev: http://cr.openjdk.java.net/~kaddepalli/8176512/webrev00/

 

The problem is the testcase randomly fails on OEL. So the solution is to use CyclicBarrier to ensure that the window is shown on the screen before attempting to get the colors in particular location.

 

Thanks,

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

From krishna.addepalli at oracle.com  Thu Jan 18 18:44:06 2018
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Thu, 18 Jan 2018 10:44:06 -0800 (PST)
Subject: <Swing Dev> [11][JDK-8137101][TEST_BUG]
 javax/swing/plaf/basic/BasicHTML/4251579/bug4251579.java failure due to
 timing
Message-ID: <e5bd1338-4a68-483b-949b-29c87684df12@default>

Hi All,

 

Please review a fix for following bug:

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

Webrev: http://cr.openjdk.java.net/~kaddepalli/8137101/webrev00/

 

The problem is that EDT doesnot get enough time to show the window on screen before the next function tries to pick colors from the screen. The solution is to use CountDownLatch to make the main thread wait deterministically before trying to pick colors.

 

Thanks,

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

From philip.race at oracle.com  Thu Jan 18 18:52:43 2018
From: philip.race at oracle.com (Philip Race)
Date: Thu, 18 Jan 2018 10:52:43 -0800
Subject: <Swing Dev> [11][JDK-8137101][TEST_BUG]
 javax/swing/plaf/basic/BasicHTML/4251579/bug4251579.java failure due to
 timing
In-Reply-To: <e5bd1338-4a68-483b-949b-29c87684df12@default>
References: <e5bd1338-4a68-483b-949b-29c87684df12@default>
Message-ID: <5A60ECFB.6030402@oracle.com>

Looks fine although fix the formatting  here where there is a missing 
space before catch :

+        }catch (InterruptedException ex) {


-phil.

On 1/18/18, 10:44 AM, Krishna Addepalli wrote:
>
> Hi All,
>
> Please review a fix for following bug:
>
> Bug: JDK-8137101 : https://bugs.openjdk.java.net/browse/JDK-8137101
>
> Webrev: http://cr.openjdk.java.net/~kaddepalli/8137101/webrev00/ 
> <http://cr.openjdk.java.net/%7Ekaddepalli/8137101/webrev00/>
>
> The problem is that EDT doesnot get enough time to show the window on 
> screen before the next function tries to pick colors from the screen. 
> The solution is to use CountDownLatch to make the main thread wait 
> deterministically before trying to pick colors.
>
> Thanks,
>
> Krishna
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20180118/d7e7c466/attachment.html>

From Sergey.Bylokhov at oracle.com  Thu Jan 18 22:56:05 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 18 Jan 2018 14:56:05 -0800
Subject: <Swing Dev> [11][JDK-8176512][TEST_BUG] add a minimal delay to
 java/awt/Paint/bug8024864.java
In-Reply-To: <b10d1925-7636-4d32-bd09-2bfea0659fd9@default>
References: <b10d1925-7636-4d32-bd09-2bfea0659fd9@default>
Message-ID: <b4e7cf22-ba71-1bf0-616a-78261e37883b@oracle.com>

Hi, Krishna.
Can you please check why "robot.waitForIdle()" does not work?

On 18/01/2018 10:02, Krishna Addepalli wrote:
> Hi All,
> 
> Please review a fix for
> 
> Bug: JDK-8176512: https://bugs.openjdk.java.net/browse/JDK-8176512
> 
> Webrev: http://cr.openjdk.java.net/~kaddepalli/8176512/webrev00/
> 
> The problem is the testcase randomly fails on OEL. So the solution is to 
> use CyclicBarrier to ensure that the window is shown on the screen 
> before attempting to get the colors in particular location.
> 
> Thanks,
> 
> Krishna
> 


-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Thu Jan 18 22:58:12 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 18 Jan 2018 14:58:12 -0800
Subject: <Swing Dev> [11][JDK-8137101][TEST_BUG]
 javax/swing/plaf/basic/BasicHTML/4251579/bug4251579.java failure due to
 timing
In-Reply-To: <e5bd1338-4a68-483b-949b-29c87684df12@default>
References: <e5bd1338-4a68-483b-949b-29c87684df12@default>
Message-ID: <3a5f3452-6c33-d16d-7e29-ba1c5e17f628@oracle.com>

Hi, Krishna.
I have the same question as in another bug: why robot.waitForIdle() does 
not work?

On 18/01/2018 10:44, Krishna Addepalli wrote:
> Hi All,
> 
> Please review a fix for following bug:
> 
> Bug: JDK-8137101 : https://bugs.openjdk.java.net/browse/JDK-8137101
> 
> Webrev: http://cr.openjdk.java.net/~kaddepalli/8137101/webrev00/
> 
> The problem is that EDT doesnot get enough time to show the window on 
> screen before the next function tries to pick colors from the screen. 
> The solution is to use CountDownLatch to make the main thread wait 
> deterministically before trying to pick colors.
> 
> Thanks,
> 
> Krishna
> 


-- 
Best regards, Sergey.


From semyon.sadetsky at oracle.com  Fri Jan 19 01:31:37 2018
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Thu, 18 Jan 2018 17:31:37 -0800
Subject: <Swing Dev> [11] Review Request: JDK-5076761 :
 JList.setSelectedValue(null, ...) doesn't do anything
In-Reply-To: <d28b5f20-ed72-46bc-9530-04fc3e989f3a@default>
References: <417f68fe-4565-40b1-b360-e6ff9e18dd33@default>
 <da38a552-d357-b86d-399e-ba1b90fca79f@oracle.com>
 <d1d36b2a-1ca9-44ea-8e50-a819a20b7980@default>
 <6e0afc35-f779-7801-cfea-d0416f322db4@oracle.com>
 <e59b096d-a4ed-4ac8-ad0e-a891ac8fab0b@default>
 <010ef445-754d-520d-c78b-c87dd98ee8dd@oracle.com>
 <fced1c2d-592a-f358-52dd-775b079d0d5f@oracle.com>
 <16167828-181b-60ca-c7c7-2f810f43cd88@oracle.com>
 <70ad5094-e10d-65ba-f507-0d79f987a2b6@oracle.com>
 <86bfcff9-e257-ef4f-fc60-e7d32351b1d4@oracle.com>
 <ea93e634-8743-76a0-d054-b4182201127a@oracle.com>
 <69a22f00-fbba-5c51-6070-0455bfe86674@oracle.com>
 <d28b5f20-ed72-46bc-9530-04fc3e989f3a@default>
Message-ID: <37c68396-9925-ad35-eb61-d24f2157e187@oracle.com>

Hi Pankaj,

This version I like more since it doesn't clear selection after an 
attempt to set it to nonexistent item.? You have my +1.

There is still a nonzero risk of incompatibility with old applications 
you need to mention in the CSR.

--Semyon


On 01/18/2018 06:47 AM, Pankaj Bansal wrote:
> Hi Sergey/Semyon,
>
> I have updated the code to clear selection if the object passed is null. It makes sense to do that as GetSelectedValue returns null if nothing is selected. This makes these two functions compatible in JList.
> I think we can deal with clearing selection if the object passed is not present in the JList in some other bug. Present bug only talks about the case when the Object passed in null.
>
> Please share your thoughts on this.
>
> webrev:
> http://cr.openjdk.java.net/~pbansal/5076761/webrev.06/
>
> Regards,
> Pankaj Bansal
>
> -----Original Message-----
> From: Sergey Bylokhov
> Sent: Wednesday, January 17, 2018 10:23 PM
> To: Semyon Sadetsky; Pankaj Bansal; swing-dev at openjdk.java.net
> Subject: Re: <Swing Dev> [11] Review Request: JDK-5076761 : JList.setSelectedValue(null, ...) doesn't do anything
>
> On 17/01/2018 08:41, Semyon Sadetsky wrote:
>>> I already listed a methods which use null as an absent of the value.
>>> And current methods were implemented with this intention.
>> But JList is fully usable without them.
> No because getSelectedValue() will return null if no elements is selected.
>
>>>>  ?as well as any pointer that JList couldn't contain null.
>>> There are no references to null in the javadoc which means that null
>>> is unsupported. By default the null value is unsupported, and it can
>>> be considered as supported only if spec accept that.
>> That is a good argument that proves that null is not considered as a
>> special value.
> What argument? There are no description that null is supported, but there are a description that null is used in somecases like getSelectedValue().
>
>
> --
> Best regards, Sergey.



From krishna.addepalli at oracle.com  Fri Jan 19 02:39:37 2018
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Thu, 18 Jan 2018 18:39:37 -0800 (PST)
Subject: <Swing Dev> [11][JDK-8137101][TEST_BUG]
 javax/swing/plaf/basic/BasicHTML/4251579/bug4251579.java failure due to
 timing
In-Reply-To: <3a5f3452-6c33-d16d-7e29-ba1c5e17f628@oracle.com>
References: <e5bd1338-4a68-483b-949b-29c87684df12@default>
 <3a5f3452-6c33-d16d-7e29-ba1c5e17f628@oracle.com>
Message-ID: <8a4572df-7af7-4b0f-add7-74e86116a1ed@default>

Hi Sergey,
Just repeating the same answer in this thread as well.

Here is my understanding of waitForIdle() - it ensures that all the events on the EDT are pushed, and it has a huge wait time of 10seconds, which should mostly guarantee that there are no pending events on the EDT till the function is executed. And it mostly works on all platforms. The test case failed on OEL, whereas it passed on Windows and Linux. I haven't checked for Mac, but most likely it would work there too. 
The testcase in question tries to paint the window, and then picks the color from a particular location on screen. The function bug8024864::showTestUI has frame.setVisible(true) as its last statement, which should ultimately generate a native paint event. Now waitForIdle will ensure that, that event has been posted, but paint/repaint will involve some work down the OS level. Now, it could be possible that, the scheduler might choose to suspend the EDT thread and run the main thread, which checks for the pixel color on the screen and it might fail.
So, although waitForIdle guarantees dispatch of all the events from the EDT, it doesnot guarantee that they have been processed. 
Hence the changes I have made to make sure that the window has been drawn on to the screen.

As a sidenote, I was looking into the code, and found this kind of code in SunToolkit.realSync:
            int iters = 0;
            while (iters < MIN_ITERS) {
                syncNativeQueue(timeout);
                iters++;
            }

The MIN_ITERS is set as 0, so this code never executes. Either the loop should be changed to do-while, or should be removed. There is another loop which does the actual work:
            while (syncNativeQueue(timeout) && iters < MAX_ITERS) {
                iters++;
            }

Let me know your thoughts on this.

Thanks,
Krishna

-----Original Message-----
From: Sergey Bylokhov 
Sent: Friday, January 19, 2018 4:28 AM
To: Krishna Addepalli <krishna.addepalli at oracle.com>; swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [11][JDK-8137101][TEST_BUG] javax/swing/plaf/basic/BasicHTML/4251579/bug4251579.java failure due to timing

Hi, Krishna.
I have the same question as in another bug: why robot.waitForIdle() does not work?

On 18/01/2018 10:44, Krishna Addepalli wrote:
> Hi All,
> 
> Please review a fix for following bug:
> 
> Bug: JDK-8137101 : https://bugs.openjdk.java.net/browse/JDK-8137101
> 
> Webrev: http://cr.openjdk.java.net/~kaddepalli/8137101/webrev00/
> 
> The problem is that EDT doesnot get enough time to show the window on 
> screen before the next function tries to pick colors from the screen.
> The solution is to use CountDownLatch to make the main thread wait 
> deterministically before trying to pick colors.
> 
> Thanks,
> 
> Krishna
> 


--
Best regards, Sergey.


From krishna.addepalli at oracle.com  Fri Jan 19 02:36:33 2018
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Thu, 18 Jan 2018 18:36:33 -0800 (PST)
Subject: <Swing Dev> [11][JDK-8176512][TEST_BUG] add a minimal delay to
 java/awt/Paint/bug8024864.java
In-Reply-To: <b4e7cf22-ba71-1bf0-616a-78261e37883b@oracle.com>
References: <b10d1925-7636-4d32-bd09-2bfea0659fd9@default>
 <b4e7cf22-ba71-1bf0-616a-78261e37883b@oracle.com>
Message-ID: <8605a161-6f55-4dcc-8c59-024ea9fb4b35@default>

Hi Sergey,

Here is my understanding of waitForIdle() - it ensures that all the events on the EDT are pushed, and it has a huge wait time of 10seconds, which should mostly guarantee that there are no pending events on the EDT till the function is executed. And it mostly works on all platforms. The test case failed on OEL, whereas it passed on Windows and Linux. I haven't checked for Mac, but most likely it would work there too. 
The testcase in question tries to paint the window, and then picks the color from a particular location on screen. The function bug8024864::showTestUI has frame.setVisible(true) as its last statement, which should ultimately generate a native paint event. Now waitForIdle will ensure that, that event has been posted, but paint/repaint will involve some work down the OS level. Now, it could be possible that, the scheduler might choose to suspend the EDT thread and run the main thread, which checks for the pixel color on the screen and it might fail.
So, although waitForIdle guarantees dispatch of all the events from the EDT, it doesnot guarantee that they have been processed. 
Hence the changes I have made to make sure that the window has been drawn on to the screen.

As a sidenote, I was looking into the code, and found this kind of code in SunToolkit.realSync:
            int iters = 0;
            while (iters < MIN_ITERS) {
                syncNativeQueue(timeout);
                iters++;
            }

The MIN_ITERS is set as 0, so this code never executes. Either the loop should be changed to do-while, or should be removed. There is another loop which does the actual work:
            while (syncNativeQueue(timeout) && iters < MAX_ITERS) {
                iters++;
            }

Let me know your thoughts on this.

Thanks,
Krishna

-----Original Message-----
From: Sergey Bylokhov 
Sent: Friday, January 19, 2018 4:26 AM
To: Krishna Addepalli <krishna.addepalli at oracle.com>; swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [11][JDK-8176512][TEST_BUG] add a minimal delay to java/awt/Paint/bug8024864.java

Hi, Krishna.
Can you please check why "robot.waitForIdle()" does not work?

On 18/01/2018 10:02, Krishna Addepalli wrote:
> Hi All,
> 
> Please review a fix for
> 
> Bug: JDK-8176512: https://bugs.openjdk.java.net/browse/JDK-8176512
> 
> Webrev: http://cr.openjdk.java.net/~kaddepalli/8176512/webrev00/
> 
> The problem is the testcase randomly fails on OEL. So the solution is 
> to use CyclicBarrier to ensure that the window is shown on the screen 
> before attempting to get the colors in particular location.
> 
> Thanks,
> 
> Krishna
> 


--
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Fri Jan 19 03:11:24 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 18 Jan 2018 19:11:24 -0800
Subject: <Swing Dev> [11][JDK-8176512][TEST_BUG] add a minimal delay to
 java/awt/Paint/bug8024864.java
In-Reply-To: <8605a161-6f55-4dcc-8c59-024ea9fb4b35@default>
References: <b10d1925-7636-4d32-bd09-2bfea0659fd9@default>
 <b4e7cf22-ba71-1bf0-616a-78261e37883b@oracle.com>
 <8605a161-6f55-4dcc-8c59-024ea9fb4b35@default>
Message-ID: <f4c07d69-b7ad-d27b-1f37-636944da69cb@oracle.com>

On 18/01/2018 18:36, Krishna Addepalli wrote:
> Here is my understanding of waitForIdle() - it ensures that all the events on the EDT are pushed, and it has a huge wait time of 10seconds, which should mostly guarantee that there are no pending events on the EDT till the function is executed. And it mostly works on all platforms. The test case failed on OEL, whereas it passed on Windows and Linux. I haven't checked for Mac, but most likely it would work there too.
> The testcase in question tries to paint the window, and then picks the color from a particular location on screen. The function bug8024864::showTestUI has frame.setVisible(true) as its last statement, which should ultimately generate a native paint event. Now waitForIdle will ensure that, that event has been posted, but paint/repaint will involve some work down the OS level. Now, it could be possible that, the scheduler might choose to suspend the EDT thread and run the main thread, which checks for the pixel color on the screen and it might fail.

waitForIdle() was implemented in a way that it should block the thread 
on which it was run until all events will be processed on EDT *and* on 
native queue. It also takes into account that if at least one event was 
processed on EDT/native then it should start from the beginning because 
native events may generate event on EDT, and events on EDT may generate 
the native events.

So it is unclear why if does not work.

-- 
Best regards, Sergey.


From krishna.addepalli at oracle.com  Fri Jan 19 03:39:42 2018
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Thu, 18 Jan 2018 19:39:42 -0800 (PST)
Subject: <Swing Dev> [11][JDK-8176512][TEST_BUG] add a minimal delay to
 java/awt/Paint/bug8024864.java
In-Reply-To: <f4c07d69-b7ad-d27b-1f37-636944da69cb@oracle.com>
References: <b10d1925-7636-4d32-bd09-2bfea0659fd9@default>
 <b4e7cf22-ba71-1bf0-616a-78261e37883b@oracle.com>
 <8605a161-6f55-4dcc-8c59-024ea9fb4b35@default>
 <f4c07d69-b7ad-d27b-1f37-636944da69cb@oracle.com>
Message-ID: <9e0e00da-0a05-4848-b801-adb1c092f0ee@default>

Hi Sergey,

Yes you are right, that waitForIdle() will make sure that all the events will be processed on EDT. However, lets say the last event on the queue takes sometime to process, then, syncNativeQueue could return true, since there are no more events generated on the queue, and the waitForIdle could return.
For example, the event on the EDT could be waiting for a network operation to complete, and till such time it might not generate any more events. But, there is a high chance that, while it is waiting, that thread could get swapped by another thread. If that thread tries to access the so called response from the network immediately, it won't be able to get it, since the other thread has not finished getting it.
Similarly, when there is a paint event, there is a small possibility that the EDT thread might get swapped out before it could draw its contents to the screen, and if the main thread accesses the screen immediately, it could get wrong results. This is what would have happened in OEL, for this test case.

Thanks,
Krishna
-----Original Message-----
From: Sergey Bylokhov 
Sent: Friday, January 19, 2018 8:41 AM
To: Krishna Addepalli <krishna.addepalli at oracle.com>; swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [11][JDK-8176512][TEST_BUG] add a minimal delay to java/awt/Paint/bug8024864.java

On 18/01/2018 18:36, Krishna Addepalli wrote:
> Here is my understanding of waitForIdle() - it ensures that all the events on the EDT are pushed, and it has a huge wait time of 10seconds, which should mostly guarantee that there are no pending events on the EDT till the function is executed. And it mostly works on all platforms. The test case failed on OEL, whereas it passed on Windows and Linux. I haven't checked for Mac, but most likely it would work there too.
> The testcase in question tries to paint the window, and then picks the color from a particular location on screen. The function bug8024864::showTestUI has frame.setVisible(true) as its last statement, which should ultimately generate a native paint event. Now waitForIdle will ensure that, that event has been posted, but paint/repaint will involve some work down the OS level. Now, it could be possible that, the scheduler might choose to suspend the EDT thread and run the main thread, which checks for the pixel color on the screen and it might fail.

waitForIdle() was implemented in a way that it should block the thread on which it was run until all events will be processed on EDT *and* on native queue. It also takes into account that if at least one event was processed on EDT/native then it should start from the beginning because native events may generate event on EDT, and events on EDT may generate the native events.

So it is unclear why if does not work.

--
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Fri Jan 19 23:50:23 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 19 Jan 2018 15:50:23 -0800
Subject: <Swing Dev> [11][JDK-8176512][TEST_BUG] add a minimal delay to
 java/awt/Paint/bug8024864.java
In-Reply-To: <9e0e00da-0a05-4848-b801-adb1c092f0ee@default>
References: <b10d1925-7636-4d32-bd09-2bfea0659fd9@default>
 <b4e7cf22-ba71-1bf0-616a-78261e37883b@oracle.com>
 <8605a161-6f55-4dcc-8c59-024ea9fb4b35@default>
 <f4c07d69-b7ad-d27b-1f37-636944da69cb@oracle.com>
 <9e0e00da-0a05-4848-b801-adb1c092f0ee@default>
Message-ID: <fe23b2f2-e3ba-7d0f-20af-67fd1c966e3d@oracle.com>

On 18/01/2018 19:39, Krishna Addepalli wrote:
> Yes you are right, that waitForIdle() will make sure that all the events will be processed on EDT. However, lets say the last event on the queue takes sometime to process, then, syncNativeQueue could return true, since there are no more events generated on the queue, and the waitForIdle could return.
> For example, the event on the EDT could be waiting for a network operation to complete, and till such time it might not generate any more events. But, there is a high chance that, while it is waiting, that thread could get swapped by another thread. If that thread tries to access the so called response from the network immediately, it won't be able to get it, since the other thread has not finished getting it.
> Similarly, when there is a paint event, there is a small possibility that the EDT thread might get swapped out before it could draw its contents to the screen, and if the main thread accesses the screen immediately, it could get wrong results. This is what would have happened in OEL, for this test case.

This situation should also be covered by the Toolkit.sync() which is 
called inside waitForIdle(); Since this test additionally waits 100 ms 
in waitTillShown() its is strange why waitForIdle() does not work.

-- 
Best regards, Sergey.


From krishna.addepalli at oracle.com  Sat Jan 20 04:38:02 2018
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Fri, 19 Jan 2018 20:38:02 -0800 (PST)
Subject: <Swing Dev> [11][JDK-8176512][TEST_BUG] add a minimal delay to
 java/awt/Paint/bug8024864.java
In-Reply-To: <fe23b2f2-e3ba-7d0f-20af-67fd1c966e3d@oracle.com>
References: <b10d1925-7636-4d32-bd09-2bfea0659fd9@default>
 <b4e7cf22-ba71-1bf0-616a-78261e37883b@oracle.com>
 <8605a161-6f55-4dcc-8c59-024ea9fb4b35@default>
 <f4c07d69-b7ad-d27b-1f37-636944da69cb@oracle.com>
 <9e0e00da-0a05-4848-b801-adb1c092f0ee@default>
 <fe23b2f2-e3ba-7d0f-20af-67fd1c966e3d@oracle.com>
Message-ID: <fb5fb035-d45f-4cf7-98a9-dce19afc2bd4@default>

Hi Sergey,

Yes, waitForIdle works 99% of the time. But, there is no deterministic guarantee, that the previous set of operations have completed before the next set of operations can begin.  
I have not seen Toolkit.sync() being called inside waitForIdle, although I doubt if even that leads to a 100% guarantee.
Also, I found the below explanation from the documentation of the realSync function, which itself mentions a caveat:

"   * <p> Notice that realSync isn't guaranteed to work if recurring
     * actions occur, such as if during processing of some event
     * another request which may generate some events occurs.  By
     * default, sync tries to perform as much as {@value #MAX_ITERS}
     * cycles of event processing, allowing for roughly {@value
     * #MAX_ITERS} additional requests.
     *
     * <p> For example, requestFocus() generates native request, which
     * generates one or two Java focus events, which then generate a
     * serie of paint events, a serie of Java focus events, which then
     * generate a serie of paint events which then are processed -
     * three cycles, minimum. "

All I have done in the test case is to ensure that it runs consistently on all types of machines and platforms.

waitTillShown() also just sleeps for 100ms, which is not a guarantee that the operation on the other thread has completed.
Hope this clarifies.

Thanks,
Krishna

-----Original Message-----
From: Sergey Bylokhov 
Sent: Saturday, January 20, 2018 5:20 AM
To: Krishna Addepalli <krishna.addepalli at oracle.com>; swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [11][JDK-8176512][TEST_BUG] add a minimal delay to java/awt/Paint/bug8024864.java

On 18/01/2018 19:39, Krishna Addepalli wrote:
> Yes you are right, that waitForIdle() will make sure that all the events will be processed on EDT. However, lets say the last event on the queue takes sometime to process, then, syncNativeQueue could return true, since there are no more events generated on the queue, and the waitForIdle could return.
> For example, the event on the EDT could be waiting for a network operation to complete, and till such time it might not generate any more events. But, there is a high chance that, while it is waiting, that thread could get swapped by another thread. If that thread tries to access the so called response from the network immediately, it won't be able to get it, since the other thread has not finished getting it.
> Similarly, when there is a paint event, there is a small possibility that the EDT thread might get swapped out before it could draw its contents to the screen, and if the main thread accesses the screen immediately, it could get wrong results. This is what would have happened in OEL, for this test case.

This situation should also be covered by the Toolkit.sync() which is called inside waitForIdle(); Since this test additionally waits 100 ms in waitTillShown() its is strange why waitForIdle() does not work.

--
Best regards, Sergey.


From pankaj.b.bansal at oracle.com  Mon Jan 22 13:12:40 2018
From: pankaj.b.bansal at oracle.com (Pankaj Bansal)
Date: Mon, 22 Jan 2018 05:12:40 -0800 (PST)
Subject: <Swing Dev> [11] Review Request: JDK-6481195 ListSelectionListener
 indicates events on model.addElement after model.clear()
Message-ID: <95f74961-80da-480e-93a2-7df0d8239034@default>

Hi All,

 

Please review the fix for JDK 11.

 

Bug:

https://bugs.openjdk.java.net/browse/JDK-6481195

 

Webrev:

http://cr.openjdk.java.net/~pbansal/6481195/webrev.00/

 

Issue:

Invalid ListSelectionEvents are being fired, when the data is added after the clear() function has been called on DefaultListModel. This only happens when the index 0 was selected before calling clear.
 

When the index 0 is selected on a JList and clear() function is called, anchor and lead are not being updated properly in DefaultSelectionModel as they are not being reset to -1 inside the removeIndexInterval() function. Because of this, when new elements are added in model, a ListSelectionEvent is fired from insertIndexInterval() function.

 

Fix:

The code inside removeIndexInterval function handles the case when 0 index is selected in special way. Removed that piece of code. 

 

Note: 

This also fixes https://bugs.openjdk.java.net/browse/JDK-4334792 partially when removeAllElements or clear() is called on DefaultListModel.

 

 

Regards

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

From Sergey.Bylokhov at oracle.com  Mon Jan 22 16:38:41 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 22 Jan 2018 08:38:41 -0800
Subject: <Swing Dev> [11][JDK-8176512][TEST_BUG] add a minimal delay to
 java/awt/Paint/bug8024864.java
In-Reply-To: <fb5fb035-d45f-4cf7-98a9-dce19afc2bd4@default>
References: <b10d1925-7636-4d32-bd09-2bfea0659fd9@default>
 <b4e7cf22-ba71-1bf0-616a-78261e37883b@oracle.com>
 <8605a161-6f55-4dcc-8c59-024ea9fb4b35@default>
 <f4c07d69-b7ad-d27b-1f37-636944da69cb@oracle.com>
 <9e0e00da-0a05-4848-b801-adb1c092f0ee@default>
 <fe23b2f2-e3ba-7d0f-20af-67fd1c966e3d@oracle.com>
 <fb5fb035-d45f-4cf7-98a9-dce19afc2bd4@default>
Message-ID: <21d78b85-1add-e7cd-0983-070b57577ce5@oracle.com>

On 19/01/2018 20:38, Krishna Addepalli wrote:
>       * <p> For example, requestFocus() generates native request, which
>       * generates one or two Java focus events, which then generate a
>       * serie of paint events, a serie of Java focus events, which then
>       * generate a serie of paint events which then are processed -
>       * three cycles, minimum. "
> 
> All I have done in the test case is to ensure that it runs consistently on all types of machines and platforms.

As described above waitForIdle() may fail if there are kind of events 
recursion. But this bug is different.

> 
> waitTillShown() also just sleeps for 100ms, which is not a guarantee that the operation on the other thread has completed.
> Hope this clarifies.

It does not guarantee but this wait + waitForIdle() should be enough.

Take a look to the code which generates the OPEN_EVENT used in the 
fix(see Window.show()).
It is posted without relation to the native peer:
==========
1) EDT: Window.setVisible()->Window.show()->Window.postWindowEvent()-> 
barrier.await();
2) Main: blocked by barrier.await();

So your code waits when the setVisible() and some additional event 
(OPEN_EVENT) will be dispatched by EDT.

==========
The usage of waitForIdle() should produce similar result:

1) EDT: Window.setVisible()->Window.show();
3) Main: post dummy event to EDT->waitLock.notifyAll();
2) Main: blocked in SunToolkit.waitForIdle(final long timeout) by 
waitLock.wait();

The old code waits when the setVisible() and some additional event 
(dummy) will be dispatched by EDT. But it also flush the native queue.

So it is still unclear why waitForIdle does not work.

> 
> Thanks,
> Krishna
> 
> -----Original Message-----
> From: Sergey Bylokhov
> Sent: Saturday, January 20, 2018 5:20 AM
> To: Krishna Addepalli <krishna.addepalli at oracle.com>; swing-dev at openjdk.java.net
> Subject: Re: <Swing Dev> [11][JDK-8176512][TEST_BUG] add a minimal delay to java/awt/Paint/bug8024864.java
> 
> On 18/01/2018 19:39, Krishna Addepalli wrote:
>> Yes you are right, that waitForIdle() will make sure that all the events will be processed on EDT. However, lets say the last event on the queue takes sometime to process, then, syncNativeQueue could return true, since there are no more events generated on the queue, and the waitForIdle could return.
>> For example, the event on the EDT could be waiting for a network operation to complete, and till such time it might not generate any more events. But, there is a high chance that, while it is waiting, that thread could get swapped by another thread. If that thread tries to access the so called response from the network immediately, it won't be able to get it, since the other thread has not finished getting it.
>> Similarly, when there is a paint event, there is a small possibility that the EDT thread might get swapped out before it could draw its contents to the screen, and if the main thread accesses the screen immediately, it could get wrong results. This is what would have happened in OEL, for this test case.
> 
> This situation should also be covered by the Toolkit.sync() which is called inside waitForIdle(); Since this test additionally waits 100 ms in waitTillShown() its is strange why waitForIdle() does not work.
> 
> --
> Best regards, Sergey.
> 


-- 
Best regards, Sergey.


From jayathirth.d.v at oracle.com  Thu Jan 25 12:57:39 2018
From: jayathirth.d.v at oracle.com (Jayathirth D V)
Date: Thu, 25 Jan 2018 04:57:39 -0800 (PST)
Subject: <Swing Dev> [11] Review Request: JDK-6481195
 ListSelectionListener indicates events on model.addElement after
 model.clear()
In-Reply-To: <95f74961-80da-480e-93a2-7df0d8239034@default>
References: <95f74961-80da-480e-93a2-7df0d8239034@default>
Message-ID: <0aa3a0d5-6506-4b92-8543-37f3235bb475@default>

Hi Pankaj,

 

Please find my inputs:

Test case is working properly before and after changes.

 

But I think we should make changes in test to actually detect all failure cases properly instead of throwing RuntimeException when we hit first failure:

                    if (numberOfEvents > 2) {

                        throw new RuntimeException("Wrong number of Events. " +

                        "Expected: 2, Actual: " + numberOfEvents);

                    }

 

                    if (list.getLeadSelectionIndex() != -1) {

                        throw new RuntimeException("Wrong Lead Index. " +

                        "Expected: -1, Actual: " + list

                        .getLeadSelectionIndex());

                    }

 

                    if (list.getAnchorSelectionIndex() != -1) {

                        throw new RuntimeException("Wrong Anchor Index. " +

                        "Expected: -1, Actual: " + list

                        .getAnchorSelectionIndex());

                    }

 

Before your code change we just hit first check throw exception which will not cover all the required conditions(proper number of events, proper lead selection index & proper anchor selection index).

We can update a boolean variable in each of 3 cases and then check them and throw relevant RuntimeException.

 

Also in test case there are some indentation problems in for loop, if condition and expressions please update them also.

 

Thanks,

Jay

 

From: Pankaj Bansal 
Sent: Monday, January 22, 2018 6:43 PM
To: swing-dev at openjdk.java.net; Sergey Bylokhov; Semyon Sadetsky; Prasanta Sadhukhan
Subject: <Swing Dev> [11] Review Request: JDK-6481195 ListSelectionListener indicates events on model.addElement after model.clear()

 

Hi All,

 

Please review the fix for JDK 11.

 

Bug:

https://bugs.openjdk.java.net/browse/JDK-6481195

 

Webrev:

http://cr.openjdk.java.net/~pbansal/6481195/webrev.00/

 

Issue:

Invalid ListSelectionEvents are being fired, when the data is added after the clear() function has been called on DefaultListModel. This only happens when the index 0 was selected before calling clear.
 

When the index 0 is selected on a JList and clear() function is called, anchor and lead are not being updated properly in DefaultSelectionModel as they are not being reset to -1 inside the removeIndexInterval() function. Because of this, when new elements are added in model, a ListSelectionEvent is fired from insertIndexInterval() function.

 

Fix:

The code inside removeIndexInterval function handles the case when 0 index is selected in special way. Removed that piece of code. 

 

Note: 

This also fixes https://bugs.openjdk.java.net/browse/JDK-4334792 partially when removeAllElements or clear() is called on DefaultListModel.

 

 

Regards

Pankaj Bansal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20180125/20a9e272/attachment.html>

From jayathirth.d.v at oracle.com  Thu Jan 25 15:02:29 2018
From: jayathirth.d.v at oracle.com (Jayathirth D V)
Date: Thu, 25 Jan 2018 07:02:29 -0800 (PST)
Subject: <Swing Dev> [11] Review Request: JDK-7007967 DefaultRowSorter:
 incorrect sorting due to not updating comparator cache
In-Reply-To: <cd5205e0-8203-42b5-b3af-1f72aedb5ca5@default>
References: <cd5205e0-8203-42b5-b3af-1f72aedb5ca5@default>
Message-ID: <5f593f1c-870e-4e92-a357-86e69c2c8aa6@default>

Hello Pankaj,

 

Please find my inputs:

At line 1036 number of characters per line is more than 80, we can divide the conditions into multiple lines.

 

1036         if (!sorted || viewToModel.length == 0 || (lastRow - firstRow) > viewToModel.length / 10) {

1037             // We either weren't sorted, or to much changed, sort it all or

1038             // this is the first row added and we have to update different 

1039             // caches

 

Test case is working fine before and after the change.

I think there is no need for us to verify row index before we delete and update the contents again.

  65         for (int row = 0; row < model.getRowCount(); row++) {

  66             // values are in sorted ascending. so the row index and

  67             // view index from sorter should be same

  68             if (row != rowSorter.convertRowIndexToView(row)) {

  69                 throw new RuntimeException("Wrong sorting");

  70             }

  71         }

 

We can remove the above code in the test case because we never hit it and throw RuntimeException.

 

Thanks,

Jay

 

From: Pankaj Bansal 
Sent: Wednesday, January 17, 2018 5:24 PM
To: swing-dev at openjdk.java.net; Sergey Bylokhov; Semyon Sadetsky
Subject: <Swing Dev> [11] Review Request: JDK-7007967 DefaultRowSorter: incorrect sorting due to not updating comparator cache

 

Hi All,

 

Please review the fix for JDK 11.

 

Bug:

https://bugs.openjdk.java.net/browse/JDK-7007967

 

Webrev:

http://cr.openjdk.java.net/~pbansal/7007967/webrev.00/

 

Issue:

The caching flags like useToString, comparators etc are not always updated in shouldOptimizeChange function. It can cause wrong cache to be used in some cases and produce wrong sorting results. 
 
For example, in the submitted test case, the integer data is added and sorted. This updates the useToString etc cache flags according to the data type provided.  //Sorts 1,2,11 as 1->2->11 (correct).
Then all the data is removed from the model and when the sorter is indicated of this, the cache flags get updated accordingly. Because of this, the useToString is set to true for the column and comparator is set to String Comparator and sorted flag is still true.
Now if Integer data rows are again added one by one, these flags are not updated and it will use the wrong caches of useToString, comparators etc and produce wrong sorting results. //Sorts 1,2,11 as 1->11->2 (Incorrect. The data is sorted according to String representation).

 

 

Fix:

There can be different approaches to solve this issue. In the current approach, changes have been done in shouldOptimizeChange function to call the sort function when first row is added to the model. This will ensure that the cache flags like useToString, comparators are updated according to the data added for the column.

 

Regards,

Pankaj Bansal

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

From krishna.addepalli at oracle.com  Thu Jan 25 15:51:27 2018
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Thu, 25 Jan 2018 07:51:27 -0800 (PST)
Subject: <Swing Dev> [11][JDK-6303622]Use generic in Swing components like
	JComboBox
Message-ID: <e011b24d-2a7a-4247-8be8-693cc2074079@default>

Hi All,

 

Please review a fix for the Enhancement:

 

JDK-6303622: https://bugs.openjdk.java.net/browse/JDK-6303622

Webrev: http://cr.openjdk.java.net/~kaddepalli/6303622/webrev00/

 

The enhancement requests to provide the generic return type for getSelectedItem() to avoid ugly casts for the developers using the api. Have done changes accordingly for JComboBox and JList, and all supporting classes.

 

Thanks,

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

From kevin.rushforth at oracle.com  Thu Jan 25 16:15:34 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 25 Jan 2018 08:15:34 -0800
Subject: <Swing Dev> [11][JDK-6303622]Use generic in Swing components
 like JComboBox
In-Reply-To: <e011b24d-2a7a-4247-8be8-693cc2074079@default>
References: <e011b24d-2a7a-4247-8be8-693cc2074079@default>
Message-ID: <5A6A02A6.4000406@oracle.com>

I presume you plan to file a CSR? Have you verified that this change 
preserves both binary and source code compatibility?

-- Kevin


Krishna Addepalli wrote:
>
> Hi All,
>
>  
>
> Please review a fix for the Enhancement:
>
>  
>
> JDK-6303622: https://bugs.openjdk.java.net/browse/JDK-6303622
>
> Webrev: http://cr.openjdk.java.net/~kaddepalli/6303622/webrev00/ 
> <http://cr.openjdk.java.net/%7Ekaddepalli/6303622/webrev00/>
>
>  
>
> The enhancement requests to provide the generic return type for 
> getSelectedItem() to avoid ugly casts for the developers using the 
> api. Have done changes accordingly for JComboBox and JList, and all 
> supporting classes.
>
>  
>
> Thanks,
>
> Krishna
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20180125/a4fb8a94/attachment.html>

From philip.race at oracle.com  Fri Jan 26 23:20:39 2018
From: philip.race at oracle.com (Philip Race)
Date: Fri, 26 Jan 2018 15:20:39 -0800
Subject: <Swing Dev> RFR: 8193483: Update client-libs ProblemList.txt
Message-ID: <5A6BB7C7.7010305@oracle.com>

bug: https://bugs.openjdk.java.net/browse/JDK-8193483
webrev; http://cr.openjdk.java.net/~prr/8193483/

An update to the ProblemList to exclude most of the tests that fail on 
Windows.

There are still a number of tests that have "errors" like timeouts that 
need to be added.

Also I need to do a pass on mac + linux. Its lengthy and tedious so that 
won't happen overnight.

You can apply this patch before running jtreg yourself so as to minimise 
failures ..
then you can see which tests I've not gotten to .. or which did not fail 
for me

To run the client tests you can do :

jtreg -a -ignore:quiet -exclude:test/jdk/ProblemList.txt 
opem/test/jdk:jdk_desktop

-phil.


From Sergey.Bylokhov at oracle.com  Fri Jan 26 23:34:33 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 26 Jan 2018 15:34:33 -0800
Subject: <Swing Dev> <AWT Dev> RFR: 8193483: Update client-libs
	ProblemList.txt
In-Reply-To: <5A6BB7C7.7010305@oracle.com>
References: <5A6BB7C7.7010305@oracle.com>
Message-ID: <8e86e6ce-0267-e838-948d-5b090e9e445d@oracle.com>

Looks fine.

On 26/01/2018 15:20, Philip Race wrote:
> bug: https://bugs.openjdk.java.net/browse/JDK-8193483
> webrev; http://cr.openjdk.java.net/~prr/8193483/
> 
> An update to the ProblemList to exclude most of the tests that fail on 
> Windows.
> 
> There are still a number of tests that have "errors" like timeouts that 
> need to be added.
> 
> Also I need to do a pass on mac + linux. Its lengthy and tedious so that 
> won't happen overnight.
> 
> You can apply this patch before running jtreg yourself so as to minimise 
> failures ..
> then you can see which tests I've not gotten to .. or which did not fail 
> for me
> 
> To run the client tests you can do :
> 
> jtreg -a -ignore:quiet -exclude:test/jdk/ProblemList.txt 
> opem/test/jdk:jdk_desktop
> 
> -phil.


-- 
Best regards, Sergey.


From pankaj.b.bansal at oracle.com  Mon Jan 29 09:00:58 2018
From: pankaj.b.bansal at oracle.com (Pankaj Bansal)
Date: Mon, 29 Jan 2018 01:00:58 -0800 (PST)
Subject: <Swing Dev> [11] Review Request: JDK-7007967 DefaultRowSorter:
 incorrect sorting due to not updating comparator cache
In-Reply-To: <5f593f1c-870e-4e92-a357-86e69c2c8aa6@default>
References: <cd5205e0-8203-42b5-b3af-1f72aedb5ca5@default>
 <5f593f1c-870e-4e92-a357-86e69c2c8aa6@default>
Message-ID: <555c7d20-4d56-4dda-adde-291cc8afb270@default>

Hello Jay,

 

I have made suggested changes.

webrev: http://cr.openjdk.java.net/~pbansal/7007967/webrev.01/

 

 

<< Test case is working fine before and after the change.

<<I think there is no need for us to verify row index before we delete and update the <<contents again.

 << 65         for (int row = 0; row < model.getRowCount(); row++) {

 << 66             // values are in sorted ascending. so the row index and

 << 67             // view index from sorter should be same

 << 68             if (row != rowSorter.convertRowIndexToView(row)) {

 << 69                 throw new RuntimeException("Wrong sorting");

 << 70             }

 << 71         }

<<We can remove the above code in the test case because we never hit it and throw RuntimeException.

 

This is required to make sure that the row sorted is in proper condition and the test passes before making changes. This makes sure that our changes are not causing the error if there are any.

 

Regards,

Pankaj Bansal

 

 

From: Jayathirth D V 
Sent: Thursday, January 25, 2018 8:32 PM
To: Pankaj Bansal; swing-dev at openjdk.java.net; Sergey Bylokhov; Semyon Sadetsky
Subject: RE: <Swing Dev> [11] Review Request: JDK-7007967 DefaultRowSorter: incorrect sorting due to not updating comparator cache

 

Hello Pankaj,

 

Please find my inputs:

At line 1036 number of characters per line is more than 80, we can divide the conditions into multiple lines.

 

1036         if (!sorted || viewToModel.length == 0 || (lastRow - firstRow) > viewToModel.length / 10) {

1037             // We either weren't sorted, or to much changed, sort it all or

1038             // this is the first row added and we have to update different 

1039             // caches

 

Test case is working fine before and after the change.

I think there is no need for us to verify row index before we delete and update the contents again.

  65         for (int row = 0; row < model.getRowCount(); row++) {

  66             // values are in sorted ascending. so the row index and

  67             // view index from sorter should be same

  68             if (row != rowSorter.convertRowIndexToView(row)) {

  69                 throw new RuntimeException("Wrong sorting");

  70             }

  71         }

 

We can remove the above code in the test case because we never hit it and throw RuntimeException.

 

Thanks,

Jay

 

From: Pankaj Bansal 
Sent: Wednesday, January 17, 2018 5:24 PM
To: HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net; Sergey Bylokhov; Semyon Sadetsky
Subject: <Swing Dev> [11] Review Request: JDK-7007967 DefaultRowSorter: incorrect sorting due to not updating comparator cache

 

Hi All,

 

Please review the fix for JDK 11.

 

Bug:

https://bugs.openjdk.java.net/browse/JDK-7007967

 

Webrev:

http://cr.openjdk.java.net/~pbansal/7007967/webrev.00/

 

Issue:

The caching flags like useToString, comparators etc are not always updated in shouldOptimizeChange function. It can cause wrong cache to be used in some cases and produce wrong sorting results. 
 
For example, in the submitted test case, the integer data is added and sorted. This updates the useToString etc cache flags according to the data type provided.  //Sorts 1,2,11 as 1->2->11 (correct).
Then all the data is removed from the model and when the sorter is indicated of this, the cache flags get updated accordingly. Because of this, the useToString is set to true for the column and comparator is set to String Comparator and sorted flag is still true.
Now if Integer data rows are again added one by one, these flags are not updated and it will use the wrong caches of useToString, comparators etc and produce wrong sorting results. //Sorts 1,2,11 as 1->11->2 (Incorrect. The data is sorted according to String representation).

 

 

Fix:

There can be different approaches to solve this issue. In the current approach, changes have been done in shouldOptimizeChange function to call the sort function when first row is added to the model. This will ensure that the cache flags like useToString, comparators are updated according to the data added for the column.

 

Regards,

Pankaj Bansal

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

From pankaj.b.bansal at oracle.com  Mon Jan 29 10:08:53 2018
From: pankaj.b.bansal at oracle.com (Pankaj Bansal)
Date: Mon, 29 Jan 2018 02:08:53 -0800 (PST)
Subject: <Swing Dev> [11] Review Request: JDK-6481195
 ListSelectionListener indicates events on model.addElement after
 model.clear()
In-Reply-To: <0aa3a0d5-6506-4b92-8543-37f3235bb475@default>
References: <95f74961-80da-480e-93a2-7df0d8239034@default>
 <0aa3a0d5-6506-4b92-8543-37f3235bb475@default>
Message-ID: <9e880244-feb4-4112-81eb-47d96a1a7090@default>

Hi Jay,

 

Thanks for the review.

 

I have made the suggested changes. 

webrev: http://cr.openjdk.java.net/~pbansal/6481195/webrev.01/

 

 

Regards,

Pankaj Bansal

 

From: Jayathirth D V 
Sent: Thursday, January 25, 2018 6:28 PM
To: Pankaj Bansal; swing-dev at openjdk.java.net; Sergey Bylokhov; Semyon Sadetsky; Prasanta Sadhukhan
Subject: RE: <Swing Dev> [11] Review Request: JDK-6481195 ListSelectionListener indicates events on model.addElement after model.clear()

 

Hi Pankaj,

 

Please find my inputs:

Test case is working properly before and after changes.

 

But I think we should make changes in test to actually detect all failure cases properly instead of throwing RuntimeException when we hit first failure:

                    if (numberOfEvents > 2) {

                        throw new RuntimeException("Wrong number of Events. " +

                        "Expected: 2, Actual: " + numberOfEvents);

                    }

 

                    if (list.getLeadSelectionIndex() != -1) {

                        throw new RuntimeException("Wrong Lead Index. " +

                        "Expected: -1, Actual: " + list

                        .getLeadSelectionIndex());

                    }

 

                    if (list.getAnchorSelectionIndex() != -1) {

                        throw new RuntimeException("Wrong Anchor Index. " +

                        "Expected: -1, Actual: " + list

                        .getAnchorSelectionIndex());

                    }

 

Before your code change we just hit first check throw exception which will not cover all the required conditions(proper number of events, proper lead selection index & proper anchor selection index).

We can update a boolean variable in each of 3 cases and then check them and throw relevant RuntimeException.

 

Also in test case there are some indentation problems in for loop, if condition and expressions please update them also.

 

Thanks,

Jay

 

From: Pankaj Bansal 
Sent: Monday, January 22, 2018 6:43 PM
To: HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net; Sergey Bylokhov; Semyon Sadetsky; Prasanta Sadhukhan
Subject: <Swing Dev> [11] Review Request: JDK-6481195 ListSelectionListener indicates events on model.addElement after model.clear()

 

Hi All,

 

Please review the fix for JDK 11.

 

Bug:

https://bugs.openjdk.java.net/browse/JDK-6481195

 

Webrev:

http://cr.openjdk.java.net/~pbansal/6481195/webrev.00/

 

Issue:

Invalid ListSelectionEvents are being fired, when the data is added after the clear() function has been called on DefaultListModel. This only happens when the index 0 was selected before calling clear.
 

When the index 0 is selected on a JList and clear() function is called, anchor and lead are not being updated properly in DefaultSelectionModel as they are not being reset to -1 inside the removeIndexInterval() function. Because of this, when new elements are added in model, a ListSelectionEvent is fired from insertIndexInterval() function.

 

Fix:

The code inside removeIndexInterval function handles the case when 0 index is selected in special way. Removed that piece of code. 

 

Note: 

This also fixes https://bugs.openjdk.java.net/browse/JDK-4334792 partially when removeAllElements or clear() is called on DefaultListModel.

 

 

Regards

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

From jayathirth.d.v at oracle.com  Tue Jan 30 06:34:04 2018
From: jayathirth.d.v at oracle.com (Jayathirth D V)
Date: Mon, 29 Jan 2018 22:34:04 -0800 (PST)
Subject: <Swing Dev> [11] Review Request: JDK-7007967 DefaultRowSorter:
 incorrect sorting due to not updating comparator cache
In-Reply-To: <555c7d20-4d56-4dda-adde-291cc8afb270@default>
References: <cd5205e0-8203-42b5-b3af-1f72aedb5ca5@default>
 <5f593f1c-870e-4e92-a357-86e69c2c8aa6@default>
 <555c7d20-4d56-4dda-adde-291cc8afb270@default>
Message-ID: <870c5ce3-51e7-4dd9-bda0-09c107aa2890@default>

Hi Pankaj,

 

It's better to make a multiline condition by dividing different conditions instead of making new line within a condition:

1036         if (!sorted || viewToModel.length == 0 || (lastRow - firstRow) >

1037                 viewToModel.length / 10) {

 

to 

 

1036         if (!sorted || viewToModel.length == 0 ||

1037              (lastRow - firstRow) > viewToModel.length / 10) {

 

In test case if need to throw multiple RuntimeException please make sure that there is difference between them instead of throwing same message "Wrong Sorting". We can use "Wrong sorting before ." and "Wrong sorting after .". Also in jtreg comments section maintain the indentation of multiline comment.

 

Thanks,

Jay

 

From: Pankaj Bansal 
Sent: Monday, January 29, 2018 2:31 PM
To: Jayathirth D V; swing-dev at openjdk.java.net; Sergey Bylokhov; Semyon Sadetsky
Subject: RE: <Swing Dev> [11] Review Request: JDK-7007967 DefaultRowSorter: incorrect sorting due to not updating comparator cache

 

Hello Jay,

 

I have made suggested changes.

webrev: http://cr.openjdk.java.net/~pbansal/7007967/webrev.01/

 

 

<< Test case is working fine before and after the change.

<<I think there is no need for us to verify row index before we delete and update the <<contents again.

 << 65         for (int row = 0; row < model.getRowCount(); row++) {

 << 66             // values are in sorted ascending. so the row index and

 << 67             // view index from sorter should be same

 << 68             if (row != rowSorter.convertRowIndexToView(row)) {

 << 69                 throw new RuntimeException("Wrong sorting");

 << 70             }

 << 71         }

<<We can remove the above code in the test case because we never hit it and throw RuntimeException.

 

This is required to make sure that the row sorted is in proper condition and the test passes before making changes. This makes sure that our changes are not causing the error if there are any.

 

Regards,

Pankaj Bansal

 

 

From: Jayathirth D V 
Sent: Thursday, January 25, 2018 8:32 PM
To: Pankaj Bansal; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net; Sergey Bylokhov; Semyon Sadetsky
Subject: RE: <Swing Dev> [11] Review Request: JDK-7007967 DefaultRowSorter: incorrect sorting due to not updating comparator cache

 

Hello Pankaj,

 

Please find my inputs:

At line 1036 number of characters per line is more than 80, we can divide the conditions into multiple lines.

 

1036         if (!sorted || viewToModel.length == 0 || (lastRow - firstRow) > viewToModel.length / 10) {

1037             // We either weren't sorted, or to much changed, sort it all or

1038             // this is the first row added and we have to update different 

1039             // caches

 

Test case is working fine before and after the change.

I think there is no need for us to verify row index before we delete and update the contents again.

  65         for (int row = 0; row < model.getRowCount(); row++) {

  66             // values are in sorted ascending. so the row index and

  67             // view index from sorter should be same

  68             if (row != rowSorter.convertRowIndexToView(row)) {

  69                 throw new RuntimeException("Wrong sorting");

  70             }

  71         }

 

We can remove the above code in the test case because we never hit it and throw RuntimeException.

 

Thanks,

Jay

 

From: Pankaj Bansal 
Sent: Wednesday, January 17, 2018 5:24 PM
To: HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net; Sergey Bylokhov; Semyon Sadetsky
Subject: <Swing Dev> [11] Review Request: JDK-7007967 DefaultRowSorter: incorrect sorting due to not updating comparator cache

 

Hi All,

 

Please review the fix for JDK 11.

 

Bug:

https://bugs.openjdk.java.net/browse/JDK-7007967

 

Webrev:

http://cr.openjdk.java.net/~pbansal/7007967/webrev.00/

 

Issue:

The caching flags like useToString, comparators etc are not always updated in shouldOptimizeChange function. It can cause wrong cache to be used in some cases and produce wrong sorting results. 
 
For example, in the submitted test case, the integer data is added and sorted. This updates the useToString etc cache flags according to the data type provided.  //Sorts 1,2,11 as 1->2->11 (correct).
Then all the data is removed from the model and when the sorter is indicated of this, the cache flags get updated accordingly. Because of this, the useToString is set to true for the column and comparator is set to String Comparator and sorted flag is still true.
Now if Integer data rows are again added one by one, these flags are not updated and it will use the wrong caches of useToString, comparators etc and produce wrong sorting results. //Sorts 1,2,11 as 1->11->2 (Incorrect. The data is sorted according to String representation).

 

 

Fix:

There can be different approaches to solve this issue. In the current approach, changes have been done in shouldOptimizeChange function to call the sort function when first row is added to the model. This will ensure that the cache flags like useToString, comparators are updated according to the data added for the column.

 

Regards,

Pankaj Bansal

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

From jayathirth.d.v at oracle.com  Tue Jan 30 06:42:34 2018
From: jayathirth.d.v at oracle.com (Jayathirth D V)
Date: Mon, 29 Jan 2018 22:42:34 -0800 (PST)
Subject: <Swing Dev> [11] Review Request: JDK-6481195
 ListSelectionListener indicates events on model.addElement after
 model.clear()
In-Reply-To: <9e880244-feb4-4112-81eb-47d96a1a7090@default>
References: <95f74961-80da-480e-93a2-7df0d8239034@default>
 <0aa3a0d5-6506-4b92-8543-37f3235bb475@default>
 <9e880244-feb4-4112-81eb-47d96a1a7090@default>
Message-ID: <9a87811e-80fc-44bc-b9d9-1f40a93b82d6@default>

Hi Pankaj,

 

Changes are fine.

 

As mentioned in previous suggestion Java code convention for different statements like if () and for () loops(http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-142311.html ) we have to maintain single space between if/for and braces. In test case this needs to be updated. There is no need for another webrev please update it before you push the change.

 

Thanks,

Jay

 

From: Pankaj Bansal 
Sent: Monday, January 29, 2018 3:39 PM
To: Jayathirth D V; swing-dev at openjdk.java.net; Sergey Bylokhov; Semyon Sadetsky; Prasanta Sadhukhan
Subject: RE: <Swing Dev> [11] Review Request: JDK-6481195 ListSelectionListener indicates events on model.addElement after model.clear()

 

Hi Jay,

 

Thanks for the review.

 

I have made the suggested changes. 

webrev: http://cr.openjdk.java.net/~pbansal/6481195/webrev.01/

 

 

Regards,

Pankaj Bansal

 

From: Jayathirth D V 
Sent: Thursday, January 25, 2018 6:28 PM
To: Pankaj Bansal; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net; Sergey Bylokhov; Semyon Sadetsky; Prasanta Sadhukhan
Subject: RE: <Swing Dev> [11] Review Request: JDK-6481195 ListSelectionListener indicates events on model.addElement after model.clear()

 

Hi Pankaj,

 

Please find my inputs:

Test case is working properly before and after changes.

 

But I think we should make changes in test to actually detect all failure cases properly instead of throwing RuntimeException when we hit first failure:

                    if (numberOfEvents > 2) {

                        throw new RuntimeException("Wrong number of Events. " +

                        "Expected: 2, Actual: " + numberOfEvents);

                    }

 

                    if (list.getLeadSelectionIndex() != -1) {

                        throw new RuntimeException("Wrong Lead Index. " +

                        "Expected: -1, Actual: " + list

                        .getLeadSelectionIndex());

                    }

 

                    if (list.getAnchorSelectionIndex() != -1) {

                        throw new RuntimeException("Wrong Anchor Index. " +

                        "Expected: -1, Actual: " + list

                        .getAnchorSelectionIndex());

                    }

 

Before your code change we just hit first check throw exception which will not cover all the required conditions(proper number of events, proper lead selection index & proper anchor selection index).

We can update a boolean variable in each of 3 cases and then check them and throw relevant RuntimeException.

 

Also in test case there are some indentation problems in for loop, if condition and expressions please update them also.

 

Thanks,

Jay

 

From: Pankaj Bansal 
Sent: Monday, January 22, 2018 6:43 PM
To: HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net; Sergey Bylokhov; Semyon Sadetsky; Prasanta Sadhukhan
Subject: <Swing Dev> [11] Review Request: JDK-6481195 ListSelectionListener indicates events on model.addElement after model.clear()

 

Hi All,

 

Please review the fix for JDK 11.

 

Bug:

https://bugs.openjdk.java.net/browse/JDK-6481195

 

Webrev:

http://cr.openjdk.java.net/~pbansal/6481195/webrev.00/

 

Issue:

Invalid ListSelectionEvents are being fired, when the data is added after the clear() function has been called on DefaultListModel. This only happens when the index 0 was selected before calling clear.
 

When the index 0 is selected on a JList and clear() function is called, anchor and lead are not being updated properly in DefaultSelectionModel as they are not being reset to -1 inside the removeIndexInterval() function. Because of this, when new elements are added in model, a ListSelectionEvent is fired from insertIndexInterval() function.

 

Fix:

The code inside removeIndexInterval function handles the case when 0 index is selected in special way. Removed that piece of code. 

 

Note: 

This also fixes https://bugs.openjdk.java.net/browse/JDK-4334792 partially when removeAllElements or clear() is called on DefaultListModel.

 

 

Regards

Pankaj Bansal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20180129/6fa4e07e/attachment.html>

From pankaj.b.bansal at oracle.com  Tue Jan 30 08:42:16 2018
From: pankaj.b.bansal at oracle.com (Pankaj Bansal)
Date: Tue, 30 Jan 2018 00:42:16 -0800 (PST)
Subject: <Swing Dev> [11] Review Request: JDK-7007967 DefaultRowSorter:
 incorrect sorting due to not updating comparator cache
In-Reply-To: <870c5ce3-51e7-4dd9-bda0-09c107aa2890@default>
References: <cd5205e0-8203-42b5-b3af-1f72aedb5ca5@default>
 <5f593f1c-870e-4e92-a357-86e69c2c8aa6@default>
 <555c7d20-4d56-4dda-adde-291cc8afb270@default>
 <870c5ce3-51e7-4dd9-bda0-09c107aa2890@default>
Message-ID: <41c982d2-7385-4134-b65f-437da74fce4a@default>

Hi Jay,

 

Thanks for the review.

 

I have incorporated the suggested changes.

webrev: http://cr.openjdk.java.net/~pbansal/7007967/webrev.02/

 

Regards,

Pankaj Bansal

From: Jayathirth D V 
Sent: Tuesday, January 30, 2018 12:04 PM
To: Pankaj Bansal; swing-dev at openjdk.java.net; Sergey Bylokhov; Semyon Sadetsky
Subject: RE: <Swing Dev> [11] Review Request: JDK-7007967 DefaultRowSorter: incorrect sorting due to not updating comparator cache

 

Hi Pankaj,

 

It's better to make a multiline condition by dividing different conditions instead of making new line within a condition:

1036         if (!sorted || viewToModel.length == 0 || (lastRow - firstRow) >

1037                 viewToModel.length / 10) {

 

to 

 

1036         if (!sorted || viewToModel.length == 0 ||

1037              (lastRow - firstRow) > viewToModel.length / 10) {

 

In test case if need to throw multiple RuntimeException please make sure that there is difference between them instead of throwing same message "Wrong Sorting". We can use "Wrong sorting before ." and "Wrong sorting after .". Also in jtreg comments section maintain the indentation of multiline comment.

 

Thanks,

Jay

 

From: Pankaj Bansal 
Sent: Monday, January 29, 2018 2:31 PM
To: Jayathirth D V; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net; Sergey Bylokhov; Semyon Sadetsky
Subject: RE: <Swing Dev> [11] Review Request: JDK-7007967 DefaultRowSorter: incorrect sorting due to not updating comparator cache

 

Hello Jay,

 

I have made suggested changes.

webrev: http://cr.openjdk.java.net/~pbansal/7007967/webrev.01/

 

 

<< Test case is working fine before and after the change.

<<I think there is no need for us to verify row index before we delete and update the <<contents again.

 << 65         for (int row = 0; row < model.getRowCount(); row++) {

 << 66             // values are in sorted ascending. so the row index and

 << 67             // view index from sorter should be same

 << 68             if (row != rowSorter.convertRowIndexToView(row)) {

 << 69                 throw new RuntimeException("Wrong sorting");

 << 70             }

 << 71         }

<<We can remove the above code in the test case because we never hit it and throw RuntimeException.

 

This is required to make sure that the row sorted is in proper condition and the test passes before making changes. This makes sure that our changes are not causing the error if there are any.

 

Regards,

Pankaj Bansal

 

 

From: Jayathirth D V 
Sent: Thursday, January 25, 2018 8:32 PM
To: Pankaj Bansal; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net; Sergey Bylokhov; Semyon Sadetsky
Subject: RE: <Swing Dev> [11] Review Request: JDK-7007967 DefaultRowSorter: incorrect sorting due to not updating comparator cache

 

Hello Pankaj,

 

Please find my inputs:

At line 1036 number of characters per line is more than 80, we can divide the conditions into multiple lines.

 

1036         if (!sorted || viewToModel.length == 0 || (lastRow - firstRow) > viewToModel.length / 10) {

1037             // We either weren't sorted, or to much changed, sort it all or

1038             // this is the first row added and we have to update different 

1039             // caches

 

Test case is working fine before and after the change.

I think there is no need for us to verify row index before we delete and update the contents again.

  65         for (int row = 0; row < model.getRowCount(); row++) {

  66             // values are in sorted ascending. so the row index and

  67             // view index from sorter should be same

  68             if (row != rowSorter.convertRowIndexToView(row)) {

  69                 throw new RuntimeException("Wrong sorting");

  70             }

  71         }

 

We can remove the above code in the test case because we never hit it and throw RuntimeException.

 

Thanks,

Jay

 

From: Pankaj Bansal 
Sent: Wednesday, January 17, 2018 5:24 PM
To: HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net; Sergey Bylokhov; Semyon Sadetsky
Subject: <Swing Dev> [11] Review Request: JDK-7007967 DefaultRowSorter: incorrect sorting due to not updating comparator cache

 

Hi All,

 

Please review the fix for JDK 11.

 

Bug:

https://bugs.openjdk.java.net/browse/JDK-7007967

 

Webrev:

http://cr.openjdk.java.net/~pbansal/7007967/webrev.00/

 

Issue:

The caching flags like useToString, comparators etc are not always updated in shouldOptimizeChange function. It can cause wrong cache to be used in some cases and produce wrong sorting results. 
 
For example, in the submitted test case, the integer data is added and sorted. This updates the useToString etc cache flags according to the data type provided.  //Sorts 1,2,11 as 1->2->11 (correct).
Then all the data is removed from the model and when the sorter is indicated of this, the cache flags get updated accordingly. Because of this, the useToString is set to true for the column and comparator is set to String Comparator and sorted flag is still true.
Now if Integer data rows are again added one by one, these flags are not updated and it will use the wrong caches of useToString, comparators etc and produce wrong sorting results. //Sorts 1,2,11 as 1->11->2 (Incorrect. The data is sorted according to String representation).

 

 

Fix:

There can be different approaches to solve this issue. In the current approach, changes have been done in shouldOptimizeChange function to call the sort function when first row is added to the model. This will ensure that the cache flags like useToString, comparators are updated according to the data added for the column.

 

Regards,

Pankaj Bansal

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

From jayathirth.d.v at oracle.com  Tue Jan 30 09:04:30 2018
From: jayathirth.d.v at oracle.com (Jayathirth D V)
Date: Tue, 30 Jan 2018 01:04:30 -0800 (PST)
Subject: <Swing Dev> [11] Review Request: JDK-7007967 DefaultRowSorter:
 incorrect sorting due to not updating comparator cache
In-Reply-To: <41c982d2-7385-4134-b65f-437da74fce4a@default>
References: <cd5205e0-8203-42b5-b3af-1f72aedb5ca5@default>
 <5f593f1c-870e-4e92-a357-86e69c2c8aa6@default>
 <555c7d20-4d56-4dda-adde-291cc8afb270@default>
 <870c5ce3-51e7-4dd9-bda0-09c107aa2890@default>
 <41c982d2-7385-4134-b65f-437da74fce4a@default>
Message-ID: <d2259cea-a305-4cee-8b92-eb7e79c6672f@default>

Hi Pankaj,

 

Changes are fine.

 

Thanks,

Jay

 

From: Pankaj Bansal 
Sent: Tuesday, January 30, 2018 2:12 PM
To: Jayathirth D V; swing-dev at openjdk.java.net; Sergey Bylokhov; Semyon Sadetsky
Subject: RE: <Swing Dev> [11] Review Request: JDK-7007967 DefaultRowSorter: incorrect sorting due to not updating comparator cache

 

Hi Jay,

 

Thanks for the review.

 

I have incorporated the suggested changes.

webrev: http://cr.openjdk.java.net/~pbansal/7007967/webrev.02/

 

Regards,

Pankaj Bansal

From: Jayathirth D V 
Sent: Tuesday, January 30, 2018 12:04 PM
To: Pankaj Bansal; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net; Sergey Bylokhov; Semyon Sadetsky
Subject: RE: <Swing Dev> [11] Review Request: JDK-7007967 DefaultRowSorter: incorrect sorting due to not updating comparator cache

 

Hi Pankaj,

 

It's better to make a multiline condition by dividing different conditions instead of making new line within a condition:

1036         if (!sorted || viewToModel.length == 0 || (lastRow - firstRow) >

1037                 viewToModel.length / 10) {

 

to 

 

1036         if (!sorted || viewToModel.length == 0 ||

1037              (lastRow - firstRow) > viewToModel.length / 10) {

 

In test case if need to throw multiple RuntimeException please make sure that there is difference between them instead of throwing same message "Wrong Sorting". We can use "Wrong sorting before ." and "Wrong sorting after .". Also in jtreg comments section maintain the indentation of multiline comment.

 

Thanks,

Jay

 

From: Pankaj Bansal 
Sent: Monday, January 29, 2018 2:31 PM
To: Jayathirth D V; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net; Sergey Bylokhov; Semyon Sadetsky
Subject: RE: <Swing Dev> [11] Review Request: JDK-7007967 DefaultRowSorter: incorrect sorting due to not updating comparator cache

 

Hello Jay,

 

I have made suggested changes.

webrev: http://cr.openjdk.java.net/~pbansal/7007967/webrev.01/

 

 

<< Test case is working fine before and after the change.

<<I think there is no need for us to verify row index before we delete and update the <<contents again.

 << 65         for (int row = 0; row < model.getRowCount(); row++) {

 << 66             // values are in sorted ascending. so the row index and

 << 67             // view index from sorter should be same

 << 68             if (row != rowSorter.convertRowIndexToView(row)) {

 << 69                 throw new RuntimeException("Wrong sorting");

 << 70             }

 << 71         }

<<We can remove the above code in the test case because we never hit it and throw RuntimeException.

 

This is required to make sure that the row sorted is in proper condition and the test passes before making changes. This makes sure that our changes are not causing the error if there are any.

 

Regards,

Pankaj Bansal

 

 

From: Jayathirth D V 
Sent: Thursday, January 25, 2018 8:32 PM
To: Pankaj Bansal; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net; Sergey Bylokhov; Semyon Sadetsky
Subject: RE: <Swing Dev> [11] Review Request: JDK-7007967 DefaultRowSorter: incorrect sorting due to not updating comparator cache

 

Hello Pankaj,

 

Please find my inputs:

At line 1036 number of characters per line is more than 80, we can divide the conditions into multiple lines.

 

1036         if (!sorted || viewToModel.length == 0 || (lastRow - firstRow) > viewToModel.length / 10) {

1037             // We either weren't sorted, or to much changed, sort it all or

1038             // this is the first row added and we have to update different 

1039             // caches

 

Test case is working fine before and after the change.

I think there is no need for us to verify row index before we delete and update the contents again.

  65         for (int row = 0; row < model.getRowCount(); row++) {

  66             // values are in sorted ascending. so the row index and

  67             // view index from sorter should be same

  68             if (row != rowSorter.convertRowIndexToView(row)) {

  69                 throw new RuntimeException("Wrong sorting");

  70             }

  71         }

 

We can remove the above code in the test case because we never hit it and throw RuntimeException.

 

Thanks,

Jay

 

From: Pankaj Bansal 
Sent: Wednesday, January 17, 2018 5:24 PM
To: HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net; Sergey Bylokhov; Semyon Sadetsky
Subject: <Swing Dev> [11] Review Request: JDK-7007967 DefaultRowSorter: incorrect sorting due to not updating comparator cache

 

Hi All,

 

Please review the fix for JDK 11.

 

Bug:

https://bugs.openjdk.java.net/browse/JDK-7007967

 

Webrev:

http://cr.openjdk.java.net/~pbansal/7007967/webrev.00/

 

Issue:

The caching flags like useToString, comparators etc are not always updated in shouldOptimizeChange function. It can cause wrong cache to be used in some cases and produce wrong sorting results. 
 
For example, in the submitted test case, the integer data is added and sorted. This updates the useToString etc cache flags according to the data type provided.  //Sorts 1,2,11 as 1->2->11 (correct).
Then all the data is removed from the model and when the sorter is indicated of this, the cache flags get updated accordingly. Because of this, the useToString is set to true for the column and comparator is set to String Comparator and sorted flag is still true.
Now if Integer data rows are again added one by one, these flags are not updated and it will use the wrong caches of useToString, comparators etc and produce wrong sorting results. //Sorts 1,2,11 as 1->11->2 (Incorrect. The data is sorted according to String representation).

 

 

Fix:

There can be different approaches to solve this issue. In the current approach, changes have been done in shouldOptimizeChange function to call the sort function when first row is added to the model. This will ensure that the cache flags like useToString, comparators are updated according to the data added for the column.

 

Regards,

Pankaj Bansal

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

From pankaj.b.bansal at oracle.com  Tue Jan 30 09:13:01 2018
From: pankaj.b.bansal at oracle.com (Pankaj Bansal)
Date: Tue, 30 Jan 2018 01:13:01 -0800 (PST)
Subject: <Swing Dev> [11] Review Request: JDK-6481195
 ListSelectionListener indicates events on model.addElement after
 model.clear()
In-Reply-To: <9a87811e-80fc-44bc-b9d9-1f40a93b82d6@default>
References: <95f74961-80da-480e-93a2-7df0d8239034@default>
 <0aa3a0d5-6506-4b92-8543-37f3235bb475@default>
 <9e880244-feb4-4112-81eb-47d96a1a7090@default>
 <9a87811e-80fc-44bc-b9d9-1f40a93b82d6@default>
Message-ID: <b8215fa7-2bb0-4d05-8447-00f3346d0ac3@default>

Hi Jay,

 

I have made the small correction you suggested.

webrev: http://cr.openjdk.java.net/~pbansal/6481195/webrev.02/

 

Regards,

Pankaj Bansal

 

From: Jayathirth D V 
Sent: Tuesday, January 30, 2018 12:13 PM
To: Pankaj Bansal; swing-dev at openjdk.java.net; Sergey Bylokhov; Semyon Sadetsky; Prasanta Sadhukhan
Subject: RE: <Swing Dev> [11] Review Request: JDK-6481195 ListSelectionListener indicates events on model.addElement after model.clear()

 

Hi Pankaj,

 

Changes are fine.

 

As mentioned in previous suggestion Java code convention for different statements like if () and for () loops(http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-142311.html ) we have to maintain single space between if/for and braces. In test case this needs to be updated. There is no need for another webrev please update it before you push the change.

 

Thanks,

Jay

 

From: Pankaj Bansal 
Sent: Monday, January 29, 2018 3:39 PM
To: Jayathirth D V; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net; Sergey Bylokhov; Semyon Sadetsky; Prasanta Sadhukhan
Subject: RE: <Swing Dev> [11] Review Request: JDK-6481195 ListSelectionListener indicates events on model.addElement after model.clear()

 

Hi Jay,

 

Thanks for the review.

 

I have made the suggested changes. 

webrev: http://cr.openjdk.java.net/~pbansal/6481195/webrev.01/

 

 

Regards,

Pankaj Bansal

 

From: Jayathirth D V 
Sent: Thursday, January 25, 2018 6:28 PM
To: Pankaj Bansal; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net; Sergey Bylokhov; Semyon Sadetsky; Prasanta Sadhukhan
Subject: RE: <Swing Dev> [11] Review Request: JDK-6481195 ListSelectionListener indicates events on model.addElement after model.clear()

 

Hi Pankaj,

 

Please find my inputs:

Test case is working properly before and after changes.

 

But I think we should make changes in test to actually detect all failure cases properly instead of throwing RuntimeException when we hit first failure:

                    if (numberOfEvents > 2) {

                        throw new RuntimeException("Wrong number of Events. " +

                        "Expected: 2, Actual: " + numberOfEvents);

                    }

 

                    if (list.getLeadSelectionIndex() != -1) {

                        throw new RuntimeException("Wrong Lead Index. " +

                        "Expected: -1, Actual: " + list

                        .getLeadSelectionIndex());

                    }

 

                    if (list.getAnchorSelectionIndex() != -1) {

                        throw new RuntimeException("Wrong Anchor Index. " +

                        "Expected: -1, Actual: " + list

                        .getAnchorSelectionIndex());

                    }

 

Before your code change we just hit first check throw exception which will not cover all the required conditions(proper number of events, proper lead selection index & proper anchor selection index).

We can update a boolean variable in each of 3 cases and then check them and throw relevant RuntimeException.

 

Also in test case there are some indentation problems in for loop, if condition and expressions please update them also.

 

Thanks,

Jay

 

From: Pankaj Bansal 
Sent: Monday, January 22, 2018 6:43 PM
To: HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net; Sergey Bylokhov; Semyon Sadetsky; Prasanta Sadhukhan
Subject: <Swing Dev> [11] Review Request: JDK-6481195 ListSelectionListener indicates events on model.addElement after model.clear()

 

Hi All,

 

Please review the fix for JDK 11.

 

Bug:

https://bugs.openjdk.java.net/browse/JDK-6481195

 

Webrev:

http://cr.openjdk.java.net/~pbansal/6481195/webrev.00/

 

Issue:

Invalid ListSelectionEvents are being fired, when the data is added after the clear() function has been called on DefaultListModel. This only happens when the index 0 was selected before calling clear.
 

When the index 0 is selected on a JList and clear() function is called, anchor and lead are not being updated properly in DefaultSelectionModel as they are not being reset to -1 inside the removeIndexInterval() function. Because of this, when new elements are added in model, a ListSelectionEvent is fired from insertIndexInterval() function.

 

Fix:

The code inside removeIndexInterval function handles the case when 0 index is selected in special way. Removed that piece of code. 

 

Note: 

This also fixes https://bugs.openjdk.java.net/browse/JDK-4334792 partially when removeAllElements or clear() is called on DefaultListModel.

 

 

Regards

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

From jayathirth.d.v at oracle.com  Tue Jan 30 09:21:58 2018
From: jayathirth.d.v at oracle.com (Jayathirth D V)
Date: Tue, 30 Jan 2018 01:21:58 -0800 (PST)
Subject: <Swing Dev> [11] Review Request: JDK-6481195
 ListSelectionListener indicates events on model.addElement after
 model.clear()
In-Reply-To: <b8215fa7-2bb0-4d05-8447-00f3346d0ac3@default>
References: <95f74961-80da-480e-93a2-7df0d8239034@default>
 <0aa3a0d5-6506-4b92-8543-37f3235bb475@default>
 <9e880244-feb4-4112-81eb-47d96a1a7090@default>
 <9a87811e-80fc-44bc-b9d9-1f40a93b82d6@default>
 <b8215fa7-2bb0-4d05-8447-00f3346d0ac3@default>
Message-ID: <056bb13a-09d0-4dc3-bf71-913d8e95acae@default>

Hi Pankaj,

 

Changes are fine.

 

Thanks,

Jay

 

From: Pankaj Bansal 
Sent: Tuesday, January 30, 2018 2:43 PM
To: Jayathirth D V; swing-dev at openjdk.java.net; Sergey Bylokhov; Semyon Sadetsky; Prasanta Sadhukhan
Subject: RE: <Swing Dev> [11] Review Request: JDK-6481195 ListSelectionListener indicates events on model.addElement after model.clear()

 

Hi Jay,

 

I have made the small correction you suggested.

webrev: http://cr.openjdk.java.net/~pbansal/6481195/webrev.02/

 

Regards,

Pankaj Bansal

 

From: Jayathirth D V 
Sent: Tuesday, January 30, 2018 12:13 PM
To: Pankaj Bansal; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net; Sergey Bylokhov; Semyon Sadetsky; Prasanta Sadhukhan
Subject: RE: <Swing Dev> [11] Review Request: JDK-6481195 ListSelectionListener indicates events on model.addElement after model.clear()

 

Hi Pankaj,

 

Changes are fine.

 

As mentioned in previous suggestion Java code convention for different statements like if () and for () loops(http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-142311.html ) we have to maintain single space between if/for and braces. In test case this needs to be updated. There is no need for another webrev please update it before you push the change.

 

Thanks,

Jay

 

From: Pankaj Bansal 
Sent: Monday, January 29, 2018 3:39 PM
To: Jayathirth D V; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net; Sergey Bylokhov; Semyon Sadetsky; Prasanta Sadhukhan
Subject: RE: <Swing Dev> [11] Review Request: JDK-6481195 ListSelectionListener indicates events on model.addElement after model.clear()

 

Hi Jay,

 

Thanks for the review.

 

I have made the suggested changes. 

webrev: http://cr.openjdk.java.net/~pbansal/6481195/webrev.01/

 

 

Regards,

Pankaj Bansal

 

From: Jayathirth D V 
Sent: Thursday, January 25, 2018 6:28 PM
To: Pankaj Bansal; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net; Sergey Bylokhov; Semyon Sadetsky; Prasanta Sadhukhan
Subject: RE: <Swing Dev> [11] Review Request: JDK-6481195 ListSelectionListener indicates events on model.addElement after model.clear()

 

Hi Pankaj,

 

Please find my inputs:

Test case is working properly before and after changes.

 

But I think we should make changes in test to actually detect all failure cases properly instead of throwing RuntimeException when we hit first failure:

                    if (numberOfEvents > 2) {

                        throw new RuntimeException("Wrong number of Events. " +

                        "Expected: 2, Actual: " + numberOfEvents);

                    }

 

                    if (list.getLeadSelectionIndex() != -1) {

                        throw new RuntimeException("Wrong Lead Index. " +

                        "Expected: -1, Actual: " + list

                        .getLeadSelectionIndex());

                    }

 

                    if (list.getAnchorSelectionIndex() != -1) {

                        throw new RuntimeException("Wrong Anchor Index. " +

                        "Expected: -1, Actual: " + list

                        .getAnchorSelectionIndex());

                    }

 

Before your code change we just hit first check throw exception which will not cover all the required conditions(proper number of events, proper lead selection index & proper anchor selection index).

We can update a boolean variable in each of 3 cases and then check them and throw relevant RuntimeException.

 

Also in test case there are some indentation problems in for loop, if condition and expressions please update them also.

 

Thanks,

Jay

 

From: Pankaj Bansal 
Sent: Monday, January 22, 2018 6:43 PM
To: HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net; Sergey Bylokhov; Semyon Sadetsky; Prasanta Sadhukhan
Subject: <Swing Dev> [11] Review Request: JDK-6481195 ListSelectionListener indicates events on model.addElement after model.clear()

 

Hi All,

 

Please review the fix for JDK 11.

 

Bug:

https://bugs.openjdk.java.net/browse/JDK-6481195

 

Webrev:

http://cr.openjdk.java.net/~pbansal/6481195/webrev.00/

 

Issue:

Invalid ListSelectionEvents are being fired, when the data is added after the clear() function has been called on DefaultListModel. This only happens when the index 0 was selected before calling clear.
 

When the index 0 is selected on a JList and clear() function is called, anchor and lead are not being updated properly in DefaultSelectionModel as they are not being reset to -1 inside the removeIndexInterval() function. Because of this, when new elements are added in model, a ListSelectionEvent is fired from insertIndexInterval() function.

 

Fix:

The code inside removeIndexInterval function handles the case when 0 index is selected in special way. Removed that piece of code. 

 

Note: 

This also fixes https://bugs.openjdk.java.net/browse/JDK-4334792 partially when removeAllElements or clear() is called on DefaultListModel.

 

 

Regards

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

From prasanta.sadhukhan at oracle.com  Tue Jan 30 10:16:15 2018
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Tue, 30 Jan 2018 15:46:15 +0530
Subject: <Swing Dev> [11] RFR JDK-8191106: Nimbus LookAndFeel does not
 apply keys FileChooser.directoryOpenButtonText/ToolTipText to JFileChooser
In-Reply-To: <01ecf34a-cc73-1e20-09c2-585e24a04be7@oracle.com>
References: <cba5c211-bc50-9e81-0141-1c0460b80070@oracle.com>
 <cba7509f-ab9c-894c-c5dd-06145b5ac112@oracle.com>
 <f28aa56c-af7a-e5c4-d5c9-d0efca19457a@oracle.com>
 <01ecf34a-cc73-1e20-09c2-585e24a04be7@oracle.com>
Message-ID: <b82590e8-ae1d-b268-9060-94518ed46617@oracle.com>

Hi,

Any comments about the fix?

Regards
Prasanta
On 1/6/2018 1:00 PM, Sergey Bylokhov wrote:
> On 04/01/2018 22:05, Prasanta Sadhukhan wrote:
>> Hi Semyon,
>>
>> It's not exactly the same. For Metal, we do not set mnemonic, not 
>> sure if that is intentional, so did not push it down to basic class.
>
> They were intentionally dropped: 
> https://bugs.openjdk.java.net/browse/JDK-8080628
>
>>
>> Regards
>> Prasanta
>> On 1/4/2018 9:34 PM, Semyon Sadetsky wrote:
>>> Hi Prasanta,
>>>
>>> Since all those L&F's now have the same implementation of the method 
>>> maybe it worth to push it down to the basic class?
>>>
>>> --Semyon
>>>
>>> On 01/04/2018 02:33 AM, Prasanta Sadhukhan wrote:
>>>> Hi All,
>>>>
>>>> Please review a fix for Nimbus L&F where it is seen that
>>>> When you select a directory in a JFileChooser dialog, the text and 
>>>> tooltip of the "approve" button is not changing to the values of 
>>>> UIManager keys FileChooser.directoryOpenButtonText and 
>>>> FileChooser.directoryOpenButtonToolTipText and remain same as it 
>>>> was before directory is selected.
>>>> It changes for Metal and windows l&f.
>>>>
>>>> This is because when directory is selected 
>>>> BasicFileChooserUI#valueChanged() calls setDirectorySelected() but 
>>>> it's not implemented for nimbus l&f and it uses default 
>>>> implementation of BasicFileChooser.
>>>> For Metal & Windows, this method is overridden to change the 
>>>> approve button text to FileChooser.directoryOpenButtonText.
>>>> Propsosed fix is to override this method for Nimbus L&f and set the 
>>>> approve button text to FileChooser.directoryOpenButtonText.
>>>>
>>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8191106
>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8191106/webrev.00/
>>>>
>>>> Regards
>>>> Prasanta
>>>>
>>>
>>
>
>



From krishna.addepalli at oracle.com  Tue Jan 30 13:51:11 2018
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Tue, 30 Jan 2018 05:51:11 -0800 (PST)
Subject: <Swing Dev> [11][JDK-6303622]Use generic in Swing components
 like JComboBox
In-Reply-To: <5A6A02A6.4000406@oracle.com>
References: <e011b24d-2a7a-4247-8be8-693cc2074079@default>
 <5A6A02A6.4000406@oracle.com>
Message-ID: <44ea779a-2935-4879-98b0-e107edf8171d@default>

Hi Kevin,

 

Thanks for your review.

 

I have filed a CSR here: https://bugs.openjdk.java.net/browse/JDK-8196396

 

Source compatibility wise, the changes will produce warnings only in some cases. For example, with the below code snippet, there would be no warnings:

JComboBox cb = new JComboBox(new String[]{"one", "two", "three"});

String c = (String)cb.getSelectedItem();

 

Whereas the below code snippet would generate "redundant cast" warning on compilation.

JComboBox<String> cb = new JComboBox<>(new String[]{"one", "two", "three"});

String c = (String)cb.getSelectedItem();

 

Binary compatibility wise, I have checked that code that was compiled in jdk10 ran without any problems in jdk11. And also, behavior wise, there are no changes. 

 

Thanks,

Krishna

From: Kevin Rushforth 
Sent: Thursday, January 25, 2018 9:46 PM
To: Krishna Addepalli <krishna.addepalli at oracle.com>
Cc: swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [11][JDK-6303622]Use generic in Swing components like JComboBox

 

I presume you plan to file a CSR? Have you verified that this change preserves both binary and source code compatibility?

-- Kevin


Krishna Addepalli wrote: 

Hi All,

 

Please review a fix for the Enhancement:

 

JDK-6303622: https://bugs.openjdk.java.net/browse/JDK-6303622

Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Ekaddepalli/6303622/webrev00/"http://cr.openjdk.java.net/~kaddepalli/6303622/webrev00/

 

The enhancement requests to provide the generic return type for getSelectedItem() to avoid ugly casts for the developers using the api. Have done changes accordingly for JComboBox and JList, and all supporting classes.

 

Thanks,

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

From kevin.rushforth at oracle.com  Tue Jan 30 13:57:52 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 30 Jan 2018 05:57:52 -0800
Subject: <Swing Dev> [11][JDK-6303622]Use generic in Swing components
 like JComboBox
In-Reply-To: <44ea779a-2935-4879-98b0-e107edf8171d@default>
References: <e011b24d-2a7a-4247-8be8-693cc2074079@default>
 <5A6A02A6.4000406@oracle.com> <44ea779a-2935-4879-98b0-e107edf8171d@default>
Message-ID: <5A7079E0.7060701@oracle.com>

I can take a look at it, but note that since I am not a "R"eviewer for 
Swing, someone who is will need to review the CSR and the fix.

-- Kevin


Krishna Addepalli wrote:
>
> Hi Kevin,
>
>  
>
> Thanks for your review.
>
>  
>
> I have filed a CSR here: https://bugs.openjdk.java.net/browse/JDK-8196396
>
>  
>
> Source compatibility wise, the changes will produce warnings only in 
> some cases. For example, with the below code snippet, there would be 
> no warnings:
>
> JComboBox cb = new JComboBox(new String[]{"one", "two", "three"});
>
> String c = (String)cb.getSelectedItem();
>
>  
>
> Whereas the below code snippet would generate "redundant cast" warning 
> on compilation.
>
> JComboBox<String> cb = new JComboBox<>(new String[]{"one", "two", 
> "three"});
>
> String c = (String)cb.getSelectedItem();
>
>  
>
> Binary compatibility wise, I have checked that code that was compiled 
> in jdk10 ran without any problems in jdk11. And also, behavior wise, 
> there are no changes.
>
>  
>
> Thanks,
>
> Krishna
>
> *From:* Kevin Rushforth
> *Sent:* Thursday, January 25, 2018 9:46 PM
> *To:* Krishna Addepalli <krishna.addepalli at oracle.com>
> *Cc:* swing-dev at openjdk.java.net
> *Subject:* Re: <Swing Dev> [11][JDK-6303622]Use generic in Swing 
> components like JComboBox
>
>  
>
> I presume you plan to file a CSR? Have you verified that this change 
> preserves both binary and source code compatibility?
>
> -- Kevin
>
>
> Krishna Addepalli wrote:
>
>     Hi All,
>
>      
>
>     Please review a fix for the Enhancement:
>
>      
>
>     JDK-6303622: https://bugs.openjdk.java.net/browse/JDK-6303622
>
>     Webrev: http://cr.openjdk.java.net/~kaddepalli/6303622/webrev00/
>     <http://cr.openjdk.java.net/%7Ekaddepalli/6303622/webrev00/>
>
>      
>
>     The enhancement requests to provide the generic return type for
>     getSelectedItem() to avoid ugly casts for the developers using the
>     api. Have done changes accordingly for JComboBox and JList, and
>     all supporting classes.
>
>      
>
>     Thanks,
>
>     Krishna
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20180130/bc6e2886/attachment.html>

From semyon.sadetsky at oracle.com  Tue Jan 30 16:52:33 2018
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Tue, 30 Jan 2018 08:52:33 -0800
Subject: <Swing Dev> [11] RFR JDK-8191106: Nimbus LookAndFeel does not
 apply keys FileChooser.directoryOpenButtonText/ToolTipText to JFileChooser
In-Reply-To: <b82590e8-ae1d-b268-9060-94518ed46617@oracle.com>
References: <cba5c211-bc50-9e81-0141-1c0460b80070@oracle.com>
 <cba7509f-ab9c-894c-c5dd-06145b5ac112@oracle.com>
 <f28aa56c-af7a-e5c4-d5c9-d0efca19457a@oracle.com>
 <01ecf34a-cc73-1e20-09c2-585e24a04be7@oracle.com>
 <b82590e8-ae1d-b268-9060-94518ed46617@oracle.com>
Message-ID: <86f71e03-1bed-8481-70f5-7f8988b10276@oracle.com>

Hi Prasanta,

Can you explain why Nimbus should get those mnemonics but Metal not.

--Semyon


On 01/30/2018 02:16 AM, Prasanta Sadhukhan wrote:
> Hi,
>
> Any comments about the fix?
>
> Regards
> Prasanta
> On 1/6/2018 1:00 PM, Sergey Bylokhov wrote:
>> On 04/01/2018 22:05, Prasanta Sadhukhan wrote:
>>> Hi Semyon,
>>>
>>> It's not exactly the same. For Metal, we do not set mnemonic, not 
>>> sure if that is intentional, so did not push it down to basic class.
>>
>> They were intentionally dropped: 
>> https://bugs.openjdk.java.net/browse/JDK-8080628
>>
>>>
>>> Regards
>>> Prasanta
>>> On 1/4/2018 9:34 PM, Semyon Sadetsky wrote:
>>>> Hi Prasanta,
>>>>
>>>> Since all those L&F's now have the same implementation of the 
>>>> method maybe it worth to push it down to the basic class?
>>>>
>>>> --Semyon
>>>>
>>>> On 01/04/2018 02:33 AM, Prasanta Sadhukhan wrote:
>>>>> Hi All,
>>>>>
>>>>> Please review a fix for Nimbus L&F where it is seen that
>>>>> When you select a directory in a JFileChooser dialog, the text and 
>>>>> tooltip of the "approve" button is not changing to the values of 
>>>>> UIManager keys FileChooser.directoryOpenButtonText and 
>>>>> FileChooser.directoryOpenButtonToolTipText and remain same as it 
>>>>> was before directory is selected.
>>>>> It changes for Metal and windows l&f.
>>>>>
>>>>> This is because when directory is selected 
>>>>> BasicFileChooserUI#valueChanged() calls setDirectorySelected() but 
>>>>> it's not implemented for nimbus l&f and it uses default 
>>>>> implementation of BasicFileChooser.
>>>>> For Metal & Windows, this method is overridden to change the 
>>>>> approve button text to FileChooser.directoryOpenButtonText.
>>>>> Propsosed fix is to override this method for Nimbus L&f and set 
>>>>> the approve button text to FileChooser.directoryOpenButtonText.
>>>>>
>>>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8191106
>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8191106/webrev.00/
>>>>>
>>>>> Regards
>>>>> Prasanta
>>>>>
>>>>
>>>
>>
>>
>



From Sergey.Bylokhov at oracle.com  Tue Jan 30 19:47:41 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 30 Jan 2018 11:47:41 -0800
Subject: <Swing Dev> [10] Review Request: 8196196 Headful tests should not
 be run in headless mode
Message-ID: <8d05a5a0-9d67-89a2-16fa-6c60bb315754@oracle.com>

Hello.
Please review small test cleanup for jdk11.

  - "@key headful" was added to some tests which requires 
DISPLAY/xorg/gtk/gnome etc.
  - Some swing tests were updated to skip unsupported look and feels, 
for example GTK LookAndFeel can be installed(bundled) but is not 
necessary supported.

The final goal of this and some other future fixes is to run all 
non-headfull tests in parallel and speedup the tests execution.

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


-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Tue Jan 30 19:48:57 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 30 Jan 2018 11:48:57 -0800
Subject: <Swing Dev> <AWT Dev> [11] Review Request: 8196196 Headful
 tests should not be run in headless mode
In-Reply-To: <8d05a5a0-9d67-89a2-16fa-6c60bb315754@oracle.com>
References: <8d05a5a0-9d67-89a2-16fa-6c60bb315754@oracle.com>
Message-ID: <94a234d3-2631-d6c0-43ec-aa7055b1fd3d@oracle.com>

Typo in the Subject -> jdk11.

On 30/01/2018 11:47, Sergey Bylokhov wrote:
> Hello.
> Please review small test cleanup for jdk11.
> 
>  ?- "@key headful" was added to some tests which requires 
> DISPLAY/xorg/gtk/gnome etc.
>  ?- Some swing tests were updated to skip unsupported look and feels, 
> for example GTK LookAndFeel can be installed(bundled) but is not 
> necessary supported.
> 
> The final goal of this and some other future fixes is to run all 
> non-headfull tests in parallel and speedup the tests execution.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8196196
> Webrev can be found at: http://cr.openjdk.java.net/~serb/8196196/webrev.02/
> 
> 


-- 
Best regards, Sergey.


From philip.race at oracle.com  Tue Jan 30 19:57:32 2018
From: philip.race at oracle.com (Phil Race)
Date: Tue, 30 Jan 2018 11:57:32 -0800
Subject: <Swing Dev> <AWT Dev> [10] Review Request: 8196196 Headful
 tests should not be run in headless mode
In-Reply-To: <8d05a5a0-9d67-89a2-16fa-6c60bb315754@oracle.com>
References: <8d05a5a0-9d67-89a2-16fa-6c60bb315754@oracle.com>
Message-ID: <4599d00a-8012-7038-b215-cfa83c7fdf81@oracle.com>

You added @headful to BadDisplayTest, but also added this logic - why ?


  public class BadDisplayTest{
     public static void main(String[] args) {
+       if (Boolean.getBoolean("java.awt.headless")) {
+           return;
+       }

-phil.

On 01/30/2018 11:47 AM, Sergey Bylokhov wrote:
> Hello.
> Please review small test cleanup for jdk11.
>
>  - "@key headful" was added to some tests which requires 
> DISPLAY/xorg/gtk/gnome etc.
>  - Some swing tests were updated to skip unsupported look and feels, 
> for example GTK LookAndFeel can be installed(bundled) but is not 
> necessary supported.
>
> The final goal of this and some other future fixes is to run all 
> non-headfull tests in parallel and speedup the tests execution.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8196196
> Webrev can be found at: 
> http://cr.openjdk.java.net/~serb/8196196/webrev.02/
>
>



From philip.race at oracle.com  Tue Jan 30 20:06:46 2018
From: philip.race at oracle.com (Phil Race)
Date: Tue, 30 Jan 2018 12:06:46 -0800
Subject: <Swing Dev> <AWT Dev> [10] Review Request: 8196196 Headful
 tests should not be run in headless mode
In-Reply-To: <4599d00a-8012-7038-b215-cfa83c7fdf81@oracle.com>
References: <8d05a5a0-9d67-89a2-16fa-6c60bb315754@oracle.com>
 <4599d00a-8012-7038-b215-cfa83c7fdf81@oracle.com>
Message-ID: <15cdff8e-43a5-944c-9ee9-aebb0118db91@oracle.com>

PS .. I have a question about identifying headful tests.

I assume that jtreg itself knows nothing about the meaning of @key 
headful .. it
just knows how to obey your command line option of -k:'!headful'

Many of the automated tests use applets. These would seem like they are 
all headful ..
How would one do the same for excluding applets without tediously adding 
this keyword.

Is there jtreg syntax to exclude '.*html' ? Which might be one way to do it.

-phil.


On 01/30/2018 11:57 AM, Phil Race wrote:
> You added @headful to BadDisplayTest, but also added this logic - why ?
>
>
>  public class BadDisplayTest{
>     public static void main(String[] args) {
> +       if (Boolean.getBoolean("java.awt.headless")) {
> +           return;
> +       }
>
> -phil.
>
> On 01/30/2018 11:47 AM, Sergey Bylokhov wrote:
>> Hello.
>> Please review small test cleanup for jdk11.
>>
>>  - "@key headful" was added to some tests which requires 
>> DISPLAY/xorg/gtk/gnome etc.
>>  - Some swing tests were updated to skip unsupported look and feels, 
>> for example GTK LookAndFeel can be installed(bundled) but is not 
>> necessary supported.
>>
>> The final goal of this and some other future fixes is to run all 
>> non-headfull tests in parallel and speedup the tests execution.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8196196
>> Webrev can be found at: 
>> http://cr.openjdk.java.net/~serb/8196196/webrev.02/
>>
>>
>



From Sergey.Bylokhov at oracle.com  Tue Jan 30 20:38:53 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 30 Jan 2018 12:38:53 -0800
Subject: <Swing Dev> <AWT Dev> [10] Review Request: 8196196 Headful
 tests should not be run in headless mode
In-Reply-To: <4599d00a-8012-7038-b215-cfa83c7fdf81@oracle.com>
References: <8d05a5a0-9d67-89a2-16fa-6c60bb315754@oracle.com>
 <4599d00a-8012-7038-b215-cfa83c7fdf81@oracle.com>
Message-ID: <18df0026-3698-8035-7a35-6b448e4a9a46@oracle.com>

This test expects that the headful toolkit/GEnvironment will throw an 
error when it tries to connect to x11 using broken DISPLAY. But if 
"java.awt.headless" is passed then our headless 
toolkit/HeadlessEnvironment will skip validation of "DISPLAY".

On 30/01/2018 11:57, Phil Race wrote:
> You added @headful to BadDisplayTest, but also added this logic - why ?
> 
> 
>  ?public class BadDisplayTest{
>  ??? public static void main(String[] args) {
> +?????? if (Boolean.getBoolean("java.awt.headless")) {
> +?????????? return;
> +?????? }
> 
> -phil.
> 
> On 01/30/2018 11:47 AM, Sergey Bylokhov wrote:
>> Hello.
>> Please review small test cleanup for jdk11.
>>
>> ?- "@key headful" was added to some tests which requires 
>> DISPLAY/xorg/gtk/gnome etc.
>> ?- Some swing tests were updated to skip unsupported look and feels, 
>> for example GTK LookAndFeel can be installed(bundled) but is not 
>> necessary supported.
>>
>> The final goal of this and some other future fixes is to run all 
>> non-headfull tests in parallel and speedup the tests execution.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8196196
>> Webrev can be found at: 
>> http://cr.openjdk.java.net/~serb/8196196/webrev.02/
>>
>>
> 


-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Tue Jan 30 22:56:11 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 30 Jan 2018 14:56:11 -0800
Subject: <Swing Dev> [11] Review Request: JDK-6481195
 ListSelectionListener indicates events on model.addElement after
 model.clear()
In-Reply-To: <056bb13a-09d0-4dc3-bf71-913d8e95acae@default>
References: <95f74961-80da-480e-93a2-7df0d8239034@default>
 <0aa3a0d5-6506-4b92-8543-37f3235bb475@default>
 <9e880244-feb4-4112-81eb-47d96a1a7090@default>
 <9a87811e-80fc-44bc-b9d9-1f40a93b82d6@default>
 <b8215fa7-2bb0-4d05-8447-00f3346d0ac3@default>
 <056bb13a-09d0-4dc3-bf71-913d8e95acae@default>
Message-ID: <4c41477d-dffc-978a-a4d2-0b1ee9ed2c68@oracle.com>

+1

On 30/01/2018 01:21, Jayathirth D V wrote:
> Hi Pankaj,
> 
> Changes are fine.
> 
> Thanks,
> 
> Jay
> 
> *From:* Pankaj Bansal
> *Sent:* Tuesday, January 30, 2018 2:43 PM
> *To:* Jayathirth D V; swing-dev at openjdk.java.net; Sergey Bylokhov; 
> Semyon Sadetsky; Prasanta Sadhukhan
> *Subject:* RE: <Swing Dev> [11] Review Request: JDK-6481195 
> ListSelectionListener indicates events on model.addElement after 
> model.clear()
> 
> Hi Jay,
> 
> I have made the small correction you suggested.
> 
> webrev: http://cr.openjdk.java.net/~pbansal/6481195/webrev.02/
> 
> Regards,
> 
> Pankaj Bansal
> 
> *From:* Jayathirth D V
> *Sent:* Tuesday, January 30, 2018 12:13 PM
> *To:* Pankaj Bansal; swing-dev at openjdk.java.net 
> <mailto:swing-dev at openjdk.java.net>; Sergey Bylokhov; Semyon Sadetsky; 
> Prasanta Sadhukhan
> *Subject:* RE: <Swing Dev> [11] Review Request: JDK-6481195 
> ListSelectionListener indicates events on model.addElement after 
> model.clear()
> 
> Hi Pankaj,
> 
> Changes are fine.
> 
> As mentioned in previous suggestion Java code convention for different 
> statements like if () and for () 
> loops(http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-142311.html 
> ) we have to maintain single space between if/for and braces. In test 
> case this needs to be updated. There is no need for another webrev 
> please update it before you push the change.
> 
> Thanks,
> 
> Jay
> 
> *From:* Pankaj Bansal
> *Sent:* Monday, January 29, 2018 3:39 PM
> *To:* Jayathirth D V; swing-dev at openjdk.java.net 
> <mailto:swing-dev at openjdk.java.net>; Sergey Bylokhov; Semyon Sadetsky; 
> Prasanta Sadhukhan
> *Subject:* RE: <Swing Dev> [11] Review Request: JDK-6481195 
> ListSelectionListener indicates events on model.addElement after 
> model.clear()
> 
> Hi Jay,
> 
> Thanks for the review.
> 
> I have made the suggested changes.
> 
> webrev: http://cr.openjdk.java.net/~pbansal/6481195/webrev.01/
> 
> Regards,
> 
> Pankaj Bansal
> 
> *From:* Jayathirth D V
> *Sent:* Thursday, January 25, 2018 6:28 PM
> *To:* Pankaj Bansal; swing-dev at openjdk.java.net 
> <mailto:swing-dev at openjdk.java.net>; Sergey Bylokhov; Semyon Sadetsky; 
> Prasanta Sadhukhan
> *Subject:* RE: <Swing Dev> [11] Review Request: JDK-6481195 
> ListSelectionListener indicates events on model.addElement after 
> model.clear()
> 
> Hi Pankaj,
> 
> Please find my inputs:
> 
> Test case is working properly before and after changes.
> 
> But I think we should make changes in test to actually detect all 
> failure cases properly instead of throwing RuntimeException when we hit 
> first failure:
> 
>  ??????????????????? if (numberOfEvents > 2) {
> 
>  ??????????????????????? throw new RuntimeException("Wrong number of 
> Events. " +
> 
>  ??????????????????????? "Expected: 2, Actual: " + numberOfEvents);
> 
>  ??????????????????? }
> 
>  ??????????????????? if (list.getLeadSelectionIndex() != -1) {
> 
>  ??????????????????????? throw new RuntimeException("Wrong Lead Index. " +
> 
>  ??????????????????????? "Expected: -1, Actual: " + list
> 
>  ????????????????????? ??.getLeadSelectionIndex());
> 
>  ??????????????????? }
> 
>  ??????????????????? if (list.getAnchorSelectionIndex() != -1) {
> 
>  ??????????????????????? throw new RuntimeException("Wrong Anchor Index. " +
> 
>  ??????????????????????? "Expected: -1, Actual: " + list
> 
>  ??????? ????????????????.getAnchorSelectionIndex());
> 
>  ??????????????????? }
> 
> Before your code change we just hit first check throw exception which 
> will not cover all the required conditions(proper number of events, 
> proper lead selection index & proper anchor selection index).
> 
> We can update a boolean variable in each of 3 cases and then check them 
> and throw relevant RuntimeException.
> 
> Also in test case there are some indentation problems in for loop, if 
> condition and expressions please update them also.
> 
> Thanks,
> 
> Jay
> 
> *From:* Pankaj Bansal
> *Sent:* Monday, January 22, 2018 6:43 PM
> *To:* swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>; 
> Sergey Bylokhov; Semyon Sadetsky; Prasanta Sadhukhan
> *Subject:* <Swing Dev> [11] Review Request: JDK-6481195 
> ListSelectionListener indicates events on model.addElement after 
> model.clear()
> 
> Hi All,
> 
> Please review the fix for JDK 11.
> 
> Bug:
> 
> https://bugs.openjdk.java.net/browse/JDK-6481195
> 
> Webrev:
> 
> http://cr.openjdk.java.net/~pbansal/6481195/webrev.00/
> 
> Issue:
> 
> Invalid ListSelectionEvents are being fired, when the data is added 
> after the clear() function has been called on DefaultListModel. This 
> only happens when the index 0 was selected before calling clear.
> 
> When the index 0 is selected on a JList and clear() function is called, 
> anchor and lead are not being updated properly in DefaultSelectionModel 
> as they are not being reset to -1 inside the removeIndexInterval() 
> function. Because of this, when new elements are added in model, a 
> ListSelectionEvent is fired from insertIndexInterval() function.
> 
> Fix:
> 
> The code inside removeIndexInterval function handles the case when 0 
> index is selected in special way. Removed that piece of code.
> 
> Note:
> 
> This also fixes https://bugs.openjdk.java.net/browse/JDK-4334792 
> partially when removeAllElements or clear() is called on DefaultListModel.
> 
> Regards
> 
> Pankaj Bansal
> 


-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Tue Jan 30 23:25:29 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 30 Jan 2018 15:25:29 -0800
Subject: <Swing Dev> [11] Review Request: JDK-7007967 DefaultRowSorter:
 incorrect sorting due to not updating comparator cache
In-Reply-To: <d2259cea-a305-4cee-8b92-eb7e79c6672f@default>
References: <cd5205e0-8203-42b5-b3af-1f72aedb5ca5@default>
 <5f593f1c-870e-4e92-a357-86e69c2c8aa6@default>
 <555c7d20-4d56-4dda-adde-291cc8afb270@default>
 <870c5ce3-51e7-4dd9-bda0-09c107aa2890@default>
 <41c982d2-7385-4134-b65f-437da74fce4a@default>
 <d2259cea-a305-4cee-8b92-eb7e79c6672f@default>
Message-ID: <d8878622-a018-1813-8a77-d6d28f88dc5b@oracle.com>

+1

On 30/01/2018 01:04, Jayathirth D V wrote:
> Hi Pankaj,
> 
> Changes are fine.
> 
> Thanks,
> 
> Jay
> 
> *From:* Pankaj Bansal
> *Sent:* Tuesday, January 30, 2018 2:12 PM
> *To:* Jayathirth D V; swing-dev at openjdk.java.net; Sergey Bylokhov; 
> Semyon Sadetsky
> *Subject:* RE: <Swing Dev> [11] Review Request: JDK-7007967 
> DefaultRowSorter: incorrect sorting due to not updating comparator cache
> 
> Hi Jay,
> 
> Thanks for the review.
> 
> I have incorporated the suggested changes.
> 
> webrev: http://cr.openjdk.java.net/~pbansal/7007967/webrev.02/
> 
> Regards,
> 
> Pankaj Bansal
> 
> *From:* Jayathirth D V
> *Sent:* Tuesday, January 30, 2018 12:04 PM
> *To:* Pankaj Bansal; swing-dev at openjdk.java.net 
> <mailto:swing-dev at openjdk.java.net>; Sergey Bylokhov; Semyon Sadetsky
> *Subject:* RE: <Swing Dev> [11] Review Request: JDK-7007967 
> DefaultRowSorter: incorrect sorting due to not updating comparator cache
> 
> Hi Pankaj,
> 
> It?s better to make a multiline condition by dividing different 
> conditions instead of making new line within a condition:
> 
> 1036???????? if (!sorted || viewToModel.length == 0 || (lastRow - 
> firstRow) >
> 
> 1037??????????? ?????viewToModel.length / 10) {
> 
> to
> 
> 1036???????? if (!sorted || viewToModel.length == 0 ||
> 
> 1037??????????? ??(lastRow - firstRow) > viewToModel.length / 10) {
> 
> In test case if need to throw multiple RuntimeException please make sure 
> that there is difference between them instead of throwing same message 
> ?Wrong Sorting?. We can use ?Wrong sorting before ?? and ?Wrong sorting 
> after ??. Also in jtreg comments section maintain the indentation of 
> multiline comment.
> 
> Thanks,
> 
> Jay
> 
> *From:* Pankaj Bansal
> *Sent:* Monday, January 29, 2018 2:31 PM
> *To:* Jayathirth D V; swing-dev at openjdk.java.net 
> <mailto:swing-dev at openjdk.java.net>; Sergey Bylokhov; Semyon Sadetsky
> *Subject:* RE: <Swing Dev> [11] Review Request: JDK-7007967 
> DefaultRowSorter: incorrect sorting due to not updating comparator cache
> 
> Hello Jay,
> 
> I have made suggested changes.
> 
> webrev: http://cr.openjdk.java.net/~pbansal/7007967/webrev.01/
> 
> << Test case is working fine before and after the change.
> 
> <<I think there is no need for us to verify row index before we delete 
> and update the <<contents again.
> 
>  ?<< 65???????? for (int row = 0; row < model.getRowCount(); row++) {
> 
>  ?<< 66???????????? // values are in sorted ascending. so the row index and
> 
>  ?<< 67???????????? // view index from sorter should be same
> 
>  ?<< 68???????????? if (row != rowSorter.convertRowIndexToView(row)) {
> 
>  ?<< 69???????????????? throw new RuntimeException("Wrong sorting");
> 
>  ?<< 70???????????? }
> 
>  ?<< 71???????? }
> 
> <<We can remove the above code in the test case because we never hit it 
> and throw RuntimeException.
> 
> This is required to make sure that the row sorted is in proper condition 
> and the test passes before making changes. This makes sure that our 
> changes are not causing the error if there are any.
> 
> Regards,
> 
> Pankaj Bansal
> 
> *From:* Jayathirth D V
> *Sent:* Thursday, January 25, 2018 8:32 PM
> *To:* Pankaj Bansal; swing-dev at openjdk.java.net 
> <mailto:swing-dev at openjdk.java.net>; Sergey Bylokhov; Semyon Sadetsky
> *Subject:* RE: <Swing Dev> [11] Review Request: JDK-7007967 
> DefaultRowSorter: incorrect sorting due to not updating comparator cache
> 
> Hello Pankaj,
> 
> Please find my inputs:
> 
> At line 1036 number of characters per line is more than 80, we can 
> divide the conditions into multiple lines.
> 
> 1036???????? if (!sorted || viewToModel.length == 0 || (lastRow - 
> firstRow) > viewToModel.length / 10) {
> 
> 1037???????????? // We either weren't sorted, or to much changed, sort 
> it all or
> 
> 1038???????????? // this is the first row added and we have to update 
> different
> 
> 1039???????????? // caches
> 
> Test case is working fine before and after the change.
> 
> I think there is no need for us to verify row index before we delete and 
> update the contents again.
> 
>  ? 65???????? for (int row = 0; row < model.getRowCount(); row++) {
> 
>  ? 66???????????? // values are in sorted ascending. so the row index and
> 
>  ? 67???????????? // view index from sorter should be same
> 
>  ? 68???????????? if (row != rowSorter.convertRowIndexToView(row)) {
> 
>  ? 69???????????????? throw new RuntimeException("Wrong sorting");
> 
>  ? 70???????????? }
> 
>  ? 71???????? }
> 
> We can remove the above code in the test case because we never hit it 
> and throw RuntimeException.
> 
> Thanks,
> 
> Jay
> 
> *From:* Pankaj Bansal
> *Sent:* Wednesday, January 17, 2018 5:24 PM
> *To:* swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>; 
> Sergey Bylokhov; Semyon Sadetsky
> *Subject:* <Swing Dev> [11] Review Request: JDK-7007967 
> DefaultRowSorter: incorrect sorting due to not updating comparator cache
> 
> Hi All,
> 
> Please review the fix for JDK 11.
> 
> Bug:
> 
> https://bugs.openjdk.java.net/browse/JDK-7007967
> 
> Webrev:
> 
> http://cr.openjdk.java.net/~pbansal/7007967/webrev.00/
> 
> Issue:
> 
> The caching flags like useToString, comparators etc are not always 
> updated in shouldOptimizeChange function. It can cause wrong cache to be 
> used in some cases and produce wrong sorting results.
> 
> For example, in the submitted test case, the integer data is added and 
> sorted. This updates the useToString etc cache flags according to the 
> data type provided. ?//Sorts 1,2,11 as 1->2->11 (correct).
> 
> Then all the data is removed from the model and when the sorter is 
> indicated of this, the cache flags get updated accordingly. Because of 
> this, the useToString is set to true for the column and comparator is 
> set to String Comparator and sorted flag is still true.
> 
> Now if Integer data rows are again added one by one, these flags are not 
> updated and it will use the wrong caches of useToString, comparators etc 
> and produce wrong sorting results. //Sorts 1,2,11 as 1->11->2 
> (Incorrect. The data is sorted according to String representation).
> 
> Fix:
> 
> There can be different approaches to solve this issue. In the current 
> approach, changes have been done in shouldOptimizeChange function to 
> call the sort function when first row is added to the model. This will 
> ensure that the cache flags like useToString, comparators are updated 
> according to the data added for the column.
> 
> Regards,
> 
> Pankaj Bansal
> 


-- 
Best regards, Sergey.


From philip.race at oracle.com  Wed Jan 31 00:07:56 2018
From: philip.race at oracle.com (Phil Race)
Date: Tue, 30 Jan 2018 16:07:56 -0800
Subject: <Swing Dev> RFR: 8196468 : Client jtreg ProblemList updates
Message-ID: <a9767755-fac9-f00f-3639-8bab2ad013f9@oracle.com>

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

There's some noise in here as I moved the swing tests added last time to 
be listed
next to other swing tests and grouped a few other tests together.

The biggest additions are a lot of failures on linux that are filed as 
just a few bugs
since they are likely the same underlying issue - probably a product 
/platform issue
and some tests that jtreg says have errors.

Most of the Windows additions here are tests that timeout for a variety 
of reasons.

-phil.



From Sergey.Bylokhov at oracle.com  Wed Jan 31 02:30:03 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 30 Jan 2018 18:30:03 -0800
Subject: <Swing Dev> RFR: 8196468 : Client jtreg ProblemList updates
In-Reply-To: <a9767755-fac9-f00f-3639-8bab2ad013f9@oracle.com>
References: <a9767755-fac9-f00f-3639-8bab2ad013f9@oracle.com>
Message-ID: <6aeb4573-5c65-1585-5ab0-e35c7034032e@oracle.com>

Looks fine.

On 30/01/2018 16:07, Phil Race wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8196468
> Webrev: http://cr.openjdk.java.net/~prr/8196468/
> 
> There's some noise in here as I moved the swing tests added last time to 
> be listed
> next to other swing tests and grouped a few other tests together.
> 
> The biggest additions are a lot of failures on linux that are filed as 
> just a few bugs
> since they are likely the same underlying issue - probably a product 
> /platform issue
> and some tests that jtreg says have errors.
> 
> Most of the Windows additions here are tests that timeout for a variety 
> of reasons.
> 
> -phil.
> 


-- 
Best regards, Sergey.


From semyon.sadetsky at oracle.com  Wed Jan 31 06:46:37 2018
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Tue, 30 Jan 2018 22:46:37 -0800
Subject: <Swing Dev> [11] Review Request: JDK-6481195
 ListSelectionListener indicates events on model.addElement after
 model.clear()
In-Reply-To: <b8215fa7-2bb0-4d05-8447-00f3346d0ac3@default>
References: <95f74961-80da-480e-93a2-7df0d8239034@default>
 <0aa3a0d5-6506-4b92-8543-37f3235bb475@default>
 <9e880244-feb4-4112-81eb-47d96a1a7090@default>
 <9a87811e-80fc-44bc-b9d9-1f40a93b82d6@default>
 <b8215fa7-2bb0-4d05-8447-00f3346d0ac3@default>
Message-ID: <a59c86d6-1e92-0506-2238-dd602643bdd1@oracle.com>

Hi Pankaj,

When only the first list element deleted the anchor and lead selection 
indexes become -1 after your fix while should be 0.

--Semyon


On 01/30/2018 01:13 AM, Pankaj Bansal wrote:
>
> Hi Jay,
>
> I have made the small correction you suggested.
>
> webrev: http://cr.openjdk.java.net/~pbansal/6481195/webrev.02/ 
> <http://cr.openjdk.java.net/%7Epbansal/6481195/webrev.02/>
>
> Regards,
>
> Pankaj Bansal
>
> *From:* Jayathirth D V
> *Sent:* Tuesday, January 30, 2018 12:13 PM
> *To:* Pankaj Bansal; swing-dev at openjdk.java.net; Sergey Bylokhov; 
> Semyon Sadetsky; Prasanta Sadhukhan
> *Subject:* RE: <Swing Dev> [11] Review Request: JDK-6481195 
> ListSelectionListener indicates events on model.addElement after 
> model.clear()
>
> Hi Pankaj,
>
> Changes are fine.
>
> As mentioned in previous suggestion Java code convention for different 
> statements like if () and for () 
> loops(http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-142311.html 
> ) we have to maintain single space between if/for and braces. In test 
> case this needs to be updated. There is no need for another webrev 
> please update it before you push the change.
>
> Thanks,
>
> Jay
>
> *From:* Pankaj Bansal
> *Sent:* Monday, January 29, 2018 3:39 PM
> *To:* Jayathirth D V; swing-dev at openjdk.java.net 
> <mailto:swing-dev at openjdk.java.net>; Sergey Bylokhov; Semyon Sadetsky; 
> Prasanta Sadhukhan
> *Subject:* RE: <Swing Dev> [11] Review Request: JDK-6481195 
> ListSelectionListener indicates events on model.addElement after 
> model.clear()
>
> Hi Jay,
>
> Thanks for the review.
>
> I have made the suggested changes.
>
> webrev: http://cr.openjdk.java.net/~pbansal/6481195/webrev.01/ 
> <http://cr.openjdk.java.net/%7Epbansal/6481195/webrev.01/>
>
> Regards,
>
> Pankaj Bansal
>
> *From:* Jayathirth D V
> *Sent:* Thursday, January 25, 2018 6:28 PM
> *To:* Pankaj Bansal; swing-dev at openjdk.java.net 
> <mailto:swing-dev at openjdk.java.net>; Sergey Bylokhov; Semyon Sadetsky; 
> Prasanta Sadhukhan
> *Subject:* RE: <Swing Dev> [11] Review Request: JDK-6481195 
> ListSelectionListener indicates events on model.addElement after 
> model.clear()
>
> Hi Pankaj,
>
> Please find my inputs:
>
> Test case is working properly before and after changes.
>
> But I think we should make changes in test to actually detect all 
> failure cases properly instead of throwing RuntimeException when we 
> hit first failure:
>
> if (numberOfEvents > 2) {
>
> throw new RuntimeException("Wrong number of Events. " +
>
> "Expected: 2, Actual: " + numberOfEvents);
>
> }
>
> if (list.getLeadSelectionIndex() != -1) {
>
> throw new RuntimeException("Wrong Lead Index. " +
>
> "Expected: -1, Actual: " + list
>
> ??.getLeadSelectionIndex());
>
> }
>
> if (list.getAnchorSelectionIndex() != -1) {
>
> throw new RuntimeException("Wrong Anchor Index. " +
>
> "Expected: -1, Actual: " + list
>
> ????????????????.getAnchorSelectionIndex());
>
> }
>
> Before your code change we just hit first check throw exception which 
> will not cover all the required conditions(proper number of events, 
> proper lead selection index & proper anchor selection index).
>
> We can update a boolean variable in each of 3 cases and then check 
> them and throw relevant RuntimeException.
>
> Also in test case there are some indentation problems in for loop, if 
> condition and expressions please update them also.
>
> Thanks,
>
> Jay
>
> *From:* Pankaj Bansal
> *Sent:* Monday, January 22, 2018 6:43 PM
> *To:* swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>; 
> Sergey Bylokhov; Semyon Sadetsky; Prasanta Sadhukhan
> *Subject:* <Swing Dev> [11] Review Request: JDK-6481195 
> ListSelectionListener indicates events on model.addElement after 
> model.clear()
>
> Hi All,
>
> Please review the fix for JDK 11.
>
> Bug:
>
> https://bugs.openjdk.java.net/browse/JDK-6481195
>
> Webrev:
>
> http://cr.openjdk.java.net/~pbansal/6481195/webrev.00/ 
> <http://cr.openjdk.java.net/%7Epbansal/6481195/webrev.00/>
>
> Issue:
>
> Invalid ListSelectionEvents are being fired, when the data is added 
> after the clear() function has been called on DefaultListModel. This 
> only happens when the index 0 was selected before calling clear.
>
> When the index 0 is selected on a JList and clear() function is 
> called, anchor and lead are not being updated properly in 
> DefaultSelectionModel as they are not being reset to -1 inside the 
> removeIndexInterval() function. Because of this, when new elements are 
> added in model, a ListSelectionEvent is fired from 
> insertIndexInterval() function.
>
> Fix:
>
> The code inside removeIndexInterval function handles the case when 0 
> index is selected in special way. Removed that piece of code.
>
> Note:
>
> This also fixes https://bugs.openjdk.java.net/browse/JDK-4334792 
> partially when removeAllElements or clear() is called on DefaultListModel.
>
> Regards
>
> Pankaj Bansal
>

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

From pankaj.b.bansal at oracle.com  Wed Jan 31 08:38:54 2018
From: pankaj.b.bansal at oracle.com (Pankaj Bansal)
Date: Wed, 31 Jan 2018 00:38:54 -0800 (PST)
Subject: <Swing Dev> [11] Review Request: JDK-6481195
 ListSelectionListener indicates events on model.addElement after
 model.clear()
In-Reply-To: <a59c86d6-1e92-0506-2238-dd602643bdd1@oracle.com>
References: <95f74961-80da-480e-93a2-7df0d8239034@default>
 <0aa3a0d5-6506-4b92-8543-37f3235bb475@default>
 <9e880244-feb4-4112-81eb-47d96a1a7090@default>
 <9a87811e-80fc-44bc-b9d9-1f40a93b82d6@default>
 <b8215fa7-2bb0-4d05-8447-00f3346d0ac3@default>
 <a59c86d6-1e92-0506-2238-dd602643bdd1@oracle.com>
Message-ID: <5abb7dd1-f8df-4ca0-80b9-acad74f690ec@default>

Hi Semyon,

 

<< When only the first list element deleted the anchor and lead selection indexes become -1 after your fix while should be 0.

Is it mentioned somewhere that it should be 0 ? I mean if lead index was 2 and only 3rd element is deleted, lead becomes 1. Same should be true when lead is 0 and first element is deleted. Is it rule that lead or anchor can't go beyond 0 considering their default value is -1? I think there is a similar bug filled as why should not lead or anchor become -1.

https://bugs.openjdk.java.net/browse/JDK-4334792

 

 

Regards,

Pankaj Bansal

 

 

From: Semyon Sadetsky 
Sent: Wednesday, January 31, 2018 12:17 PM
To: Pankaj Bansal; Jayathirth D V; swing-dev at openjdk.java.net; Sergey Bylokhov; Prasanta Sadhukhan
Subject: Re: <Swing Dev> [11] Review Request: JDK-6481195 ListSelectionListener indicates events on model.addElement after model.clear()

 

Hi Pankaj,

When only the first list element deleted the anchor and lead selection indexes become -1 after your fix while should be 0.

--Semyon

 

On 01/30/2018 01:13 AM, Pankaj Bansal wrote:

Hi Jay,

 

I have made the small correction you suggested.

webrev: HYPERLINK "http://cr.openjdk.java.net/%7Epbansal/6481195/webrev.02/"http://cr.openjdk.java.net/~pbansal/6481195/webrev.02/

 

Regards,

Pankaj Bansal

 

From: Jayathirth D V 
Sent: Tuesday, January 30, 2018 12:13 PM
To: Pankaj Bansal; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net; Sergey Bylokhov; Semyon Sadetsky; Prasanta Sadhukhan
Subject: RE: <Swing Dev> [11] Review Request: JDK-6481195 ListSelectionListener indicates events on model.addElement after model.clear()

 

Hi Pankaj,

 

Changes are fine.

 

As mentioned in previous suggestion Java code convention for different statements like if () and for () loops(http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-142311.html ) we have to maintain single space between if/for and braces. In test case this needs to be updated. There is no need for another webrev please update it before you push the change.

 

Thanks,

Jay

 

From: Pankaj Bansal 
Sent: Monday, January 29, 2018 3:39 PM
To: Jayathirth D V; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net; Sergey Bylokhov; Semyon Sadetsky; Prasanta Sadhukhan
Subject: RE: <Swing Dev> [11] Review Request: JDK-6481195 ListSelectionListener indicates events on model.addElement after model.clear()

 

Hi Jay,

 

Thanks for the review.

 

I have made the suggested changes. 

webrev: HYPERLINK "http://cr.openjdk.java.net/%7Epbansal/6481195/webrev.01/"http://cr.openjdk.java.net/~pbansal/6481195/webrev.01/

 

 

Regards,

Pankaj Bansal

 

From: Jayathirth D V 
Sent: Thursday, January 25, 2018 6:28 PM
To: Pankaj Bansal; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net; Sergey Bylokhov; Semyon Sadetsky; Prasanta Sadhukhan
Subject: RE: <Swing Dev> [11] Review Request: JDK-6481195 ListSelectionListener indicates events on model.addElement after model.clear()

 

Hi Pankaj,

 

Please find my inputs:

Test case is working properly before and after changes.

 

But I think we should make changes in test to actually detect all failure cases properly instead of throwing RuntimeException when we hit first failure:

                    if (numberOfEvents > 2) {

                        throw new RuntimeException("Wrong number of Events. " +

                        "Expected: 2, Actual: " + numberOfEvents);

                    }

 

                    if (list.getLeadSelectionIndex() != -1) {

                        throw new RuntimeException("Wrong Lead Index. " +

                        "Expected: -1, Actual: " + list

                        .getLeadSelectionIndex());

                    }

 

                    if (list.getAnchorSelectionIndex() != -1) {

                        throw new RuntimeException("Wrong Anchor Index. " +

                        "Expected: -1, Actual: " + list

                        .getAnchorSelectionIndex());

                    }

 

Before your code change we just hit first check throw exception which will not cover all the required conditions(proper number of events, proper lead selection index & proper anchor selection index).

We can update a boolean variable in each of 3 cases and then check them and throw relevant RuntimeException.

 

Also in test case there are some indentation problems in for loop, if condition and expressions please update them also.

 

Thanks,

Jay

 

From: Pankaj Bansal 
Sent: Monday, January 22, 2018 6:43 PM
To: HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net; Sergey Bylokhov; Semyon Sadetsky; Prasanta Sadhukhan
Subject: <Swing Dev> [11] Review Request: JDK-6481195 ListSelectionListener indicates events on model.addElement after model.clear()

 

Hi All,

 

Please review the fix for JDK 11.

 

Bug:

https://bugs.openjdk.java.net/browse/JDK-6481195

 

Webrev:

HYPERLINK "http://cr.openjdk.java.net/%7Epbansal/6481195/webrev.00/"http://cr.openjdk.java.net/~pbansal/6481195/webrev.00/

 

Issue:

Invalid ListSelectionEvents are being fired, when the data is added after the clear() function has been called on DefaultListModel. This only happens when the index 0 was selected before calling clear.
 

When the index 0 is selected on a JList and clear() function is called, anchor and lead are not being updated properly in DefaultSelectionModel as they are not being reset to -1 inside the removeIndexInterval() function. Because of this, when new elements are added in model, a ListSelectionEvent is fired from insertIndexInterval() function.

 

Fix:

The code inside removeIndexInterval function handles the case when 0 index is selected in special way. Removed that piece of code. 

 

Note: 

This also fixes https://bugs.openjdk.java.net/browse/JDK-4334792 partially when removeAllElements or clear() is called on DefaultListModel.

 

 

Regards

Pankaj Bansal

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

From prasanta.sadhukhan at oracle.com  Wed Jan 31 13:41:23 2018
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Wed, 31 Jan 2018 19:11:23 +0530
Subject: <Swing Dev> [11] RFR JDK-8191106: Nimbus LookAndFeel does not
 apply keys FileChooser.directoryOpenButtonText/ToolTipText to JFileChooser
In-Reply-To: <86f71e03-1bed-8481-70f5-7f8988b10276@oracle.com>
References: <cba5c211-bc50-9e81-0141-1c0460b80070@oracle.com>
 <cba7509f-ab9c-894c-c5dd-06145b5ac112@oracle.com>
 <f28aa56c-af7a-e5c4-d5c9-d0efca19457a@oracle.com>
 <01ecf34a-cc73-1e20-09c2-585e24a04be7@oracle.com>
 <b82590e8-ae1d-b268-9060-94518ed46617@oracle.com>
 <86f71e03-1bed-8481-70f5-7f8988b10276@oracle.com>
Message-ID: <3ca8afde-2580-f839-b647-d6745c932a0c@oracle.com>

Hi Semyon,

I could not find in spec if Nimbus should get the mnemonics but 
historically, we supported mnemonics for nimbus, see 
https://bugs.openjdk.java.net/browse/JDK-8002077

Regards
Prasanta
On 1/30/2018 10:22 PM, Semyon Sadetsky wrote:
> Hi Prasanta,
>
> Can you explain why Nimbus should get those mnemonics but Metal not.
>
> --Semyon
>
>
> On 01/30/2018 02:16 AM, Prasanta Sadhukhan wrote:
>> Hi,
>>
>> Any comments about the fix?
>>
>> Regards
>> Prasanta
>> On 1/6/2018 1:00 PM, Sergey Bylokhov wrote:
>>> On 04/01/2018 22:05, Prasanta Sadhukhan wrote:
>>>> Hi Semyon,
>>>>
>>>> It's not exactly the same. For Metal, we do not set mnemonic, not 
>>>> sure if that is intentional, so did not push it down to basic class.
>>>
>>> They were intentionally dropped: 
>>> https://bugs.openjdk.java.net/browse/JDK-8080628
>>>
>>>>
>>>> Regards
>>>> Prasanta
>>>> On 1/4/2018 9:34 PM, Semyon Sadetsky wrote:
>>>>> Hi Prasanta,
>>>>>
>>>>> Since all those L&F's now have the same implementation of the 
>>>>> method maybe it worth to push it down to the basic class?
>>>>>
>>>>> --Semyon
>>>>>
>>>>> On 01/04/2018 02:33 AM, Prasanta Sadhukhan wrote:
>>>>>> Hi All,
>>>>>>
>>>>>> Please review a fix for Nimbus L&F where it is seen that
>>>>>> When you select a directory in a JFileChooser dialog, the text 
>>>>>> and tooltip of the "approve" button is not changing to the values 
>>>>>> of UIManager keys FileChooser.directoryOpenButtonText and 
>>>>>> FileChooser.directoryOpenButtonToolTipText and remain same as it 
>>>>>> was before directory is selected.
>>>>>> It changes for Metal and windows l&f.
>>>>>>
>>>>>> This is because when directory is selected 
>>>>>> BasicFileChooserUI#valueChanged() calls setDirectorySelected() 
>>>>>> but it's not implemented for nimbus l&f and it uses default 
>>>>>> implementation of BasicFileChooser.
>>>>>> For Metal & Windows, this method is overridden to change the 
>>>>>> approve button text to FileChooser.directoryOpenButtonText.
>>>>>> Propsosed fix is to override this method for Nimbus L&f and set 
>>>>>> the approve button text to FileChooser.directoryOpenButtonText.
>>>>>>
>>>>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8191106
>>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8191106/webrev.00/
>>>>>>
>>>>>> Regards
>>>>>> Prasanta
>>>>>>
>>>>>
>>>>
>>>
>>>
>>
>



From semyon.sadetsky at oracle.com  Wed Jan 31 16:18:46 2018
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Wed, 31 Jan 2018 08:18:46 -0800
Subject: <Swing Dev> [11] Review Request: JDK-6481195
 ListSelectionListener indicates events on model.addElement after
 model.clear()
In-Reply-To: <5abb7dd1-f8df-4ca0-80b9-acad74f690ec@default>
References: <95f74961-80da-480e-93a2-7df0d8239034@default>
 <0aa3a0d5-6506-4b92-8543-37f3235bb475@default>
 <9e880244-feb4-4112-81eb-47d96a1a7090@default>
 <9a87811e-80fc-44bc-b9d9-1f40a93b82d6@default>
 <b8215fa7-2bb0-4d05-8447-00f3346d0ac3@default>
 <a59c86d6-1e92-0506-2238-dd602643bdd1@oracle.com>
 <5abb7dd1-f8df-4ca0-80b9-acad74f690ec@default>
Message-ID: <1402ccc9-dfb8-dd2f-935d-b847939ab122@oracle.com>

Hi Pankaj,

This is directly specified in getLeadSelectionIndex()/ 
getAnchorSelectionIndex().

Anchor and lead indexes are used in lot of places. Which tests did you 
run after the fix?

--Semyon


On 01/31/2018 12:38 AM, Pankaj Bansal wrote:
>
> Hi Semyon,
>
> << When only the first list element deleted the anchor and lead 
> selection indexes become -1 after your fix while should be 0.
>
> Is it mentioned somewhere that it should be 0 ? I mean if lead index 
> was 2 and only 3^rd element is deleted, lead becomes 1. Same should be 
> true when lead is 0 and first element is deleted. Is it rule that lead 
> or anchor can?t go beyond 0 considering their default value is -1? I 
> think there is a similar bug filled as why should not lead or anchor 
> become -1.
>
> https://bugs.openjdk.java.net/browse/JDK-4334792
>
> Regards,
>
> Pankaj Bansal
>
> *From:*Semyon Sadetsky
> *Sent:* Wednesday, January 31, 2018 12:17 PM
> *To:* Pankaj Bansal; Jayathirth D V; swing-dev at openjdk.java.net; 
> Sergey Bylokhov; Prasanta Sadhukhan
> *Subject:* Re: <Swing Dev> [11] Review Request: JDK-6481195 
> ListSelectionListener indicates events on model.addElement after 
> model.clear()
>
> Hi Pankaj,
>
> When only the first list element deleted the anchor and lead selection 
> indexes become -1 after your fix while should be 0.
>
> --Semyon
>
> On 01/30/2018 01:13 AM, Pankaj Bansal wrote:
>
>     Hi Jay,
>
>     I have made the small correction you suggested.
>
>     webrev: http://cr.openjdk.java.net/~pbansal/6481195/webrev.02/
>     <http://cr.openjdk.java.net/%7Epbansal/6481195/webrev.02/>
>
>     Regards,
>
>     Pankaj Bansal
>
>     *From:* Jayathirth D V
>     *Sent:* Tuesday, January 30, 2018 12:13 PM
>     *To:* Pankaj Bansal; swing-dev at openjdk.java.net
>     <mailto:swing-dev at openjdk.java.net>; Sergey Bylokhov; Semyon
>     Sadetsky; Prasanta Sadhukhan
>     *Subject:* RE: <Swing Dev> [11] Review Request: JDK-6481195
>     ListSelectionListener indicates events on model.addElement after
>     model.clear()
>
>     Hi Pankaj,
>
>     Changes are fine.
>
>     As mentioned in previous suggestion Java code convention for
>     different statements like if () and for ()
>     loops(http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-142311.html
>     ) we have to maintain single space between if/for and braces. In
>     test case this needs to be updated. There is no need for another
>     webrev please update it before you push the change.
>
>     Thanks,
>
>     Jay
>
>     *From:* Pankaj Bansal
>     *Sent:* Monday, January 29, 2018 3:39 PM
>     *To:* Jayathirth D V; swing-dev at openjdk.java.net
>     <mailto:swing-dev at openjdk.java.net>; Sergey Bylokhov; Semyon
>     Sadetsky; Prasanta Sadhukhan
>     *Subject:* RE: <Swing Dev> [11] Review Request: JDK-6481195
>     ListSelectionListener indicates events on model.addElement after
>     model.clear()
>
>     Hi Jay,
>
>     Thanks for the review.
>
>     I have made the suggested changes.
>
>     webrev: http://cr.openjdk.java.net/~pbansal/6481195/webrev.01/
>     <http://cr.openjdk.java.net/%7Epbansal/6481195/webrev.01/>
>
>     Regards,
>
>     Pankaj Bansal
>
>     *From:* Jayathirth D V
>     *Sent:* Thursday, January 25, 2018 6:28 PM
>     *To:* Pankaj Bansal; swing-dev at openjdk.java.net
>     <mailto:swing-dev at openjdk.java.net>; Sergey Bylokhov; Semyon
>     Sadetsky; Prasanta Sadhukhan
>     *Subject:* RE: <Swing Dev> [11] Review Request: JDK-6481195
>     ListSelectionListener indicates events on model.addElement after
>     model.clear()
>
>     Hi Pankaj,
>
>     Please find my inputs:
>
>     Test case is working properly before and after changes.
>
>     But I think we should make changes in test to actually detect all
>     failure cases properly instead of throwing RuntimeException when
>     we hit first failure:
>
>     if (numberOfEvents > 2) {
>
>     throw new RuntimeException("Wrong number of Events. " +
>
>     "Expected: 2, Actual: " + numberOfEvents);
>
>     }
>
>     if (list.getLeadSelectionIndex() != -1) {
>
>     throw new RuntimeException("Wrong Lead Index. " +
>
>     "Expected: -1, Actual: " + list
>
>     ??.getLeadSelectionIndex());
>
>     }
>
>     if (list.getAnchorSelectionIndex() != -1) {
>
>     throw new RuntimeException("Wrong Anchor Index. " +
>
>     "Expected: -1, Actual: " + list
>
>     ????????????????.getAnchorSelectionIndex());
>
>     }
>
>     Before your code change we just hit first check throw exception
>     which will not cover all the required conditions(proper number of
>     events, proper lead selection index & proper anchor selection index).
>
>     We can update a boolean variable in each of 3 cases and then check
>     them and throw relevant RuntimeException.
>
>     Also in test case there are some indentation problems in for loop,
>     if condition and expressions please update them also.
>
>     Thanks,
>
>     Jay
>
>     *From:* Pankaj Bansal
>     *Sent:* Monday, January 22, 2018 6:43 PM
>     *To:* swing-dev at openjdk.java.net
>     <mailto:swing-dev at openjdk.java.net>; Sergey Bylokhov; Semyon
>     Sadetsky; Prasanta Sadhukhan
>     *Subject:* <Swing Dev> [11] Review Request: JDK-6481195
>     ListSelectionListener indicates events on model.addElement after
>     model.clear()
>
>     Hi All,
>
>     Please review the fix for JDK 11.
>
>     Bug:
>
>     https://bugs.openjdk.java.net/browse/JDK-6481195
>
>     Webrev:
>
>     http://cr.openjdk.java.net/~pbansal/6481195/webrev.00/
>     <http://cr.openjdk.java.net/%7Epbansal/6481195/webrev.00/>
>
>     Issue:
>
>     Invalid ListSelectionEvents are being fired, when the data is
>     added after the clear() function has been called on
>     DefaultListModel. This only happens when the index 0 was selected
>     before calling clear.
>
>     When the index 0 is selected on a JList and clear() function is
>     called, anchor and lead are not being updated properly in
>     DefaultSelectionModel as they are not being reset to -1 inside the
>     removeIndexInterval() function. Because of this, when new elements
>     are added in model, a ListSelectionEvent is fired from
>     insertIndexInterval() function.
>
>     Fix:
>
>     The code inside removeIndexInterval function handles the case when
>     0 index is selected in special way. Removed that piece of code.
>
>     Note:
>
>     This also fixes https://bugs.openjdk.java.net/browse/JDK-4334792
>     partially when removeAllElements or clear() is called on
>     DefaultListModel.
>
>     Regards
>
>     Pankaj Bansal
>

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

From semyon.sadetsky at oracle.com  Wed Jan 31 16:28:02 2018
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Wed, 31 Jan 2018 08:28:02 -0800
Subject: <Swing Dev> [11] RFR JDK-8191106: Nimbus LookAndFeel does not
 apply keys FileChooser.directoryOpenButtonText/ToolTipText to JFileChooser
In-Reply-To: <3ca8afde-2580-f839-b647-d6745c932a0c@oracle.com>
References: <cba5c211-bc50-9e81-0141-1c0460b80070@oracle.com>
 <cba7509f-ab9c-894c-c5dd-06145b5ac112@oracle.com>
 <f28aa56c-af7a-e5c4-d5c9-d0efca19457a@oracle.com>
 <01ecf34a-cc73-1e20-09c2-585e24a04be7@oracle.com>
 <b82590e8-ae1d-b268-9060-94518ed46617@oracle.com>
 <86f71e03-1bed-8481-70f5-7f8988b10276@oracle.com>
 <3ca8afde-2580-f839-b647-d6745c932a0c@oracle.com>
Message-ID: <9bba919e-d0d0-2bb6-a583-f843cadbb330@oracle.com>

Hi Prasanta,

As I understand JDK-8080628 mnemonics for Open/Save button are redundant 
and should be dropped for all Look and Feels.

--Semyon

On 01/31/2018 05:41 AM, Prasanta Sadhukhan wrote:
> Hi Semyon,
>
> I could not find in spec if Nimbus should get the mnemonics but 
> historically, we supported mnemonics for nimbus, see 
> https://bugs.openjdk.java.net/browse/JDK-8002077
>
> Regards
> Prasanta
> On 1/30/2018 10:22 PM, Semyon Sadetsky wrote:
>> Hi Prasanta,
>>
>> Can you explain why Nimbus should get those mnemonics but Metal not.
>>
>> --Semyon
>>
>>
>> On 01/30/2018 02:16 AM, Prasanta Sadhukhan wrote:
>>> Hi,
>>>
>>> Any comments about the fix?
>>>
>>> Regards
>>> Prasanta
>>> On 1/6/2018 1:00 PM, Sergey Bylokhov wrote:
>>>> On 04/01/2018 22:05, Prasanta Sadhukhan wrote:
>>>>> Hi Semyon,
>>>>>
>>>>> It's not exactly the same. For Metal, we do not set mnemonic, not 
>>>>> sure if that is intentional, so did not push it down to basic class.
>>>>
>>>> They were intentionally dropped: 
>>>> https://bugs.openjdk.java.net/browse/JDK-8080628
>>>>
>>>>>
>>>>> Regards
>>>>> Prasanta
>>>>> On 1/4/2018 9:34 PM, Semyon Sadetsky wrote:
>>>>>> Hi Prasanta,
>>>>>>
>>>>>> Since all those L&F's now have the same implementation of the 
>>>>>> method maybe it worth to push it down to the basic class?
>>>>>>
>>>>>> --Semyon
>>>>>>
>>>>>> On 01/04/2018 02:33 AM, Prasanta Sadhukhan wrote:
>>>>>>> Hi All,
>>>>>>>
>>>>>>> Please review a fix for Nimbus L&F where it is seen that
>>>>>>> When you select a directory in a JFileChooser dialog, the text 
>>>>>>> and tooltip of the "approve" button is not changing to the 
>>>>>>> values of UIManager keys FileChooser.directoryOpenButtonText and 
>>>>>>> FileChooser.directoryOpenButtonToolTipText and remain same as it 
>>>>>>> was before directory is selected.
>>>>>>> It changes for Metal and windows l&f.
>>>>>>>
>>>>>>> This is because when directory is selected 
>>>>>>> BasicFileChooserUI#valueChanged() calls setDirectorySelected() 
>>>>>>> but it's not implemented for nimbus l&f and it uses default 
>>>>>>> implementation of BasicFileChooser.
>>>>>>> For Metal & Windows, this method is overridden to change the 
>>>>>>> approve button text to FileChooser.directoryOpenButtonText.
>>>>>>> Propsosed fix is to override this method for Nimbus L&f and set 
>>>>>>> the approve button text to FileChooser.directoryOpenButtonText.
>>>>>>>
>>>>>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8191106
>>>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8191106/webrev.00/
>>>>>>>
>>>>>>> Regards
>>>>>>> Prasanta
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>



From philip.race at oracle.com  Wed Jan 31 18:08:28 2018
From: philip.race at oracle.com (Phil Race)
Date: Wed, 31 Jan 2018 10:08:28 -0800
Subject: <Swing Dev> RFR: 8196468 : Client jtreg ProblemList updates
In-Reply-To: <6aeb4573-5c65-1585-5ab0-e35c7034032e@oracle.com>
References: <a9767755-fac9-f00f-3639-8bab2ad013f9@oracle.com>
 <6aeb4573-5c65-1585-5ab0-e35c7034032e@oracle.com>
Message-ID: <c20e85d3-bc22-463c-a385-7c8e1bc30845@oracle.com>

I need to update this before I push. v0 added

216 java/awt/Modal/FileDialog/FileDialogTKModal1Test.java 8196430 linux-all
217 java/awt/Modal/FileDialog/FileDialogTKModal2Test.java 8196430 linux-all
218 java/awt/Modal/FileDialog/FileDialogTKModal3Test.java 8196430 linux-all
219 java/awt/Modal/FileDialog/FileDialogTKModal4Test.java 8196430 linux-all
220 java/awt/Modal/FileDialog/FileDialogTKModal5Test.java 8196430 linux-all
221 java/awt/Modal/FileDialog/FileDialogTKModal6Test.java 8196430 
linux-all But these tests were already excluded on windows+mac under a 
different ID .. Now adding this line, jtreg seems to prefer this new 
line and doesn't see that it should be ignoring the test on windows 
under the other ID. So you can only exclude a test under one ID .. even 
if failures are on different platforms and the causes are unrelated. I 
have removed the original one and made these entries platform generic. 
http://cr.openjdk.java.net/~prr/8196468.1/ -phil.

On 01/30/2018 06:30 PM, Sergey Bylokhov wrote:
> Looks fine.
>
> On 30/01/2018 16:07, Phil Race wrote:
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8196468
>> Webrev: http://cr.openjdk.java.net/~prr/8196468/
>>
>> There's some noise in here as I moved the swing tests added last time 
>> to be listed
>> next to other swing tests and grouped a few other tests together.
>>
>> The biggest additions are a lot of failures on linux that are filed 
>> as just a few bugs
>> since they are likely the same underlying issue - probably a product 
>> /platform issue
>> and some tests that jtreg says have errors.
>>
>> Most of the Windows additions here are tests that timeout for a 
>> variety of reasons.
>>
>> -phil.
>>
>
>

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

From Sergey.Bylokhov at oracle.com  Wed Jan 31 19:00:28 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 31 Jan 2018 11:00:28 -0800
Subject: <Swing Dev> RFR: 8196468 : Client jtreg ProblemList updates
In-Reply-To: <c20e85d3-bc22-463c-a385-7c8e1bc30845@oracle.com>
References: <a9767755-fac9-f00f-3639-8bab2ad013f9@oracle.com>
 <6aeb4573-5c65-1585-5ab0-e35c7034032e@oracle.com>
 <c20e85d3-bc22-463c-a385-7c8e1bc30845@oracle.com>
Message-ID: <840b7b38-6659-fcaf-91b9-5d983ccf2942@oracle.com>

+1
On 31/01/2018 10:08, Phil Race wrote:
> linux-all But these tests were already excluded on windows+mac under a 
> different ID .. Now adding this line, jtreg seems to prefer this new 
> line and doesn't see that it should be ignoring the test on windows 
> under the other ID. So you can only exclude a test under one ID .. even 
> if failures are on different platforms and the causes are unrelated.

Maybe we can create RFE for jtreg?

> 
> On 01/30/2018 06:30 PM, Sergey Bylokhov wrote:
>> Looks fine.
>>
>> On 30/01/2018 16:07, Phil Race wrote:
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8196468
>>> Webrev: http://cr.openjdk.java.net/~prr/8196468/
>>>
>>> There's some noise in here as I moved the swing tests added last time 
>>> to be listed
>>> next to other swing tests and grouped a few other tests together.
>>>
>>> The biggest additions are a lot of failures on linux that are filed 
>>> as just a few bugs
>>> since they are likely the same underlying issue - probably a product 
>>> /platform issue
>>> and some tests that jtreg says have errors.
>>>
>>> Most of the Windows additions here are tests that timeout for a 
>>> variety of reasons.
>>>
>>> -phil.
>>>
>>
>>
> 


-- 
Best regards, Sergey.


From pankaj.b.bansal at oracle.com  Wed Jan 31 19:04:44 2018
From: pankaj.b.bansal at oracle.com (Pankaj Bansal)
Date: Wed, 31 Jan 2018 11:04:44 -0800 (PST)
Subject: <Swing Dev> [11] Review Request: JDK-6481195
 ListSelectionListener indicates events on model.addElement after
 model.clear()
In-Reply-To: <1402ccc9-dfb8-dd2f-935d-b847939ab122@oracle.com>
References: <95f74961-80da-480e-93a2-7df0d8239034@default>
 <0aa3a0d5-6506-4b92-8543-37f3235bb475@default>
 <9e880244-feb4-4112-81eb-47d96a1a7090@default>
 <9a87811e-80fc-44bc-b9d9-1f40a93b82d6@default>
 <b8215fa7-2bb0-4d05-8447-00f3346d0ac3@default>
 <a59c86d6-1e92-0506-2238-dd602643bdd1@oracle.com>
 <5abb7dd1-f8df-4ca0-80b9-acad74f690ec@default>
 <1402ccc9-dfb8-dd2f-935d-b847939ab122@oracle.com>
Message-ID: <5fb71560-7da4-4dff-b2ff-c56f9b17b80c@default>

Hi Semyon,

 

Thanks for the review.

 

<< This is directly specified in getLeadSelectionIndex()/ getAnchorSelectionIndex().

Sorry but I am not able to find anything specific to handling of case of 0th item being deleted when first row is selected or anything which states that anchor or lead can't be -1. I guess I may be missing something here or not able to infer what you are saying. Can you please point out which specific statement describes the behavior you suggested.

 

<<Anchor and lead indexes are used in lot of places. Which tests did you run after the fix?

I have run following tests. I have run most of them(closed/jck) on Windows, but I think if this change is to affect something, it would not be platform specific. All the following runs have passed successfully (no new failures/errors).

 

All automated tests  in: Open/test/jdk/javax/swing/JList,  /JTable, /JTableHeader, /JTree 

All automated tests  in: Closed/test/jdk/javax/swing/JList, /Jtable, /JTableeHeader, /JTree, /DefaultListSelectionModel, /DefaultListModel, /DefaultListCellRenderer

All tests  in: jck/swing_javax/JList, /JTable, /Tree, /DefaultListSelectionModel, /DefaultSingleSelectionModel , /DefaultListModel, /DefaultListCellRenderer

Few demos like SwingSet2, Java2D

 

Please let me know if you think I should run some more tests.

 

Regards,

Pankaj Bansal

From: Semyon Sadetsky 
Sent: Wednesday, January 31, 2018 9:49 PM
To: Pankaj Bansal; swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [11] Review Request: JDK-6481195 ListSelectionListener indicates events on model.addElement after model.clear()

 

Hi Pankaj,

This is directly specified in getLeadSelectionIndex()/ getAnchorSelectionIndex().

Anchor and lead indexes are used in lot of places. Which tests did you run after the fix?

--Semyon

 

On 01/31/2018 12:38 AM, Pankaj Bansal wrote:

Hi Semyon,

 

<< When only the first list element deleted the anchor and lead selection indexes become -1 after your fix while should be 0.

Is it mentioned somewhere that it should be 0 ? I mean if lead index was 2 and only 3rd element is deleted, lead becomes 1. Same should be true when lead is 0 and first element is deleted. Is it rule that lead or anchor can't go beyond 0 considering their default value is -1? I think there is a similar bug filled as why should not lead or anchor become -1.

https://bugs.openjdk.java.net/browse/JDK-4334792

 

 

Regards,

Pankaj Bansal

 

 

From: Semyon Sadetsky 
Sent: Wednesday, January 31, 2018 12:17 PM
To: Pankaj Bansal; Jayathirth D V; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net; Sergey Bylokhov; Prasanta Sadhukhan
Subject: Re: <Swing Dev> [11] Review Request: JDK-6481195 ListSelectionListener indicates events on model.addElement after model.clear()

 

Hi Pankaj,

When only the first list element deleted the anchor and lead selection indexes become -1 after your fix while should be 0.

--Semyon

 

On 01/30/2018 01:13 AM, Pankaj Bansal wrote:

Hi Jay,

 

I have made the small correction you suggested.

webrev: HYPERLINK "http://cr.openjdk.java.net/%7Epbansal/6481195/webrev.02/"http://cr.openjdk.java.net/~pbansal/6481195/webrev.02/

 

Regards,

Pankaj Bansal

 

From: Jayathirth D V 
Sent: Tuesday, January 30, 2018 12:13 PM
To: Pankaj Bansal; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net; Sergey Bylokhov; Semyon Sadetsky; Prasanta Sadhukhan
Subject: RE: <Swing Dev> [11] Review Request: JDK-6481195 ListSelectionListener indicates events on model.addElement after model.clear()

 

Hi Pankaj,

 

Changes are fine.

 

As mentioned in previous suggestion Java code convention for different statements like if () and for () loops(http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-142311.html ) we have to maintain single space between if/for and braces. In test case this needs to be updated. There is no need for another webrev please update it before you push the change.

 

Thanks,

Jay

 

From: Pankaj Bansal 
Sent: Monday, January 29, 2018 3:39 PM
To: Jayathirth D V; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net; Sergey Bylokhov; Semyon Sadetsky; Prasanta Sadhukhan
Subject: RE: <Swing Dev> [11] Review Request: JDK-6481195 ListSelectionListener indicates events on model.addElement after model.clear()

 

Hi Jay,

 

Thanks for the review.

 

I have made the suggested changes. 

webrev: HYPERLINK "http://cr.openjdk.java.net/%7Epbansal/6481195/webrev.01/"http://cr.openjdk.java.net/~pbansal/6481195/webrev.01/

 

 

Regards,

Pankaj Bansal

 

From: Jayathirth D V 
Sent: Thursday, January 25, 2018 6:28 PM
To: Pankaj Bansal; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net; Sergey Bylokhov; Semyon Sadetsky; Prasanta Sadhukhan
Subject: RE: <Swing Dev> [11] Review Request: JDK-6481195 ListSelectionListener indicates events on model.addElement after model.clear()

 

Hi Pankaj,

 

Please find my inputs:

Test case is working properly before and after changes.

 

But I think we should make changes in test to actually detect all failure cases properly instead of throwing RuntimeException when we hit first failure:

                    if (numberOfEvents > 2) {

                        throw new RuntimeException("Wrong number of Events. " +

                        "Expected: 2, Actual: " + numberOfEvents);

                    }

 

                    if (list.getLeadSelectionIndex() != -1) {

                        throw new RuntimeException("Wrong Lead Index. " +

                        "Expected: -1, Actual: " + list

                        .getLeadSelectionIndex());

                    }

 

                    if (list.getAnchorSelectionIndex() != -1) {

                        throw new RuntimeException("Wrong Anchor Index. " +

                        "Expected: -1, Actual: " + list

                        .getAnchorSelectionIndex());

                    }

 

Before your code change we just hit first check throw exception which will not cover all the required conditions(proper number of events, proper lead selection index & proper anchor selection index).

We can update a boolean variable in each of 3 cases and then check them and throw relevant RuntimeException.

 

Also in test case there are some indentation problems in for loop, if condition and expressions please update them also.

 

Thanks,

Jay

 

From: Pankaj Bansal 
Sent: Monday, January 22, 2018 6:43 PM
To: HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net; Sergey Bylokhov; Semyon Sadetsky; Prasanta Sadhukhan
Subject: <Swing Dev> [11] Review Request: JDK-6481195 ListSelectionListener indicates events on model.addElement after model.clear()

 

Hi All,

 

Please review the fix for JDK 11.

 

Bug:

https://bugs.openjdk.java.net/browse/JDK-6481195

 

Webrev:

HYPERLINK "http://cr.openjdk.java.net/%7Epbansal/6481195/webrev.00/"http://cr.openjdk.java.net/~pbansal/6481195/webrev.00/

 

Issue:

Invalid ListSelectionEvents are being fired, when the data is added after the clear() function has been called on DefaultListModel. This only happens when the index 0 was selected before calling clear.
 

When the index 0 is selected on a JList and clear() function is called, anchor and lead are not being updated properly in DefaultSelectionModel as they are not being reset to -1 inside the removeIndexInterval() function. Because of this, when new elements are added in model, a ListSelectionEvent is fired from insertIndexInterval() function.

 

Fix:

The code inside removeIndexInterval function handles the case when 0 index is selected in special way. Removed that piece of code. 

 

Note: 

This also fixes https://bugs.openjdk.java.net/browse/JDK-4334792 partially when removeAllElements or clear() is called on DefaultListModel.

 

 

Regards

Pankaj Bansal

 

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