From semyon.sadetsky at oracle.com  Thu Mar  1 00:52:09 2018
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Wed, 28 Feb 2018 16:52:09 -0800
Subject: <Swing Dev> [11] RFR JDK-8198777:
 JList.getPreferredScrollableViewportSize(): fix mistake in doc for height
 calc
In-Reply-To: <c52763c8-c6b9-3748-2f31-d30afd68bf5b@oracle.com>
References: <c52763c8-c6b9-3748-2f31-d30afd68bf5b@oracle.com>
Message-ID: <4cb56cf0-2507-4063-cbe3-a15f13358abe@oracle.com>

Hello Alexey,

"height of the first cell" has relative meaning. I suggest to change it 
to "height of cell with index 0".

Also, it would be nice to specify the case when the model is empty.

--Semyon

On 02/28/2018 01:39 PM, Alexey Ivanov wrote:
> Hello,
>
> Could you please review the fix for jdk11?
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8198777
> webrev: http://cr.openjdk.java.net/~aivanov/8198777/webrev.0/
> csr: https://bugs.openjdk.java.net/browse/JDK-8198822
>
> It is a small fix to documentation of 
> JList.getPreferredScrollableViewportSize().
>
> If either fixedCellWidth or fixedCellHeight are not set and the model 
> isn't empty, heuristics are used. The height is based one the height 
> of the first cell rather than fixedCellHeight.
>
>
> Regards,
> Alexey



From alexey.ivanov at oracle.com  Thu Mar  1 12:21:54 2018
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Thu, 1 Mar 2018 12:21:54 +0000
Subject: <Swing Dev> [11] RFR JDK-8198777:
 JList.getPreferredScrollableViewportSize(): fix mistake in doc for height
 calc
In-Reply-To: <4cb56cf0-2507-4063-cbe3-a15f13358abe@oracle.com>
References: <c52763c8-c6b9-3748-2f31-d30afd68bf5b@oracle.com>
 <4cb56cf0-2507-4063-cbe3-a15f13358abe@oracle.com>
Message-ID: <e71f8c52-8548-c855-9d35-c968047bfb70@oracle.com>

Hello Semyon,

Thank you for your review.

The updated version:
http://cr.openjdk.java.net/~aivanov/8198777/webrev.1/

The case where the model is empty is covered in the paragraph above. No 
change is necessary there.

Regards,
Alexey

On 01/03/2018 00:52, Semyon Sadetsky wrote:
> Hello Alexey,
>
> "height of the first cell" has relative meaning. I suggest to change 
> it to "height of cell with index 0".
>
> Also, it would be nice to specify the case when the model is empty.
>
> --Semyon
>
> On 02/28/2018 01:39 PM, Alexey Ivanov wrote:
>> Hello,
>>
>> Could you please review the fix for jdk11?
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8198777
>> webrev: http://cr.openjdk.java.net/~aivanov/8198777/webrev.0/
>> csr: https://bugs.openjdk.java.net/browse/JDK-8198822
>>
>> It is a small fix to documentation of 
>> JList.getPreferredScrollableViewportSize().
>>
>> If either fixedCellWidth or fixedCellHeight are not set and the model 
>> isn't empty, heuristics are used. The height is based one the height 
>> of the first cell rather than fixedCellHeight.
>>
>>
>> Regards,
>> Alexey
>



From pankaj.b.bansal at oracle.com  Thu Mar  1 12:36:12 2018
From: pankaj.b.bansal at oracle.com (Pankaj Bansal)
Date: Thu, 1 Mar 2018 04:36:12 -0800 (PST)
Subject: <Swing Dev> [11] JDK-8190347: [TESTBUG] Test
 javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentJComboBox.java
 fails
In-Reply-To: <5d05e857-325c-b3ad-e446-0de6aa70b073@oracle.com>
References: <7d0dfeac-97ef-4c36-81bc-8fc3c6223359@default>
 <4c4362ed-b80d-40dc-9bcd-7dc3f6dbbb3f@default>
 <f39e9019-8a0d-4574-889d-edff2da5adfd@default>
 <18203ec3-d7b5-47df-98d3-4234cb437a4e@default>
 <6a9f6bb0-292d-1e05-1c23-522f20ffedf8@oracle.com>
 <fe1ca8ad-7dad-4028-b11b-df27c4120eef@default>
 <3b47f589-2de9-8590-4010-9736e3ad9427@oracle.com>
 <886530f7-c29c-45e9-ba59-95234ffc78e1@default>
 <4e2a3e7d-b43b-8571-26b1-d4d9abe19276@oracle.com>
 <5d05e857-325c-b3ad-e446-0de6aa70b073@oracle.com>
Message-ID: <26f58787-2b4c-4042-92c4-d0627fa9d6aa@default>

Hi Sergey,

JDK-8024627: This is not reproducible on Windows 10, but I can reproduce it on Ubuntu 16.04 and Mac.
On Ubuntu, only the first click does not trigger the event, but subsequent clicks are triggered, but on Mac none of the clicks is triggered.
The test javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentJComboBox.java passes on Ubuntu.

I will like to point out, it looks like there are multiple things wrong with this test and the present bug jdk-8190347 was filled to fix just one problem in specific scenario described in explanation which is independent of the OS. 
The mac specific issue "Flag is not triggered for point **" will be fixed by the bug you pointed out JDK-8024627. This same issue "Flag is not triggered for point **"  is also observed in javax/swing/JWindow/ShapedAndTranslucentWindows/SetShapeAndClickSwing.java, which is failing because of JDK-8013450 (mentioned in problemList) on Mac. JDK-8013450 and JDK-8024627 look duplicate.

I think the problemList also needs to be updated as javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentJComboBox.java will be fixed for Mac with JDK-8024627, not JDK-8190347.
Webrev:
http://cr.openjdk.java.net/~pbansal/8190347/webrev.03/


Regards,
Pankaj Bansal

-----Original Message-----
From: Sergey Bylokhov 
Sent: Thursday, March 1, 2018 4:13 AM
To: Prasanta Sadhukhan; Pankaj Bansal; swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [11] JDK-8190347: [TESTBUG] Test javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentJComboBox.java fails

Hi,Pankaj.
I have just recognized that this test was pushed to the jdk by our sqe team when the bug itself was not fixed/closed: JDK-8024627 Can you please confirm that initial bug is fixed(or still reproducuble)

On 22/02/2018 21:57, Prasanta Sadhukhan wrote:
> looks fine to me.
> 
> Regards
> Prasanta
> On 2/23/2018 11:10 AM, Pankaj Bansal wrote:
>>
>> Hi Prasanta,
>>
>> Thanks for the review.
>>
>> <<ok. thanks for the clarification. One point however, in spec it is 
>> mentioned to use "As of v1.3, it is recommended that <<developers 
>> call
>> |Component.AccessibleAWTComponent.getAccessibleChild()| instead of this"
>>
>> Done.
>>
>> Webrev:
>>
>> http://cr.openjdk.java.net/~pbansal/8190347/webrev.02/
>> <http://cr.openjdk.java.net/%7Epbansal/8190347/webrev.02/>
>>
>> Regards,
>>
>> Pankaj Bansal
>>
>> *From:*Prasanta Sadhukhan
>> *Sent:* Thursday, February 22, 2018 8:59 PM
>> *To:* Pankaj Bansal; swing-dev at openjdk.java.net
>> *Subject:* Re: <Swing Dev> [11] JDK-8190347: [TESTBUG] Test 
>> javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentJComboBox.
>> java
>> fails
>>
>> ok. thanks for t he clarification. One point however, in spec it is 
>> mentioned to use "As of v1.3, it is recommended that developers call
>> |Component.AccessibleAWTComponent.getAccessibleChild()| instead of this"
>>
>> getAccessibleChild(JComponent?c,
>>  ???????????????????????????????????? int?i)
>>
>> Regards
>> Prasanta
>>
>> On 2/22/2018 8:36 PM, Pankaj Bansal wrote:
>>
>>     Hi Prasanta,
>>
>>     Thanks for the review.
>>
>>     <<I guess you mentioned that we cannot fix completely for
>>     scaleFactor > 2. Does this fix cater to those scaleFactors too?
>>
>>     This fix is not specific to any particular scale factor. I have
>>     just modified it to work independent of the fact popup is created
>>     above or below. This change is independent of any HiDPI settings.
>>     Using HiDPi scale >= 2 is just one of reproducing this issue. It
>>     can be reproduced altering the window size, changing number of
>>     items in popUp etc. basically the test case should not assume that
>>     popup will be opaque always when there are scenarios, when it
>>     won't be opaque.
>>
>>     << If not, I think it should be alright to restrict the testcase
>>     to run with uiScale=1.0 as it is not testing any hidpi feature.
>>     I found this issue while working on a bug
>>     https://bugs.openjdk.java.net/browse/JDK-8164811, which involves
>>     using translucent components with HiDPI screens and that issue was
>>     found because of this test case only. So I think this test case is
>>     supposed to work well on HiDPI screens. All the test cases in the
>>     same folder are run on 1.5 scale by default.
>>
>>     Regards,
>>
>>     Pankaj Bansal
>>
>>
>>     *From:*Prasanta Sadhukhan
>>     *Sent:* Thursday, February 22, 2018 8:14 PM
>>     *To:* Jayathirth D V; Pankaj Bansal; swing-dev at openjdk.java.net
>>     <mailto:swing-dev at openjdk.java.net>; Sergey Bylokhov
>>     *Subject:* Re: <Swing Dev> [11] JDK-8190347: [TESTBUG] Test
>>     javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentJComboBox.java
>>     fails
>>
>>     Hi Pankaj,
>>
>>     I guess you mentioned that we cannot fix completely for
>>     scaleFactor > 2. Does this fix cater to those scaleFactors too? If
>>     not, I think it should be alright to restrict the testcase to run
>>     with uiScale=1.0 as it is not testing any hidpi feature.
>>
>>     Regards
>>     Prasanta
>>
>>     On 2/22/2018 7:56 PM, Jayathirth D V wrote:
>>
>>         Hi Pankaj,
>>
>>         Copyright year should contain only the initial creation year
>>         and latest year in which the change is made. So you should
>>         replace 2016 with 2018. No need for another webrev you can
>>         make that change while pushing.
>>
>>         Other changes present in webrev.01 over webrev.00 is fine.
>>
>>         Please wait for more inputs from others before pushing the change.
>>
>>         Thanks,
>>
>>         Jay
>>
>>         *From:* Pankaj Bansal
>>         *Sent:* Thursday, February 22, 2018 7:39 PM
>>         *To:* Jayathirth D V; swing-dev at openjdk.java.net
>>         <mailto:swing-dev at openjdk.java.net>; Sergey Bylokhov; Prasanta
>>         Sadhukhan
>>         *Subject:* RE: <Swing Dev> [11] JDK-8190347: [TESTBUG] Test
>>         javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentJComboBox.java
>>         fails
>>
>>         Hello Jay,
>>
>>         Thanks for the review.
>>
>>         << We need to update Copyright year, add new bug id in jtreg
>>         comment & it's better to keep jtreg comments before code for
>>         program starts like import statements.
>>
>>         Done.
>>
>>         Webrev
>>
>>         http://cr.openjdk.java.net/~pbansal/8190347/webrev.01/
>>         <http://cr.openjdk.java.net/%7Epbansal/8190347/webrev.01/>
>>
>>         << I think any one condition out of
>>         "(popup.getLocationOnScreen().y > ls.y" ???&
>>         ?"window.getHeight() < popup.getHeight() + south.getHeight()"
>>         would be enough to verify if popup.y <<exceeds window.y or not.
>>
>>         No, it will not work. "popup.getLocationOnScreen().y > ls.y"
>>         is required to find whether the popup is created above or
>>         below the JComboBox.
>>
>>         If it is below, raise exception as color conditions should
>>         have passed and this is an issue
>>
>>         If it is above, then we further need to verify, if it will fit
>>         inside the window or not. If it does not fit, then popup will
>>         be opaque and raise exception as color test should have passed.
>>
>>         Here we are trying to be sure that when the test has failed,
>>         it was not because of the reason that popup was translucent.
>>         In case of translucent popup, the color test will not pass and
>>         exception should not be thrown as it is expected.
>>
>>         <<Also I remember we discussed on call that if possible we can
>>         keep the main window starting at y = 0, so that we have enough
>>         space below the window giving test more chance to <<execute
>>         properly.
>>
>>         All that was required assuming that we can't find if the popup
>>         is created below or above the JComboBox. But I was able to
>>         find that using the popup and JComboBox location and this
>>         change is no longer needed.
>>
>>         Regards,
>>
>>         Pankaj Bansal
>>
>>         *From:* Jayathirth D V
>>         *Sent:* Thursday, February 22, 2018 6:26 PM
>>         *To:* Pankaj Bansal; swing-dev at openjdk.java.net
>>         <mailto:swing-dev at openjdk.java.net>; Sergey Bylokhov; Prasanta
>>         Sadhukhan
>>         *Subject:* RE: <Swing Dev> [11] JDK-8190347: [TESTBUG] Test
>>         javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentJComboBox.java
>>         fails
>>
>>         Hi Pankaj,
>>
>>         Please find my input:
>>
>>         We need to update Copyright year, add new bug id in jtreg
>>         comment & it's better to keep jtreg comments before code for
>>         program starts like import statements.
>>
>>         I think any one condition out of
>>         "(popup.getLocationOnScreen().y > ls.y" ???&  
>>         ?"window.getHeight() < popup.getHeight() + south.getHeight()"
>>         would be enough to verify if popup.y exceeds window.y or not.
>>
>>         Also I remember we discussed on call that if possible we can
>>         keep the main window starting at y = 0, so that we have enough
>>         space below the window giving test more chance to execute
>>         properly.
>>
>>         Thanks,
>>
>>         Jay
>>
>>         *From:* Pankaj Bansal
>>         *Sent:* Thursday, February 22, 2018 5:34 PM
>>         *To:* swing-dev at openjdk.java.net
>>         <mailto:swing-dev at openjdk.java.net>; Sergey Bylokhov; Prasanta
>>         Sadhukhan
>>         *Subject:* <Swing Dev> [11] JDK-8190347: [TESTBUG] Test
>>         javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentJComboBox.java
>>         fails
>>
>>         Hi All,
>>
>>         Please review the test only fix for JDK 11.
>>
>>         Bug:
>>
>>         https://bugs.openjdk.java.net/browse/JDK-8190347
>>
>>         webrev:
>>
>>         http://cr.openjdk.java.net/~pbansal/8190347/webrev.00/
>>         <http://cr.openjdk.java.net/%7Epbansal/8190347/webrev.00/>
>>
>>         Issue:
>>
>>         The test TranslucentJComboBox creates a Translucent JWindow
>>         and then adds a JComboBox at the bottom. Then a popup is
>>         created when clicked on JComboBox. The test always checks the
>>         popup for opaqueness whether it is created below or above the
>>         JComboBox. If it is created below the JComboBox, it will be
>>         opaque. ?If it is created above the JComboBox and it does not
>>         fit within the JWindow containing JComboBox, it will be opaque.
>>
>>         But in some scenarios, the Popup is created above the
>>         JComboBox and it can fit within the JWindow. In this case, it
>>         be translucent and the test will fail. The test needs to
>>         consider these scenarios.
>>
>>         One of the scenario to reproduce this is to run this test on a
>>         1920X1080 screen with HiDPI value 2.0. The popup will be
>>         created above and it will fit within the JWindow of size
>>         500X500. The test fails.
>>
>>         Fix:
>>
>>         Made changes to check if the popup is created below or above
>>         the JComboBox when the color values don't pass the conditions.
>>         If it is created below or if it is created above and If it
>>         does not fit, through the exception else ignore.
>>
>>         Regards,
>>
>>         Pankaj Bansal
>>
> 


--
Best regards, Sergey.


From prasanta.sadhukhan at oracle.com  Thu Mar  1 14:02:18 2018
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Thu, 1 Mar 2018 19:32:18 +0530
Subject: <Swing Dev> [11] RFR
 JDK-7190978:javax/swing/JComponent/7154030/bug7154030.java fails on windows,
 mac
In-Reply-To: <974b5a7b-0dad-fef3-8741-3f4104ecc47a@oracle.com>
References: <ec1f71d9-d204-868c-ed01-aca0183537d1@oracle.com>
 <a5b0ad78-8065-707a-5049-43dd8a79e14d@oracle.com>
 <974b5a7b-0dad-fef3-8741-3f4104ecc47a@oracle.com>
Message-ID: <4d953185-7dae-6bba-962c-dab91a126d27@oracle.com>

Yes, I was also not convinced, that is why I tested for multiple 
iterations. It seems to me the webrev.00 is the better "fix" as I saw 
only 2-3 pixels differ which cause the exact match to fail. But,I am not 
sure why in linux, the bufferedimages are exact. Maybe, there are some 
differences with robot screencapture between platforms. Are you aware of 
any?

Regards
Prasanta
On 3/1/2018 4:18 AM, Sergey Bylokhov wrote:
> Hi, Prasanta.
> It looks strange that half a second is not enough to hide a single 
> Swing component, isn't it?
>
> On 28/02/2018 01:15, Prasanta Sadhukhan wrote:
>> Hi All,
>>
>> It seems the test fails intermittently on windows as I can see 1 or 2 
>> failures out of 15 iterations citing either "failing to hide opaque 
>> button" or "failing to hide non-opaque button".
>> ??It did not fail for me in linux and mac in 15 iterations.
>> I have increased the delay before the robot screen capture when the 
>> button is being hidden which causes it to pass on windows 7 on all 15 
>> iterations. It does not affect ubuntu 17.10? and mac 10.13.3 where it 
>> still passes.
>>
>> webrev: cr.openjdk.java.net/~psadhukhan/7190978/webrev.01/
>>
>> Regards
>> Prasanta
>> On 2/22/2018 9:51 PM, Prasanta Sadhukhan wrote:
>>> Hi All,
>>>
>>> Please review a testbug fix for an issue whereby it seen that it 
>>> fails citing "failing to hide opaque button".
>>> It is seen that the test compares the buffered image strictly 
>>> pixel-by-pixel and even if it differs by 1,2 pixels it fails which 
>>> is what was happening here.
>>> Proposed fix is to make it more lenient by allowing a tolerance of 
>>> 20pixels difference in the comparison of 2 bufferedimage.
>>> It is verified on windows.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-7190978
>>> webrev: http://cr.openjdk.java.net/~psadhukhan/7190978/webrev.00/
>>>
>>> Regards
>>> Prasanta
>>
>
>



From semyon.sadetsky at oracle.com  Thu Mar  1 17:56:28 2018
From: semyon.sadetsky at oracle.com (semyon.sadetsky at oracle.com)
Date: Thu, 1 Mar 2018 09:56:28 -0800
Subject: <Swing Dev> [11] RFR JDK-8198777:
 JList.getPreferredScrollableViewportSize(): fix mistake in doc for height
 calc
In-Reply-To: <e71f8c52-8548-c855-9d35-c968047bfb70@oracle.com>
References: <c52763c8-c6b9-3748-2f31-d30afd68bf5b@oracle.com>
 <4cb56cf0-2507-4063-cbe3-a15f13358abe@oracle.com>
 <e71f8c52-8548-c855-9d35-c968047bfb70@oracle.com>
Message-ID: <3ec33e96-1702-d1a6-17fe-6c652fd449c3@oracle.com>

+1

--Semyon


On 3/1/18 4:21 AM, Alexey Ivanov wrote:
> Hello Semyon,
>
> Thank you for your review.
>
> The updated version:
> http://cr.openjdk.java.net/~aivanov/8198777/webrev.1/
>
> The case where the model is empty is covered in the paragraph above. 
> No change is necessary there.
>
> Regards,
> Alexey
>
> On 01/03/2018 00:52, Semyon Sadetsky wrote:
>> Hello Alexey,
>>
>> "height of the first cell" has relative meaning. I suggest to change 
>> it to "height of cell with index 0".
>>
>> Also, it would be nice to specify the case when the model is empty.
>>
>> --Semyon
>>
>> On 02/28/2018 01:39 PM, Alexey Ivanov wrote:
>>> Hello,
>>>
>>> Could you please review the fix for jdk11?
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8198777
>>> webrev: http://cr.openjdk.java.net/~aivanov/8198777/webrev.0/
>>> csr: https://bugs.openjdk.java.net/browse/JDK-8198822
>>>
>>> It is a small fix to documentation of 
>>> JList.getPreferredScrollableViewportSize().
>>>
>>> If either fixedCellWidth or fixedCellHeight are not set and the 
>>> model isn't empty, heuristics are used. The height is based one the 
>>> height of the first cell rather than fixedCellHeight.
>>>
>>>
>>> Regards,
>>> Alexey
>>
>



From prasanta.sadhukhan at oracle.com  Thu Mar  1 18:01:56 2018
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Thu, 1 Mar 2018 23:31:56 +0530
Subject: <Swing Dev> [11] RFR JDK-8194943:Regression automated test
 'open/test/jdk/javax/swing/JInternalFrame/8020708/bug8020708.java' fails
Message-ID: <02bca7ef-063b-41ce-76d5-ef50952821fa@oracle.com>

Hi All,

Please review a test fix for an issue whereby it is seen that close 
mnemonics for different locales was not working.
The issue has nothing to do with menmonics but with the test using robot 
to press CTRL+SPACE to show system menu.
However, it is found that CTRL+SPACE is a known hotkey combination to 
switch to chinese keyboard so
when this key combination is pressed, it is trying to find the chinese 
locale mnemonics which is not present.

Proposed fix is to change the key combination to SHIFT+ESCAPE as it also 
is used to show system menu
as per jdk implementation
http://hg.openjdk.java.net/jdk/client/file/838c11e59a38/src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java#l853
http://hg.openjdk.java.net/jdk/client/file/838c11e59a38/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicLookAndFeel.java#l866

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

Regards
Prasanta



From semyon.sadetsky at oracle.com  Thu Mar  1 18:05:07 2018
From: semyon.sadetsky at oracle.com (semyon.sadetsky at oracle.com)
Date: Thu, 1 Mar 2018 10:05:07 -0800
Subject: <Swing Dev> [11] RFR JDK-8194943:Regression automated test
 'open/test/jdk/javax/swing/JInternalFrame/8020708/bug8020708.java' fails
In-Reply-To: <02bca7ef-063b-41ce-76d5-ef50952821fa@oracle.com>
References: <02bca7ef-063b-41ce-76d5-ef50952821fa@oracle.com>
Message-ID: <0dc5d10c-2e26-0d4b-6914-cd39b990553f@oracle.com>

+1

--Semyon


On 3/1/18 10:01 AM, Prasanta Sadhukhan wrote:
> Hi All,
>
> Please review a test fix for an issue whereby it is seen that close 
> mnemonics for different locales was not working.
> The issue has nothing to do with menmonics but with the test using 
> robot to press CTRL+SPACE to show system menu.
> However, it is found that CTRL+SPACE is a known hotkey combination to 
> switch to chinese keyboard so
> when this key combination is pressed, it is trying to find the chinese 
> locale mnemonics which is not present.
>
> Proposed fix is to change the key combination to SHIFT+ESCAPE as it 
> also is used to show system menu
> as per jdk implementation
> http://hg.openjdk.java.net/jdk/client/file/838c11e59a38/src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java#l853 
>
> http://hg.openjdk.java.net/jdk/client/file/838c11e59a38/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicLookAndFeel.java#l866 
>
>
> Bug:https://bugs.openjdk.java.net/browse/JDK-8194943
> webrev: http://cr.openjdk.java.net/~psadhukhan/8194943/webrev.00/
>
> Regards
> Prasanta
>



From shashidhara.veerabhadraiah at oracle.com  Thu Mar  1 18:19:56 2018
From: shashidhara.veerabhadraiah at oracle.com (shashidhara.veerabhadraiah at oracle.com)
Date: Thu, 1 Mar 2018 23:49:56 +0530
Subject: <Swing Dev> [11] RFR JDK-8194943:Regression automated test
 'open/test/jdk/javax/swing/JInternalFrame/8020708/bug8020708.java' fails
In-Reply-To: <0dc5d10c-2e26-0d4b-6914-cd39b990553f@oracle.com>
References: <02bca7ef-063b-41ce-76d5-ef50952821fa@oracle.com>
 <0dc5d10c-2e26-0d4b-6914-cd39b990553f@oracle.com>
Message-ID: <7db67aab-26c8-f6c2-06f4-f1493a4d3256@oracle.com>

Looks good to me Prasanta.


On 01/03/18 11:35 PM, semyon.sadetsky at oracle.com wrote:
> +1
>
> --Semyon
>
>
> On 3/1/18 10:01 AM, Prasanta Sadhukhan wrote:
>> Hi All,
>>
>> Please review a test fix for an issue whereby it is seen that close 
>> mnemonics for different locales was not working.
>> The issue has nothing to do with menmonics but with the test using 
>> robot to press CTRL+SPACE to show system menu.
>> However, it is found that CTRL+SPACE is a known hotkey combination to 
>> switch to chinese keyboard so
>> when this key combination is pressed, it is trying to find the 
>> chinese locale mnemonics which is not present.
>>
>> Proposed fix is to change the key combination to SHIFT+ESCAPE as it 
>> also is used to show system menu
>> as per jdk implementation
>> http://hg.openjdk.java.net/jdk/client/file/838c11e59a38/src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java#l853 
>>
>> http://hg.openjdk.java.net/jdk/client/file/838c11e59a38/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicLookAndFeel.java#l866 
>>
>>
>> Bug:https://bugs.openjdk.java.net/browse/JDK-8194943
>> webrev: http://cr.openjdk.java.net/~psadhukhan/8194943/webrev.00/
>>
>> Regards
>> Prasanta
>>
>



From Sergey.Bylokhov at oracle.com  Thu Mar  1 21:10:37 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 1 Mar 2018 13:10:37 -0800
Subject: <Swing Dev> [11] RFR
 JDK-7190978:javax/swing/JComponent/7154030/bug7154030.java fails on windows,
 mac
In-Reply-To: <4d953185-7dae-6bba-962c-dab91a126d27@oracle.com>
References: <ec1f71d9-d204-868c-ed01-aca0183537d1@oracle.com>
 <a5b0ad78-8065-707a-5049-43dd8a79e14d@oracle.com>
 <974b5a7b-0dad-fef3-8741-3f4104ecc47a@oracle.com>
 <4d953185-7dae-6bba-962c-dab91a126d27@oracle.com>
Message-ID: <20a3da9f-7e09-250f-a93c-7b0a1ac19957@oracle.com>

On 01/03/2018 06:02, Prasanta Sadhukhan wrote:
> Yes, I was also not convinced, that is why I tested for multiple 
> iterations. It seems to me the webrev.00 is the better "fix" as I saw 
> only 2-3 pixels differ which cause the exact match to fail. But,I am not 
> sure why in linux, the bufferedimages are exact. Maybe, there are some 
> differences with robot screencapture between platforms. Are you aware of 
> any?

screencapture should work in the same way on all platforms, if the 
problem in robot we should fix it. Otherwise we will get a list of 
unstable tests here and there.

> 
> Regards
> Prasanta
> On 3/1/2018 4:18 AM, Sergey Bylokhov wrote:
>> Hi, Prasanta.
>> It looks strange that half a second is not enough to hide a single 
>> Swing component, isn't it?
>>
>> On 28/02/2018 01:15, Prasanta Sadhukhan wrote:
>>> Hi All,
>>>
>>> It seems the test fails intermittently on windows as I can see 1 or 2 
>>> failures out of 15 iterations citing either "failing to hide opaque 
>>> button" or "failing to hide non-opaque button".
>>> ??It did not fail for me in linux and mac in 15 iterations.
>>> I have increased the delay before the robot screen capture when the 
>>> button is being hidden which causes it to pass on windows 7 on all 15 
>>> iterations. It does not affect ubuntu 17.10? and mac 10.13.3 where it 
>>> still passes.
>>>
>>> webrev: cr.openjdk.java.net/~psadhukhan/7190978/webrev.01/
>>>
>>> Regards
>>> Prasanta
>>> On 2/22/2018 9:51 PM, Prasanta Sadhukhan wrote:
>>>> Hi All,
>>>>
>>>> Please review a testbug fix for an issue whereby it seen that it 
>>>> fails citing "failing to hide opaque button".
>>>> It is seen that the test compares the buffered image strictly 
>>>> pixel-by-pixel and even if it differs by 1,2 pixels it fails which 
>>>> is what was happening here.
>>>> Proposed fix is to make it more lenient by allowing a tolerance of 
>>>> 20pixels difference in the comparison of 2 bufferedimage.
>>>> It is verified on windows.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-7190978
>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/7190978/webrev.00/
>>>>
>>>> Regards
>>>> Prasanta
>>>
>>
>>
> 


-- 
Best regards, Sergey.


From prasanta.sadhukhan at oracle.com  Fri Mar  2 14:09:19 2018
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Fri, 2 Mar 2018 19:39:19 +0530
Subject: <Swing Dev> [11] RFR JDK-8194767:Regression automated Test
 'javax/swing/JEditorPane/6917744/bug6917744.java' fails
Message-ID: <59a7c7cb-4190-e9aa-b70d-5eff89ff1c11@oracle.com>

Hi All,

Please review a test fix for an issue where the test fails citing 
"Invalid HTML position" because pressing PAGE_DOWN does not cause the 
document to scroll down to end of document.
This is because even though robot send PAGE_DOWN key events but the 
focus is not in the editorpane so it does not scroll.

Proposed fix is to make sure the editorPane is in focus and caret is 
present in the document so that robot PAGE_DOWN events by robot causes 
it to scroll to end of document.

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

Regards
Prasanta


From semyon.sadetsky at oracle.com  Fri Mar  2 17:10:10 2018
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Fri, 2 Mar 2018 09:10:10 -0800
Subject: <Swing Dev> [11] RFR JDK-8194767:Regression automated Test
 'javax/swing/JEditorPane/6917744/bug6917744.java' fails
In-Reply-To: <59a7c7cb-4190-e9aa-b70d-5eff89ff1c11@oracle.com>
References: <59a7c7cb-4190-e9aa-b70d-5eff89ff1c11@oracle.com>
Message-ID: <03382e3d-fa29-865b-6df7-6c12b787e0a4@oracle.com>

Hi Prasant,

 ? 72???????????????? frame.setVisible(true);
 ? 73
 ? 74???????????????? p = editorPane.getLocationOnScreen();

It may not receive the right screen location that quick. You need to 
wait when the frame is shown.

Since this is a test bug please remove regression labels in JIRA.

--Semyon

On 03/02/2018 06:09 AM, Prasanta Sadhukhan wrote:
> Hi All,
>
> Please review a test fix for an issue where the test fails citing 
> "Invalid HTML position" because pressing PAGE_DOWN does not cause the 
> document to scroll down to end of document.
> This is because even though robot send PAGE_DOWN key events but the 
> focus is not in the editorpane so it does not scroll.
>
> Proposed fix is to make sure the editorPane is in focus and caret is 
> present in the document so that robot PAGE_DOWN events by robot causes 
> it to scroll to end of document.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8194767
> webrev: http://cr.openjdk.java.net/~psadhukhan/8194767/webrev.00/
>
> Regards
> Prasanta



From prasanta.sadhukhan at oracle.com  Fri Mar  2 17:55:18 2018
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Fri, 2 Mar 2018 23:25:18 +0530
Subject: <Swing Dev> [11] RFR JDK-8194767:Regression automated Test
 'javax/swing/JEditorPane/6917744/bug6917744.java' fails
In-Reply-To: <03382e3d-fa29-865b-6df7-6c12b787e0a4@oracle.com>
References: <59a7c7cb-4190-e9aa-b70d-5eff89ff1c11@oracle.com>
 <03382e3d-fa29-865b-6df7-6c12b787e0a4@oracle.com>
Message-ID: <78391405-2441-765f-d5bd-3b95678ff0cf@oracle.com>

Thanks Semyon for the review. Updated webrev: 
http://cr.openjdk.java.net/~psadhukhan/8194767/webrev.01/

Regards
Prasanta
On 3/2/2018 10:40 PM, Semyon Sadetsky wrote:
> Hi Prasant,
>
> ? 72???????????????? frame.setVisible(true);
> ? 73
> ? 74???????????????? p = editorPane.getLocationOnScreen();
>
> It may not receive the right screen location that quick. You need to 
> wait when the frame is shown.
>
> Since this is a test bug please remove regression labels in JIRA.
>
> --Semyon
>
> On 03/02/2018 06:09 AM, Prasanta Sadhukhan wrote:
>> Hi All,
>>
>> Please review a test fix for an issue where the test fails citing 
>> "Invalid HTML position" because pressing PAGE_DOWN does not cause the 
>> document to scroll down to end of document.
>> This is because even though robot send PAGE_DOWN key events but the 
>> focus is not in the editorpane so it does not scroll.
>>
>> Proposed fix is to make sure the editorPane is in focus and caret is 
>> present in the document so that robot PAGE_DOWN events by robot 
>> causes it to scroll to end of document.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8194767
>> webrev: http://cr.openjdk.java.net/~psadhukhan/8194767/webrev.00/
>>
>> Regards
>> Prasanta
>



From alexandre.iline at oracle.com  Fri Mar  2 19:19:39 2018
From: alexandre.iline at oracle.com (Alexandre (Shura) Iline)
Date: Fri, 2 Mar 2018 11:19:39 -0800
Subject: <Swing Dev> RFR JDK-8198922 Provide instrumentation for
 sanity/client/SwingSet/src/ButtonDemoScreenshotTest.java
Message-ID: <03CFF8F9-6DB1-430E-A93A-FCA512EC49D3@oracle.com>

Hi,

Could you please take a look on this fix?

This fix adds some instrumentation to an existing test which is known to fail intermittently. 
Bug: https://bugs.openjdk.java.net/browse/JDK-8198922
Webrev: http://cr.openjdk.java.net/~shurailine/8198922/webrev.00/

Thank you.

Shura

From philip.race at oracle.com  Fri Mar  2 19:36:32 2018
From: philip.race at oracle.com (Philip Race)
Date: Fri, 02 Mar 2018 11:36:32 -0800
Subject: <Swing Dev> RFR JDK-8198922 Provide instrumentation for
	sanity/client/SwingSet/src/ButtonDemoScreenshotTest.java
In-Reply-To: <03CFF8F9-6DB1-430E-A93A-FCA512EC49D3@oracle.com>
References: <03CFF8F9-6DB1-430E-A93A-FCA512EC49D3@oracle.com>
Message-ID: <5A99A7C0.7060503@oracle.com>

Instead of checking this in, why not make the changes locally, don't commit,
instead submit a test job to run sanity as many times as needed until 
you get
the stack trace you need. That seems like a much faster way of getting what
you need.

-phil.

On 3/2/18, 11:19 AM, Alexandre (Shura) Iline wrote:
> Hi,
>
> Could you please take a look on this fix?
>
> This fix adds some instrumentation to an existing test which is known to fail intermittently.
> Bug: https://bugs.openjdk.java.net/browse/JDK-8198922
> Webrev: http://cr.openjdk.java.net/~shurailine/8198922/webrev.00/
>
> Thank you.
>
> Shura


From alexandre.iline at oracle.com  Fri Mar  2 19:41:00 2018
From: alexandre.iline at oracle.com (Alexandre (Shura) Iline)
Date: Fri, 2 Mar 2018 11:41:00 -0800
Subject: <Swing Dev> RFR JDK-8198922 Provide instrumentation for
 sanity/client/SwingSet/src/ButtonDemoScreenshotTest.java
In-Reply-To: <5A99A7C0.7060503@oracle.com>
References: <03CFF8F9-6DB1-430E-A93A-FCA512EC49D3@oracle.com>
 <5A99A7C0.7060503@oracle.com>
Message-ID: <7FAF2F09-85CF-4540-A9BD-1CEEE79D1B7B@oracle.com>



> On Mar 2, 2018, at 11:36 AM, Philip Race <philip.race at oracle.com> wrote:
> 
> Instead of checking this in, why not make the changes locally, don't commit,
> instead submit a test job to run sanity as many times as needed until you get
> the stack trace you need. That seems like a much faster way of getting what
> you need.


This test fails no more than 3 times in 1000 runs on a fast Mac host. I am not able to make it to fail locally. We already have machinery which is doing that repeated execution, so, on the contrary, committing this and observing the results there is much easier than to replicate that system locally.

Shura


> 
> -phil.
> 
> On 3/2/18, 11:19 AM, Alexandre (Shura) Iline wrote:
>> Hi,
>> 
>> Could you please take a look on this fix?
>> 
>> This fix adds some instrumentation to an existing test which is known to fail intermittently.
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8198922
>> Webrev: http://cr.openjdk.java.net/~shurailine/8198922/webrev.00/
>> 
>> Thank you.
>> 
>> Shura



From semyon.sadetsky at oracle.com  Fri Mar  2 19:46:15 2018
From: semyon.sadetsky at oracle.com (semyon.sadetsky at oracle.com)
Date: Fri, 2 Mar 2018 11:46:15 -0800
Subject: <Swing Dev> [11] RFR JDK-8194767:Regression automated Test
 'javax/swing/JEditorPane/6917744/bug6917744.java' fails
In-Reply-To: <78391405-2441-765f-d5bd-3b95678ff0cf@oracle.com>
References: <59a7c7cb-4190-e9aa-b70d-5eff89ff1c11@oracle.com>
 <03382e3d-fa29-865b-6df7-6c12b787e0a4@oracle.com>
 <78391405-2441-765f-d5bd-3b95678ff0cf@oracle.com>
Message-ID: <36dd2893-a212-d31b-36bc-ca7099f39c89@oracle.com>

+1

--Semyon


On 3/2/18 9:55 AM, Prasanta Sadhukhan wrote:
> Thanks Semyon for the review. Updated webrev: 
> http://cr.openjdk.java.net/~psadhukhan/8194767/webrev.01/
>
> Regards
> Prasanta
> On 3/2/2018 10:40 PM, Semyon Sadetsky wrote:
>> Hi Prasant,
>>
>>   72                 frame.setVisible(true);
>>   73
>>   74                 p = editorPane.getLocationOnScreen();
>>
>> It may not receive the right screen location that quick. You need to 
>> wait when the frame is shown.
>>
>> Since this is a test bug please remove regression labels in JIRA.
>>
>> --Semyon
>>
>> On 03/02/2018 06:09 AM, Prasanta Sadhukhan wrote:
>>> Hi All,
>>>
>>> Please review a test fix for an issue where the test fails citing 
>>> "Invalid HTML position" because pressing PAGE_DOWN does not cause 
>>> the document to scroll down to end of document.
>>> This is because even though robot send PAGE_DOWN key events but the 
>>> focus is not in the editorpane so it does not scroll.
>>>
>>> Proposed fix is to make sure the editorPane is in focus and caret is 
>>> present in the document so that robot PAGE_DOWN events by robot 
>>> causes it to scroll to end of document.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8194767
>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8194767/webrev.00/
>>>
>>> Regards
>>> Prasanta
>>
>



From philip.race at oracle.com  Fri Mar  2 22:17:25 2018
From: philip.race at oracle.com (Philip Race)
Date: Fri, 02 Mar 2018 14:17:25 -0800
Subject: <Swing Dev> RFR JDK-8198922 Provide instrumentation for
	sanity/client/SwingSet/src/ButtonDemoScreenshotTest.java
In-Reply-To: <7FAF2F09-85CF-4540-A9BD-1CEEE79D1B7B@oracle.com>
References: <03CFF8F9-6DB1-430E-A93A-FCA512EC49D3@oracle.com>
 <5A99A7C0.7060503@oracle.com>
 <7FAF2F09-85CF-4540-A9BD-1CEEE79D1B7B@oracle.com>
Message-ID: <5A99CD75.5010803@oracle.com>

OK.

-phil.

On 3/2/18, 11:41 AM, Alexandre (Shura) Iline wrote:
>
>> On Mar 2, 2018, at 11:36 AM, Philip Race<philip.race at oracle.com>  wrote:
>>
>> Instead of checking this in, why not make the changes locally, don't commit,
>> instead submit a test job to run sanity as many times as needed until you get
>> the stack trace you need. That seems like a much faster way of getting what
>> you need.
>
> This test fails no more than 3 times in 1000 runs on a fast Mac host. I am not able to make it to fail locally. We already have machinery which is doing that repeated execution, so, on the contrary, committing this and observing the results there is much easier than to replicate that system locally.
>
> Shura
>
>
>> -phil.
>>
>> On 3/2/18, 11:19 AM, Alexandre (Shura) Iline wrote:
>>> Hi,
>>>
>>> Could you please take a look on this fix?
>>>
>>> This fix adds some instrumentation to an existing test which is known to fail intermittently.
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8198922
>>> Webrev: http://cr.openjdk.java.net/~shurailine/8198922/webrev.00/
>>>
>>> Thank you.
>>>
>>> Shura


From philip.race at oracle.com  Fri Mar  2 22:30:36 2018
From: philip.race at oracle.com (Phil Race)
Date: Fri, 2 Mar 2018 14:30:36 -0800
Subject: <Swing Dev> [11] RFR JDK-8194767:Regression automated Test
 'javax/swing/JEditorPane/6917744/bug6917744.java' fails
In-Reply-To: <36dd2893-a212-d31b-36bc-ca7099f39c89@oracle.com>
References: <59a7c7cb-4190-e9aa-b70d-5eff89ff1c11@oracle.com>
 <03382e3d-fa29-865b-6df7-6c12b787e0a4@oracle.com>
 <78391405-2441-765f-d5bd-3b95678ff0cf@oracle.com>
 <36dd2893-a212-d31b-36bc-ca7099f39c89@oracle.com>
Message-ID: <b9e80dc0-e83a-1363-47b3-94b173ff8cce@oracle.com>

looks ok.

-phil

On 03/02/2018 11:46 AM, semyon.sadetsky at oracle.com wrote:
> +1
>
> --Semyon
>
>
> On 3/2/18 9:55 AM, Prasanta Sadhukhan wrote:
>> Thanks Semyon for the review. Updated webrev: 
>> http://cr.openjdk.java.net/~psadhukhan/8194767/webrev.01/
>>
>> Regards
>> Prasanta
>> On 3/2/2018 10:40 PM, Semyon Sadetsky wrote:
>>> Hi Prasant,
>>>
>>>   72                 frame.setVisible(true);
>>>   73
>>>   74                 p = editorPane.getLocationOnScreen();
>>>
>>> It may not receive the right screen location that quick. You need to 
>>> wait when the frame is shown.
>>>
>>> Since this is a test bug please remove regression labels in JIRA.
>>>
>>> --Semyon
>>>
>>> On 03/02/2018 06:09 AM, Prasanta Sadhukhan wrote:
>>>> Hi All,
>>>>
>>>> Please review a test fix for an issue where the test fails citing 
>>>> "Invalid HTML position" because pressing PAGE_DOWN does not cause 
>>>> the document to scroll down to end of document.
>>>> This is because even though robot send PAGE_DOWN key events but the 
>>>> focus is not in the editorpane so it does not scroll.
>>>>
>>>> Proposed fix is to make sure the editorPane is in focus and caret 
>>>> is present in the document so that robot PAGE_DOWN events by robot 
>>>> causes it to scroll to end of document.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8194767
>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8194767/webrev.00/
>>>>
>>>> Regards
>>>> Prasanta
>>>
>>
>



From Sergey.Bylokhov at oracle.com  Fri Mar  2 22:32:36 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 2 Mar 2018 14:32:36 -0800
Subject: <Swing Dev> RFR JDK-8198922 Provide instrumentation for
 sanity/client/SwingSet/src/ButtonDemoScreenshotTest.java
In-Reply-To: <03CFF8F9-6DB1-430E-A93A-FCA512EC49D3@oracle.com>
References: <03CFF8F9-6DB1-430E-A93A-FCA512EC49D3@oracle.com>
Message-ID: <538dd3ad-9d2b-324a-d005-d0745ff9d281@oracle.com>

Looks fine.

On 02/03/2018 11:19, Alexandre (Shura) Iline wrote:
> Hi,
> 
> Could you please take a look on this fix?
> 
> This fix adds some instrumentation to an existing test which is known to fail intermittently.
> Bug: https://bugs.openjdk.java.net/browse/JDK-8198922
> Webrev: http://cr.openjdk.java.net/~shurailine/8198922/webrev.00/
> 
> Thank you.
> 
> Shura
> 


-- 
Best regards, Sergey.


From krishna.addepalli at oracle.com  Sat Mar  3 07:10:08 2018
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Fri, 2 Mar 2018 23:10:08 -0800 (PST)
Subject: <Swing Dev> [11][JDK-8195095]Images are not scaled correctly in
	JEditorPane
Message-ID: <d8dc441e-4025-489b-86d4-6bd8df5e4fba@default>

Hi All,

 

Please review a fix for JDK-8195095: https://bugs.openjdk.java.net/browse/JDK-8195095

 

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

 

Problem: When a text html is specified with an image, omitting either the height/width parameter, JEditorPane scales it to default value of the missing parameter, whereas it should fetch the actual value from the image.

 

Fix: The problem is in ImageView.java. In the imageUpdate function, in the resizing logic the "changed" flag is set to 1 if height is present, and to 2 if width is present. But while updating the width, the check is swapped, i.e width is set if flag is 1 and vice versa.

 

PS: The webrev contains a new "circle.png" file, so when you import the patch, you may need to manually copy the file, since "hg import" doesnot automatically import the .png files from the patch file.

 

Thanks

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

From prasanta.sadhukhan at oracle.com  Sat Mar  3 07:36:13 2018
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Sat, 3 Mar 2018 13:06:13 +0530
Subject: <Swing Dev> [11][JDK-8195095]Images are not scaled correctly in
 JEditorPane
In-Reply-To: <d8dc441e-4025-489b-86d4-6bd8df5e4fba@default>
References: <d8dc441e-4025-489b-86d4-6bd8df5e4fba@default>
Message-ID: <c6d33e58-fa7e-09dd-a2dd-fbc4e5c864b1@oracle.com>

looks good to me.

Only thing, in test, JFrame creation also needs to be in EDT.

Regards
Prasanta
On 3/3/2018 12:40 PM, Krishna Addepalli wrote:
>
> Hi All,
>
> Please review a fix for JDK-8195095: 
> https://bugs.openjdk.java.net/browse/JDK-8195095
>
> Webrev: http://cr.openjdk.java.net/~kaddepalli/8195095/webrev00 
> <http://cr.openjdk.java.net/%7Ekaddepalli/8195095/webrev00>
>
> Problem: When a text html is specified with an image, omitting either 
> the height/width parameter, JEditorPane scales it to default value of 
> the missing parameter, whereas it should fetch the actual value from 
> the image.
>
> Fix: The problem is in ImageView.java. In the imageUpdate function, in 
> the resizing logic the ?changed? flag is set to 1 if height is 
> present, and to 2 if width is present. But while updating the width, 
> the check is swapped, i.e width is set if flag is 1 and vice versa.
>
> PS: The webrev contains a new ?circle.png? file, so when you import 
> the patch, you may need to manually copy the file, since ?hg import? 
> doesnot automatically import the .png files from the patch file.
>
> Thanks
>
> Krishna
>

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

From krishna.addepalli at oracle.com  Sat Mar  3 08:07:18 2018
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Sat, 3 Mar 2018 00:07:18 -0800 (PST)
Subject: <Swing Dev> [11][JDK-8195095]Images are not scaled correctly in
 JEditorPane
In-Reply-To: <c6d33e58-fa7e-09dd-a2dd-fbc4e5c864b1@oracle.com>
References: <d8dc441e-4025-489b-86d4-6bd8df5e4fba@default>
 <c6d33e58-fa7e-09dd-a2dd-fbc4e5c864b1@oracle.com>
Message-ID: <7325ffb8-4b61-498b-8405-7d771bdfca0d@default>

Hi Prasanta,

 

Thanks for the quick review. I have updated the testcase with your suggestion. Here it is: http://cr.openjdk.java.net/~kaddepalli/8195095/webrev01

 

Krishna

 

From: Prasanta Sadhukhan 
Sent: Saturday, March 3, 2018 1:06 PM
To: Krishna Addepalli <krishna.addepalli at oracle.com>; swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [11][JDK-8195095]Images are not scaled correctly in JEditorPane

 

looks good to me. 

Only thing, in test, JFrame creation also needs to be in EDT.

Regards
Prasanta

On 3/3/2018 12:40 PM, Krishna Addepalli wrote:

Hi All,

 

Please review a fix for JDK-8195095: https://bugs.openjdk.java.net/browse/JDK-8195095

 

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

 

Problem: When a text html is specified with an image, omitting either the height/width parameter, JEditorPane scales it to default value of the missing parameter, whereas it should fetch the actual value from the image.

 

Fix: The problem is in ImageView.java. In the imageUpdate function, in the resizing logic the "changed" flag is set to 1 if height is present, and to 2 if width is present. But while updating the width, the check is swapped, i.e width is set if flag is 1 and vice versa.

 

PS: The webrev contains a new "circle.png" file, so when you import the patch, you may need to manually copy the file, since "hg import" doesnot automatically import the .png files from the patch file.

 

Thanks

Krishna

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

From krishna.addepalli at oracle.com  Sat Mar  3 14:30:06 2018
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Sat, 3 Mar 2018 06:30:06 -0800 (PST)
Subject: <Swing Dev>
 [11][JDK-8197785]javax.accessibility.AccessibilityBundle will reload the
 ResourceBundle for every call to toDisplayString
Message-ID: <7c9fd13a-4af8-4302-9e87-c0c6d41eceae@default>

Hi All,

 

Please review a simple fix for JDK-8197785: https://bugs.openjdk.java.net/browse/JDK-8197785

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

 

As the bug description suggests, AccessibleBundle.loadResourceBundle has the line "table.contains" which causes it to reload the resource bundle for each call.

Changing it to "table.containsKey" fixes the problem.

 

Thanks,

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

From philip.race at oracle.com  Sat Mar  3 16:14:07 2018
From: philip.race at oracle.com (Philip Race)
Date: Sat, 03 Mar 2018 08:14:07 -0800
Subject: <Swing Dev>
 [11][JDK-8197785]javax.accessibility.AccessibilityBundle will reload the
 ResourceBundle for every call to toDisplayString
In-Reply-To: <7c9fd13a-4af8-4302-9e87-c0c6d41eceae@default>
References: <7c9fd13a-4af8-4302-9e87-c0c6d41eceae@default>
Message-ID: <5A9AC9CF.5080809@oracle.com>

The fix is straightforward and I've seen this bug pattern before.
In fact there may even have been a sweep for uses of contains() to make 
sure it was as intended,
but if so it wasn't thorough enough.
But I'm wondering why the test extends Button and not JButton ?
I'm then further wondering if it could then be made headless .. ie no 
need to create or display a Frame ?

-phil.

On 3/3/18, 6:30 AM, Krishna Addepalli wrote:
>
> Hi All,
>
> Please review a simple fix for JDK-8197785: 
> https://bugs.openjdk.java.net/browse/JDK-8197785
>
> Webrev: http://cr.openjdk.java.net/~kaddepalli/8197785/webrev00/ 
> <http://cr.openjdk.java.net/%7Ekaddepalli/8197785/webrev00/>
>
> As the bug description suggests, AccessibleBundle.loadResourceBundle 
> has the line "table.contains" which causes it to reload the resource 
> bundle for each call.
>
> Changing it to "table.containsKey" fixes the problem.
>
> Thanks,
>
> Krishna
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20180303/bd4ae4c6/attachment.html>

From krishna.addepalli at oracle.com  Mon Mar  5 13:39:26 2018
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Mon, 5 Mar 2018 05:39:26 -0800 (PST)
Subject: <Swing Dev>
 [11][JDK-8197785]javax.accessibility.AccessibilityBundle will reload the
 ResourceBundle for every call to toDisplayString
In-Reply-To: <5A9AC9CF.5080809@oracle.com>
References: <7c9fd13a-4af8-4302-9e87-c0c6d41eceae@default>
 <5A9AC9CF.5080809@oracle.com>
Message-ID: <ac40cafb-4bc2-4868-87bd-0cc20cf4a7ba@default>

Hi Phil

 

Thank you for the review.

 

I have checked the accessibility package, and found that contains is used with a Vector of AccessibleState objects in the file AccessibleStateset.

 

However in AccessibilityBundle, the table is used to store a set of values associated with a particular locale, and going by the context, I find little reason that using contains is intentional here. 

 

And regarding the testcase, the thought of making it headless crossed my mind while writing it, but I was not sure if just creating a Button is allowed in headless mode. 

Fortunately, I modified the testcase enough that, no swing widgets need to be created, and we can safely run the test in headless mode.

 

Here is the new webrev: http://cr.openjdk.java.net/~kaddepalli/8197785/webrev01/

 

Thanks,

Krishna

 

From: Philip Race 
Sent: Saturday, March 3, 2018 9:44 PM
To: Krishna Addepalli <krishna.addepalli at oracle.com>
Cc: swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [11][JDK-8197785]javax.accessibility.AccessibilityBundle will reload the ResourceBundle for every call to toDisplayString

 

The fix is straightforward and I've seen this bug pattern before.
In fact there may even have been a sweep for uses of contains() to make sure it was as intended,
but if so it wasn't thorough enough.
But I'm wondering why the test extends Button and not JButton ?
I'm then further wondering if it could then be made headless .. ie no need to create or display a Frame ?

-phil.

On 3/3/18, 6:30 AM, Krishna Addepalli wrote: 

Hi All,

 

Please review a simple fix for JDK-8197785: https://bugs.openjdk.java.net/browse/JDK-8197785

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

 

As the bug description suggests, AccessibleBundle.loadResourceBundle has the line "table.contains" which causes it to reload the resource bundle for each call.

Changing it to "table.containsKey" fixes the problem.

 

Thanks,

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

From semyon.sadetsky at oracle.com  Mon Mar  5 16:30:53 2018
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Mon, 5 Mar 2018 08:30:53 -0800
Subject: <Swing Dev> [11][JDK-8195095]Images are not scaled correctly in
 JEditorPane
In-Reply-To: <7325ffb8-4b61-498b-8405-7d771bdfca0d@default>
References: <d8dc441e-4025-489b-86d4-6bd8df5e4fba@default>
 <c6d33e58-fa7e-09dd-a2dd-fbc4e5c864b1@oracle.com>
 <7325ffb8-4b61-498b-8405-7d771bdfca0d@default>
Message-ID: <8922c58d-6f8d-f0b0-de2f-cc57832d42c1@oracle.com>

Hi Krishna,

I tried your test before the fix and it passed.

--Semyon


On 03/03/2018 12:07 AM, Krishna Addepalli wrote:
>
> Hi Prasanta,
>
> Thanks for the quick review. I have updated the testcase with your 
> suggestion. Here it is: 
> http://cr.openjdk.java.net/~kaddepalli/8195095/webrev01 
> <http://cr.openjdk.java.net/%7Ekaddepalli/8195095/webrev01>
>
> Krishna
>
> *From:*Prasanta Sadhukhan
> *Sent:* Saturday, March 3, 2018 1:06 PM
> *To:* Krishna Addepalli <krishna.addepalli at oracle.com>; 
> swing-dev at openjdk.java.net
> *Subject:* Re: <Swing Dev> [11][JDK-8195095]Images are not scaled 
> correctly in JEditorPane
>
> looks good to me.
>
> Only thing, in test, JFrame creation also needs to be in EDT.
>
> Regards
> Prasanta
>
> On 3/3/2018 12:40 PM, Krishna Addepalli wrote:
>
>     Hi All,
>
>     Please review a fix for JDK-8195095:
>     https://bugs.openjdk.java.net/browse/JDK-8195095
>
>     Webrev: http://cr.openjdk.java.net/~kaddepalli/8195095/webrev00
>     <http://cr.openjdk.java.net/%7Ekaddepalli/8195095/webrev00>
>
>     Problem: When a text html is specified with an image, omitting
>     either the height/width parameter, JEditorPane scales it to
>     default value of the missing parameter, whereas it should fetch
>     the actual value from the image.
>
>     Fix: The problem is in ImageView.java. In the imageUpdate
>     function, in the resizing logic the ?changed? flag is set to 1 if
>     height is present, and to 2 if width is present. But while
>     updating the width, the check is swapped, i.e width is set if flag
>     is 1 and vice versa.
>
>     PS: The webrev contains a new ?circle.png? file, so when you
>     import the patch, you may need to manually copy the file, since
>     ?hg import? doesnot automatically import the .png files from the
>     patch file.
>
>     Thanks
>
>     Krishna
>

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

From semyon.sadetsky at oracle.com  Mon Mar  5 17:00:43 2018
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Mon, 5 Mar 2018 09:00:43 -0800
Subject: <Swing Dev>
 [11][JDK-8197785]javax.accessibility.AccessibilityBundle will reload the
 ResourceBundle for every call to toDisplayString
In-Reply-To: <ac40cafb-4bc2-4868-87bd-0cc20cf4a7ba@default>
References: <7c9fd13a-4af8-4302-9e87-c0c6d41eceae@default>
 <5A9AC9CF.5080809@oracle.com> <ac40cafb-4bc2-4868-87bd-0cc20cf4a7ba@default>
Message-ID: <52832a36-c6fe-ca1c-c779-d69677d178a3@oracle.com>

Hi Krishna,

Is there any reason to use Hashmap. It seems the synchronization is 
surplus here and its better to use HashMap.

--Semyon

On 03/05/2018 05:39 AM, Krishna Addepalli wrote:
>
> Hi Phil
>
> Thank you for the review.
>
> I have checked the accessibility package, and found that contains is 
> used with a Vector of AccessibleState objects in the file 
> AccessibleStateset.
>
> However in AccessibilityBundle, the table is used to store a set of 
> values associated with a particular locale, and going by the context, 
> I find little reason that using contains is intentional here.
>
> And regarding the testcase, the thought of making it headless crossed 
> my mind while writing it, but I was not sure if just creating a Button 
> is allowed in headless mode.
>
> Fortunately, I modified the testcase enough that, no swing widgets 
> need to be created, and we can safely run the test in headless mode.
>
> Here is the new webrev: 
> http://cr.openjdk.java.net/~kaddepalli/8197785/webrev01/ 
> <http://cr.openjdk.java.net/%7Ekaddepalli/8197785/webrev01/>
>
> Thanks,
>
> Krishna
>
> *From:*Philip Race
> *Sent:* Saturday, March 3, 2018 9:44 PM
> *To:* Krishna Addepalli <krishna.addepalli at oracle.com>
> *Cc:* swing-dev at openjdk.java.net
> *Subject:* Re: <Swing Dev> 
> [11][JDK-8197785]javax.accessibility.AccessibilityBundle will reload 
> the ResourceBundle for every call to toDisplayString
>
> The fix is straightforward and I've seen this bug pattern before.
> In fact there may even have been a sweep for uses of contains() to 
> make sure it was as intended,
> but if so it wasn't thorough enough.
> But I'm wondering why the test extends Button and not JButton ?
> I'm then further wondering if it could then be made headless .. ie no 
> need to create or display a Frame ?
>
> -phil.
>
> On 3/3/18, 6:30 AM, Krishna Addepalli wrote:
>
>     Hi All,
>
>     Please review a simple fix for JDK-8197785:
>     https://bugs.openjdk.java.net/browse/JDK-8197785
>
>     Webrev: http://cr.openjdk.java.net/~kaddepalli/8197785/webrev00/
>     <http://cr.openjdk.java.net/%7Ekaddepalli/8197785/webrev00/>
>
>     As the bug description suggests,
>     AccessibleBundle.loadResourceBundle has the line ?table.contains?
>     which causes it to reload the resource bundle for each call.
>
>     Changing it to ?table.containsKey? fixes the problem.
>
>     Thanks,
>
>     Krishna
>

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

From semyon.sadetsky at oracle.com  Mon Mar  5 17:09:24 2018
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Mon, 5 Mar 2018 09:09:24 -0800
Subject: <Swing Dev>
 [11][JDK-8197785]javax.accessibility.AccessibilityBundle will reload the
 ResourceBundle for every call to toDisplayString
In-Reply-To: <52832a36-c6fe-ca1c-c779-d69677d178a3@oracle.com>
References: <7c9fd13a-4af8-4302-9e87-c0c6d41eceae@default>
 <5A9AC9CF.5080809@oracle.com> <ac40cafb-4bc2-4868-87bd-0cc20cf4a7ba@default>
 <52832a36-c6fe-ca1c-c779-d69677d178a3@oracle.com>
Message-ID: <4be4b83e-d8ea-aa50-376f-60232b589491@oracle.com>

On 03/05/2018 09:00 AM, Semyon Sadetsky wrote:
>
> Hi Krishna,
>
> Is there any reason to use Hashmap. It seems the synchronization is 
> surplus here and its better to use HashMap.
>
I meant Hashtable. Sorry.

--Semyon

> --Semyon
>
> On 03/05/2018 05:39 AM, Krishna Addepalli wrote:
>>
>> Hi Phil
>>
>> Thank you for the review.
>>
>> I have checked the accessibility package, and found that contains is 
>> used with a Vector of AccessibleState objects in the file 
>> AccessibleStateset.
>>
>> However in AccessibilityBundle, the table is used to store a set of 
>> values associated with a particular locale, and going by the context, 
>> I find little reason that using contains is intentional here.
>>
>> And regarding the testcase, the thought of making it headless crossed 
>> my mind while writing it, but I was not sure if just creating a 
>> Button is allowed in headless mode.
>>
>> Fortunately, I modified the testcase enough that, no swing widgets 
>> need to be created, and we can safely run the test in headless mode.
>>
>> Here is the new webrev: 
>> http://cr.openjdk.java.net/~kaddepalli/8197785/webrev01/ 
>> <http://cr.openjdk.java.net/%7Ekaddepalli/8197785/webrev01/>
>>
>> Thanks,
>>
>> Krishna
>>
>> *From:*Philip Race
>> *Sent:* Saturday, March 3, 2018 9:44 PM
>> *To:* Krishna Addepalli <krishna.addepalli at oracle.com>
>> *Cc:* swing-dev at openjdk.java.net
>> *Subject:* Re: <Swing Dev> 
>> [11][JDK-8197785]javax.accessibility.AccessibilityBundle will reload 
>> the ResourceBundle for every call to toDisplayString
>>
>> The fix is straightforward and I've seen this bug pattern before.
>> In fact there may even have been a sweep for uses of contains() to 
>> make sure it was as intended,
>> but if so it wasn't thorough enough.
>> But I'm wondering why the test extends Button and not JButton ?
>> I'm then further wondering if it could then be made headless .. ie no 
>> need to create or display a Frame ?
>>
>> -phil.
>>
>> On 3/3/18, 6:30 AM, Krishna Addepalli wrote:
>>
>>     Hi All,
>>
>>     Please review a simple fix for JDK-8197785:
>>     https://bugs.openjdk.java.net/browse/JDK-8197785
>>
>>     Webrev: http://cr.openjdk.java.net/~kaddepalli/8197785/webrev00/
>>     <http://cr.openjdk.java.net/%7Ekaddepalli/8197785/webrev00/>
>>
>>     As the bug description suggests,
>>     AccessibleBundle.loadResourceBundle has the line ?table.contains?
>>     which causes it to reload the resource bundle for each call.
>>
>>     Changing it to ?table.containsKey? fixes the problem.
>>
>>     Thanks,
>>
>>     Krishna
>>
>

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

From Sergey.Bylokhov at oracle.com  Mon Mar  5 17:21:27 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 5 Mar 2018 09:21:27 -0800
Subject: <Swing Dev> [11] JDK-8190347: [TESTBUG] Test
 javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentJComboBox.java
 fails
In-Reply-To: <26f58787-2b4c-4042-92c4-d0627fa9d6aa@default>
References: <7d0dfeac-97ef-4c36-81bc-8fc3c6223359@default>
 <4c4362ed-b80d-40dc-9bcd-7dc3f6dbbb3f@default>
 <f39e9019-8a0d-4574-889d-edff2da5adfd@default>
 <18203ec3-d7b5-47df-98d3-4234cb437a4e@default>
 <6a9f6bb0-292d-1e05-1c23-522f20ffedf8@oracle.com>
 <fe1ca8ad-7dad-4028-b11b-df27c4120eef@default>
 <3b47f589-2de9-8590-4010-9736e3ad9427@oracle.com>
 <886530f7-c29c-45e9-ba59-95234ffc78e1@default>
 <4e2a3e7d-b43b-8571-26b1-d4d9abe19276@oracle.com>
 <5d05e857-325c-b3ad-e446-0de6aa70b073@oracle.com>
 <26f58787-2b4c-4042-92c4-d0627fa9d6aa@default>
Message-ID: <79b248e7-f0ee-a72e-dfc3-265f10d02043@oracle.com>

On 01/03/2018 04:36, Pankaj Bansal wrote:
> The mac specific issue "Flag is not triggered for point **" will be fixed by the bug you pointed out JDK-8024627. This same issue "Flag is not triggered for point **"  is also observed in javax/swing/JWindow/ShapedAndTranslucentWindows/SetShapeAndClickSwing.java, which is failing because of JDK-8013450 (mentioned in problemList) on Mac. JDK-8013450 and JDK-8024627 look duplicate.

They cannot be duplicates because JDK-8013450 is macOS specific and 
JDK-8024627 was found on windows/linux/mac.
Please take a look to these issues after this one.

> I think the problemList also needs to be updated as javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentJComboBox.java will be fixed for Mac with JDK-8024627, not JDK-8190347.
> Webrev:
> http://cr.openjdk.java.net/~pbansal/8190347/webrev.03/

Looks fine.


-- 
Best regards, Sergey.


From krishna.addepalli at oracle.com  Mon Mar  5 18:23:04 2018
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Mon, 5 Mar 2018 10:23:04 -0800 (PST)
Subject: <Swing Dev> [11][JDK-8195095]Images are not scaled correctly in
 JEditorPane
In-Reply-To: <8922c58d-6f8d-f0b0-de2f-cc57832d42c1@oracle.com>
References: <d8dc441e-4025-489b-86d4-6bd8df5e4fba@default>
 <c6d33e58-fa7e-09dd-a2dd-fbc4e5c864b1@oracle.com>
 <7325ffb8-4b61-498b-8405-7d771bdfca0d@default>
 <8922c58d-6f8d-f0b0-de2f-cc57832d42c1@oracle.com>
Message-ID: <3ea361c1-3591-4f0a-9466-ed14c520538f@default>

Hi Semyon,

 

Did you try it in Windows or Linux? I have tested it on Mac, and found that it fails before the fix and passes after the fix.

 

Thanks,

Krishna

 

From: Semyon Sadetsky 
Sent: Monday, March 5, 2018 10:01 PM
To: Krishna Addepalli <krishna.addepalli at oracle.com>; Prasanta Sadhukhan <prasanta.sadhukhan at oracle.com>; swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [11][JDK-8195095]Images are not scaled correctly in JEditorPane

 

Hi Krishna,

I tried your test before the fix and it passed.

--Semyon

 

On 03/03/2018 12:07 AM, Krishna Addepalli wrote:

Hi Prasanta,

 

Thanks for the quick review. I have updated the testcase with your suggestion. Here it is: HYPERLINK "http://cr.openjdk.java.net/%7Ekaddepalli/8195095/webrev01"http://cr.openjdk.java.net/~kaddepalli/8195095/webrev01

 

Krishna

 

From: Prasanta Sadhukhan 
Sent: Saturday, March 3, 2018 1:06 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> [11][JDK-8195095]Images are not scaled correctly in JEditorPane

 

looks good to me. 

Only thing, in test, JFrame creation also needs to be in EDT.

Regards
Prasanta

On 3/3/2018 12:40 PM, Krishna Addepalli wrote:

Hi All,

 

Please review a fix for JDK-8195095: https://bugs.openjdk.java.net/browse/JDK-8195095

 

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

 

Problem: When a text html is specified with an image, omitting either the height/width parameter, JEditorPane scales it to default value of the missing parameter, whereas it should fetch the actual value from the image.

 

Fix: The problem is in ImageView.java. In the imageUpdate function, in the resizing logic the "changed" flag is set to 1 if height is present, and to 2 if width is present. But while updating the width, the check is swapped, i.e width is set if flag is 1 and vice versa.

 

PS: The webrev contains a new "circle.png" file, so when you import the patch, you may need to manually copy the file, since "hg import" doesnot automatically import the .png files from the patch file.

 

Thanks

Krishna

 

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

From semyon.sadetsky at oracle.com  Mon Mar  5 18:27:03 2018
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Mon, 5 Mar 2018 10:27:03 -0800
Subject: <Swing Dev> [11][JDK-8195095]Images are not scaled correctly in
 JEditorPane
In-Reply-To: <3ea361c1-3591-4f0a-9466-ed14c520538f@default>
References: <d8dc441e-4025-489b-86d4-6bd8df5e4fba@default>
 <c6d33e58-fa7e-09dd-a2dd-fbc4e5c864b1@oracle.com>
 <7325ffb8-4b61-498b-8405-7d771bdfca0d@default>
 <8922c58d-6f8d-f0b0-de2f-cc57832d42c1@oracle.com>
 <3ea361c1-3591-4f0a-9466-ed14c520538f@default>
Message-ID: <e71f11a2-9b38-1bb8-5f9c-3a9e8344f5d5@oracle.com>

On 03/05/2018 10:23 AM, Krishna Addepalli wrote:

> Hi Semyon,
>
> Did you try it in Windows or Linux? I have tested it on Mac, and found 
> that it fails before the fix and passes after the fix.
>
I tried it on Linux. But the change is in generic code why the test 
result depends on the platform?

--Semyon
>
> Thanks,
>
> Krishna
>
> *From:*Semyon Sadetsky
> *Sent:* Monday, March 5, 2018 10:01 PM
> *To:* Krishna Addepalli <krishna.addepalli at oracle.com>; Prasanta 
> Sadhukhan <prasanta.sadhukhan at oracle.com>; swing-dev at openjdk.java.net
> *Subject:* Re: <Swing Dev> [11][JDK-8195095]Images are not scaled 
> correctly in JEditorPane
>
> Hi Krishna,
>
> I tried your test before the fix and it passed.
>
> --Semyon
>
> On 03/03/2018 12:07 AM, Krishna Addepalli wrote:
>
>     Hi Prasanta,
>
>     Thanks for the quick review. I have updated the testcase with your
>     suggestion. Here it is:
>     http://cr.openjdk.java.net/~kaddepalli/8195095/webrev01
>     <http://cr.openjdk.java.net/%7Ekaddepalli/8195095/webrev01>
>
>     Krishna
>
>     *From:*Prasanta Sadhukhan
>     *Sent:* Saturday, March 3, 2018 1:06 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> [11][JDK-8195095]Images are not scaled
>     correctly in JEditorPane
>
>     looks good to me.
>
>     Only thing, in test, JFrame creation also needs to be in EDT.
>
>     Regards
>     Prasanta
>
>     On 3/3/2018 12:40 PM, Krishna Addepalli wrote:
>
>         Hi All,
>
>         Please review a fix for JDK-8195095:
>         https://bugs.openjdk.java.net/browse/JDK-8195095
>
>         Webrev:
>         http://cr.openjdk.java.net/~kaddepalli/8195095/webrev00
>         <http://cr.openjdk.java.net/%7Ekaddepalli/8195095/webrev00>
>
>         Problem: When a text html is specified with an image, omitting
>         either the height/width parameter, JEditorPane scales it to
>         default value of the missing parameter, whereas it should
>         fetch the actual value from the image.
>
>         Fix: The problem is in ImageView.java. In the imageUpdate
>         function, in the resizing logic the ?changed? flag is set to 1
>         if height is present, and to 2 if width is present. But while
>         updating the width, the check is swapped, i.e width is set if
>         flag is 1 and vice versa.
>
>         PS: The webrev contains a new ?circle.png? file, so when you
>         import the patch, you may need to manually copy the file,
>         since ?hg import? doesnot automatically import the .png files
>         from the patch file.
>
>         Thanks
>
>         Krishna
>

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

From krishna.addepalli at oracle.com  Mon Mar  5 18:29:17 2018
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Mon, 5 Mar 2018 10:29:17 -0800 (PST)
Subject: <Swing Dev> [11][JDK-8195095]Images are not scaled correctly in
 JEditorPane
In-Reply-To: <e71f11a2-9b38-1bb8-5f9c-3a9e8344f5d5@oracle.com>
References: <d8dc441e-4025-489b-86d4-6bd8df5e4fba@default>
 <c6d33e58-fa7e-09dd-a2dd-fbc4e5c864b1@oracle.com>
 <7325ffb8-4b61-498b-8405-7d771bdfca0d@default>
 <8922c58d-6f8d-f0b0-de2f-cc57832d42c1@oracle.com>
 <3ea361c1-3591-4f0a-9466-ed14c520538f@default>
 <e71f11a2-9b38-1bb8-5f9c-3a9e8344f5d5@oracle.com>
Message-ID: <580cb1f1-2ea1-401a-85e7-e4d37f84279a@default>

I tried on Ubuntu 17.10, but since the getPixelColor always returns black, the test will pass, which is why I was asking.

 

Thanks,

Krishna

 

From: Semyon Sadetsky 
Sent: Monday, March 5, 2018 11:57 PM
To: Krishna Addepalli <krishna.addepalli at oracle.com>; Prasanta Sadhukhan <prasanta.sadhukhan at oracle.com>; swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [11][JDK-8195095]Images are not scaled correctly in JEditorPane

 

On 03/05/2018 10:23 AM, Krishna Addepalli wrote:

Hi Semyon,

 

Did you try it in Windows or Linux? I have tested it on Mac, and found that it fails before the fix and passes after the fix.

I tried it on Linux. But the change is in generic code why the test result depends on the platform?

--Semyon



 

Thanks,

Krishna

 

From: Semyon Sadetsky 
Sent: Monday, March 5, 2018 10:01 PM
To: Krishna Addepalli HYPERLINK "mailto:krishna.addepalli at oracle.com"<krishna.addepalli at oracle.com>; Prasanta Sadhukhan HYPERLINK "mailto:prasanta.sadhukhan at oracle.com"<prasanta.sadhukhan at oracle.com>; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [11][JDK-8195095]Images are not scaled correctly in JEditorPane

 

Hi Krishna,

I tried your test before the fix and it passed.

--Semyon

 

On 03/03/2018 12:07 AM, Krishna Addepalli wrote:

Hi Prasanta,

 

Thanks for the quick review. I have updated the testcase with your suggestion. Here it is: HYPERLINK "http://cr.openjdk.java.net/%7Ekaddepalli/8195095/webrev01"http://cr.openjdk.java.net/~kaddepalli/8195095/webrev01

 

Krishna

 

From: Prasanta Sadhukhan 
Sent: Saturday, March 3, 2018 1:06 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> [11][JDK-8195095]Images are not scaled correctly in JEditorPane

 

looks good to me. 

Only thing, in test, JFrame creation also needs to be in EDT.

Regards
Prasanta

On 3/3/2018 12:40 PM, Krishna Addepalli wrote:

Hi All,

 

Please review a fix for JDK-8195095: https://bugs.openjdk.java.net/browse/JDK-8195095

 

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

 

Problem: When a text html is specified with an image, omitting either the height/width parameter, JEditorPane scales it to default value of the missing parameter, whereas it should fetch the actual value from the image.

 

Fix: The problem is in ImageView.java. In the imageUpdate function, in the resizing logic the "changed" flag is set to 1 if height is present, and to 2 if width is present. But while updating the width, the check is swapped, i.e width is set if flag is 1 and vice versa.

 

PS: The webrev contains a new "circle.png" file, so when you import the patch, you may need to manually copy the file, since "hg import" doesnot automatically import the .png files from the patch file.

 

Thanks

Krishna

 

 

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

From krishna.addepalli at oracle.com  Mon Mar  5 18:41:21 2018
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Mon, 5 Mar 2018 10:41:21 -0800 (PST)
Subject: <Swing Dev>
 [11][JDK-8197785]javax.accessibility.AccessibilityBundle will reload the
 ResourceBundle for every call to toDisplayString
In-Reply-To: <4be4b83e-d8ea-aa50-376f-60232b589491@oracle.com>
References: <7c9fd13a-4af8-4302-9e87-c0c6d41eceae@default>
 <5A9AC9CF.5080809@oracle.com> <ac40cafb-4bc2-4868-87bd-0cc20cf4a7ba@default>
 <52832a36-c6fe-ca1c-c779-d69677d178a3@oracle.com>
 <4be4b83e-d8ea-aa50-376f-60232b589491@oracle.com>
Message-ID: <45e945b8-5c82-4f16-b801-a04b78a77567@default>

Hi Semyon,

 

Thank you for the review. I don't see any reason why HashMap can't be used here. But could you clarify what you meant by "synchronization is surplus here"?

 

Besides, whether we use HashMap /Hashtable, the fix for this particular bug still remains. 

As for changing (if that is necessary), I think we should address it in a separate bug?

 

Thanks,

Krishna

 

From: Semyon Sadetsky 
Sent: Monday, March 5, 2018 10:39 PM
To: Krishna Addepalli <krishna.addepalli at oracle.com>; Philip Race <philip.race at oracle.com>
Cc: swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [11][JDK-8197785]javax.accessibility.AccessibilityBundle will reload the ResourceBundle for every call to toDisplayString

 

On 03/05/2018 09:00 AM, Semyon Sadetsky wrote:



Hi Krishna,

Is there any reason to use Hashmap. It seems the synchronization is surplus here and its better to use HashMap.

I meant Hashtable. Sorry.

--Semyon

--Semyon

On 03/05/2018 05:39 AM, Krishna Addepalli wrote:

Hi Phil

 

Thank you for the review.

 

I have checked the accessibility package, and found that contains is used with a Vector of AccessibleState objects in the file AccessibleStateset.

 

However in AccessibilityBundle, the table is used to store a set of values associated with a particular locale, and going by the context, I find little reason that using contains is intentional here. 

 

And regarding the testcase, the thought of making it headless crossed my mind while writing it, but I was not sure if just creating a Button is allowed in headless mode. 

Fortunately, I modified the testcase enough that, no swing widgets need to be created, and we can safely run the test in headless mode.

 

Here is the new webrev: HYPERLINK "http://cr.openjdk.java.net/%7Ekaddepalli/8197785/webrev01/"http://cr.openjdk.java.net/~kaddepalli/8197785/webrev01/

 

Thanks,

Krishna

 

From: Philip Race 
Sent: Saturday, March 3, 2018 9:44 PM
To: Krishna Addepalli HYPERLINK "mailto:krishna.addepalli at oracle.com"<krishna.addepalli at oracle.com>
Cc: HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [11][JDK-8197785]javax.accessibility.AccessibilityBundle will reload the ResourceBundle for every call to toDisplayString

 

The fix is straightforward and I've seen this bug pattern before.
In fact there may even have been a sweep for uses of contains() to make sure it was as intended,
but if so it wasn't thorough enough.
But I'm wondering why the test extends Button and not JButton ?
I'm then further wondering if it could then be made headless .. ie no need to create or display a Frame ?

-phil.

On 3/3/18, 6:30 AM, Krishna Addepalli wrote: 

Hi All,

 

Please review a simple fix for JDK-8197785: https://bugs.openjdk.java.net/browse/JDK-8197785

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

 

As the bug description suggests, AccessibleBundle.loadResourceBundle has the line "table.contains" which causes it to reload the resource bundle for each call.

Changing it to "table.containsKey" fixes the problem.

 

Thanks,

Krishna

 

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

From krishna.addepalli at oracle.com  Mon Mar  5 19:11:50 2018
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Mon, 5 Mar 2018 11:11:50 -0800 (PST)
Subject: <Swing Dev>
 [11][JDK-8197785]javax.accessibility.AccessibilityBundle will reload the
 ResourceBundle for every call to toDisplayString
In-Reply-To: <5A9D952B.2010309@oracle.com>
References: <7c9fd13a-4af8-4302-9e87-c0c6d41eceae@default>
 <5A9AC9CF.5080809@oracle.com> <ac40cafb-4bc2-4868-87bd-0cc20cf4a7ba@default>
 <5A9D952B.2010309@oracle.com>
Message-ID: <6c20f799-59a6-4f3e-a4b3-5fbd94433907@default>

Hi Phil 

 

Thanks for the pointers. 

Since you mentioned that the bug pattern was observed before, I just did a quick search in accessibility module to see if any such cases are there. I could only find that for a Vector, which as you said is fine.

Second, I was also trying to understand if the "contains" function was really intended in the bug, but looking at the code, I did not find any reason that they should have used contains rather than "containsKey".

 

Sure will fix the space issue before pushing.

 

Thanks,

Krishna

 

From: Philip Race 
Sent: Tuesday, March 6, 2018 12:36 AM
To: Krishna Addepalli <krishna.addepalli at oracle.com>
Cc: swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [11][JDK-8197785]javax.accessibility.AccessibilityBundle will reload the ResourceBundle for every call to toDisplayString

 

 

On 03/05/2018 05:39 AM, Krishna Addepalli wrote:

Hi Phil

 

Thank you for the review.

 

I have checked the accessibility package, and found that contains is used with a Vector of AccessibleState objects in the file AccessibleStateset.


contains is fine for a Vector .. it is the map case that folks can get wrong.




 

However in AccessibilityBundle, the table is used to store a set of values associated with a particular locale, and going by the context, I find little reason that using contains is intentional here. 


I did not suggest it was. I was observing that using contains instead of containsKey
is a mistake we've seen before. 




 

And regarding the testcase, the thought of making it headless crossed my mind while writing it, but I was not sure if just creating a Button is allowed in headless mode. 

Fortunately, I modified the testcase enough that, no swing widgets need to be created, and we can safely run the test in headless mode.


java.awt.Button is heavyweight and can't even be constructed in headless.
JButton is lightweight and can be constructed in headless mode.




 

Here is the new webrev: HYPERLINK "http://cr.openjdk.java.net/%7Ekaddepalli/8197785/webrev01/"http://cr.openjdk.java.net/~kaddepalli/8197785/webrev01/

  42     public static void main(String... args) throws Exception{

"Exception{" -> "Exception {"

Please fix before pushing.

Looks good other than that.


-phil.



 

Thanks,

Krishna

 

From: Philip Race 
Sent: Saturday, March 3, 2018 9:44 PM
To: Krishna Addepalli HYPERLINK "mailto:krishna.addepalli at oracle.com"<krishna.addepalli at oracle.com>
Cc: HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [11][JDK-8197785]javax.accessibility.AccessibilityBundle will reload the ResourceBundle for every call to toDisplayString

 

The fix is straightforward and I've seen this bug pattern before.
In fact there may even have been a sweep for uses of contains() to make sure it was as intended,
but if so it wasn't thorough enough.
But I'm wondering why the test extends Button and not JButton ?
I'm then further wondering if it could then be made headless .. ie no need to create or display a Frame ?

-phil.

On 3/3/18, 6:30 AM, Krishna Addepalli wrote: 

Hi All,

 

Please review a simple fix for JDK-8197785: https://bugs.openjdk.java.net/browse/JDK-8197785

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

 

As the bug description suggests, AccessibleBundle.loadResourceBundle has the line "table.contains" which causes it to reload the resource bundle for each call.

Changing it to "table.containsKey" fixes the problem.

 

Thanks,

Krishna

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

From semyon.sadetsky at oracle.com  Mon Mar  5 19:21:47 2018
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Mon, 5 Mar 2018 11:21:47 -0800
Subject: <Swing Dev>
 [11][JDK-8197785]javax.accessibility.AccessibilityBundle will reload the
 ResourceBundle for every call to toDisplayString
In-Reply-To: <45e945b8-5c82-4f16-b801-a04b78a77567@default>
References: <7c9fd13a-4af8-4302-9e87-c0c6d41eceae@default>
 <5A9AC9CF.5080809@oracle.com> <ac40cafb-4bc2-4868-87bd-0cc20cf4a7ba@default>
 <52832a36-c6fe-ca1c-c779-d69677d178a3@oracle.com>
 <4be4b83e-d8ea-aa50-376f-60232b589491@oracle.com>
 <45e945b8-5c82-4f16-b801-a04b78a77567@default>
Message-ID: <0d9cddff-3b89-c6f7-5369-8c22f9894ce3@oracle.com>

On 03/05/2018 10:41 AM, Krishna Addepalli wrote:

> Hi Semyon,
>
> Thank you for the review. I don?t see any reason why HashMap can?t be 
> used here. But could you clarify what you meant by ?synchronization is 
> surplus here??
>
Sure. Hashtable is synchronized. And since the locale bundle is created 
once now and then is only read there is no need to have extra thread 
access synchronization.
>
> Besides, whether we use HashMap /Hashtable, the fix for this 
> particular bug still remains.
>
> As for changing (if that is necessary), I think we should address it 
> in a separate bug?
>
It is not unrelated completely since you are fixing a performance issue. 
I suggest to fix it for one since it is easy.

--Semyon
>
> Thanks,
>
> Krishna
>
> *From:*Semyon Sadetsky
> *Sent:* Monday, March 5, 2018 10:39 PM
> *To:* Krishna Addepalli <krishna.addepalli at oracle.com>; Philip Race 
> <philip.race at oracle.com>
> *Cc:* swing-dev at openjdk.java.net
> *Subject:* Re: <Swing Dev> 
> [11][JDK-8197785]javax.accessibility.AccessibilityBundle will reload 
> the ResourceBundle for every call to toDisplayString
>
> On 03/05/2018 09:00 AM, Semyon Sadetsky wrote:
>
>     Hi Krishna,
>
>     Is there any reason to use Hashmap. It seems the synchronization
>     is surplus here and its better to use HashMap.
>
> I meant Hashtable. Sorry.
>
> --Semyon
>
>     --Semyon
>
>     On 03/05/2018 05:39 AM, Krishna Addepalli wrote:
>
>         Hi Phil
>
>         Thank you for the review.
>
>         I have checked the accessibility package, and found that
>         contains is used with a Vector of AccessibleState objects in
>         the file AccessibleStateset.
>
>         However in AccessibilityBundle, the table is used to store a
>         set of values associated with a particular locale, and going
>         by the context, I find little reason that using contains is
>         intentional here.
>
>         And regarding the testcase, the thought of making it headless
>         crossed my mind while writing it, but I was not sure if just
>         creating a Button is allowed in headless mode.
>
>         Fortunately, I modified the testcase enough that, no swing
>         widgets need to be created, and we can safely run the test in
>         headless mode.
>
>         Here is the new webrev:
>         http://cr.openjdk.java.net/~kaddepalli/8197785/webrev01/
>         <http://cr.openjdk.java.net/%7Ekaddepalli/8197785/webrev01/>
>
>         Thanks,
>
>         Krishna
>
>         *From:*Philip Race
>         *Sent:* Saturday, March 3, 2018 9:44 PM
>         *To:* Krishna Addepalli <krishna.addepalli at oracle.com>
>         <mailto:krishna.addepalli at oracle.com>
>         *Cc:* swing-dev at openjdk.java.net
>         <mailto:swing-dev at openjdk.java.net>
>         *Subject:* Re: <Swing Dev>
>         [11][JDK-8197785]javax.accessibility.AccessibilityBundle will
>         reload the ResourceBundle for every call to toDisplayString
>
>         The fix is straightforward and I've seen this bug pattern before.
>         In fact there may even have been a sweep for uses of
>         contains() to make sure it was as intended,
>         but if so it wasn't thorough enough.
>         But I'm wondering why the test extends Button and not JButton ?
>         I'm then further wondering if it could then be made headless
>         .. ie no need to create or display a Frame ?
>
>         -phil.
>
>         On 3/3/18, 6:30 AM, Krishna Addepalli wrote:
>
>             Hi All,
>
>             Please review a simple fix for JDK-8197785:
>             https://bugs.openjdk.java.net/browse/JDK-8197785
>
>             Webrev:
>             http://cr.openjdk.java.net/~kaddepalli/8197785/webrev00/
>             <http://cr.openjdk.java.net/%7Ekaddepalli/8197785/webrev00/>
>
>             As the bug description suggests,
>             AccessibleBundle.loadResourceBundle has the line
>             ?table.contains? which causes it to reload the resource
>             bundle for each call.
>
>             Changing it to ?table.containsKey? fixes the problem.
>
>             Thanks,
>
>             Krishna
>

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

From philip.race at ORACLE.COM  Mon Mar  5 19:06:19 2018
From: philip.race at ORACLE.COM (Philip Race)
Date: Mon, 05 Mar 2018 11:06:19 -0800
Subject: <Swing Dev>
 [11][JDK-8197785]javax.accessibility.AccessibilityBundle will reload the
 ResourceBundle for every call to toDisplayString
In-Reply-To: <ac40cafb-4bc2-4868-87bd-0cc20cf4a7ba@default>
References: <7c9fd13a-4af8-4302-9e87-c0c6d41eceae@default>
 <5A9AC9CF.5080809@oracle.com> <ac40cafb-4bc2-4868-87bd-0cc20cf4a7ba@default>
Message-ID: <5A9D952B.2010309@oracle.com>



On 03/05/2018 05:39 AM, Krishna Addepalli wrote:
>
> Hi Phil
>
> Thank you for the review.
>
> I have checked the accessibility package, and found that contains is 
> used with a Vector of AccessibleState objects in the file 
> AccessibleStateset.
>

contains is fine for a Vector .. it is the map case that folks can get 
wrong.

> However in AccessibilityBundle, the table is used to store a set of 
> values associated with a particular locale, and going by the context, 
> I find little reason that using contains is intentional here.
>

I did not suggest it was. I was observing that using contains instead of 
containsKey
is a mistake we've seen before.

> And regarding the testcase, the thought of making it headless crossed 
> my mind while writing it, but I was not sure if just creating a Button 
> is allowed in headless mode.
>
> Fortunately, I modified the testcase enough that, no swing widgets 
> need to be created, and we can safely run the test in headless mode.
>

java.awt.Button is heavyweight and can't even be constructed in headless.
JButton is lightweight and can be constructed in headless mode.

> Here is the new webrev: 
> http://cr.openjdk.java.net/~kaddepalli/8197785/webrev01/ 
> <http://cr.openjdk.java.net/%7Ekaddepalli/8197785/webrev01/>
>
   42     public static void main(String... args) throws Exception{

"Exception{" -> "Exception {"

Please fix before pushing.

Looks good other than that.


-phil.
>
> Thanks,
>
> Krishna
>
> *From:*Philip Race
> *Sent:* Saturday, March 3, 2018 9:44 PM
> *To:* Krishna Addepalli <krishna.addepalli at oracle.com>
> *Cc:* swing-dev at openjdk.java.net
> *Subject:* Re: <Swing Dev> 
> [11][JDK-8197785]javax.accessibility.AccessibilityBundle will reload 
> the ResourceBundle for every call to toDisplayString
>
> The fix is straightforward and I've seen this bug pattern before.
> In fact there may even have been a sweep for uses of contains() to 
> make sure it was as intended,
> but if so it wasn't thorough enough.
> But I'm wondering why the test extends Button and not JButton ?
> I'm then further wondering if it could then be made headless .. ie no 
> need to create or display a Frame ?
>
> -phil.
>
> On 3/3/18, 6:30 AM, Krishna Addepalli wrote:
>
>     Hi All,
>
>     Please review a simple fix for JDK-8197785:
>     https://bugs.openjdk.java.net/browse/JDK-8197785
>
>     Webrev: http://cr.openjdk.java.net/~kaddepalli/8197785/webrev00/
>     <http://cr.openjdk.java.net/%7Ekaddepalli/8197785/webrev00/>
>
>     As the bug description suggests,
>     AccessibleBundle.loadResourceBundle has the line ?table.contains?
>     which causes it to reload the resource bundle for each call.
>
>     Changing it to ?table.containsKey? fixes the problem.
>
>     Thanks,
>
>     Krishna
>


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

From philip.race at oracle.com  Mon Mar  5 20:49:47 2018
From: philip.race at oracle.com (Phil Race)
Date: Mon, 5 Mar 2018 12:49:47 -0800
Subject: <Swing Dev>
 [11][JDK-8197785]javax.accessibility.AccessibilityBundle will reload the
 ResourceBundle for every call to toDisplayString
In-Reply-To: <0d9cddff-3b89-c6f7-5369-8c22f9894ce3@oracle.com>
References: <7c9fd13a-4af8-4302-9e87-c0c6d41eceae@default>
 <5A9AC9CF.5080809@oracle.com> <ac40cafb-4bc2-4868-87bd-0cc20cf4a7ba@default>
 <52832a36-c6fe-ca1c-c779-d69677d178a3@oracle.com>
 <4be4b83e-d8ea-aa50-376f-60232b589491@oracle.com>
 <45e945b8-5c82-4f16-b801-a04b78a77567@default>
 <0d9cddff-3b89-c6f7-5369-8c22f9894ce3@oracle.com>
Message-ID: <450af7a3-9c59-f329-76a6-386e619e59d5@oracle.com>

I originally thought you were referring to the Hashtable in the test ?
That really doesn't matter.
If you are referring to the use of hashtable in the JDK class then I
think it is safer to leave it as is. Hashtable is provably safe here, and
for HashMap you'd need to ensure that concurrent read and write
are safe. The HashMap is created only once but may be updated
more than once, even if it is not likely in real world use (multiple 
locales in use).
The performance cost here is negligible, probably not measurable in
real world code where there is no contention for the lock

-phil.

On 03/05/2018 11:21 AM, Semyon Sadetsky wrote:
>
> On 03/05/2018 10:41 AM, Krishna Addepalli wrote:
>
>> Hi Semyon,
>>
>> Thank you for the review. I don?t see any reason why HashMap can?t be 
>> used here. But could you clarify what you meant by ?synchronization 
>> is surplus here??
>>
> Sure. Hashtable is synchronized. And since the locale bundle is 
> created once now and then is only read there is no need to have extra 
> thread access synchronization.
>>
>> Besides, whether we use HashMap /Hashtable, the fix for this 
>> particular bug still remains.
>>
>> As for changing (if that is necessary), I think we should address it 
>> in a separate bug?
>>
> It is not unrelated completely since you are fixing a performance 
> issue. I suggest to fix it for one since it is easy.
>
> --Semyon
>>
>> Thanks,
>>
>> Krishna
>>
>> *From:*Semyon Sadetsky
>> *Sent:* Monday, March 5, 2018 10:39 PM
>> *To:* Krishna Addepalli <krishna.addepalli at oracle.com>; Philip Race 
>> <philip.race at oracle.com>
>> *Cc:* swing-dev at openjdk.java.net
>> *Subject:* Re: <Swing Dev> 
>> [11][JDK-8197785]javax.accessibility.AccessibilityBundle will reload 
>> the ResourceBundle for every call to toDisplayString
>>
>> On 03/05/2018 09:00 AM, Semyon Sadetsky wrote:
>>
>>     Hi Krishna,
>>
>>     Is there any reason to use Hashmap. It seems the synchronization
>>     is surplus here and its better to use HashMap.
>>
>> I meant Hashtable. Sorry.
>>
>> --Semyon
>>
>>     --Semyon
>>
>>     On 03/05/2018 05:39 AM, Krishna Addepalli wrote:
>>
>>         Hi Phil
>>
>>         Thank you for the review.
>>
>>         I have checked the accessibility package, and found that
>>         contains is used with a Vector of AccessibleState objects in
>>         the file AccessibleStateset.
>>
>>         However in AccessibilityBundle, the table is used to store a
>>         set of values associated with a particular locale, and going
>>         by the context, I find little reason that using contains is
>>         intentional here.
>>
>>         And regarding the testcase, the thought of making it headless
>>         crossed my mind while writing it, but I was not sure if just
>>         creating a Button is allowed in headless mode.
>>
>>         Fortunately, I modified the testcase enough that, no swing
>>         widgets need to be created, and we can safely run the test in
>>         headless mode.
>>
>>         Here is the new webrev:
>>         http://cr.openjdk.java.net/~kaddepalli/8197785/webrev01/
>>         <http://cr.openjdk.java.net/%7Ekaddepalli/8197785/webrev01/>
>>
>>         Thanks,
>>
>>         Krishna
>>
>>         *From:*Philip Race
>>         *Sent:* Saturday, March 3, 2018 9:44 PM
>>         *To:* Krishna Addepalli <krishna.addepalli at oracle.com>
>>         <mailto:krishna.addepalli at oracle.com>
>>         *Cc:* swing-dev at openjdk.java.net
>>         <mailto:swing-dev at openjdk.java.net>
>>         *Subject:* Re: <Swing Dev>
>>         [11][JDK-8197785]javax.accessibility.AccessibilityBundle will
>>         reload the ResourceBundle for every call to toDisplayString
>>
>>         The fix is straightforward and I've seen this bug pattern before.
>>         In fact there may even have been a sweep for uses of
>>         contains() to make sure it was as intended,
>>         but if so it wasn't thorough enough.
>>         But I'm wondering why the test extends Button and not JButton ?
>>         I'm then further wondering if it could then be made headless
>>         .. ie no need to create or display a Frame ?
>>
>>         -phil.
>>
>>         On 3/3/18, 6:30 AM, Krishna Addepalli wrote:
>>
>>             Hi All,
>>
>>             Please review a simple fix for JDK-8197785:
>>             https://bugs.openjdk.java.net/browse/JDK-8197785
>>
>>             Webrev:
>>             http://cr.openjdk.java.net/~kaddepalli/8197785/webrev00/
>>             <http://cr.openjdk.java.net/%7Ekaddepalli/8197785/webrev00/>
>>
>>             As the bug description suggests,
>>             AccessibleBundle.loadResourceBundle has the line
>>             ?table.contains? which causes it to reload the resource
>>             bundle for each call.
>>
>>             Changing it to ?table.containsKey? fixes the problem.
>>
>>             Thanks,
>>
>>             Krishna
>>
>

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

From semyon.sadetsky at oracle.com  Tue Mar  6 17:45:39 2018
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Tue, 6 Mar 2018 09:45:39 -0800
Subject: <Swing Dev>
 [11][JDK-8197785]javax.accessibility.AccessibilityBundle will reload the
 ResourceBundle for every call to toDisplayString
In-Reply-To: <450af7a3-9c59-f329-76a6-386e619e59d5@oracle.com>
References: <7c9fd13a-4af8-4302-9e87-c0c6d41eceae@default>
 <5A9AC9CF.5080809@oracle.com> <ac40cafb-4bc2-4868-87bd-0cc20cf4a7ba@default>
 <52832a36-c6fe-ca1c-c779-d69677d178a3@oracle.com>
 <4be4b83e-d8ea-aa50-376f-60232b589491@oracle.com>
 <45e945b8-5c82-4f16-b801-a04b78a77567@default>
 <0d9cddff-3b89-c6f7-5369-8c22f9894ce3@oracle.com>
 <450af7a3-9c59-f329-76a6-386e619e59d5@oracle.com>
Message-ID: <3884a1fc-7da2-6aeb-fa41-a23e6e6d36f7@oracle.com>

On 03/05/2018 12:49 PM, Phil Race wrote:

> I originally thought you were referring to the Hashtable in the test ?
No. I meant Hashtable created in line 151.
> That really doesn't matter.
> If you are referring to the use of hashtable in the JDK class then I
> think it is safer to leave it as is. Hashtable is provably safe here, and
> for HashMap you'd need to ensure that concurrent read and write
> are safe. The HashMap is created only once but may be updated
> more than once, even if it is not likely in real world use (multiple 
> locales in use).
Can you point to place where this Hashmap is updated other then where it 
is initialized?

> The performance cost here is negligible, probably not measurable in
> real world code where there is no contention for the lock
This requires evidence. You need to know the load characteristic to 
state that. If collisions are proven to be rare the optimistic locking 
is preferable. But still, I don't see any grounds to have any collisions 
since these are read-only data. Synchronization may degrade performance 
a lot and may be a source for deadlocks so it's always better to avoid it.

--Semyon
>
> -phil.
>
> On 03/05/2018 11:21 AM, Semyon Sadetsky wrote:
>>
>> On 03/05/2018 10:41 AM, Krishna Addepalli wrote:
>>
>>> Hi Semyon,
>>>
>>> Thank you for the review. I don?t see any reason why HashMap can?t 
>>> be used here. But could you clarify what you meant by 
>>> ?synchronization is surplus here??
>>>
>> Sure. Hashtable is synchronized. And since the locale bundle is 
>> created once now and then is only read there is no need to have extra 
>> thread access synchronization.
>>>
>>> Besides, whether we use HashMap /Hashtable, the fix for this 
>>> particular bug still remains.
>>>
>>> As for changing (if that is necessary), I think we should address it 
>>> in a separate bug?
>>>
>> It is not unrelated completely since you are fixing a performance 
>> issue. I suggest to fix it for one since it is easy.
>>
>> --Semyon
>>>
>>> Thanks,
>>>
>>> Krishna
>>>
>>> *From:*Semyon Sadetsky
>>> *Sent:* Monday, March 5, 2018 10:39 PM
>>> *To:* Krishna Addepalli <krishna.addepalli at oracle.com>; Philip Race 
>>> <philip.race at oracle.com>
>>> *Cc:* swing-dev at openjdk.java.net
>>> *Subject:* Re: <Swing Dev> 
>>> [11][JDK-8197785]javax.accessibility.AccessibilityBundle will reload 
>>> the ResourceBundle for every call to toDisplayString
>>>
>>> On 03/05/2018 09:00 AM, Semyon Sadetsky wrote:
>>>
>>>     Hi Krishna,
>>>
>>>     Is there any reason to use Hashmap. It seems the synchronization
>>>     is surplus here and its better to use HashMap.
>>>
>>> I meant Hashtable. Sorry.
>>>
>>> --Semyon
>>>
>>>     --Semyon
>>>
>>>     On 03/05/2018 05:39 AM, Krishna Addepalli wrote:
>>>
>>>         Hi Phil
>>>
>>>         Thank you for the review.
>>>
>>>         I have checked the accessibility package, and found that
>>>         contains is used with a Vector of AccessibleState objects in
>>>         the file AccessibleStateset.
>>>
>>>         However in AccessibilityBundle, the table is used to store a
>>>         set of values associated with a particular locale, and going
>>>         by the context, I find little reason that using contains is
>>>         intentional here.
>>>
>>>         And regarding the testcase, the thought of making it
>>>         headless crossed my mind while writing it, but I was not
>>>         sure if just creating a Button is allowed in headless mode.
>>>
>>>         Fortunately, I modified the testcase enough that, no swing
>>>         widgets need to be created, and we can safely run the test
>>>         in headless mode.
>>>
>>>         Here is the new webrev:
>>>         http://cr.openjdk.java.net/~kaddepalli/8197785/webrev01/
>>>         <http://cr.openjdk.java.net/%7Ekaddepalli/8197785/webrev01/>
>>>
>>>         Thanks,
>>>
>>>         Krishna
>>>
>>>         *From:*Philip Race
>>>         *Sent:* Saturday, March 3, 2018 9:44 PM
>>>         *To:* Krishna Addepalli <krishna.addepalli at oracle.com>
>>>         <mailto:krishna.addepalli at oracle.com>
>>>         *Cc:* swing-dev at openjdk.java.net
>>>         <mailto:swing-dev at openjdk.java.net>
>>>         *Subject:* Re: <Swing Dev>
>>>         [11][JDK-8197785]javax.accessibility.AccessibilityBundle
>>>         will reload the ResourceBundle for every call to toDisplayString
>>>
>>>         The fix is straightforward and I've seen this bug pattern
>>>         before.
>>>         In fact there may even have been a sweep for uses of
>>>         contains() to make sure it was as intended,
>>>         but if so it wasn't thorough enough.
>>>         But I'm wondering why the test extends Button and not JButton ?
>>>         I'm then further wondering if it could then be made headless
>>>         .. ie no need to create or display a Frame ?
>>>
>>>         -phil.
>>>
>>>         On 3/3/18, 6:30 AM, Krishna Addepalli wrote:
>>>
>>>             Hi All,
>>>
>>>             Please review a simple fix for JDK-8197785:
>>>             https://bugs.openjdk.java.net/browse/JDK-8197785
>>>
>>>             Webrev:
>>>             http://cr.openjdk.java.net/~kaddepalli/8197785/webrev00/
>>>             <http://cr.openjdk.java.net/%7Ekaddepalli/8197785/webrev00/>
>>>
>>>             As the bug description suggests,
>>>             AccessibleBundle.loadResourceBundle has the line
>>>             ?table.contains? which causes it to reload the resource
>>>             bundle for each call.
>>>
>>>             Changing it to ?table.containsKey? fixes the problem.
>>>
>>>             Thanks,
>>>
>>>             Krishna
>>>
>>
>

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

From philip.race at oracle.com  Tue Mar  6 18:01:29 2018
From: philip.race at oracle.com (Phil Race)
Date: Tue, 6 Mar 2018 10:01:29 -0800
Subject: <Swing Dev>
 [11][JDK-8197785]javax.accessibility.AccessibilityBundle will reload the
 ResourceBundle for every call to toDisplayString
In-Reply-To: <3884a1fc-7da2-6aeb-fa41-a23e6e6d36f7@oracle.com>
References: <7c9fd13a-4af8-4302-9e87-c0c6d41eceae@default>
 <5A9AC9CF.5080809@oracle.com> <ac40cafb-4bc2-4868-87bd-0cc20cf4a7ba@default>
 <52832a36-c6fe-ca1c-c779-d69677d178a3@oracle.com>
 <4be4b83e-d8ea-aa50-376f-60232b589491@oracle.com>
 <45e945b8-5c82-4f16-b801-a04b78a77567@default>
 <0d9cddff-3b89-c6f7-5369-8c22f9894ce3@oracle.com>
 <450af7a3-9c59-f329-76a6-386e619e59d5@oracle.com>
 <3884a1fc-7da2-6aeb-fa41-a23e6e6d36f7@oracle.com>
Message-ID: <6c68fc95-2df6-47f9-de53-44d917ed5a0a@oracle.com>



On 03/06/2018 09:45 AM, Semyon Sadetsky wrote:
> Can you point to place where this Hashmap is updated other then where 
> it is initialized?

You mean Hashtable ?

  161                 table.put(locale, resourceTable);

Will be executed once per locale.

-phil.



From semyon.sadetsky at oracle.com  Tue Mar  6 18:15:43 2018
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Tue, 6 Mar 2018 10:15:43 -0800
Subject: <Swing Dev>
 [11][JDK-8197785]javax.accessibility.AccessibilityBundle will reload the
 ResourceBundle for every call to toDisplayString
In-Reply-To: <6c68fc95-2df6-47f9-de53-44d917ed5a0a@oracle.com>
References: <7c9fd13a-4af8-4302-9e87-c0c6d41eceae@default>
 <5A9AC9CF.5080809@oracle.com> <ac40cafb-4bc2-4868-87bd-0cc20cf4a7ba@default>
 <52832a36-c6fe-ca1c-c779-d69677d178a3@oracle.com>
 <4be4b83e-d8ea-aa50-376f-60232b589491@oracle.com>
 <45e945b8-5c82-4f16-b801-a04b78a77567@default>
 <0d9cddff-3b89-c6f7-5369-8c22f9894ce3@oracle.com>
 <450af7a3-9c59-f329-76a6-386e619e59d5@oracle.com>
 <3884a1fc-7da2-6aeb-fa41-a23e6e6d36f7@oracle.com>
 <6c68fc95-2df6-47f9-de53-44d917ed5a0a@oracle.com>
Message-ID: <bef45850-a816-1cf3-0bf5-fe5f395b058d@oracle.com>

On 03/06/2018 10:01 AM, Phil Race wrote:

>
>
> On 03/06/2018 09:45 AM, Semyon Sadetsky wrote:
>> Can you point to place where this Hashmap is updated other then where 
>> it is initialized?
>
> You mean Hashtable ?
Right, sorry.
>
> ?161???????????????? table.put(locale, resourceTable);
>
> Will be executed once per locale.
It updates "table" not "resourceTable". The "table" field could be 
treated differently since writing in it really very rare but it is ok to 
leave it as it is. All what I meant concerned only the "resourceTable".

--Semyon
>
> -phil.
>



From Sergey.Bylokhov at oracle.com  Wed Mar  7 00:17:17 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 6 Mar 2018 16:17:17 -0800
Subject: <Swing Dev> [11] Review Request: 8199022 New failures should be
 added to ProblemList
Message-ID: <a4c8aa6d-b70d-ce7a-a11e-c6606f5c7243@oracle.com>

Hello.
Please review an update of the ProblemList for jdk11.

The goal is to make our testing as stable as possible and exclude any 
unstable tests(I have started from the tests which may be run in the 
headless mode).
In this iteration I have updated the problemList for tests which were 
failed in our nightly at least once for last week. I tested this fix in 
mach5 seven times and always got a green status for open tests.

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

  - The ProblemList.txt is updated, I have created a list of new bugs 
for the tests which fail at least once in a few iterations on a 
different systems.
  - The TEST.ROOT is updated, because "javax/swing" was missed when it 
was updated last time in JDK-8002120. The reason is that our tests does 
not work well in the agentvm mode(they affects each other in some 
unclear way which is reproduced in nightly only).


-- 
Best regards, Sergey.


From philip.race at oracle.com  Wed Mar  7 00:33:25 2018
From: philip.race at oracle.com (Philip Race)
Date: Tue, 06 Mar 2018 16:33:25 -0800
Subject: <Swing Dev> <AWT Dev> [11] Review Request: 8199022 New failures
 should be added to ProblemList
In-Reply-To: <a4c8aa6d-b70d-ce7a-a11e-c6606f5c7243@oracle.com>
References: <a4c8aa6d-b70d-ce7a-a11e-c6606f5c7243@oracle.com>
Message-ID: <5A9F3355.5090005@oracle.com>

+1

-phil.

On 3/6/18, 4:17 PM, Sergey Bylokhov wrote:
> Hello.
> Please review an update of the ProblemList for jdk11.
>
> The goal is to make our testing as stable as possible and exclude any 
> unstable tests(I have started from the tests which may be run in the 
> headless mode).
> In this iteration I have updated the problemList for tests which were 
> failed in our nightly at least once for last week. I tested this fix 
> in mach5 seven times and always got a green status for open tests.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8199022
> Webrev can be found at: 
> http://cr.openjdk.java.net/~serb/8199022/webrev.00/
>
>  - The ProblemList.txt is updated, I have created a list of new bugs 
> for the tests which fail at least once in a few iterations on a 
> different systems.
>  - The TEST.ROOT is updated, because "javax/swing" was missed when it 
> was updated last time in JDK-8002120. The reason is that our tests 
> does not work well in the agentvm mode(they affects each other in some 
> unclear way which is reproduced in nightly only).
>
>


From prasanta.sadhukhan at oracle.com  Wed Mar  7 08:21:28 2018
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Wed, 7 Mar 2018 13:51:28 +0530
Subject: <Swing Dev> [11] Review Request: 8199022 New failures should be
 added to ProblemList
In-Reply-To: <a4c8aa6d-b70d-ce7a-a11e-c6606f5c7243@oracle.com>
References: <a4c8aa6d-b70d-ce7a-a11e-c6606f5c7243@oracle.com>
Message-ID: <41dd6940-ad8e-f0e6-d329-c5a94789fd50@oracle.com>

Hi Sergey,

Looks ok to me. Could you also please add these tests to the list as well

java/awt/image/VolatileImage/CustomCompositeTest.java 8199002 
windows-all, linux-all
java/awt/image/VolatileImage/GradientPaints.java 8199003 linux-all
java/awt/JAWT/JAWT.sh?? windows-all

Regards
Prasanta
On 3/7/2018 5:47 AM, Sergey Bylokhov wrote:
> Hello.
> Please review an update of the ProblemList for jdk11.
>
> The goal is to make our testing as stable as possible and exclude any 
> unstable tests(I have started from the tests which may be run in the 
> headless mode).
> In this iteration I have updated the problemList for tests which were 
> failed in our nightly at least once for last week. I tested this fix 
> in mach5 seven times and always got a green status for open tests.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8199022
> Webrev can be found at: 
> http://cr.openjdk.java.net/~serb/8199022/webrev.00/
>
> ?- The ProblemList.txt is updated, I have created a list of new bugs 
> for the tests which fail at least once in a few iterations on a 
> different systems.
> ?- The TEST.ROOT is updated, because "javax/swing" was missed when it 
> was updated last time in JDK-8002120. The reason is that our tests 
> does not work well in the agentvm mode(they affects each other in some 
> unclear way which is reproduced in nightly only).
>
>

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

From krishna.addepalli at oracle.com  Wed Mar  7 13:28:43 2018
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Wed, 7 Mar 2018 05:28:43 -0800 (PST)
Subject: <Swing Dev>
 [11][JDK-8197785]javax.accessibility.AccessibilityBundle will reload the
 ResourceBundle for every call to toDisplayString
In-Reply-To: <bef45850-a816-1cf3-0bf5-fe5f395b058d@oracle.com>
References: <7c9fd13a-4af8-4302-9e87-c0c6d41eceae@default>
 <5A9AC9CF.5080809@oracle.com> <ac40cafb-4bc2-4868-87bd-0cc20cf4a7ba@default>
 <52832a36-c6fe-ca1c-c779-d69677d178a3@oracle.com>
 <4be4b83e-d8ea-aa50-376f-60232b589491@oracle.com>
 <45e945b8-5c82-4f16-b801-a04b78a77567@default>
 <0d9cddff-3b89-c6f7-5369-8c22f9894ce3@oracle.com>
 <450af7a3-9c59-f329-76a6-386e619e59d5@oracle.com>
 <3884a1fc-7da2-6aeb-fa41-a23e6e6d36f7@oracle.com>
 <6c68fc95-2df6-47f9-de53-44d917ed5a0a@oracle.com>
 <bef45850-a816-1cf3-0bf5-fe5f395b058d@oracle.com>
Message-ID: <a82a3b5e-1460-421a-a1b6-ac0cb1ff50e6@default>

Hi Semyon,

Modified the code as per your suggestions. Here is the new webrev: http://cr.openjdk.java.net/~kaddepalli/8197785/webrev02

Thanks,
Krishna

-----Original Message-----
From: Semyon Sadetsky 
Sent: Tuesday, March 6, 2018 11:46 PM
To: Phil Race <philip.race at oracle.com>; Krishna Addepalli <krishna.addepalli at oracle.com>
Cc: swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [11][JDK-8197785]javax.accessibility.AccessibilityBundle will reload the ResourceBundle for every call to toDisplayString

On 03/06/2018 10:01 AM, Phil Race wrote:

>
>
> On 03/06/2018 09:45 AM, Semyon Sadetsky wrote:
>> Can you point to place where this Hashmap is updated other then where 
>> it is initialized?
>
> You mean Hashtable ?
Right, sorry.
>
> ?161???????????????? table.put(locale, resourceTable);
>
> Will be executed once per locale.
It updates "table" not "resourceTable". The "table" field could be treated differently since writing in it really very rare but it is ok to leave it as it is. All what I meant concerned only the "resourceTable".

--Semyon
>
> -phil.
>



From Sergey.Bylokhov at oracle.com  Wed Mar  7 13:55:58 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 7 Mar 2018 05:55:58 -0800
Subject: <Swing Dev> [11] Review Request: 8199022 New failures should be
 added to ProblemList
In-Reply-To: <41dd6940-ad8e-f0e6-d329-c5a94789fd50@oracle.com>
References: <a4c8aa6d-b70d-ce7a-a11e-c6606f5c7243@oracle.com>
 <41dd6940-ad8e-f0e6-d329-c5a94789fd50@oracle.com>
Message-ID: <b472fe19-4771-7b98-b189-b1cbcabc7916@oracle.com>

Hi, Prasanta.
What bugid for java/awt/JAWT/JAWT.sh ?

On 07/03/2018 00:21, Prasanta Sadhukhan wrote:
> Hi Sergey,
> 
> Looks ok to me. Could you also please add these tests to the list as well
> 
> java/awt/image/VolatileImage/CustomCompositeTest.java 8199002 
> windows-all, linux-all
> java/awt/image/VolatileImage/GradientPaints.java 8199003 linux-all
> java/awt/JAWT/JAWT.sh?? windows-all
> 
> Regards
> Prasanta
> On 3/7/2018 5:47 AM, Sergey Bylokhov wrote:
>> Hello.
>> Please review an update of the ProblemList for jdk11.
>>
>> The goal is to make our testing as stable as possible and exclude any 
>> unstable tests(I have started from the tests which may be run in the 
>> headless mode).
>> In this iteration I have updated the problemList for tests which were 
>> failed in our nightly at least once for last week. I tested this fix 
>> in mach5 seven times and always got a green status for open tests.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8199022
>> Webrev can be found at: 
>> http://cr.openjdk.java.net/~serb/8199022/webrev.00/
>>
>> ?- The ProblemList.txt is updated, I have created a list of new bugs 
>> for the tests which fail at least once in a few iterations on a 
>> different systems.
>> ?- The TEST.ROOT is updated, because "javax/swing" was missed when it 
>> was updated last time in JDK-8002120. The reason is that our tests 
>> does not work well in the agentvm mode(they affects each other in some 
>> unclear way which is reproduced in nightly only).
>>
>>
> 


-- 
Best regards, Sergey.


From prasanta.sadhukhan at oracle.com  Wed Mar  7 13:57:13 2018
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Wed, 7 Mar 2018 19:27:13 +0530
Subject: <Swing Dev> [11] Review Request: 8199022 New failures should be
 added to ProblemList
In-Reply-To: <b472fe19-4771-7b98-b189-b1cbcabc7916@oracle.com>
References: <a4c8aa6d-b70d-ce7a-a11e-c6606f5c7243@oracle.com>
 <41dd6940-ad8e-f0e6-d329-c5a94789fd50@oracle.com>
 <b472fe19-4771-7b98-b189-b1cbcabc7916@oracle.com>
Message-ID: <c2fd412c-4f8c-f314-cafa-8a741799e8c0@oracle.com>

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


On 3/7/2018 7:25 PM, Sergey Bylokhov wrote:
> Hi, Prasanta.
> What bugid for java/awt/JAWT/JAWT.sh ?
>
> On 07/03/2018 00:21, Prasanta Sadhukhan wrote:
>> Hi Sergey,
>>
>> Looks ok to me. Could you also please add these tests to the list as 
>> well
>>
>> java/awt/image/VolatileImage/CustomCompositeTest.java 8199002 
>> windows-all, linux-all
>> java/awt/image/VolatileImage/GradientPaints.java 8199003 linux-all
>> java/awt/JAWT/JAWT.sh?? windows-all
>>
>> Regards
>> Prasanta
>> On 3/7/2018 5:47 AM, Sergey Bylokhov wrote:
>>> Hello.
>>> Please review an update of the ProblemList for jdk11.
>>>
>>> The goal is to make our testing as stable as possible and exclude 
>>> any unstable tests(I have started from the tests which may be run in 
>>> the headless mode).
>>> In this iteration I have updated the problemList for tests which 
>>> were failed in our nightly at least once for last week. I tested 
>>> this fix in mach5 seven times and always got a green status for open 
>>> tests.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8199022
>>> Webrev can be found at: 
>>> http://cr.openjdk.java.net/~serb/8199022/webrev.00/
>>>
>>> ?- The ProblemList.txt is updated, I have created a list of new bugs 
>>> for the tests which fail at least once in a few iterations on a 
>>> different systems.
>>> ?- The TEST.ROOT is updated, because "javax/swing" was missed when 
>>> it was updated last time in JDK-8002120. The reason is that our 
>>> tests does not work well in the agentvm mode(they affects each other 
>>> in some unclear way which is reproduced in nightly only).
>>>
>>>
>>
>
>

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

From semyon.sadetsky at oracle.com  Wed Mar  7 15:57:26 2018
From: semyon.sadetsky at oracle.com (semyon.sadetsky at oracle.com)
Date: Wed, 7 Mar 2018 07:57:26 -0800
Subject: <Swing Dev>
 [11][JDK-8197785]javax.accessibility.AccessibilityBundle will reload the
 ResourceBundle for every call to toDisplayString
In-Reply-To: <a82a3b5e-1460-421a-a1b6-ac0cb1ff50e6@default>
References: <7c9fd13a-4af8-4302-9e87-c0c6d41eceae@default>
 <5A9AC9CF.5080809@oracle.com> <ac40cafb-4bc2-4868-87bd-0cc20cf4a7ba@default>
 <52832a36-c6fe-ca1c-c779-d69677d178a3@oracle.com>
 <4be4b83e-d8ea-aa50-376f-60232b589491@oracle.com>
 <45e945b8-5c82-4f16-b801-a04b78a77567@default>
 <0d9cddff-3b89-c6f7-5369-8c22f9894ce3@oracle.com>
 <450af7a3-9c59-f329-76a6-386e619e59d5@oracle.com>
 <3884a1fc-7da2-6aeb-fa41-a23e6e6d36f7@oracle.com>
 <6c68fc95-2df6-47f9-de53-44d917ed5a0a@oracle.com>
 <bef45850-a816-1cf3-0bf5-fe5f395b058d@oracle.com>
 <a82a3b5e-1460-421a-a1b6-ac0cb1ff50e6@default>
Message-ID: <90a37387-f834-3016-7b7a-68577a48d7e1@oracle.com>

+1

--Semyon


On 3/7/18 5:28 AM, Krishna Addepalli wrote:
> Hi Semyon,
>
> Modified the code as per your suggestions. Here is the new webrev: http://cr.openjdk.java.net/~kaddepalli/8197785/webrev02
>
> Thanks,
> Krishna
>
> -----Original Message-----
> From: Semyon Sadetsky
> Sent: Tuesday, March 6, 2018 11:46 PM
> To: Phil Race <philip.race at oracle.com>; Krishna Addepalli <krishna.addepalli at oracle.com>
> Cc: swing-dev at openjdk.java.net
> Subject: Re: <Swing Dev> [11][JDK-8197785]javax.accessibility.AccessibilityBundle will reload the ResourceBundle for every call to toDisplayString
>
> On 03/06/2018 10:01 AM, Phil Race wrote:
>
>>
>> On 03/06/2018 09:45 AM, Semyon Sadetsky wrote:
>>> Can you point to place where this Hashmap is updated other then where
>>> it is initialized?
>> You mean Hashtable ?
> Right, sorry.
>>   161                 table.put(locale, resourceTable);
>>
>> Will be executed once per locale.
> It updates "table" not "resourceTable". The "table" field could be treated differently since writing in it really very rare but it is ok to leave it as it is. All what I meant concerned only the "resourceTable".
>
> --Semyon
>> -phil.
>>



From krishna.addepalli at oracle.com  Wed Mar  7 16:19:05 2018
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Wed, 7 Mar 2018 08:19:05 -0800 (PST)
Subject: <Swing Dev>
 [11][JDK-8197785]javax.accessibility.AccessibilityBundle will reload the
 ResourceBundle for every call to toDisplayString
In-Reply-To: <90a37387-f834-3016-7b7a-68577a48d7e1@oracle.com>
References: <7c9fd13a-4af8-4302-9e87-c0c6d41eceae@default>
 <5A9AC9CF.5080809@oracle.com> <ac40cafb-4bc2-4868-87bd-0cc20cf4a7ba@default>
 <52832a36-c6fe-ca1c-c779-d69677d178a3@oracle.com>
 <4be4b83e-d8ea-aa50-376f-60232b589491@oracle.com>
 <45e945b8-5c82-4f16-b801-a04b78a77567@default>
 <0d9cddff-3b89-c6f7-5369-8c22f9894ce3@oracle.com>
 <450af7a3-9c59-f329-76a6-386e619e59d5@oracle.com>
 <3884a1fc-7da2-6aeb-fa41-a23e6e6d36f7@oracle.com>
 <6c68fc95-2df6-47f9-de53-44d917ed5a0a@oracle.com>
 <bef45850-a816-1cf3-0bf5-fe5f395b058d@oracle.com>
 <a82a3b5e-1460-421a-a1b6-ac0cb1ff50e6@default>
 <90a37387-f834-3016-7b7a-68577a48d7e1@oracle.com>
Message-ID: <244618a3-f562-42ce-b62b-5b645fd59d2d@default>

Thanks for the review Semyon!

-----Original Message-----
From: Semyon Sadetsky 
Sent: Wednesday, March 7, 2018 9:27 PM
To: Krishna Addepalli <krishna.addepalli at oracle.com>; Philip Race <philip.race at oracle.com>
Cc: swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [11][JDK-8197785]javax.accessibility.AccessibilityBundle will reload the ResourceBundle for every call to toDisplayString

+1

--Semyon


On 3/7/18 5:28 AM, Krishna Addepalli wrote:
> Hi Semyon,
>
> Modified the code as per your suggestions. Here is the new webrev: 
> http://cr.openjdk.java.net/~kaddepalli/8197785/webrev02
>
> Thanks,
> Krishna
>
> -----Original Message-----
> From: Semyon Sadetsky
> Sent: Tuesday, March 6, 2018 11:46 PM
> To: Phil Race <philip.race at oracle.com>; Krishna Addepalli 
> <krishna.addepalli at oracle.com>
> Cc: swing-dev at openjdk.java.net
> Subject: Re: <Swing Dev> 
> [11][JDK-8197785]javax.accessibility.AccessibilityBundle will reload 
> the ResourceBundle for every call to toDisplayString
>
> On 03/06/2018 10:01 AM, Phil Race wrote:
>
>>
>> On 03/06/2018 09:45 AM, Semyon Sadetsky wrote:
>>> Can you point to place where this Hashmap is updated other then 
>>> where it is initialized?
>> You mean Hashtable ?
> Right, sorry.
>>   161                 table.put(locale, resourceTable);
>>
>> Will be executed once per locale.
> It updates "table" not "resourceTable". The "table" field could be treated differently since writing in it really very rare but it is ok to leave it as it is. All what I meant concerned only the "resourceTable".
>
> --Semyon
>> -phil.
>>



From krishna.addepalli at oracle.com  Wed Mar  7 16:18:44 2018
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Wed, 7 Mar 2018 08:18:44 -0800 (PST)
Subject: <Swing Dev> [11][JDK-8195095]Images are not scaled correctly in
 JEditorPane
In-Reply-To: <580cb1f1-2ea1-401a-85e7-e4d37f84279a@default>
References: <d8dc441e-4025-489b-86d4-6bd8df5e4fba@default>
 <c6d33e58-fa7e-09dd-a2dd-fbc4e5c864b1@oracle.com>
 <7325ffb8-4b61-498b-8405-7d771bdfca0d@default>
 <8922c58d-6f8d-f0b0-de2f-cc57832d42c1@oracle.com>
 <3ea361c1-3591-4f0a-9466-ed14c520538f@default>
 <e71f11a2-9b38-1bb8-5f9c-3a9e8344f5d5@oracle.com>
 <580cb1f1-2ea1-401a-85e7-e4d37f84279a@default>
Message-ID: <a235cb60-1e7a-4785-925b-b09e3fa9e923@default>

Hi Semyon,

 

To reduce the possibility of the test passing / failing due to wrong reasons, I have changed the color of the image to blue, and updated the test accordingly.

Here is the new webrev: http://cr.openjdk.java.net/~kaddepalli/8195095/webrev02

 

Thanks,

Krishna

 

From: Krishna Addepalli 
Sent: Monday, March 5, 2018 11:59 PM
To: Semyon Sadetsky <semyon.sadetsky at oracle.com>; Prasanta Sadhukhan <prasanta.sadhukhan at oracle.com>; swing-dev at openjdk.java.net
Subject: RE: <Swing Dev> [11][JDK-8195095]Images are not scaled correctly in JEditorPane

 

I tried on Ubuntu 17.10, but since the getPixelColor always returns black, the test will pass, which is why I was asking.

 

Thanks,

Krishna

 

From: Semyon Sadetsky 
Sent: Monday, March 5, 2018 11:57 PM
To: Krishna Addepalli <HYPERLINK "mailto:krishna.addepalli at oracle.com"krishna.addepalli at oracle.com>; Prasanta Sadhukhan <HYPERLINK "mailto:prasanta.sadhukhan at oracle.com"prasanta.sadhukhan at oracle.com>; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [11][JDK-8195095]Images are not scaled correctly in JEditorPane

 

On 03/05/2018 10:23 AM, Krishna Addepalli wrote:

Hi Semyon,

 

Did you try it in Windows or Linux? I have tested it on Mac, and found that it fails before the fix and passes after the fix.

I tried it on Linux. But the change is in generic code why the test result depends on the platform?

--Semyon

 

Thanks,

Krishna

 

From: Semyon Sadetsky 
Sent: Monday, March 5, 2018 10:01 PM
To: Krishna Addepalli HYPERLINK "mailto:krishna.addepalli at oracle.com"<krishna.addepalli at oracle.com>; Prasanta Sadhukhan HYPERLINK "mailto:prasanta.sadhukhan at oracle.com"<prasanta.sadhukhan at oracle.com>; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [11][JDK-8195095]Images are not scaled correctly in JEditorPane

 

Hi Krishna,

I tried your test before the fix and it passed.

--Semyon

 

On 03/03/2018 12:07 AM, Krishna Addepalli wrote:

Hi Prasanta,

 

Thanks for the quick review. I have updated the testcase with your suggestion. Here it is: HYPERLINK "http://cr.openjdk.java.net/%7Ekaddepalli/8195095/webrev01"http://cr.openjdk.java.net/~kaddepalli/8195095/webrev01

 

Krishna

 

From: Prasanta Sadhukhan 
Sent: Saturday, March 3, 2018 1:06 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> [11][JDK-8195095]Images are not scaled correctly in JEditorPane

 

looks good to me. 

Only thing, in test, JFrame creation also needs to be in EDT.

Regards
Prasanta

On 3/3/2018 12:40 PM, Krishna Addepalli wrote:

Hi All,

 

Please review a fix for JDK-8195095: https://bugs.openjdk.java.net/browse/JDK-8195095

 

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

 

Problem: When a text html is specified with an image, omitting either the height/width parameter, JEditorPane scales it to default value of the missing parameter, whereas it should fetch the actual value from the image.

 

Fix: The problem is in ImageView.java. In the imageUpdate function, in the resizing logic the "changed" flag is set to 1 if height is present, and to 2 if width is present. But while updating the width, the check is swapped, i.e width is set if flag is 1 and vice versa.

 

PS: The webrev contains a new "circle.png" file, so when you import the patch, you may need to manually copy the file, since "hg import" doesnot automatically import the .png files from the patch file.

 

Thanks

Krishna

 

 

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

From Sergey.Bylokhov at oracle.com  Wed Mar  7 16:53:01 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 7 Mar 2018 08:53:01 -0800
Subject: <Swing Dev>
 [11][JDK-8197785]javax.accessibility.AccessibilityBundle will reload the
 ResourceBundle for every call to toDisplayString
In-Reply-To: <244618a3-f562-42ce-b62b-5b645fd59d2d@default>
References: <7c9fd13a-4af8-4302-9e87-c0c6d41eceae@default>
 <5A9AC9CF.5080809@oracle.com> <ac40cafb-4bc2-4868-87bd-0cc20cf4a7ba@default>
 <52832a36-c6fe-ca1c-c779-d69677d178a3@oracle.com>
 <4be4b83e-d8ea-aa50-376f-60232b589491@oracle.com>
 <45e945b8-5c82-4f16-b801-a04b78a77567@default>
 <0d9cddff-3b89-c6f7-5369-8c22f9894ce3@oracle.com>
 <450af7a3-9c59-f329-76a6-386e619e59d5@oracle.com>
 <3884a1fc-7da2-6aeb-fa41-a23e6e6d36f7@oracle.com>
 <6c68fc95-2df6-47f9-de53-44d917ed5a0a@oracle.com>
 <bef45850-a816-1cf3-0bf5-fe5f395b058d@oracle.com>
 <a82a3b5e-1460-421a-a1b6-ac0cb1ff50e6@default>
 <90a37387-f834-3016-7b7a-68577a48d7e1@oracle.com>
 <244618a3-f562-42ce-b62b-5b645fd59d2d@default>
Message-ID: <53704fa8-6226-eb13-e0dc-0f8f27d96819@oracle.com>

Hi, Krishna.
The .02 version of the fix have changed the behavior of 
toDisplayString() method. Before the fix it throws NPE for key=null, 
after the fix it returns null. I guess version .01 should be fine as it 
simple and supposed to fix one reported bug.

On 07/03/2018 08:19, Krishna Addepalli wrote:
> Thanks for the review Semyon!
> 
> -----Original Message-----
> From: Semyon Sadetsky
> Sent: Wednesday, March 7, 2018 9:27 PM
> To: Krishna Addepalli <krishna.addepalli at oracle.com>; Philip Race <philip.race at oracle.com>
> Cc: swing-dev at openjdk.java.net
> Subject: Re: <Swing Dev> [11][JDK-8197785]javax.accessibility.AccessibilityBundle will reload the ResourceBundle for every call to toDisplayString
> 
> +1
> 
> --Semyon
> 
> 
> On 3/7/18 5:28 AM, Krishna Addepalli wrote:
>> Hi Semyon,
>>
>> Modified the code as per your suggestions. Here is the new webrev:
>> http://cr.openjdk.java.net/~kaddepalli/8197785/webrev02
>>
>> Thanks,
>> Krishna
>>
>> -----Original Message-----
>> From: Semyon Sadetsky
>> Sent: Tuesday, March 6, 2018 11:46 PM
>> To: Phil Race <philip.race at oracle.com>; Krishna Addepalli
>> <krishna.addepalli at oracle.com>
>> Cc: swing-dev at openjdk.java.net
>> Subject: Re: <Swing Dev>
>> [11][JDK-8197785]javax.accessibility.AccessibilityBundle will reload
>> the ResourceBundle for every call to toDisplayString
>>
>> On 03/06/2018 10:01 AM, Phil Race wrote:
>>
>>>
>>> On 03/06/2018 09:45 AM, Semyon Sadetsky wrote:
>>>> Can you point to place where this Hashmap is updated other then
>>>> where it is initialized?
>>> You mean Hashtable ?
>> Right, sorry.
>>>    161                 table.put(locale, resourceTable);
>>>
>>> Will be executed once per locale.
>> It updates "table" not "resourceTable". The "table" field could be treated differently since writing in it really very rare but it is ok to leave it as it is. All what I meant concerned only the "resourceTable".
>>
>> --Semyon
>>> -phil.
>>>
> 


-- 
Best regards, Sergey.


From semyon.sadetsky at oracle.com  Wed Mar  7 17:54:25 2018
From: semyon.sadetsky at oracle.com (semyon.sadetsky at oracle.com)
Date: Wed, 7 Mar 2018 09:54:25 -0800
Subject: <Swing Dev>
 [11][JDK-8197785]javax.accessibility.AccessibilityBundle will reload the
 ResourceBundle for every call to toDisplayString
In-Reply-To: <53704fa8-6226-eb13-e0dc-0f8f27d96819@oracle.com>
References: <7c9fd13a-4af8-4302-9e87-c0c6d41eceae@default>
 <5A9AC9CF.5080809@oracle.com> <ac40cafb-4bc2-4868-87bd-0cc20cf4a7ba@default>
 <52832a36-c6fe-ca1c-c779-d69677d178a3@oracle.com>
 <4be4b83e-d8ea-aa50-376f-60232b589491@oracle.com>
 <45e945b8-5c82-4f16-b801-a04b78a77567@default>
 <0d9cddff-3b89-c6f7-5369-8c22f9894ce3@oracle.com>
 <450af7a3-9c59-f329-76a6-386e619e59d5@oracle.com>
 <3884a1fc-7da2-6aeb-fa41-a23e6e6d36f7@oracle.com>
 <6c68fc95-2df6-47f9-de53-44d917ed5a0a@oracle.com>
 <bef45850-a816-1cf3-0bf5-fe5f395b058d@oracle.com>
 <a82a3b5e-1460-421a-a1b6-ac0cb1ff50e6@default>
 <90a37387-f834-3016-7b7a-68577a48d7e1@oracle.com>
 <244618a3-f562-42ce-b62b-5b645fd59d2d@default>
 <53704fa8-6226-eb13-e0dc-0f8f27d96819@oracle.com>
Message-ID: <7a34616c-7ac3-7057-598a-ad82f4938504@oracle.com>

On 3/7/18 8:53 AM, Sergey Bylokhov wrote:

> Hi, Krishna.
> The .02 version of the fix have changed the behavior of 
> toDisplayString() method. Before the fix it throws NPE for key=null, 
> after the fix it returns null. 
That's ok. It is an improvement. NPE is not expected result according to 
the toDisplayString() method spec.

--Semyon

> I guess version .01 should be fine as it simple and supposed to fix 
> one reported bug.
>
> On 07/03/2018 08:19, Krishna Addepalli wrote:
>> Thanks for the review Semyon!
>>
>> -----Original Message-----
>> From: Semyon Sadetsky
>> Sent: Wednesday, March 7, 2018 9:27 PM
>> To: Krishna Addepalli <krishna.addepalli at oracle.com>; Philip Race 
>> <philip.race at oracle.com>
>> Cc: swing-dev at openjdk.java.net
>> Subject: Re: <Swing Dev> 
>> [11][JDK-8197785]javax.accessibility.AccessibilityBundle will reload 
>> the ResourceBundle for every call to toDisplayString
>>
>> +1
>>
>> --Semyon
>>
>>
>> On 3/7/18 5:28 AM, Krishna Addepalli wrote:
>>> Hi Semyon,
>>>
>>> Modified the code as per your suggestions. Here is the new webrev:
>>> http://cr.openjdk.java.net/~kaddepalli/8197785/webrev02
>>>
>>> Thanks,
>>> Krishna
>>>
>>> -----Original Message-----
>>> From: Semyon Sadetsky
>>> Sent: Tuesday, March 6, 2018 11:46 PM
>>> To: Phil Race <philip.race at oracle.com>; Krishna Addepalli
>>> <krishna.addepalli at oracle.com>
>>> Cc: swing-dev at openjdk.java.net
>>> Subject: Re: <Swing Dev>
>>> [11][JDK-8197785]javax.accessibility.AccessibilityBundle will reload
>>> the ResourceBundle for every call to toDisplayString
>>>
>>> On 03/06/2018 10:01 AM, Phil Race wrote:
>>>
>>>>
>>>> On 03/06/2018 09:45 AM, Semyon Sadetsky wrote:
>>>>> Can you point to place where this Hashmap is updated other then
>>>>> where it is initialized?
>>>> You mean Hashtable ?
>>> Right, sorry.
>>>>    161 table.put(locale, resourceTable);
>>>>
>>>> Will be executed once per locale.
>>> It updates "table" not "resourceTable". The "table" field could be 
>>> treated differently since writing in it really very rare but it is 
>>> ok to leave it as it is. All what I meant concerned only the 
>>> "resourceTable".
>>>
>>> --Semyon
>>>> -phil.
>>>>
>>
>
>



From semyon.sadetsky at oracle.com  Wed Mar  7 18:21:11 2018
From: semyon.sadetsky at oracle.com (semyon.sadetsky at oracle.com)
Date: Wed, 7 Mar 2018 10:21:11 -0800
Subject: <Swing Dev>
 [11][JDK-8197785]javax.accessibility.AccessibilityBundle will reload the
 ResourceBundle for every call to toDisplayString
In-Reply-To: <f63dd554-11e8-344c-7abb-1439634e820f@oracle.com>
References: <7c9fd13a-4af8-4302-9e87-c0c6d41eceae@default>
 <5A9AC9CF.5080809@oracle.com> <ac40cafb-4bc2-4868-87bd-0cc20cf4a7ba@default>
 <52832a36-c6fe-ca1c-c779-d69677d178a3@oracle.com>
 <4be4b83e-d8ea-aa50-376f-60232b589491@oracle.com>
 <45e945b8-5c82-4f16-b801-a04b78a77567@default>
 <0d9cddff-3b89-c6f7-5369-8c22f9894ce3@oracle.com>
 <450af7a3-9c59-f329-76a6-386e619e59d5@oracle.com>
 <3884a1fc-7da2-6aeb-fa41-a23e6e6d36f7@oracle.com>
 <6c68fc95-2df6-47f9-de53-44d917ed5a0a@oracle.com>
 <bef45850-a816-1cf3-0bf5-fe5f395b058d@oracle.com>
 <a82a3b5e-1460-421a-a1b6-ac0cb1ff50e6@default>
 <90a37387-f834-3016-7b7a-68577a48d7e1@oracle.com>
 <244618a3-f562-42ce-b62b-5b645fd59d2d@default>
 <53704fa8-6226-eb13-e0dc-0f8f27d96819@oracle.com>
 <7a34616c-7ac3-7057-598a-ad82f4938504@oracle.com>
 <f63dd554-11e8-344c-7abb-1439634e820f@oracle.com>
Message-ID: <248e44c6-e1ec-3f51-851e-88044562af97@oracle.com>

On 3/7/18 10:12 AM, Sergey Bylokhov wrote:

> On 07/03/2018 09:54, semyon.sadetsky at oracle.com wrote:
>> On 3/7/18 8:53 AM, Sergey Bylokhov wrote:
>>
>>> Hi, Krishna.
>>> The .02 version of the fix have changed the behavior of 
>>> toDisplayString() method. Before the fix it throws NPE for key=null, 
>>> after the fix it returns null. 
>> That's ok.
>
> That's not ok, since we change a behavior without discussion that the 
> benefits of change outweigh the disadvantages, when we implemented 
> some unrelated fix.
That's not true. You may find the discussion in the current thread. Fill 
free to provide your arguments to it.
>
>> It is an improvement. NPE is not expected result according to the 
>> toDisplayString() method spec.
>
> It also changed result of toDisplayString(), previously it did not 
> returned null. I think .01 is better and simpler.
>
Returning null is better than throwing NPE especially in the case when 
NPE doesn't correspond to the spec. Krishna kindly agreed to fix both 
issues at once. I didn't get what is the problem?


From Sergey.Bylokhov at oracle.com  Wed Mar  7 18:12:18 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 7 Mar 2018 10:12:18 -0800
Subject: <Swing Dev>
 [11][JDK-8197785]javax.accessibility.AccessibilityBundle will reload the
 ResourceBundle for every call to toDisplayString
In-Reply-To: <7a34616c-7ac3-7057-598a-ad82f4938504@oracle.com>
References: <7c9fd13a-4af8-4302-9e87-c0c6d41eceae@default>
 <5A9AC9CF.5080809@oracle.com> <ac40cafb-4bc2-4868-87bd-0cc20cf4a7ba@default>
 <52832a36-c6fe-ca1c-c779-d69677d178a3@oracle.com>
 <4be4b83e-d8ea-aa50-376f-60232b589491@oracle.com>
 <45e945b8-5c82-4f16-b801-a04b78a77567@default>
 <0d9cddff-3b89-c6f7-5369-8c22f9894ce3@oracle.com>
 <450af7a3-9c59-f329-76a6-386e619e59d5@oracle.com>
 <3884a1fc-7da2-6aeb-fa41-a23e6e6d36f7@oracle.com>
 <6c68fc95-2df6-47f9-de53-44d917ed5a0a@oracle.com>
 <bef45850-a816-1cf3-0bf5-fe5f395b058d@oracle.com>
 <a82a3b5e-1460-421a-a1b6-ac0cb1ff50e6@default>
 <90a37387-f834-3016-7b7a-68577a48d7e1@oracle.com>
 <244618a3-f562-42ce-b62b-5b645fd59d2d@default>
 <53704fa8-6226-eb13-e0dc-0f8f27d96819@oracle.com>
 <7a34616c-7ac3-7057-598a-ad82f4938504@oracle.com>
Message-ID: <f63dd554-11e8-344c-7abb-1439634e820f@oracle.com>

On 07/03/2018 09:54, semyon.sadetsky at oracle.com wrote:
> On 3/7/18 8:53 AM, Sergey Bylokhov wrote:
> 
>> Hi, Krishna.
>> The .02 version of the fix have changed the behavior of 
>> toDisplayString() method. Before the fix it throws NPE for key=null, 
>> after the fix it returns null. 
> That's ok.

That's not ok, since we change a behavior without discussion that the 
benefits of change outweigh the disadvantages, when we implemented some 
unrelated fix.

> It is an improvement. NPE is not expected result according to 
> the toDisplayString() method spec.

It also changed result of toDisplayString(), previously it did not 
returned null. I think .01 is better and simpler.


-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Wed Mar  7 18:40:24 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 7 Mar 2018 10:40:24 -0800
Subject: <Swing Dev>
 [11][JDK-8197785]javax.accessibility.AccessibilityBundle will reload the
 ResourceBundle for every call to toDisplayString
In-Reply-To: <248e44c6-e1ec-3f51-851e-88044562af97@oracle.com>
References: <7c9fd13a-4af8-4302-9e87-c0c6d41eceae@default>
 <5A9AC9CF.5080809@oracle.com> <ac40cafb-4bc2-4868-87bd-0cc20cf4a7ba@default>
 <52832a36-c6fe-ca1c-c779-d69677d178a3@oracle.com>
 <4be4b83e-d8ea-aa50-376f-60232b589491@oracle.com>
 <45e945b8-5c82-4f16-b801-a04b78a77567@default>
 <0d9cddff-3b89-c6f7-5369-8c22f9894ce3@oracle.com>
 <450af7a3-9c59-f329-76a6-386e619e59d5@oracle.com>
 <3884a1fc-7da2-6aeb-fa41-a23e6e6d36f7@oracle.com>
 <6c68fc95-2df6-47f9-de53-44d917ed5a0a@oracle.com>
 <bef45850-a816-1cf3-0bf5-fe5f395b058d@oracle.com>
 <a82a3b5e-1460-421a-a1b6-ac0cb1ff50e6@default>
 <90a37387-f834-3016-7b7a-68577a48d7e1@oracle.com>
 <244618a3-f562-42ce-b62b-5b645fd59d2d@default>
 <53704fa8-6226-eb13-e0dc-0f8f27d96819@oracle.com>
 <7a34616c-7ac3-7057-598a-ad82f4938504@oracle.com>
 <f63dd554-11e8-344c-7abb-1439634e820f@oracle.com>
 <248e44c6-e1ec-3f51-851e-88044562af97@oracle.com>
Message-ID: <4cb07c34-f482-110c-98f7-afec3adb71f5@oracle.com>

On 07/03/2018 10:21, semyon.sadetsky at oracle.com wrote:
>> That's not ok, since we change a behavior without discussion that the 
>> benefits of change outweigh the disadvantages, when we implemented 
>> some unrelated fix.
> That's not true. You may find the discussion in the current thread. Fill 
> free to provide your arguments to it.

I found nothing related to the behavior, only some conclusion about 
possible performance difference.

>>> It is an improvement. NPE is not expected result according to the 
>>> toDisplayString() method spec.
>>
>> It also changed result of toDisplayString(), previously it did not 
>> returned null. I think .01 is better and simpler.
>>
> Returning null is better than throwing NPE especially in the case when 
> NPE doesn't correspond to the spec. Krishna kindly agreed to fix both 
> issues at once. I didn't get what is the problem?

Nope, if the method start to return null means that all its usage should 
be checked for null return value. As I said it is better to use version 
.01 which fixed the problem w/o side effects.

-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Wed Mar  7 19:08:08 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 7 Mar 2018 11:08:08 -0800
Subject: <Swing Dev> [11] Review Request: 8199022 New failures should be
 added to ProblemList
In-Reply-To: <c2fd412c-4f8c-f314-cafa-8a741799e8c0@oracle.com>
References: <a4c8aa6d-b70d-ce7a-a11e-c6606f5c7243@oracle.com>
 <41dd6940-ad8e-f0e6-d329-c5a94789fd50@oracle.com>
 <b472fe19-4771-7b98-b189-b1cbcabc7916@oracle.com>
 <c2fd412c-4f8c-f314-cafa-8a741799e8c0@oracle.com>
Message-ID: <5ac042e7-02d3-8bc2-d9db-37d2219f290a@oracle.com>

The patch is updated:
http://cr.openjdk.java.net/~serb/8199022/webrev.01

On 07/03/2018 05:57, Prasanta Sadhukhan wrote:
> JDK-8197798 <https://bugs.openjdk.java.net/browse/JDK-8197798>
> 
> 
> On 3/7/2018 7:25 PM, Sergey Bylokhov wrote:
>> Hi, Prasanta.
>> What bugid for java/awt/JAWT/JAWT.sh ?
>>
>> On 07/03/2018 00:21, Prasanta Sadhukhan wrote:
>>> Hi Sergey,
>>>
>>> Looks ok to me. Could you also please add these tests to the list as 
>>> well
>>>
>>> java/awt/image/VolatileImage/CustomCompositeTest.java 8199002 
>>> windows-all, linux-all
>>> java/awt/image/VolatileImage/GradientPaints.java 8199003 linux-all
>>> java/awt/JAWT/JAWT.sh?? windows-all
>>>
>>> Regards
>>> Prasanta
>>> On 3/7/2018 5:47 AM, Sergey Bylokhov wrote:
>>>> Hello.
>>>> Please review an update of the ProblemList for jdk11.
>>>>
>>>> The goal is to make our testing as stable as possible and exclude 
>>>> any unstable tests(I have started from the tests which may be run in 
>>>> the headless mode).
>>>> In this iteration I have updated the problemList for tests which 
>>>> were failed in our nightly at least once for last week. I tested 
>>>> this fix in mach5 seven times and always got a green status for open 
>>>> tests.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8199022
>>>> Webrev can be found at: 
>>>> http://cr.openjdk.java.net/~serb/8199022/webrev.00/
>>>>
>>>> ?- The ProblemList.txt is updated, I have created a list of new bugs 
>>>> for the tests which fail at least once in a few iterations on a 
>>>> different systems.
>>>> ?- The TEST.ROOT is updated, because "javax/swing" was missed when 
>>>> it was updated last time in JDK-8002120. The reason is that our 
>>>> tests does not work well in the agentvm mode(they affects each other 
>>>> in some unclear way which is reproduced in nightly only).
>>>>
>>>>
>>>
>>
>>
> 


-- 
Best regards, Sergey.


From semyon.sadetsky at oracle.com  Wed Mar  7 19:17:58 2018
From: semyon.sadetsky at oracle.com (semyon.sadetsky at oracle.com)
Date: Wed, 7 Mar 2018 11:17:58 -0800
Subject: <Swing Dev>
 [11][JDK-8197785]javax.accessibility.AccessibilityBundle will reload the
 ResourceBundle for every call to toDisplayString
In-Reply-To: <4cb07c34-f482-110c-98f7-afec3adb71f5@oracle.com>
References: <7c9fd13a-4af8-4302-9e87-c0c6d41eceae@default>
 <5A9AC9CF.5080809@oracle.com> <ac40cafb-4bc2-4868-87bd-0cc20cf4a7ba@default>
 <52832a36-c6fe-ca1c-c779-d69677d178a3@oracle.com>
 <4be4b83e-d8ea-aa50-376f-60232b589491@oracle.com>
 <45e945b8-5c82-4f16-b801-a04b78a77567@default>
 <0d9cddff-3b89-c6f7-5369-8c22f9894ce3@oracle.com>
 <450af7a3-9c59-f329-76a6-386e619e59d5@oracle.com>
 <3884a1fc-7da2-6aeb-fa41-a23e6e6d36f7@oracle.com>
 <6c68fc95-2df6-47f9-de53-44d917ed5a0a@oracle.com>
 <bef45850-a816-1cf3-0bf5-fe5f395b058d@oracle.com>
 <a82a3b5e-1460-421a-a1b6-ac0cb1ff50e6@default>
 <90a37387-f834-3016-7b7a-68577a48d7e1@oracle.com>
 <244618a3-f562-42ce-b62b-5b645fd59d2d@default>
 <53704fa8-6226-eb13-e0dc-0f8f27d96819@oracle.com>
 <7a34616c-7ac3-7057-598a-ad82f4938504@oracle.com>
 <f63dd554-11e8-344c-7abb-1439634e820f@oracle.com>
 <248e44c6-e1ec-3f51-851e-88044562af97@oracle.com>
 <4cb07c34-f482-110c-98f7-afec3adb71f5@oracle.com>
Message-ID: <007c07df-aa85-c975-1d53-adb1f0684c84@oracle.com>

On 3/7/18 10:40 AM, Sergey Bylokhov wrote:

> On 07/03/2018 10:21, semyon.sadetsky at oracle.com wrote:
>>> That's not ok, since we change a behavior without discussion that 
>>> the benefits of change outweigh the disadvantages, when we 
>>> implemented some unrelated fix.
>> That's not true. You may find the discussion in the current thread. 
>> Fill free to provide your arguments to it.
>
> I found nothing related to the behavior, only some conclusion about 
> possible performance difference.
So you agree?
>
>>>> It is an improvement. NPE is not expected result according to the 
>>>> toDisplayString() method spec.
>>>
>>> It also changed result of toDisplayString(), previously it did not 
>>> returned null. I think .01 is better and simpler.
>>>
>> Returning null is better than throwing NPE especially in the case 
>> when NPE doesn't correspond to the spec. Krishna kindly agreed to fix 
>> both issues at once. I didn't get what is the problem?
>
> Nope, if the method start to return null means that all its usage 
> should be checked for null return value. 
You always should check for null return if the spec does not say that 
null is never returned. In this specific case if null check is absent 
the NPE will be thrown in the user code instead of JDK code, so there is 
no degradation.
> As I said it is better to use version .01 which fixed the problem w/o 
> side effects.
>
Thanks for your advice. Try to provide more arguments next time.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20180307/6ee519ed/attachment.html>

From Sergey.Bylokhov at oracle.com  Wed Mar  7 19:34:13 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 7 Mar 2018 11:34:13 -0800
Subject: <Swing Dev>
 [11][JDK-8197785]javax.accessibility.AccessibilityBundle will reload the
 ResourceBundle for every call to toDisplayString
In-Reply-To: <007c07df-aa85-c975-1d53-adb1f0684c84@oracle.com>
References: <7c9fd13a-4af8-4302-9e87-c0c6d41eceae@default>
 <5A9AC9CF.5080809@oracle.com> <ac40cafb-4bc2-4868-87bd-0cc20cf4a7ba@default>
 <52832a36-c6fe-ca1c-c779-d69677d178a3@oracle.com>
 <4be4b83e-d8ea-aa50-376f-60232b589491@oracle.com>
 <45e945b8-5c82-4f16-b801-a04b78a77567@default>
 <0d9cddff-3b89-c6f7-5369-8c22f9894ce3@oracle.com>
 <450af7a3-9c59-f329-76a6-386e619e59d5@oracle.com>
 <3884a1fc-7da2-6aeb-fa41-a23e6e6d36f7@oracle.com>
 <6c68fc95-2df6-47f9-de53-44d917ed5a0a@oracle.com>
 <bef45850-a816-1cf3-0bf5-fe5f395b058d@oracle.com>
 <a82a3b5e-1460-421a-a1b6-ac0cb1ff50e6@default>
 <90a37387-f834-3016-7b7a-68577a48d7e1@oracle.com>
 <244618a3-f562-42ce-b62b-5b645fd59d2d@default>
 <53704fa8-6226-eb13-e0dc-0f8f27d96819@oracle.com>
 <7a34616c-7ac3-7057-598a-ad82f4938504@oracle.com>
 <f63dd554-11e8-344c-7abb-1439634e820f@oracle.com>
 <248e44c6-e1ec-3f51-851e-88044562af97@oracle.com>
 <4cb07c34-f482-110c-98f7-afec3adb71f5@oracle.com>
 <007c07df-aa85-c975-1d53-adb1f0684c84@oracle.com>
Message-ID: <0ef47a37-cfb4-d420-50b7-43344a842ecb@oracle.com>

On 07/03/2018 11:17, semyon.sadetsky at oracle.com wrote:
>> I found nothing related to the behavior, only some conclusion about 
>> possible performance difference.
> So you agree?

Agreed with what? Unrelated to the current fix and unproven possible 
performance change in rare situation is not outweigh the change in behavior.

>>> Returning null is better than throwing NPE especially in the case 
>>> when NPE doesn't correspond to the spec. Krishna kindly agreed to fix 
>>> both issues at once. I didn't get what is the problem?
>>
>> Nope, if the method start to return null means that all its usage 
>> should be checked for null return value. 
> You always should check for null return if the spec does not say that 
> null is never returned. In this specific case if null check is absent 
> the NPE will be thrown in the user code instead of JDK code, so there is 
> no degradation.
>> As I said it is better to use version .01 which fixed the problem w/o 
>> side effects.
>>
> Thanks for your advice. Try to provide more arguments next time.

You are welcome.


-- 
Best regards, Sergey.


From semyon.sadetsky at oracle.com  Wed Mar  7 19:34:40 2018
From: semyon.sadetsky at oracle.com (semyon.sadetsky at oracle.com)
Date: Wed, 7 Mar 2018 11:34:40 -0800
Subject: <Swing Dev>
 [11][JDK-8197785]javax.accessibility.AccessibilityBundle will reload the
 ResourceBundle for every call to toDisplayString
In-Reply-To: <007c07df-aa85-c975-1d53-adb1f0684c84@oracle.com>
References: <7c9fd13a-4af8-4302-9e87-c0c6d41eceae@default>
 <5A9AC9CF.5080809@oracle.com> <ac40cafb-4bc2-4868-87bd-0cc20cf4a7ba@default>
 <52832a36-c6fe-ca1c-c779-d69677d178a3@oracle.com>
 <4be4b83e-d8ea-aa50-376f-60232b589491@oracle.com>
 <45e945b8-5c82-4f16-b801-a04b78a77567@default>
 <0d9cddff-3b89-c6f7-5369-8c22f9894ce3@oracle.com>
 <450af7a3-9c59-f329-76a6-386e619e59d5@oracle.com>
 <3884a1fc-7da2-6aeb-fa41-a23e6e6d36f7@oracle.com>
 <6c68fc95-2df6-47f9-de53-44d917ed5a0a@oracle.com>
 <bef45850-a816-1cf3-0bf5-fe5f395b058d@oracle.com>
 <a82a3b5e-1460-421a-a1b6-ac0cb1ff50e6@default>
 <90a37387-f834-3016-7b7a-68577a48d7e1@oracle.com>
 <244618a3-f562-42ce-b62b-5b645fd59d2d@default>
 <53704fa8-6226-eb13-e0dc-0f8f27d96819@oracle.com>
 <7a34616c-7ac3-7057-598a-ad82f4938504@oracle.com>
 <f63dd554-11e8-344c-7abb-1439634e820f@oracle.com>
 <248e44c6-e1ec-3f51-851e-88044562af97@oracle.com>
 <4cb07c34-f482-110c-98f7-afec3adb71f5@oracle.com>
 <007c07df-aa85-c975-1d53-adb1f0684c84@oracle.com>
Message-ID: <2ba4ff53-6837-a988-95c7-54a77cffb962@oracle.com>

I just noticed that null returning scenario only possible when locale 
independent state name is null but the latter should never happen. So we 
simply may ignore this null/NPE worry.

--Semyon


On 3/7/18 11:17 AM, semyon.sadetsky at oracle.com wrote:
>
> On 3/7/18 10:40 AM, Sergey Bylokhov wrote:
>
>> On 07/03/2018 10:21, semyon.sadetsky at oracle.com wrote:
>>>> That's not ok, since we change a behavior without discussion that 
>>>> the benefits of change outweigh the disadvantages, when we 
>>>> implemented some unrelated fix.
>>> That's not true. You may find the discussion in the current thread. 
>>> Fill free to provide your arguments to it.
>>
>> I found nothing related to the behavior, only some conclusion about 
>> possible performance difference.
> So you agree?
>>
>>>>> It is an improvement. NPE is not expected result according to the 
>>>>> toDisplayString() method spec.
>>>>
>>>> It also changed result of toDisplayString(), previously it did not 
>>>> returned null. I think .01 is better and simpler.
>>>>
>>> Returning null is better than throwing NPE especially in the case 
>>> when NPE doesn't correspond to the spec. Krishna kindly agreed to 
>>> fix both issues at once. I didn't get what is the problem?
>>
>> Nope, if the method start to return null means that all its usage 
>> should be checked for null return value. 
> You always should check for null return if the spec does not say that 
> null is never returned. In this specific case if null check is absent 
> the NPE will be thrown in the user code instead of JDK code, so there 
> is no degradation.
>> As I said it is better to use version .01 which fixed the problem w/o 
>> side effects.
>>
> Thanks for your advice. Try to provide more arguments next time.

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

From krishna.addepalli at oracle.com  Thu Mar  8 00:30:36 2018
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Wed, 7 Mar 2018 16:30:36 -0800 (PST)
Subject: <Swing Dev>
 [11][JDK-8197785]javax.accessibility.AccessibilityBundle will reload the
 ResourceBundle for every call to toDisplayString
In-Reply-To: <2ba4ff53-6837-a988-95c7-54a77cffb962@oracle.com>
References: <7c9fd13a-4af8-4302-9e87-c0c6d41eceae@default>
 <5A9AC9CF.5080809@oracle.com> <ac40cafb-4bc2-4868-87bd-0cc20cf4a7ba@default>
 <52832a36-c6fe-ca1c-c779-d69677d178a3@oracle.com>
 <4be4b83e-d8ea-aa50-376f-60232b589491@oracle.com>
 <45e945b8-5c82-4f16-b801-a04b78a77567@default>
 <0d9cddff-3b89-c6f7-5369-8c22f9894ce3@oracle.com>
 <450af7a3-9c59-f329-76a6-386e619e59d5@oracle.com>
 <3884a1fc-7da2-6aeb-fa41-a23e6e6d36f7@oracle.com>
 <6c68fc95-2df6-47f9-de53-44d917ed5a0a@oracle.com>
 <bef45850-a816-1cf3-0bf5-fe5f395b058d@oracle.com>
 <a82a3b5e-1460-421a-a1b6-ac0cb1ff50e6@default>
 <90a37387-f834-3016-7b7a-68577a48d7e1@oracle.com>
 <244618a3-f562-42ce-b62b-5b645fd59d2d@default>
 <53704fa8-6226-eb13-e0dc-0f8f27d96819@oracle.com>
 <7a34616c-7ac3-7057-598a-ad82f4938504@oracle.com>
 <f63dd554-11e8-344c-7abb-1439634e820f@oracle.com>
 <248e44c6-e1ec-3f51-851e-88044562af97@oracle.com>
 <4cb07c34-f482-110c-98f7-afec3adb71f5@oracle.com>
 <007c07df-aa85-c975-1d53-adb1f0684c84@oracle.com>
 <2ba4ff53-6837-a988-95c7-54a77cffb962@oracle.com>
Message-ID: <38524d39-cd6a-4032-8dd3-91ac4f40ec8d@default>

Hi Sergey,

?

I understand the behavior change of raising an exception vs quietly returning null. As per my understanding, this happens only when someone passes a null for the locale key right? If so, how about explicitly checking for null, and throwing exception?

?

@Semyon,

?

I think we should address this change in a separate bug, since we want behavior question answered.

?

Thanks,

Krishna

?

From: Semyon Sadetsky 
Sent: Thursday, March 8, 2018 1:05 AM
To: Sergey Bylokhov <sergey.bylokhov at oracle.com>; Krishna Addepalli <krishna.addepalli at oracle.com>; Philip Race <philip.race at oracle.com>
Cc: swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [11][JDK-8197785]javax.accessibility.AccessibilityBundle will reload the ResourceBundle for every call to toDisplayString

?

I just noticed that null returning scenario only possible when? locale independent state name is null but the latter should never happen. So we simply may ignore this null/NPE worry.

--Semyon

?

On 3/7/18 11:17 AM, HYPERLINK "mailto:semyon.sadetsky at oracle.com"semyon.sadetsky at oracle.com wrote:

On 3/7/18 10:40 AM, Sergey Bylokhov wrote:

On 07/03/2018 10:21, HYPERLINK "mailto:semyon.sadetsky at oracle.com"semyon.sadetsky at oracle.com wrote: 



That's not ok, since we change a behavior without discussion that the benefits of change outweigh the disadvantages, when we implemented some unrelated fix. 

That's not true. You may find the discussion in the current thread. Fill free to provide your arguments to it. 


I found nothing related to the behavior, only some conclusion about possible performance difference. 

So you agree?







It is an improvement. NPE is not expected result according to the toDisplayString() method spec. 


It also changed result of toDisplayString(), previously it did not returned null. I think .01 is better and simpler. 

Returning null is better than throwing NPE especially in the case when NPE doesn't correspond to the spec. Krishna kindly agreed to fix both issues at once. I didn't get what is the problem? 


Nope, if the method start to return null means that all its usage should be checked for null return value. 

You always should check for null return if the spec does not say that null is never returned. In this specific case if null check is absent the NPE will be thrown in the user code instead of JDK code, so there is no degradation.



As I said it is better to use version .01 which fixed the problem w/o side effects. 

Thanks for your advice. Try to provide more arguments next time.

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

From prasanta.sadhukhan at oracle.com  Thu Mar  8 05:42:47 2018
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Thu, 8 Mar 2018 11:12:47 +0530
Subject: <Swing Dev> [11] Review Request: 8199022 New failures should be
 added to ProblemList
In-Reply-To: <5ac042e7-02d3-8bc2-d9db-37d2219f290a@oracle.com>
References: <a4c8aa6d-b70d-ce7a-a11e-c6606f5c7243@oracle.com>
 <41dd6940-ad8e-f0e6-d329-c5a94789fd50@oracle.com>
 <b472fe19-4771-7b98-b189-b1cbcabc7916@oracle.com>
 <c2fd412c-4f8c-f314-cafa-8a741799e8c0@oracle.com>
 <5ac042e7-02d3-8bc2-d9db-37d2219f290a@oracle.com>
Message-ID: <b157fb3f-e951-59ee-ae1b-2ad656e4c545@oracle.com>

+1

Regards
Prasanta
On 3/8/2018 12:38 AM, Sergey Bylokhov wrote:
> The patch is updated:
> http://cr.openjdk.java.net/~serb/8199022/webrev.01
>
> On 07/03/2018 05:57, Prasanta Sadhukhan wrote:
>> JDK-8197798 <https://bugs.openjdk.java.net/browse/JDK-8197798>
>>
>>
>> On 3/7/2018 7:25 PM, Sergey Bylokhov wrote:
>>> Hi, Prasanta.
>>> What bugid for java/awt/JAWT/JAWT.sh ?
>>>
>>> On 07/03/2018 00:21, Prasanta Sadhukhan wrote:
>>>> Hi Sergey,
>>>>
>>>> Looks ok to me. Could you also please add these tests to the list 
>>>> as well
>>>>
>>>> java/awt/image/VolatileImage/CustomCompositeTest.java 8199002 
>>>> windows-all, linux-all
>>>> java/awt/image/VolatileImage/GradientPaints.java 8199003 linux-all
>>>> java/awt/JAWT/JAWT.sh?? windows-all
>>>>
>>>> Regards
>>>> Prasanta
>>>> On 3/7/2018 5:47 AM, Sergey Bylokhov wrote:
>>>>> Hello.
>>>>> Please review an update of the ProblemList for jdk11.
>>>>>
>>>>> The goal is to make our testing as stable as possible and exclude 
>>>>> any unstable tests(I have started from the tests which may be run 
>>>>> in the headless mode).
>>>>> In this iteration I have updated the problemList for tests which 
>>>>> were failed in our nightly at least once for last week. I tested 
>>>>> this fix in mach5 seven times and always got a green status for 
>>>>> open tests.
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8199022
>>>>> Webrev can be found at: 
>>>>> http://cr.openjdk.java.net/~serb/8199022/webrev.00/
>>>>>
>>>>> ?- The ProblemList.txt is updated, I have created a list of new 
>>>>> bugs for the tests which fail at least once in a few iterations on 
>>>>> a different systems.
>>>>> ?- The TEST.ROOT is updated, because "javax/swing" was missed when 
>>>>> it was updated last time in JDK-8002120. The reason is that our 
>>>>> tests does not work well in the agentvm mode(they affects each 
>>>>> other in some unclear way which is reproduced in nightly only).
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>



From Sergey.Bylokhov at oracle.com  Fri Mar  9 01:14:02 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 8 Mar 2018 17:14:02 -0800
Subject: <Swing Dev> [10] Review Request: JDK-7108280 :
 JList.getSelectedValuesList fails if JList.setSelectionInterval larger than
 list
In-Reply-To: <d88047c7-33cd-465b-ab6e-fbf7f2612baf@default>
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>
 <d88047c7-33cd-465b-ab6e-fbf7f2612baf@default>
Message-ID: <4de29e03-d055-fcbf-aeb2-5ddf1be52e83@oracle.com>

Looks fine to me.

On 03/01/2018 03:53, Pankaj Bansal wrote:
> 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.


-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Fri Mar  9 01:17:25 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 8 Mar 2018 17:17:25 -0800
Subject: <Swing Dev> [11] [JDK-8074286] : Add getSelectedIndices() to
 ListSelectionModel
In-Reply-To: <2730e768-abde-4e00-bb0f-b0481aae10ae@default>
References: <2730e768-abde-4e00-bb0f-b0481aae10ae@default>
Message-ID: <314fb4ba-48b6-e3b7-6556-60ddc9934478@oracle.com>

Hi, Pankaj.
The fix looks fine, please add @since tag for the new methods in CSR.

On 02/02/2018 09:06, Pankaj Bansal wrote:
> Hi All,
> 
> Please review a fix for the Enhancement. I will raise a CSR after 
> technical evaluation.
> 
> Enhancement:
> 
> https://bugs.openjdk.java.net/browse/JDK-8074286
> 
> Webrev:
> 
> http://cr.openjdk.java.net/~pbansal/8074286/webrev.00/
> 
> The enhancement requests to add getSelectedIndices function to 
> ListSelectionModel Interface as same function with duplicate 
> implementation is being used in JList, JTable and DefaultTableColumnModel.
> 
> I have also added the getSelectedItemsCount function in 
> ListSelectionModel, as this is also being used at multiple places with 
> same implementation.
> 
> JList.getSelectedValues and JList.getSelectedValuesList are also 
> modified to use getSelectionIndices instead of replicating the same code.
> 
> Regards,
> 
> Pankaj Bansal
> 


-- 
Best regards, Sergey.


From semyon.sadetsky at oracle.com  Fri Mar  9 01:47:22 2018
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Thu, 8 Mar 2018 17:47:22 -0800
Subject: <Swing Dev> [10] Review Request: JDK-7108280 :
 JList.getSelectedValuesList fails if JList.setSelectionInterval larger than
 list
In-Reply-To: <d88047c7-33cd-465b-ab6e-fbf7f2612baf@default>
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>
 <d88047c7-33cd-465b-ab6e-fbf7f2612baf@default>
Message-ID: <38837ea6-b97b-36f2-0cd1-95b2bd8d063c@oracle.com>

Hi Pankaj,

what will be the return from JList.getSelectedIndices()? in the issue 
scenario?

--Semyon

On 01/03/2018 03:53 AM, Pankaj Bansal wrote:

> 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 pquiring at gmail.com  Fri Mar  9 03:58:15 2018
From: pquiring at gmail.com (Peter Quiring)
Date: Thu, 8 Mar 2018 22:58:15 -0500
Subject: <Swing Dev> right ALT key generates wrong modifiers
Message-ID: <CA+3dX1wsMFkR9Ejqb2b3orBm9bJ5ny6nSvZ+uUo6acqHonvcWA@mail.gmail.com>

A new check for VK_RMENU is generating new modifier bits for the right
ALT key causing shortcuts to fail.

http://hg.openjdk.java.net/jdk/jdk/file/ba545e52b932/src/java.desktop/windows/native/libawt/windows/awt_Component.cpp#l2718

See bug # 8194873

https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8194873

For example:

JOptionPane.showConfirmDialog(this, "Do you wish to save file?",
"Confirm", JOptionPane.YES_NO_CANCEL_OPTION)

When you type left ALT+Y it works, but right ALT+Y does NOT work.

This is a regression added in Java9.

Please fix asap, thanks.

-- 
Peter Quiring


From pankaj.b.bansal at oracle.com  Fri Mar  9 05:47:30 2018
From: pankaj.b.bansal at oracle.com (Pankaj Bansal)
Date: Thu, 8 Mar 2018 21:47:30 -0800 (PST)
Subject: <Swing Dev> [10] Review Request: JDK-7108280 :
 JList.getSelectedValuesList fails if JList.setSelectionInterval larger than
 list
In-Reply-To: <38837ea6-b97b-36f2-0cd1-95b2bd8d063c@oracle.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>
 <d88047c7-33cd-465b-ab6e-fbf7f2612baf@default>
 <38837ea6-b97b-36f2-0cd1-95b2bd8d063c@oracle.com>
Message-ID: <f84fa6be-dd82-441e-801c-d4f40b61a0a2@default>

Hi Semyon,

<<what will be the return from JList.getSelectedIndices()  in the issue scenario?
I have not made any changes to JList.getSelectedIndices method. It will return the selected indices in selection model.

Regards,
Pankaj Bansal

-----Original Message-----
From: Semyon Sadetsky 
Sent: Friday, March 9, 2018 7:17 AM
To: Pankaj Bansal; 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 Pankaj,

what will be the return from JList.getSelectedIndices()? in the issue scenario?

--Semyon

On 01/03/2018 03:53 AM, Pankaj Bansal wrote:

> 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 krishna.addepalli at oracle.com  Fri Mar  9 09:16:13 2018
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Fri, 9 Mar 2018 01:16:13 -0800 (PST)
Subject: <Swing Dev>
 [11][JDK-8197785]javax.accessibility.AccessibilityBundle will reload the
 ResourceBundle for every call to toDisplayString
In-Reply-To: <38524d39-cd6a-4032-8dd3-91ac4f40ec8d@default>
References: <7c9fd13a-4af8-4302-9e87-c0c6d41eceae@default>
 <5A9AC9CF.5080809@oracle.com> <ac40cafb-4bc2-4868-87bd-0cc20cf4a7ba@default>
 <52832a36-c6fe-ca1c-c779-d69677d178a3@oracle.com>
 <4be4b83e-d8ea-aa50-376f-60232b589491@oracle.com>
 <45e945b8-5c82-4f16-b801-a04b78a77567@default>
 <0d9cddff-3b89-c6f7-5369-8c22f9894ce3@oracle.com>
 <450af7a3-9c59-f329-76a6-386e619e59d5@oracle.com>
 <3884a1fc-7da2-6aeb-fa41-a23e6e6d36f7@oracle.com>
 <6c68fc95-2df6-47f9-de53-44d917ed5a0a@oracle.com>
 <bef45850-a816-1cf3-0bf5-fe5f395b058d@oracle.com>
 <a82a3b5e-1460-421a-a1b6-ac0cb1ff50e6@default>
 <90a37387-f834-3016-7b7a-68577a48d7e1@oracle.com>
 <244618a3-f562-42ce-b62b-5b645fd59d2d@default>
 <53704fa8-6226-eb13-e0dc-0f8f27d96819@oracle.com>
 <7a34616c-7ac3-7057-598a-ad82f4938504@oracle.com>
 <f63dd554-11e8-344c-7abb-1439634e820f@oracle.com>
 <248e44c6-e1ec-3f51-851e-88044562af97@oracle.com>
 <4cb07c34-f482-110c-98f7-afec3adb71f5@oracle.com>
 <007c07df-aa85-c975-1d53-adb1f0684c84@oracle.com>
 <2ba4ff53-6837-a988-95c7-54a77cffb962@oracle.com>
 <38524d39-cd6a-4032-8dd3-91ac4f40ec8d@default>
Message-ID: <d4ffc518-5131-4026-be21-b21ca380d3c6@default>

Hi Sergey/Semyon,

?

I have pushed webrev01 which simply fixes the bug as reported, and created a new issue JDK-8199400 to address the point of changing Hashtable to HashMap.

Once we are clear about the changes, we can push them with this bug.

?

Thanks,

Krishna

?

From: Krishna Addepalli 
Sent: Thursday, March 8, 2018 6:01 AM
To: Semyon Sadetsky <semyon.sadetsky at oracle.com>; Sergey Bylokhov <sergey.bylokhov at oracle.com>; Philip Race <philip.race at oracle.com>
Cc: swing-dev at openjdk.java.net
Subject: RE: <Swing Dev> [11][JDK-8197785]javax.accessibility.AccessibilityBundle will reload the ResourceBundle for every call to toDisplayString

?

Hi Sergey,

?

I understand the behavior change of raising an exception vs quietly returning null. As per my understanding, this happens only when someone passes a null for the locale key right? If so, how about explicitly checking for null, and throwing exception?

?

@Semyon,

?

I think we should address this change in a separate bug, since we want behavior question answered.

?

Thanks,

Krishna

?

From: Semyon Sadetsky 
Sent: Thursday, March 8, 2018 1:05 AM
To: Sergey Bylokhov <HYPERLINK "mailto:sergey.bylokhov at oracle.com"sergey.bylokhov at oracle.com>; Krishna Addepalli <HYPERLINK "mailto:krishna.addepalli at oracle.com"krishna.addepalli at oracle.com>; Philip Race <HYPERLINK "mailto:philip.race at oracle.com"philip.race at oracle.com>
Cc: HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [11][JDK-8197785]javax.accessibility.AccessibilityBundle will reload the ResourceBundle for every call to toDisplayString

?

I just noticed that null returning scenario only possible when? locale independent state name is null but the latter should never happen. So we simply may ignore this null/NPE worry.

--Semyon

?

On 3/7/18 11:17 AM, HYPERLINK "mailto:semyon.sadetsky at oracle.com"semyon.sadetsky at oracle.com wrote:

On 3/7/18 10:40 AM, Sergey Bylokhov wrote:

On 07/03/2018 10:21, HYPERLINK "mailto:semyon.sadetsky at oracle.com"semyon.sadetsky at oracle.com wrote: 

That's not ok, since we change a behavior without discussion that the benefits of change outweigh the disadvantages, when we implemented some unrelated fix. 

That's not true. You may find the discussion in the current thread. Fill free to provide your arguments to it. 


I found nothing related to the behavior, only some conclusion about possible performance difference. 

So you agree?

?

It is an improvement. NPE is not expected result according to the toDisplayString() method spec. 


It also changed result of toDisplayString(), previously it did not returned null. I think .01 is better and simpler. 

Returning null is better than throwing NPE especially in the case when NPE doesn't correspond to the spec. Krishna kindly agreed to fix both issues at once. I didn't get what is the problem? 


Nope, if the method start to return null means that all its usage should be checked for null return value. 

You always should check for null return if the spec does not say that null is never returned. In this specific case if null check is absent the NPE will be thrown in the user code instead of JDK code, so there is no degradation.

As I said it is better to use version .01 which fixed the problem w/o side effects. 

Thanks for your advice. Try to provide more arguments next time.

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

From semyon.sadetsky at oracle.com  Fri Mar  9 16:14:28 2018
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Fri, 9 Mar 2018 08:14:28 -0800
Subject: <Swing Dev> [10] Review Request: JDK-7108280 :
 JList.getSelectedValuesList fails if JList.setSelectionInterval larger than
 list
In-Reply-To: <f84fa6be-dd82-441e-801c-d4f40b61a0a2@default>
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>
 <d88047c7-33cd-465b-ab6e-fbf7f2612baf@default>
 <38837ea6-b97b-36f2-0cd1-95b2bd8d063c@oracle.com>
 <f84fa6be-dd82-441e-801c-d4f40b61a0a2@default>
Message-ID: <d71a2ad9-047a-6896-bb47-53622f7ff33b@oracle.com>

Hi Pankaj,

Where this fix should go? In 10?
How does this fix correspond to the 8074286 change you've just posted 
where IOOBE is thrown again?

On 03/08/2018 09:47 PM, Pankaj Bansal wrote:
> Hi Semyon,
>
> <<what will be the return from JList.getSelectedIndices()  in the issue scenario?
> I have not made any changes to JList.getSelectedIndices method. It will return the selected indices in selection model.
Then there will be discrepancy between getSelectedValues**() and 
getSelectedIndices() of the same list.

--Semyon
>
> Regards,
> Pankaj Bansal
>
> -----Original Message-----
> From: Semyon Sadetsky
> Sent: Friday, March 9, 2018 7:17 AM
> To: Pankaj Bansal; 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 Pankaj,
>
> what will be the return from JList.getSelectedIndices()? in the issue scenario?
>
> --Semyon
>
> On 01/03/2018 03:53 AM, Pankaj Bansal wrote:
>
>> 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 pankaj.b.bansal at oracle.com  Fri Mar  9 16:28:30 2018
From: pankaj.b.bansal at oracle.com (Pankaj Bansal)
Date: Fri, 9 Mar 2018 08:28:30 -0800 (PST)
Subject: <Swing Dev> [10] Review Request: JDK-7108280 :
 JList.getSelectedValuesList fails if JList.setSelectionInterval larger than
 list
In-Reply-To: <d71a2ad9-047a-6896-bb47-53622f7ff33b@oracle.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>
 <d88047c7-33cd-465b-ab6e-fbf7f2612baf@default>
 <38837ea6-b97b-36f2-0cd1-95b2bd8d063c@oracle.com>
 <f84fa6be-dd82-441e-801c-d4f40b61a0a2@default>
 <d71a2ad9-047a-6896-bb47-53622f7ff33b@oracle.com>
Message-ID: <bbad4b5f-fd1f-49fe-ba0b-6ff22fdd2e29@default>

Hi Semyon,

Thanks for the review.

<< Where this fix should go? In 10?
This will go in 11. Actually this is pending from sometime and I have to change the fix version. Should I send a new request for this (once the review is approved) or just update the information here.

<< How does this fix correspond to the 8074286 change you've just posted where IOOBE is thrown again?
These two fixes address same piece of code. I will update the webrev for 8074286 if this fix goes first. Basically I will have to resolve the changes depending upon which fix will go first.

Regards,
Pankaj Bansal

-----Original Message-----
From: Semyon Sadetsky 
Sent: Friday, March 9, 2018 9:44 PM
To: Pankaj Bansal; 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 Pankaj,

Where this fix should go? In 10?
How does this fix correspond to the 8074286 change you've just posted where IOOBE is thrown again?

On 03/08/2018 09:47 PM, Pankaj Bansal wrote:
> Hi Semyon,
>
> <<what will be the return from JList.getSelectedIndices()  in the issue scenario?
> I have not made any changes to JList.getSelectedIndices method. It will return the selected indices in selection model.
Then there will be discrepancy between getSelectedValues**() and
getSelectedIndices() of the same list.

--Semyon
>
> Regards,
> Pankaj Bansal
>
> -----Original Message-----
> From: Semyon Sadetsky
> Sent: Friday, March 9, 2018 7:17 AM
> To: Pankaj Bansal; 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 Pankaj,
>
> what will be the return from JList.getSelectedIndices()? in the issue scenario?
>
> --Semyon
>
> On 01/03/2018 03:53 AM, Pankaj Bansal wrote:
>
>> 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 semyon.sadetsky at oracle.com  Fri Mar  9 18:53:42 2018
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Fri, 9 Mar 2018 10:53:42 -0800
Subject: <Swing Dev> right ALT key generates wrong modifiers
In-Reply-To: <CA+3dX1wsMFkR9Ejqb2b3orBm9bJ5ny6nSvZ+uUo6acqHonvcWA@mail.gmail.com>
References: <CA+3dX1wsMFkR9Ejqb2b3orBm9bJ5ny6nSvZ+uUo6acqHonvcWA@mail.gmail.com>
Message-ID: <2d41a5de-aee3-d766-7301-cd8f42236a31@oracle.com>

Hi Peter,

Thanks for pointing that. Now 
https://bugs.openjdk.java.net/browse/JDK-8194873 is created to track 
this issue.

--Semyon


On 03/08/2018 07:58 PM, Peter Quiring wrote:
> A new check for VK_RMENU is generating new modifier bits for the right
> ALT key causing shortcuts to fail.
>
> http://hg.openjdk.java.net/jdk/jdk/file/ba545e52b932/src/java.desktop/windows/native/libawt/windows/awt_Component.cpp#l2718
>
> See bug # 8194873
>
> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8194873
>
> For example:
>
> JOptionPane.showConfirmDialog(this, "Do you wish to save file?",
> "Confirm", JOptionPane.YES_NO_CANCEL_OPTION)
>
> When you type left ALT+Y it works, but right ALT+Y does NOT work.
>
> This is a regression added in Java9.
>
> Please fix asap, thanks.
>



From pankaj.b.bansal at oracle.com  Mon Mar 12 08:52:35 2018
From: pankaj.b.bansal at oracle.com (Pankaj Bansal)
Date: Mon, 12 Mar 2018 01:52:35 -0700 (PDT)
Subject: <Swing Dev> [11] JDK-8191957: JFileChooser shows empty name for
 external drives shown under Desktop
Message-ID: <065d066f-810c-4284-9de6-059f4235e61b@default>

Hi All,

 

Please review the test only fix for JDK 11.

 

Bug:

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

 

webrev:

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

 

Issue:

In windows 10, the "External Drives" or "Removable drives" names are empty when root directory "Desktop" is selected in JFileChooser. Only the icon is shown and name is empty.

Fix:

The system folder names are found by calling FileSystemView.getSystemDisplayName, which in turn calls  Win32ShellFolderManager2.isFileSystemRoot. Here it was wrongly assumed that a drive will always be child of "DRIVES" or "MY PC". But in windows 10, the external drives are also shown as children of root directory "Desktop". Made changes to consider drives names which are children of "Desktop".

 

Note:

This is a windows 10 specific issues. 

You will need an removable drive attached to you system to test this.

 

Regards,

Pankaj Bansal

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

From pankaj.b.bansal at oracle.com  Mon Mar 12 14:59:37 2018
From: pankaj.b.bansal at oracle.com (Pankaj Bansal)
Date: Mon, 12 Mar 2018 07:59:37 -0700 (PDT)
Subject: <Swing Dev> [11] Review Request: JDK-7108280 :
 JList.getSelectedValuesList fails if JList.setSelectionInterval larger than
 list
Message-ID: <1185695b-4d45-4c89-9ebb-2d2a4a29328d@default>

Hi All,

Changing the subject to update the fix version to 11 to avoid any confusion.

Regards,
Pankaj Bansal

-----Original Message-----
From: Pankaj Bansal 
Sent: Friday, March 9, 2018 9:59 PM
To: Semyon Sadetsky; 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 Semyon,

Thanks for the review.

<< Where this fix should go? In 10?
This will go in 11. Actually this is pending from sometime and I have to change the fix version. Should I send a new request for this (once the review is approved) or just update the information here.

<< How does this fix correspond to the 8074286 change you've just posted where IOOBE is thrown again?
These two fixes address same piece of code. I will update the webrev for 8074286 if this fix goes first. Basically I will have to resolve the changes depending upon which fix will go first.

Regards,
Pankaj Bansal

-----Original Message-----
From: Semyon Sadetsky
Sent: Friday, March 9, 2018 9:44 PM
To: Pankaj Bansal; 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 Pankaj,

Where this fix should go? In 10?
How does this fix correspond to the 8074286 change you've just posted where IOOBE is thrown again?

On 03/08/2018 09:47 PM, Pankaj Bansal wrote:
> Hi Semyon,
>
> <<what will be the return from JList.getSelectedIndices()  in the issue scenario?
> I have not made any changes to JList.getSelectedIndices method. It will return the selected indices in selection model.
Then there will be discrepancy between getSelectedValues**() and
getSelectedIndices() of the same list.

--Semyon
>
> Regards,
> Pankaj Bansal
>
> -----Original Message-----
> From: Semyon Sadetsky
> Sent: Friday, March 9, 2018 7:17 AM
> To: Pankaj Bansal; 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 Pankaj,
>
> what will be the return from JList.getSelectedIndices()? in the issue scenario?
>
> --Semyon
>
> On 01/03/2018 03:53 AM, Pankaj Bansal wrote:
>
>> 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 Sergey.Bylokhov at oracle.com  Tue Mar 13 05:27:17 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 12 Mar 2018 22:27:17 -0700
Subject: <Swing Dev> [11] Review Request: 8198342 Test
 FileSystemViewListenerLeak.java is unstable
Message-ID: <fc43100e-ad12-5a01-52f4-a19a97b0a88e@oracle.com>

Hello.
Please review the update of the test for jdk11.

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

This test creates a number of FileSystemView which internally register a 
listeners in UIManager, and the test assumes that these listeners will 
be removed when FileSystemView will be collected by GC.(The listener 
itself is removed by the Cleaner which uses a separate thread).

The problem is that in the high-loaded systems when the test is executed 
in parallel with many other heavyweight tests the cleaner's thread is 
not always able to remove the listeners in time and test fails.

In the fix the umber of FileSystemView in the test is decreased to 1, I 
have checked that the test still fail before related bug(JDK-8175968) 
was fixed.


-- 
Best regards, Sergey.


From prasanta.sadhukhan at oracle.com  Tue Mar 13 08:10:18 2018
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Tue, 13 Mar 2018 13:40:18 +0530
Subject: <Swing Dev> [11] [JDK-8074286] : Add getSelectedIndices() to
 ListSelectionModel
In-Reply-To: <314fb4ba-48b6-e3b7-6556-60ddc9934478@oracle.com>
References: <2730e768-abde-4e00-bb0f-b0481aae10ae@default>
 <314fb4ba-48b6-e3b7-6556-60ddc9934478@oracle.com>
Message-ID: <ed9a8206-362c-9fb8-dbeb-aacd9300c09b@oracle.com>

Hi Pankaj,

Looks good to me, only thing I have some reservations is 
JList.getSelectedValues is deprecated since jdk7, so in my opinion, we 
should not modify it. Please add noreg-cleanup label to JBS.

Regards
Prasanta
On 3/9/2018 6:47 AM, Sergey Bylokhov wrote:
> Hi, Pankaj.
> The fix looks fine, please add @since tag for the new methods in CSR.
>
> On 02/02/2018 09:06, Pankaj Bansal wrote:
>> Hi All,
>>
>> Please review a fix for the Enhancement. I will raise a CSR after 
>> technical evaluation.
>>
>> Enhancement:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8074286
>>
>> Webrev:
>>
>> http://cr.openjdk.java.net/~pbansal/8074286/webrev.00/
>>
>> The enhancement requests to add getSelectedIndices function to 
>> ListSelectionModel Interface as same function with duplicate 
>> implementation is being used in JList, JTable and 
>> DefaultTableColumnModel.
>>
>> I have also added the getSelectedItemsCount function in 
>> ListSelectionModel, as this is also being used at multiple places 
>> with same implementation.
>>
>> JList.getSelectedValues and JList.getSelectedValuesList are also 
>> modified to use getSelectionIndices instead of replicating the same 
>> code.
>>
>> Regards,
>>
>> Pankaj Bansal
>>
>
>



From manajit.halder at oracle.com  Tue Mar 13 09:56:14 2018
From: manajit.halder at oracle.com (Manajit Halder)
Date: Tue, 13 Mar 2018 15:26:14 +0530
Subject: <Swing Dev> swing-dev Digest, Vol 131, Issue 17
In-Reply-To: <mailman.49172.1520445676.26058.swing-dev@openjdk.java.net>
References: <mailman.49172.1520445676.26058.swing-dev@openjdk.java.net>
Message-ID: <06969865-4DDF-4A83-A9D8-3598C70B64EF@oracle.com>

Looks good to me.

Regards,
Manajit

> 
> From: Krishna Addepalli <krishna.addepalli at oracle.com <mailto:krishna.addepalli at oracle.com>>
> Subject: Re: <Swing Dev> [11][JDK-8195095]Images are not scaled correctly in JEditorPane
> Date: 7 March 2018 at 9:48:44 PM IST
> To: Semyon Sadetsky <semyon.sadetsky at oracle.com <mailto:semyon.sadetsky at oracle.com>>, Prasanta Sadhukhan <prasanta.sadhukhan at oracle.com <mailto:prasanta.sadhukhan at oracle.com>>, swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>
> 
> 
> Hi Semyon,
>  
> To reduce the possibility of the test passing / failing due to wrong reasons, I have changed the color of the image to blue, and updated the test accordingly.
> Here is the new webrev: http://cr.openjdk.java.net/~kaddepalli/8195095/webrev02 <http://cr.openjdk.java.net/~kaddepalli/8195095/webrev02>
>  
> Thanks,
> Krishna
> ? <>
> From: Krishna Addepalli 
> Sent: Monday, March 5, 2018 11:59 PM
> To: Semyon Sadetsky <semyon.sadetsky at oracle.com <mailto:semyon.sadetsky at oracle.com>>; Prasanta Sadhukhan <prasanta.sadhukhan at oracle.com <mailto:prasanta.sadhukhan at oracle.com>>; swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>
> Subject: RE: <Swing Dev> [11][JDK-8195095]Images are not scaled correctly in JEditorPane
>  
> I tried on Ubuntu 17.10, but since the getPixelColor always returns black, the test will pass, which is why I was asking.
>  
> Thanks,
> Krishna
>  
> From: Semyon Sadetsky 
> Sent: Monday, March 5, 2018 11:57 PM
> To: Krishna Addepalli <krishna.addepalli at oracle.com <mailto:krishna.addepalli at oracle.com>>; Prasanta Sadhukhan <prasanta.sadhukhan at oracle.com <mailto:prasanta.sadhukhan at oracle.com>>; swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>
> Subject: Re: <Swing Dev> [11][JDK-8195095]Images are not scaled correctly in JEditorPane
>  
> On 03/05/2018 10:23 AM, Krishna Addepalli wrote:
> 
> Hi Semyon,
>  
> Did you try it in Windows or Linux? I have tested it on Mac, and found that it fails before the fix and passes after the fix.
> I tried it on Linux. But the change is in generic code why the test result depends on the platform?
> 
> --Semyon
> 
>  
> Thanks,
> Krishna
>  
> From: Semyon Sadetsky 
> Sent: Monday, March 5, 2018 10:01 PM
> To: Krishna Addepalli <krishna.addepalli at oracle.com> <mailto:krishna.addepalli at oracle.com>; Prasanta Sadhukhan <prasanta.sadhukhan at oracle.com> <mailto:prasanta.sadhukhan at oracle.com>; swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>
> Subject: Re: <Swing Dev> [11][JDK-8195095]Images are not scaled correctly in JEditorPane
>  
> Hi Krishna,
> 
> I tried your test before the fix and it passed.
> 
> --Semyon
> 
>  
> On 03/03/2018 12:07 AM, Krishna Addepalli wrote:
> Hi Prasanta,
>  
> Thanks for the quick review. I have updated the testcase with your suggestion. Here it is: http://cr.openjdk.java.net/~kaddepalli/8195095/webrev01 <http://cr.openjdk.java.net/%7Ekaddepalli/8195095/webrev01>
>  
> Krishna
>  
> From: Prasanta Sadhukhan 
> Sent: Saturday, March 3, 2018 1:06 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> [11][JDK-8195095]Images are not scaled correctly in JEditorPane
>  
> looks good to me. 
> 
> Only thing, in test, JFrame creation also needs to be in EDT.
> 
> Regards
> Prasanta
> On 3/3/2018 12:40 PM, Krishna Addepalli wrote:
> Hi All,
>  
> Please review a fix for JDK-8195095: https://bugs.openjdk.java.net/browse/JDK-8195095 <https://bugs.openjdk.java.net/browse/JDK-8195095>
>  
> Webrev: http://cr.openjdk.java.net/~kaddepalli/8195095/webrev00 <http://cr.openjdk.java.net/%7Ekaddepalli/8195095/webrev00>
>  
> Problem: When a text html is specified with an image, omitting either the height/width parameter, JEditorPane scales it to default value of the missing parameter, whereas it should fetch the actual value from the image.
>  
> Fix: The problem is in ImageView.java. In the imageUpdate function, in the resizing logic the ?changed? flag is set to 1 if height is present, and to 2 if width is present. But while updating the width, the check is swapped, i.e width is set if flag is 1 and vice versa.
>  
> PS: The webrev contains a new ?circle.png? file, so when you import the patch, you may need to manually copy the file, since ?hg import? doesnot automatically import the .png files from the patch file.
>  
> Thanks
> Krishna
>  
>  
>  
> 
> 
> 
> 
> On 07/03/2018 08:19, Krishna Addepalli wrote:
>> Thanks for the review Semyon!
>> 
>> -----Original Message-----
>> From: Semyon Sadetsky
>> Sent: Wednesday, March 7, 2018 9:27 PM
>> To: Krishna Addepalli <krishna.addepalli at oracle.com <mailto:krishna.addepalli at oracle.com>>; Philip Race <philip.race at oracle.com <mailto:philip.race at oracle.com>>
>> Cc: swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>
>> Subject: Re: <Swing Dev> [11][JDK-8197785]javax.accessibility.AccessibilityBundle will reload the ResourceBundle for every call to toDisplayString
>> 
>> +1
>> 
>> --Semyon
>> 
>> 
>> On 3/7/18 5:28 AM, Krishna Addepalli wrote:
>>> Hi Semyon,
>>> 
>>> Modified the code as per your suggestions. Here is the new webrev:
>>> http://cr.openjdk.java.net/~kaddepalli/8197785/webrev02 <http://cr.openjdk.java.net/~kaddepalli/8197785/webrev02>
>>> 
>>> Thanks,
>>> Krishna
>>> 
>>> -----Original Message-----
>>> From: Semyon Sadetsky
>>> Sent: Tuesday, March 6, 2018 11:46 PM
>>> To: Phil Race <philip.race at oracle.com <mailto:philip.race at oracle.com>>; Krishna Addepalli
>>> <krishna.addepalli at oracle.com <mailto:krishna.addepalli at oracle.com>>
>>> Cc: swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>
>>> Subject: Re: <Swing Dev>
>>> [11][JDK-8197785]javax.accessibility.AccessibilityBundle will reload
>>> the ResourceBundle for every call to toDisplayString
>>> 
>>> On 03/06/2018 10:01 AM, Phil Race wrote:
>>> 
>>>> 
>>>> On 03/06/2018 09:45 AM, Semyon Sadetsky wrote:
>>>>> Can you point to place where this Hashmap is updated other then
>>>>> where it is initialized?
>>>> You mean Hashtable ?
>>> Right, sorry.
>>>>   161                 table.put(locale, resourceTable);
>>>> 
>>>> Will be executed once per locale.
>>> It updates "table" not "resourceTable". The "table" field could be treated differently since writing in it really very rare but it is ok to leave it as it is. All what I meant concerned only the "resourceTable".
>>> 
>>> --Semyon
>>>> -phil.
>>>> 
>> 
> 
> 
> -- 
> Best regards, Sergey.
> 
> 
> 
> 
> 
>> Hi, Krishna.
>> The .02 version of the fix have changed the behavior of 
>> toDisplayString() method. Before the fix it throws NPE for key=null, 
>> after the fix it returns null. 
> That's ok. It is an improvement. NPE is not expected result according to 
> the toDisplayString() method spec.
> 
> --Semyon
> 
>> I guess version .01 should be fine as it simple and supposed to fix 
>> one reported bug.
>> 
>> On 07/03/2018 08:19, Krishna Addepalli wrote:
>>> Thanks for the review Semyon!
>>> 
>>> -----Original Message-----
>>> From: Semyon Sadetsky
>>> Sent: Wednesday, March 7, 2018 9:27 PM
>>> To: Krishna Addepalli <krishna.addepalli at oracle.com <mailto:krishna.addepalli at oracle.com>>; Philip Race 
>>> <philip.race at oracle.com <mailto:philip.race at oracle.com>>
>>> Cc: swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>
>>> Subject: Re: <Swing Dev> 
>>> [11][JDK-8197785]javax.accessibility.AccessibilityBundle will reload 
>>> the ResourceBundle for every call to toDisplayString
>>> 
>>> +1
>>> 
>>> --Semyon
>>> 
>>> 
>>> On 3/7/18 5:28 AM, Krishna Addepalli wrote:
>>>> Hi Semyon,
>>>> 
>>>> Modified the code as per your suggestions. Here is the new webrev:
>>>> http://cr.openjdk.java.net/~kaddepalli/8197785/webrev02 <http://cr.openjdk.java.net/~kaddepalli/8197785/webrev02>
>>>> 
>>>> Thanks,
>>>> Krishna
>>>> 
>>>> -----Original Message-----
>>>> From: Semyon Sadetsky
>>>> Sent: Tuesday, March 6, 2018 11:46 PM
>>>> To: Phil Race <philip.race at oracle.com <mailto:philip.race at oracle.com>>; Krishna Addepalli
>>>> <krishna.addepalli at oracle.com <mailto:krishna.addepalli at oracle.com>>
>>>> Cc: swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>
>>>> Subject: Re: <Swing Dev>
>>>> [11][JDK-8197785]javax.accessibility.AccessibilityBundle will reload
>>>> the ResourceBundle for every call to toDisplayString
>>>> 
>>>> On 03/06/2018 10:01 AM, Phil Race wrote:
>>>> 
>>>>> 
>>>>> On 03/06/2018 09:45 AM, Semyon Sadetsky wrote:
>>>>>> Can you point to place where this Hashmap is updated other then
>>>>>> where it is initialized?
>>>>> You mean Hashtable ?
>>>> Right, sorry.
>>>>>   161 table.put(locale, resourceTable);
>>>>> 
>>>>> Will be executed once per locale.
>>>> It updates "table" not "resourceTable". The "table" field could be 
>>>> treated differently since writing in it really very rare but it is 
>>>> ok to leave it as it is. All what I meant concerned only the 
>>>> "resourceTable".
>>>> 
>>>> --Semyon
>>>>> -phil.
>>>>> 
>>> 
>> 
>> 
> 
> 
> 
> 

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

From krishna.addepalli at oracle.com  Tue Mar 13 14:15:33 2018
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Tue, 13 Mar 2018 07:15:33 -0700 (PDT)
Subject: <Swing Dev> [11][JDK-8195095]Images are not scaled correctly in
 JEditorPane
In-Reply-To: <a235cb60-1e7a-4785-925b-b09e3fa9e923@default>
References: <d8dc441e-4025-489b-86d4-6bd8df5e4fba@default>
 <c6d33e58-fa7e-09dd-a2dd-fbc4e5c864b1@oracle.com>
 <7325ffb8-4b61-498b-8405-7d771bdfca0d@default>
 <8922c58d-6f8d-f0b0-de2f-cc57832d42c1@oracle.com>
 <3ea361c1-3591-4f0a-9466-ed14c520538f@default>
 <e71f11a2-9b38-1bb8-5f9c-3a9e8344f5d5@oracle.com>
 <580cb1f1-2ea1-401a-85e7-e4d37f84279a@default>
 <a235cb60-1e7a-4785-925b-b09e3fa9e923@default>
Message-ID: <3dac9625-9ce3-431a-ad94-4a049c6fdd55@default>

Hi Semyon,

 

I have tested the new webrev on Ubuntu 17.10, and it fails before the fix and passes after the fix.

Did you get a chance to check this?

 

Thanks,

Krishna

 

From: Krishna Addepalli 
Sent: Wednesday, March 7, 2018 9:49 PM
To: Semyon Sadetsky <semyon.sadetsky at oracle.com>; Prasanta Sadhukhan <prasanta.sadhukhan at oracle.com>; swing-dev at openjdk.java.net
Subject: RE: <Swing Dev> [11][JDK-8195095]Images are not scaled correctly in JEditorPane

 

Hi Semyon,

 

To reduce the possibility of the test passing / failing due to wrong reasons, I have changed the color of the image to blue, and updated the test accordingly.

Here is the new webrev: http://cr.openjdk.java.net/~kaddepalli/8195095/webrev02

 

Thanks,

Krishna

 

From: Krishna Addepalli 
Sent: Monday, March 5, 2018 11:59 PM
To: Semyon Sadetsky <HYPERLINK "mailto:semyon.sadetsky at oracle.com"semyon.sadetsky at oracle.com>; Prasanta Sadhukhan <HYPERLINK "mailto:prasanta.sadhukhan at oracle.com"prasanta.sadhukhan at oracle.com>; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: RE: <Swing Dev> [11][JDK-8195095]Images are not scaled correctly in JEditorPane

 

I tried on Ubuntu 17.10, but since the getPixelColor always returns black, the test will pass, which is why I was asking.

 

Thanks,

Krishna

 

From: Semyon Sadetsky 
Sent: Monday, March 5, 2018 11:57 PM
To: Krishna Addepalli <HYPERLINK "mailto:krishna.addepalli at oracle.com"krishna.addepalli at oracle.com>; Prasanta Sadhukhan <HYPERLINK "mailto:prasanta.sadhukhan at oracle.com"prasanta.sadhukhan at oracle.com>; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [11][JDK-8195095]Images are not scaled correctly in JEditorPane

 

On 03/05/2018 10:23 AM, Krishna Addepalli wrote:

Hi Semyon,

 

Did you try it in Windows or Linux? I have tested it on Mac, and found that it fails before the fix and passes after the fix.

I tried it on Linux. But the change is in generic code why the test result depends on the platform?

--Semyon

 

Thanks,

Krishna

 

From: Semyon Sadetsky 
Sent: Monday, March 5, 2018 10:01 PM
To: Krishna Addepalli HYPERLINK "mailto:krishna.addepalli at oracle.com"<krishna.addepalli at oracle.com>; Prasanta Sadhukhan HYPERLINK "mailto:prasanta.sadhukhan at oracle.com"<prasanta.sadhukhan at oracle.com>; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [11][JDK-8195095]Images are not scaled correctly in JEditorPane

 

Hi Krishna,

I tried your test before the fix and it passed.

--Semyon

 

On 03/03/2018 12:07 AM, Krishna Addepalli wrote:

Hi Prasanta,

 

Thanks for the quick review. I have updated the testcase with your suggestion. Here it is: HYPERLINK "http://cr.openjdk.java.net/%7Ekaddepalli/8195095/webrev01"http://cr.openjdk.java.net/~kaddepalli/8195095/webrev01

 

Krishna

 

From: Prasanta Sadhukhan 
Sent: Saturday, March 3, 2018 1:06 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> [11][JDK-8195095]Images are not scaled correctly in JEditorPane

 

looks good to me. 

Only thing, in test, JFrame creation also needs to be in EDT.

Regards
Prasanta

On 3/3/2018 12:40 PM, Krishna Addepalli wrote:

Hi All,

 

Please review a fix for JDK-8195095: https://bugs.openjdk.java.net/browse/JDK-8195095

 

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

 

Problem: When a text html is specified with an image, omitting either the height/width parameter, JEditorPane scales it to default value of the missing parameter, whereas it should fetch the actual value from the image.

 

Fix: The problem is in ImageView.java. In the imageUpdate function, in the resizing logic the "changed" flag is set to 1 if height is present, and to 2 if width is present. But while updating the width, the check is swapped, i.e width is set if flag is 1 and vice versa.

 

PS: The webrev contains a new "circle.png" file, so when you import the patch, you may need to manually copy the file, since "hg import" doesnot automatically import the .png files from the patch file.

 

Thanks

Krishna

 

 

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

From semyon.sadetsky at oracle.com  Tue Mar 13 17:51:39 2018
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Tue, 13 Mar 2018 10:51:39 -0700
Subject: <Swing Dev> [11][JDK-8195095]Images are not scaled correctly in
 JEditorPane
In-Reply-To: <3dac9625-9ce3-431a-ad94-4a049c6fdd55@default>
References: <d8dc441e-4025-489b-86d4-6bd8df5e4fba@default>
 <c6d33e58-fa7e-09dd-a2dd-fbc4e5c864b1@oracle.com>
 <7325ffb8-4b61-498b-8405-7d771bdfca0d@default>
 <8922c58d-6f8d-f0b0-de2f-cc57832d42c1@oracle.com>
 <3ea361c1-3591-4f0a-9466-ed14c520538f@default>
 <e71f11a2-9b38-1bb8-5f9c-3a9e8344f5d5@oracle.com>
 <580cb1f1-2ea1-401a-85e7-e4d37f84279a@default>
 <a235cb60-1e7a-4785-925b-b09e3fa9e923@default>
 <3dac9625-9ce3-431a-ad94-4a049c6fdd55@default>
Message-ID: <4fbe71bd-603d-bdc7-99de-d937425b6354@oracle.com>

+1

--Semyon


On 03/13/2018 07:15 AM, Krishna Addepalli wrote:
>
> Hi Semyon,
>
> I have tested the new webrev on Ubuntu 17.10, and it fails before the 
> fix and passes after the fix.
>
> Did you get a chance to check this?
>
> Thanks,
>
> Krishna
>
> *From:*Krishna Addepalli
> *Sent:* Wednesday, March 7, 2018 9:49 PM
> *To:* Semyon Sadetsky <semyon.sadetsky at oracle.com>; Prasanta Sadhukhan 
> <prasanta.sadhukhan at oracle.com>; swing-dev at openjdk.java.net
> *Subject:* RE: <Swing Dev> [11][JDK-8195095]Images are not scaled 
> correctly in JEditorPane
>
> Hi Semyon,
>
> To reduce the possibility of the test passing / failing due to wrong 
> reasons, I have changed the color of the image to blue, and updated 
> the test accordingly.
>
> Here is the new webrev: 
> http://cr.openjdk.java.net/~kaddepalli/8195095/webrev02 
> <http://cr.openjdk.java.net/%7Ekaddepalli/8195095/webrev02>
>
> Thanks,
>
> Krishna
>
> *From:*Krishna Addepalli
> *Sent:* Monday, March 5, 2018 11:59 PM
> *To:* Semyon Sadetsky <semyon.sadetsky at oracle.com 
> <mailto:semyon.sadetsky at oracle.com>>; Prasanta Sadhukhan 
> <prasanta.sadhukhan at oracle.com 
> <mailto:prasanta.sadhukhan at oracle.com>>; swing-dev at openjdk.java.net 
> <mailto:swing-dev at openjdk.java.net>
> *Subject:* RE: <Swing Dev> [11][JDK-8195095]Images are not scaled 
> correctly in JEditorPane
>
> I tried on Ubuntu 17.10, but since the getPixelColor always returns 
> black, the test will pass, which is why I was asking.
>
> Thanks,
>
> Krishna
>
> *From:*Semyon Sadetsky
> *Sent:* Monday, March 5, 2018 11:57 PM
> *To:* Krishna Addepalli <krishna.addepalli at oracle.com 
> <mailto:krishna.addepalli at oracle.com>>; Prasanta Sadhukhan 
> <prasanta.sadhukhan at oracle.com 
> <mailto:prasanta.sadhukhan at oracle.com>>; swing-dev at openjdk.java.net 
> <mailto:swing-dev at openjdk.java.net>
> *Subject:* Re: <Swing Dev> [11][JDK-8195095]Images are not scaled 
> correctly in JEditorPane
>
> On 03/05/2018 10:23 AM, Krishna Addepalli wrote:
>
>     Hi Semyon,
>
>     Did you try it in Windows or Linux? I have tested it on Mac, and
>     found that it fails before the fix and passes after the fix.
>
> I tried it on Linux. But the change is in generic code why the test 
> result depends on the platform?
>
> --Semyon
>
>     Thanks,
>
>     Krishna
>
>     *From:*Semyon Sadetsky
>     *Sent:* Monday, March 5, 2018 10:01 PM
>     *To:* Krishna Addepalli <krishna.addepalli at oracle.com>
>     <mailto:krishna.addepalli at oracle.com>; Prasanta Sadhukhan
>     <prasanta.sadhukhan at oracle.com>
>     <mailto:prasanta.sadhukhan at oracle.com>; swing-dev at openjdk.java.net
>     <mailto:swing-dev at openjdk.java.net>
>     *Subject:* Re: <Swing Dev> [11][JDK-8195095]Images are not scaled
>     correctly in JEditorPane
>
>     Hi Krishna,
>
>     I tried your test before the fix and it passed.
>
>     --Semyon
>
>     On 03/03/2018 12:07 AM, Krishna Addepalli wrote:
>
>         Hi Prasanta,
>
>         Thanks for the quick review. I have updated the testcase with
>         your suggestion. Here it is:
>         http://cr.openjdk.java.net/~kaddepalli/8195095/webrev01
>         <http://cr.openjdk.java.net/%7Ekaddepalli/8195095/webrev01>
>
>         Krishna
>
>         *From:*Prasanta Sadhukhan
>         *Sent:* Saturday, March 3, 2018 1:06 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> [11][JDK-8195095]Images are not
>         scaled correctly in JEditorPane
>
>         looks good to me.
>
>         Only thing, in test, JFrame creation also needs to be in EDT.
>
>         Regards
>         Prasanta
>
>         On 3/3/2018 12:40 PM, Krishna Addepalli wrote:
>
>             Hi All,
>
>             Please review a fix for JDK-8195095:
>             https://bugs.openjdk.java.net/browse/JDK-8195095
>
>             Webrev:
>             http://cr.openjdk.java.net/~kaddepalli/8195095/webrev00
>             <http://cr.openjdk.java.net/%7Ekaddepalli/8195095/webrev00>
>
>             Problem: When a text html is specified with an image,
>             omitting either the height/width parameter, JEditorPane
>             scales it to default value of the missing parameter,
>             whereas it should fetch the actual value from the image.
>
>             Fix: The problem is in ImageView.java. In the imageUpdate
>             function, in the resizing logic the ?changed? flag is set
>             to 1 if height is present, and to 2 if width is present.
>             But while updating the width, the check is swapped, i.e
>             width is set if flag is 1 and vice versa.
>
>             PS: The webrev contains a new ?circle.png? file, so when
>             you import the patch, you may need to manually copy the
>             file, since ?hg import? doesnot automatically import the
>             .png files from the patch file.
>
>             Thanks
>
>             Krishna
>

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

From pankaj.b.bansal at oracle.com  Wed Mar 14 00:14:15 2018
From: pankaj.b.bansal at oracle.com (Pankaj Bansal)
Date: Tue, 13 Mar 2018 17:14:15 -0700 (PDT)
Subject: <Swing Dev> [11] Review Request: JDK-7108280 :
 JList.getSelectedValuesList fails if JList.setSelectionInterval larger than
 list
In-Reply-To: <1185695b-4d45-4c89-9ebb-2d2a4a29328d@default>
References: <1185695b-4d45-4c89-9ebb-2d2a4a29328d@default>
Message-ID: <8504ed57-f95c-4bff-a632-3b966f8bd564@default>

Hi Semyon,

Do you have any further questions regarding this?

Regards,
Pankaj Bansal

-----Original Message-----
From: Pankaj Bansal 
Sent: Monday, March 12, 2018 8:30 PM
To: Semyon Sadetsky; swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [11] Review Request: JDK-7108280 : JList.getSelectedValuesList fails if JList.setSelectionInterval larger than list

Hi All,

Changing the subject to update the fix version to 11 to avoid any confusion.

Regards,
Pankaj Bansal

-----Original Message-----
From: Pankaj Bansal
Sent: Friday, March 9, 2018 9:59 PM
To: Semyon Sadetsky; 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 Semyon,

Thanks for the review.

<< Where this fix should go? In 10?
This will go in 11. Actually this is pending from sometime and I have to change the fix version. Should I send a new request for this (once the review is approved) or just update the information here.

<< How does this fix correspond to the 8074286 change you've just posted where IOOBE is thrown again?
These two fixes address same piece of code. I will update the webrev for 8074286 if this fix goes first. Basically I will have to resolve the changes depending upon which fix will go first.

Regards,
Pankaj Bansal

-----Original Message-----
From: Semyon Sadetsky
Sent: Friday, March 9, 2018 9:44 PM
To: Pankaj Bansal; 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 Pankaj,

Where this fix should go? In 10?
How does this fix correspond to the 8074286 change you've just posted where IOOBE is thrown again?

On 03/08/2018 09:47 PM, Pankaj Bansal wrote:
> Hi Semyon,
>
> <<what will be the return from JList.getSelectedIndices()  in the issue scenario?
> I have not made any changes to JList.getSelectedIndices method. It will return the selected indices in selection model.
Then there will be discrepancy between getSelectedValues**() and
getSelectedIndices() of the same list.

--Semyon
>
> Regards,
> Pankaj Bansal
>
> -----Original Message-----
> From: Semyon Sadetsky
> Sent: Friday, March 9, 2018 7:17 AM
> To: Pankaj Bansal; 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 Pankaj,
>
> what will be the return from JList.getSelectedIndices()? in the issue scenario?
>
> --Semyon
>
> On 01/03/2018 03:53 AM, Pankaj Bansal wrote:
>
>> 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 krishna.addepalli at oracle.com  Wed Mar 14 08:24:38 2018
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Wed, 14 Mar 2018 01:24:38 -0700 (PDT)
Subject: <Swing Dev> [11] Review Request: JDK-7108280 :
 JList.getSelectedValuesList fails if JList.setSelectionInterval larger than
 list
In-Reply-To: <8504ed57-f95c-4bff-a632-3b966f8bd564@default>
References: <1185695b-4d45-4c89-9ebb-2d2a4a29328d@default>
 <8504ed57-f95c-4bff-a632-3b966f8bd564@default>
Message-ID: <a8ba1637-9821-4b79-b188-2e3bbcdd1f7d@default>

Hi Pankaj,

The fix looks good to me. 
However I have some suggestions for your fix:
        if ((iMin < 0) || (iMax < 0)) {
             return new Object[0];
         }
 
         int size = dm.getSize();
         if (iMin > size) {
             return new Object[]{};
         }
         iMax = iMax < size ? iMax : size - 1;

Instead of repeating the if condition and the statement within, move the condition into to the top if, so that it looks like this:
	If((iMin < 0) || (iMax < 0) || (iMin > size)) {
		Return new Object[0];
	}
And move the size declaration to the top.

Also, in the GetSelectedValuesListTest.java test case, you have two different functions - namely checkSelectionByList and checkSelectionByArray. They are identical except the api they call and the collection they take as parameter. 
You can make it as a single function.

Thanks,
Krishna

-----Original Message-----
From: Pankaj Bansal 
Sent: Wednesday, March 14, 2018 5:44 AM
To: Semyon Sadetsky <semyon.sadetsky at oracle.com>; swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [11] Review Request: JDK-7108280 : JList.getSelectedValuesList fails if JList.setSelectionInterval larger than list

Hi Semyon,

Do you have any further questions regarding this?

Regards,
Pankaj Bansal

-----Original Message-----
From: Pankaj Bansal
Sent: Monday, March 12, 2018 8:30 PM
To: Semyon Sadetsky; swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [11] Review Request: JDK-7108280 : JList.getSelectedValuesList fails if JList.setSelectionInterval larger than list

Hi All,

Changing the subject to update the fix version to 11 to avoid any confusion.

Regards,
Pankaj Bansal

-----Original Message-----
From: Pankaj Bansal
Sent: Friday, March 9, 2018 9:59 PM
To: Semyon Sadetsky; 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 Semyon,

Thanks for the review.

<< Where this fix should go? In 10?
This will go in 11. Actually this is pending from sometime and I have to change the fix version. Should I send a new request for this (once the review is approved) or just update the information here.

<< How does this fix correspond to the 8074286 change you've just posted where IOOBE is thrown again?
These two fixes address same piece of code. I will update the webrev for 8074286 if this fix goes first. Basically I will have to resolve the changes depending upon which fix will go first.

Regards,
Pankaj Bansal

-----Original Message-----
From: Semyon Sadetsky
Sent: Friday, March 9, 2018 9:44 PM
To: Pankaj Bansal; 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 Pankaj,

Where this fix should go? In 10?
How does this fix correspond to the 8074286 change you've just posted where IOOBE is thrown again?

On 03/08/2018 09:47 PM, Pankaj Bansal wrote:
> Hi Semyon,
>
> <<what will be the return from JList.getSelectedIndices()  in the issue scenario?
> I have not made any changes to JList.getSelectedIndices method. It will return the selected indices in selection model.
Then there will be discrepancy between getSelectedValues**() and
getSelectedIndices() of the same list.

--Semyon
>
> Regards,
> Pankaj Bansal
>
> -----Original Message-----
> From: Semyon Sadetsky
> Sent: Friday, March 9, 2018 7:17 AM
> To: Pankaj Bansal; 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 Pankaj,
>
> what will be the return from JList.getSelectedIndices()? in the issue scenario?
>
> --Semyon
>
> On 01/03/2018 03:53 AM, Pankaj Bansal wrote:
>
>> 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 pankaj.b.bansal at oracle.com  Wed Mar 14 11:29:51 2018
From: pankaj.b.bansal at oracle.com (Pankaj Bansal)
Date: Wed, 14 Mar 2018 04:29:51 -0700 (PDT)
Subject: <Swing Dev> [11] Review Request: JDK-7108280 :
 JList.getSelectedValuesList fails if JList.setSelectionInterval larger than
 list
In-Reply-To: <a8ba1637-9821-4b79-b188-2e3bbcdd1f7d@default>
References: <1185695b-4d45-4c89-9ebb-2d2a4a29328d@default>
 <8504ed57-f95c-4bff-a632-3b966f8bd564@default>
 <a8ba1637-9821-4b79-b188-2e3bbcdd1f7d@default>
Message-ID: <661169c3-b974-4908-ad76-12bb710a9864@default>

Hi Krishna,

Thanks for the review.

I have incorporate the changes you suggested. Please have a look.
Webrev: 
http://cr.openjdk.java.net/~pbansal/7108280/webrev.02/

Regards,
Pankaj Bansal

-----Original Message-----
From: Krishna Addepalli 
Sent: Wednesday, March 14, 2018 1:55 PM
To: Pankaj Bansal; Semyon Sadetsky; swing-dev at openjdk.java.net
Subject: RE: <Swing Dev> [11] Review Request: JDK-7108280 : JList.getSelectedValuesList fails if JList.setSelectionInterval larger than list

Hi Pankaj,

The fix looks good to me. 
However I have some suggestions for your fix:
        if ((iMin < 0) || (iMax < 0)) {
             return new Object[0];
         }
 
         int size = dm.getSize();
         if (iMin > size) {
             return new Object[]{};
         }
         iMax = iMax < size ? iMax : size - 1;

Instead of repeating the if condition and the statement within, move the condition into to the top if, so that it looks like this:
	If((iMin < 0) || (iMax < 0) || (iMin > size)) {
		Return new Object[0];
	}
And move the size declaration to the top.

Also, in the GetSelectedValuesListTest.java test case, you have two different functions - namely checkSelectionByList and checkSelectionByArray. They are identical except the api they call and the collection they take as parameter. 
You can make it as a single function.

Thanks,
Krishna

-----Original Message-----
From: Pankaj Bansal
Sent: Wednesday, March 14, 2018 5:44 AM
To: Semyon Sadetsky <semyon.sadetsky at oracle.com>; swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [11] Review Request: JDK-7108280 : JList.getSelectedValuesList fails if JList.setSelectionInterval larger than list

Hi Semyon,

Do you have any further questions regarding this?

Regards,
Pankaj Bansal

-----Original Message-----
From: Pankaj Bansal
Sent: Monday, March 12, 2018 8:30 PM
To: Semyon Sadetsky; swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [11] Review Request: JDK-7108280 : JList.getSelectedValuesList fails if JList.setSelectionInterval larger than list

Hi All,

Changing the subject to update the fix version to 11 to avoid any confusion.

Regards,
Pankaj Bansal

-----Original Message-----
From: Pankaj Bansal
Sent: Friday, March 9, 2018 9:59 PM
To: Semyon Sadetsky; 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 Semyon,

Thanks for the review.

<< Where this fix should go? In 10?
This will go in 11. Actually this is pending from sometime and I have to change the fix version. Should I send a new request for this (once the review is approved) or just update the information here.

<< How does this fix correspond to the 8074286 change you've just posted where IOOBE is thrown again?
These two fixes address same piece of code. I will update the webrev for 8074286 if this fix goes first. Basically I will have to resolve the changes depending upon which fix will go first.

Regards,
Pankaj Bansal

-----Original Message-----
From: Semyon Sadetsky
Sent: Friday, March 9, 2018 9:44 PM
To: Pankaj Bansal; 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 Pankaj,

Where this fix should go? In 10?
How does this fix correspond to the 8074286 change you've just posted where IOOBE is thrown again?

On 03/08/2018 09:47 PM, Pankaj Bansal wrote:
> Hi Semyon,
>
> <<what will be the return from JList.getSelectedIndices()  in the issue scenario?
> I have not made any changes to JList.getSelectedIndices method. It will return the selected indices in selection model.
Then there will be discrepancy between getSelectedValues**() and
getSelectedIndices() of the same list.

--Semyon
>
> Regards,
> Pankaj Bansal
>
> -----Original Message-----
> From: Semyon Sadetsky
> Sent: Friday, March 9, 2018 7:17 AM
> To: Pankaj Bansal; 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 Pankaj,
>
> what will be the return from JList.getSelectedIndices()? in the issue scenario?
>
> --Semyon
>
> On 01/03/2018 03:53 AM, Pankaj Bansal wrote:
>
>> 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 krishna.addepalli at oracle.com  Wed Mar 14 11:33:30 2018
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Wed, 14 Mar 2018 04:33:30 -0700 (PDT)
Subject: <Swing Dev> [11] Review Request: JDK-7108280 :
 JList.getSelectedValuesList fails if JList.setSelectionInterval larger than
 list
In-Reply-To: <661169c3-b974-4908-ad76-12bb710a9864@default>
References: <1185695b-4d45-4c89-9ebb-2d2a4a29328d@default>
 <8504ed57-f95c-4bff-a632-3b966f8bd564@default>
 <a8ba1637-9821-4b79-b188-2e3bbcdd1f7d@default>
 <661169c3-b974-4908-ad76-12bb710a9864@default>
Message-ID: <0c6242c4-ab15-4d1c-afed-a1bca9772cc6@default>

Hi Pankaj,

The changes look fine.

Thanks,
Krishna

-----Original Message-----
From: Pankaj Bansal 
Sent: Wednesday, March 14, 2018 5:00 PM
To: Krishna Addepalli <krishna.addepalli at oracle.com>; swing-dev at openjdk.java.net
Subject: RE: <Swing Dev> [11] Review Request: JDK-7108280 : JList.getSelectedValuesList fails if JList.setSelectionInterval larger than list

Hi Krishna,

Thanks for the review.

I have incorporate the changes you suggested. Please have a look.
Webrev: 
http://cr.openjdk.java.net/~pbansal/7108280/webrev.02/

Regards,
Pankaj Bansal

-----Original Message-----
From: Krishna Addepalli
Sent: Wednesday, March 14, 2018 1:55 PM
To: Pankaj Bansal; Semyon Sadetsky; swing-dev at openjdk.java.net
Subject: RE: <Swing Dev> [11] Review Request: JDK-7108280 : JList.getSelectedValuesList fails if JList.setSelectionInterval larger than list

Hi Pankaj,

The fix looks good to me. 
However I have some suggestions for your fix:
        if ((iMin < 0) || (iMax < 0)) {
             return new Object[0];
         }
 
         int size = dm.getSize();
         if (iMin > size) {
             return new Object[]{};
         }
         iMax = iMax < size ? iMax : size - 1;

Instead of repeating the if condition and the statement within, move the condition into to the top if, so that it looks like this:
	If((iMin < 0) || (iMax < 0) || (iMin > size)) {
		Return new Object[0];
	}
And move the size declaration to the top.

Also, in the GetSelectedValuesListTest.java test case, you have two different functions - namely checkSelectionByList and checkSelectionByArray. They are identical except the api they call and the collection they take as parameter. 
You can make it as a single function.

Thanks,
Krishna

-----Original Message-----
From: Pankaj Bansal
Sent: Wednesday, March 14, 2018 5:44 AM
To: Semyon Sadetsky <semyon.sadetsky at oracle.com>; swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [11] Review Request: JDK-7108280 : JList.getSelectedValuesList fails if JList.setSelectionInterval larger than list

Hi Semyon,

Do you have any further questions regarding this?

Regards,
Pankaj Bansal

-----Original Message-----
From: Pankaj Bansal
Sent: Monday, March 12, 2018 8:30 PM
To: Semyon Sadetsky; swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [11] Review Request: JDK-7108280 : JList.getSelectedValuesList fails if JList.setSelectionInterval larger than list

Hi All,

Changing the subject to update the fix version to 11 to avoid any confusion.

Regards,
Pankaj Bansal

-----Original Message-----
From: Pankaj Bansal
Sent: Friday, March 9, 2018 9:59 PM
To: Semyon Sadetsky; 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 Semyon,

Thanks for the review.

<< Where this fix should go? In 10?
This will go in 11. Actually this is pending from sometime and I have to change the fix version. Should I send a new request for this (once the review is approved) or just update the information here.

<< How does this fix correspond to the 8074286 change you've just posted where IOOBE is thrown again?
These two fixes address same piece of code. I will update the webrev for 8074286 if this fix goes first. Basically I will have to resolve the changes depending upon which fix will go first.

Regards,
Pankaj Bansal

-----Original Message-----
From: Semyon Sadetsky
Sent: Friday, March 9, 2018 9:44 PM
To: Pankaj Bansal; 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 Pankaj,

Where this fix should go? In 10?
How does this fix correspond to the 8074286 change you've just posted where IOOBE is thrown again?

On 03/08/2018 09:47 PM, Pankaj Bansal wrote:
> Hi Semyon,
>
> <<what will be the return from JList.getSelectedIndices()  in the issue scenario?
> I have not made any changes to JList.getSelectedIndices method. It will return the selected indices in selection model.
Then there will be discrepancy between getSelectedValues**() and
getSelectedIndices() of the same list.

--Semyon
>
> Regards,
> Pankaj Bansal
>
> -----Original Message-----
> From: Semyon Sadetsky
> Sent: Friday, March 9, 2018 7:17 AM
> To: Pankaj Bansal; 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 Pankaj,
>
> what will be the return from JList.getSelectedIndices()? in the issue scenario?
>
> --Semyon
>
> On 01/03/2018 03:53 AM, Pankaj Bansal wrote:
>
>> 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 philip.race at oracle.com  Wed Mar 14 21:46:58 2018
From: philip.race at oracle.com (Phil Race)
Date: Wed, 14 Mar 2018 14:46:58 -0700
Subject: <Swing Dev> RFR: 8198897: Compilation errors in jdk.accessibility
	with VS 2017
Message-ID: <9362320d-bcb5-8aaf-4826-a2089a70c748@oracle.com>

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

Small fixes in the accessibility native code.
See the bug report for the warnings.

-phil.


From krishna.addepalli at oracle.com  Thu Mar 15 01:36:54 2018
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Wed, 14 Mar 2018 18:36:54 -0700 (PDT)
Subject: <Swing Dev> RFR: 8198897: Compilation errors in
 jdk.accessibility with VS 2017
In-Reply-To: <9362320d-bcb5-8aaf-4826-a2089a70c748@oracle.com>
References: <9362320d-bcb5-8aaf-4826-a2089a70c748@oracle.com>
Message-ID: <b6df5c2f-27e3-4aa7-b6e0-a97df2f659d7@default>

Hi Phil,

The changes look fine.
Although, in C++, it is recommended to use static_cast/dynamic_cast/reinterpret_cast rather than plain old C style cast.

Thanks,
Krishna

-----Original Message-----
From: Phil Race 
Sent: Thursday, March 15, 2018 3:17 AM
To: swing-dev at openjdk.java.net
Subject: <Swing Dev> RFR: 8198897: Compilation errors in jdk.accessibility with VS 2017

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

Small fixes in the accessibility native code.
See the bug report for the warnings.

-phil.


From pankaj.b.bansal at oracle.com  Thu Mar 15 11:04:55 2018
From: pankaj.b.bansal at oracle.com (Pankaj Bansal)
Date: Thu, 15 Mar 2018 04:04:55 -0700 (PDT)
Subject: <Swing Dev> [11] [JDK-8074286] : Add getSelectedIndices() to
 ListSelectionModel
In-Reply-To: <ed9a8206-362c-9fb8-dbeb-aacd9300c09b@oracle.com>
References: <2730e768-abde-4e00-bb0f-b0481aae10ae@default>
 <314fb4ba-48b6-e3b7-6556-60ddc9934478@oracle.com>
 <ed9a8206-362c-9fb8-dbeb-aacd9300c09b@oracle.com>
Message-ID: <ceae7200-cbfb-48ed-9af8-886687fe2c50@default>

Hi Sergey/Prasanta,

Thanks for the review.

I have incorporated the review comments given by Sergey, Prasanta and Joe (in the CSR).
I have created the CSR https://bugs.openjdk.java.net/browse/JDK-8199395. Please have a look at the CSR as well.

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

Regards,
Pankaj Bansal


-----Original Message-----
From: Prasanta Sadhukhan 
Sent: Tuesday, March 13, 2018 1:40 PM
To: Pankaj Bansal; swing-dev at openjdk.java.net
Cc: Sergey Bylokhov
Subject: Re: <Swing Dev> [11] [JDK-8074286] : Add getSelectedIndices() to ListSelectionModel

Hi Pankaj,

Looks good to me, only thing I have some reservations is JList.getSelectedValues is deprecated since jdk7, so in my opinion, we should not modify it. Please add noreg-cleanup label to JBS.

Regards
Prasanta
On 3/9/2018 6:47 AM, Sergey Bylokhov wrote:
> Hi, Pankaj.
> The fix looks fine, please add @since tag for the new methods in CSR.
>
> On 02/02/2018 09:06, Pankaj Bansal wrote:
>> Hi All,
>>
>> Please review a fix for the Enhancement. I will raise a CSR after 
>> technical evaluation.
>>
>> Enhancement:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8074286
>>
>> Webrev:
>>
>> http://cr.openjdk.java.net/~pbansal/8074286/webrev.00/
>>
>> The enhancement requests to add getSelectedIndices function to 
>> ListSelectionModel Interface as same function with duplicate 
>> implementation is being used in JList, JTable and 
>> DefaultTableColumnModel.
>>
>> I have also added the getSelectedItemsCount function in 
>> ListSelectionModel, as this is also being used at multiple places 
>> with same implementation.
>>
>> JList.getSelectedValues and JList.getSelectedValuesList are also 
>> modified to use getSelectionIndices instead of replicating the same 
>> code.
>>
>> Regards,
>>
>> Pankaj Bansal
>>
>
>



From prasanta.sadhukhan at oracle.com  Fri Mar 16 09:19:03 2018
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Fri, 16 Mar 2018 14:49:03 +0530
Subject: <Swing Dev> [11] [JDK-8074286] : Add getSelectedIndices() to
 ListSelectionModel
In-Reply-To: <ceae7200-cbfb-48ed-9af8-886687fe2c50@default>
References: <2730e768-abde-4e00-bb0f-b0481aae10ae@default>
 <314fb4ba-48b6-e3b7-6556-60ddc9934478@oracle.com>
 <ed9a8206-362c-9fb8-dbeb-aacd9300c09b@oracle.com>
 <ceae7200-cbfb-48ed-9af8-886687fe2c50@default>
Message-ID: <913a441b-c572-2df1-c382-3fa4f1ee3133@oracle.com>

+1

Regards
Prasanta
On 3/15/2018 4:34 PM, Pankaj Bansal wrote:
> Hi Sergey/Prasanta,
>
> Thanks for the review.
>
> I have incorporated the review comments given by Sergey, Prasanta and Joe (in the CSR).
> I have created the CSR https://bugs.openjdk.java.net/browse/JDK-8199395. Please have a look at the CSR as well.
>
> Webrev:
> http://cr.openjdk.java.net/~pbansal/8074286/webrev.01/
>
> Regards,
> Pankaj Bansal
>
>
> -----Original Message-----
> From: Prasanta Sadhukhan
> Sent: Tuesday, March 13, 2018 1:40 PM
> To: Pankaj Bansal; swing-dev at openjdk.java.net
> Cc: Sergey Bylokhov
> Subject: Re: <Swing Dev> [11] [JDK-8074286] : Add getSelectedIndices() to ListSelectionModel
>
> Hi Pankaj,
>
> Looks good to me, only thing I have some reservations is JList.getSelectedValues is deprecated since jdk7, so in my opinion, we should not modify it. Please add noreg-cleanup label to JBS.
>
> Regards
> Prasanta
> On 3/9/2018 6:47 AM, Sergey Bylokhov wrote:
>> Hi, Pankaj.
>> The fix looks fine, please add @since tag for the new methods in CSR.
>>
>> On 02/02/2018 09:06, Pankaj Bansal wrote:
>>> Hi All,
>>>
>>> Please review a fix for the Enhancement. I will raise a CSR after
>>> technical evaluation.
>>>
>>> Enhancement:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8074286
>>>
>>> Webrev:
>>>
>>> http://cr.openjdk.java.net/~pbansal/8074286/webrev.00/
>>>
>>> The enhancement requests to add getSelectedIndices function to
>>> ListSelectionModel Interface as same function with duplicate
>>> implementation is being used in JList, JTable and
>>> DefaultTableColumnModel.
>>>
>>> I have also added the getSelectedItemsCount function in
>>> ListSelectionModel, as this is also being used at multiple places
>>> with same implementation.
>>>
>>> JList.getSelectedValues and JList.getSelectedValuesList are also
>>> modified to use getSelectionIndices instead of replicating the same
>>> code.
>>>
>>> Regards,
>>>
>>> Pankaj Bansal
>>>
>>



From krishna.addepalli at oracle.com  Fri Mar 16 10:32:47 2018
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Fri, 16 Mar 2018 03:32:47 -0700 (PDT)
Subject: <Swing Dev> [11] JDK-8191957: JFileChooser shows empty name
Message-ID: <c796237f-069c-4f7a-ac43-2db74342b72a@default>

Hi Pankaj,

The fix looks fine to me. However I have couple points:

1. Please put a comment at the line of fix, about how Windows 10 treats the Desktop folder.
2. The test case can be a headless one, since you are not creating any gui components.

Thanks,
Krishna


-----Original Message-----
From: swing-dev-request at openjdk.java.net <swing-dev-request at openjdk.java.net> 
Sent: Monday, March 12, 2018 5:30 PM
To: swing-dev at openjdk.java.net
Subject: swing-dev Digest, Vol 131, Issue 25

Send swing-dev mailing list submissions to
	swing-dev at openjdk.java.net

To subscribe or unsubscribe via the World Wide Web, visit
	http://mail.openjdk.java.net/mailman/listinfo/swing-dev
or, via email, send a message with subject or body 'help' to
	swing-dev-request at openjdk.java.net

You can reach the person managing the list at
	swing-dev-owner at openjdk.java.net

When replying, please edit your Subject line so it is more specific than "Re: Contents of swing-dev digest..."


Today's Topics:

   1.  [11] JDK-8191957: JFileChooser shows empty name for external
      drives shown under Desktop (Pankaj Bansal)


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

Message: 1
Date: Mon, 12 Mar 2018 01:52:35 -0700 (PDT)
From: Pankaj Bansal <pankaj.b.bansal at oracle.com>
To: swing-dev at openjdk.java.net
Subject: <Swing Dev> [11] JDK-8191957: JFileChooser shows empty name
	for external drives shown under Desktop
Message-ID: <065d066f-810c-4284-9de6-059f4235e61b at default>
Content-Type: text/plain; charset="us-ascii"

Hi All,

 

Please review the test only fix for JDK 11.

 

Bug:

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

 	

webrev:

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

 

Issue:

In windows 10, the "External Drives" or "Removable drives" names are empty when root directory "Desktop" is selected in JFileChooser. Only the icon is shown and name is empty.

Fix:

The system folder names are found by calling FileSystemView.getSystemDisplayName, which in turn calls  Win32ShellFolderManager2.isFileSystemRoot. Here it was wrongly assumed that a drive will always be child of "DRIVES" or "MY PC". But in windows 10, the external drives are also shown as children of root directory "Desktop". Made changes to consider drives names which are children of "Desktop".

 

Note:

This is a windows 10 specific issues. 

You will need an removable drive attached to you system to test this.

 

Regards,

Pankaj Bansal

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

End of swing-dev Digest, Vol 131, Issue 25
******************************************


From pankaj.b.bansal at oracle.com  Fri Mar 16 11:11:47 2018
From: pankaj.b.bansal at oracle.com (Pankaj Bansal)
Date: Fri, 16 Mar 2018 04:11:47 -0700 (PDT)
Subject: <Swing Dev> [11] JDK-8191957: JFileChooser shows empty name
In-Reply-To: <c796237f-069c-4f7a-ac43-2db74342b72a@default>
References: <c796237f-069c-4f7a-ac43-2db74342b72a@default>
Message-ID: <6a7c2496-a678-44de-9e2b-e8d035d45e8c@default>

Hi Krishna,

Thanks for the review.

I have incorporated the review comments. Please have a look.
Webrev: http://cr.openjdk.java.net/~pbansal/8191957/webrev.01/

Regards,
Pankaj Bansal

-----Original Message-----
From: Krishna Addepalli 
Sent: Friday, March 16, 2018 4:03 PM
To: swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [11] JDK-8191957: JFileChooser shows empty name

Hi Pankaj,

The fix looks fine to me. However I have couple points:

1. Please put a comment at the line of fix, about how Windows 10 treats the Desktop folder.
2. The test case can be a headless one, since you are not creating any gui components.

Thanks,
Krishna


-----Original Message-----
From: swing-dev-request at openjdk.java.net <swing-dev-request at openjdk.java.net> 
Sent: Monday, March 12, 2018 5:30 PM
To: swing-dev at openjdk.java.net
Subject: swing-dev Digest, Vol 131, Issue 25

Send swing-dev mailing list submissions to
	swing-dev at openjdk.java.net

To subscribe or unsubscribe via the World Wide Web, visit
	http://mail.openjdk.java.net/mailman/listinfo/swing-dev
or, via email, send a message with subject or body 'help' to
	swing-dev-request at openjdk.java.net

You can reach the person managing the list at
	swing-dev-owner at openjdk.java.net

When replying, please edit your Subject line so it is more specific than "Re: Contents of swing-dev digest..."


Today's Topics:

   1.  [11] JDK-8191957: JFileChooser shows empty name for external
      drives shown under Desktop (Pankaj Bansal)


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

Message: 1
Date: Mon, 12 Mar 2018 01:52:35 -0700 (PDT)
From: Pankaj Bansal <pankaj.b.bansal at oracle.com>
To: swing-dev at openjdk.java.net
Subject: <Swing Dev> [11] JDK-8191957: JFileChooser shows empty name
	for external drives shown under Desktop
Message-ID: <065d066f-810c-4284-9de6-059f4235e61b at default>
Content-Type: text/plain; charset="us-ascii"

Hi All,

 

Please review the test only fix for JDK 11.

 

Bug:

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

 	

webrev:

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

 

Issue:

In windows 10, the "External Drives" or "Removable drives" names are empty when root directory "Desktop" is selected in JFileChooser. Only the icon is shown and name is empty.

Fix:

The system folder names are found by calling FileSystemView.getSystemDisplayName, which in turn calls  Win32ShellFolderManager2.isFileSystemRoot. Here it was wrongly assumed that a drive will always be child of "DRIVES" or "MY PC". But in windows 10, the external drives are also shown as children of root directory "Desktop". Made changes to consider drives names which are children of "Desktop".

 

Note:

This is a windows 10 specific issues. 

You will need an removable drive attached to you system to test this.

 

Regards,

Pankaj Bansal

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

End of swing-dev Digest, Vol 131, Issue 25
******************************************


From krishna.addepalli at oracle.com  Fri Mar 16 11:17:33 2018
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Fri, 16 Mar 2018 04:17:33 -0700 (PDT)
Subject: <Swing Dev> [11] JDK-8191957: JFileChooser shows empty name for
 external drives shown under Desktop
Message-ID: <81badaad-78d4-4e71-8d4d-47a3a3067802@default>

Hi Pankaj,

The changes look fine to me.

Thanks,
Krishna

-----Original Message-----
From: Pankaj Bansal 
Sent: Friday, March 16, 2018 4:42 PM
To: Krishna Addepalli <krishna.addepalli at oracle.com>; swing-dev at openjdk.java.net
Subject: RE: <Swing Dev> [11] JDK-8191957: JFileChooser shows empty name

Hi Krishna,

Thanks for the review.

I have incorporated the review comments. Please have a look.
Webrev: http://cr.openjdk.java.net/~pbansal/8191957/webrev.01/

Regards,
Pankaj Bansal

-----Original Message-----
From: Krishna Addepalli 
Sent: Friday, March 16, 2018 4:03 PM
To: swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [11] JDK-8191957: JFileChooser shows empty name

Hi Pankaj,

The fix looks fine to me. However I have couple points:

1. Please put a comment at the line of fix, about how Windows 10 treats the Desktop folder.
2. The test case can be a headless one, since you are not creating any gui components.

Thanks,
Krishna


-----Original Message-----
From: swing-dev-request at openjdk.java.net <swing-dev-request at openjdk.java.net> 
Sent: Monday, March 12, 2018 5:30 PM
To: swing-dev at openjdk.java.net
Subject: swing-dev Digest, Vol 131, Issue 25

Send swing-dev mailing list submissions to
	swing-dev at openjdk.java.net

To subscribe or unsubscribe via the World Wide Web, visit
	http://mail.openjdk.java.net/mailman/listinfo/swing-dev
or, via email, send a message with subject or body 'help' to
	swing-dev-request at openjdk.java.net

You can reach the person managing the list at
	swing-dev-owner at openjdk.java.net

When replying, please edit your Subject line so it is more specific than "Re: Contents of swing-dev digest..."


Today's Topics:

   1.  [11] JDK-8191957: JFileChooser shows empty name for external
      drives shown under Desktop (Pankaj Bansal)


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

Message: 1
Date: Mon, 12 Mar 2018 01:52:35 -0700 (PDT)
From: Pankaj Bansal <pankaj.b.bansal at oracle.com>
To: swing-dev at openjdk.java.net
Subject: <Swing Dev> [11] JDK-8191957: JFileChooser shows empty name
	for external drives shown under Desktop
Message-ID: <065d066f-810c-4284-9de6-059f4235e61b at default>
Content-Type: text/plain; charset="us-ascii"

Hi All,

 

Please review the test only fix for JDK 11.

 

Bug:

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

 	

webrev:

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

 

Issue:

In windows 10, the "External Drives" or "Removable drives" names are empty when root directory "Desktop" is selected in JFileChooser. Only the icon is shown and name is empty.

Fix:

The system folder names are found by calling FileSystemView.getSystemDisplayName, which in turn calls  Win32ShellFolderManager2.isFileSystemRoot. Here it was wrongly assumed that a drive will always be child of "DRIVES" or "MY PC". But in windows 10, the external drives are also shown as children of root directory "Desktop". Made changes to consider drives names which are children of "Desktop".

 

Note:

This is a windows 10 specific issues. 

You will need an removable drive attached to you system to test this.

 

Regards,

Pankaj Bansal

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

End of swing-dev Digest, Vol 131, Issue 25
******************************************


From philip.race at oracle.com  Fri Mar 16 17:34:52 2018
From: philip.race at oracle.com (Phil Race)
Date: Fri, 16 Mar 2018 10:34:52 -0700
Subject: <Swing Dev> RFR: 8198649 : Switch AWT/Swing's default GTK version
	to 3
Message-ID: <da7a00f5-389a-a532-12f0-433063e9aceb@oracle.com>

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

This is a very small change to switch the default GTK library loaded
from GTK 2.2 to GTK 3.

Both are supported as of JDK 9 but it still defaults to 2.2 and you use
jdk.gtk.version=3 to switch.

Since only one of these can be loaded a switch is necessary in case
auto-detect fails or JDK get to load its version first, but making GTK3 load
by default will help with SWT interop as shown here  where we load
Swing's GTK L+F followed by SWT

---
import javax.swing.UIManager;
import org.eclipse.swt.widgets.Display;

public class SWT_Swing {
  public static void main(String[] args) throws Exception {
UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
         Display display = new Display();
  }
}

--

/jdk9/bin/java -Djdk.gtk.verbose=true  -cp swt.jar:. SWT_Swing Looking 
for GTK2 library...
GTK2 library loaded.

(java:21435): GLib-GObject-WARNING **: cannot register existing type 
'GdkDisplayManager'

(java:21435): GLib-CRITICAL **: g_once_init_leave: assertion 'result != 
0' failed

(java:21435): GLib-GObject-CRITICAL **: g_object_new: assertion 
'G_TYPE_IS_OBJECT (object_type)' failed

---

As you can see SWT now cannot work since JDK loaded GTK 2.2 by default
and unlike JDK SWT has no detection code or automatic fall back

But with the proposed change we get no error :
~/jdk-11/build/linux-x86_64-normal-server-release/jdk/bin/java 
-Djdk.gtk.verbose=true  -cp swt.jar:. SWT_Swing
Looking for GTK3 library...
GTK3 library loaded.

Granted, the reverse problem would happen for apps that depend on GTK 2.2
but that is looking backwards ..

I have also run the SwingSet2 demo in the various cases and it is fine.

We expect to make the same switch for JavaFX.

-phil.





From krishna.addepalli at oracle.com  Fri Mar 16 17:38:45 2018
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Fri, 16 Mar 2018 17:38:45 +0000 (UTC)
Subject: <Swing Dev> <AWT Dev> RFR: 8198649 : Switch AWT/Swing's default
 GTK version to 3
In-Reply-To: <da7a00f5-389a-a532-12f0-433063e9aceb@oracle.com>
References: <da7a00f5-389a-a532-12f0-433063e9aceb@oracle.com>
Message-ID: <c3607557-05bd-436b-b190-58174a7b22d3@default>

Hi Phil, 

The change looks fine for me.

Thanks,
Krishna

-----Original Message-----
From: Phil Race 
Sent: Friday, March 16, 2018 11:05 PM
To: awt-dev at openjdk.java.net; swing-dev at openjdk.java.net
Subject: <AWT Dev> RFR: 8198649 : Switch AWT/Swing's default GTK version to 3

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

This is a very small change to switch the default GTK library loaded from GTK 2.2 to GTK 3.

Both are supported as of JDK 9 but it still defaults to 2.2 and you use
jdk.gtk.version=3 to switch.

Since only one of these can be loaded a switch is necessary in case auto-detect fails or JDK get to load its version first, but making GTK3 load by default will help with SWT interop as shown here  where we load Swing's GTK L+F followed by SWT

---
import javax.swing.UIManager;
import org.eclipse.swt.widgets.Display;

public class SWT_Swing {
  public static void main(String[] args) throws Exception { UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
         Display display = new Display();
  }
}

--

/jdk9/bin/java -Djdk.gtk.verbose=true  -cp swt.jar:. SWT_Swing Looking for GTK2 library...
GTK2 library loaded.

(java:21435): GLib-GObject-WARNING **: cannot register existing type 'GdkDisplayManager'

(java:21435): GLib-CRITICAL **: g_once_init_leave: assertion 'result != 0' failed

(java:21435): GLib-GObject-CRITICAL **: g_object_new: assertion 'G_TYPE_IS_OBJECT (object_type)' failed

---

As you can see SWT now cannot work since JDK loaded GTK 2.2 by default and unlike JDK SWT has no detection code or automatic fall back

But with the proposed change we get no error :
~/jdk-11/build/linux-x86_64-normal-server-release/jdk/bin/java
-Djdk.gtk.verbose=true  -cp swt.jar:. SWT_Swing Looking for GTK3 library...
GTK3 library loaded.

Granted, the reverse problem would happen for apps that depend on GTK 2.2 but that is looking backwards ..

I have also run the SwingSet2 demo in the various cases and it is fine.

We expect to make the same switch for JavaFX.

-phil.





From kevin.rushforth at oracle.com  Fri Mar 16 20:11:10 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Fri, 16 Mar 2018 13:11:10 -0700
Subject: <Swing Dev> RFR: 8198649 : Switch AWT/Swing's default GTK
	version to 3
In-Reply-To: <da7a00f5-389a-a532-12f0-433063e9aceb@oracle.com>
References: <da7a00f5-389a-a532-12f0-433063e9aceb@oracle.com>
Message-ID: <5AAC24DE.5020105@oracle.com>

This looks fine to me. I checked FX / Swing interop and it works as 
expected. If there is a mismatch in defaults (which there will be until 
FX switches the default, or after we which when running FX on an older 
JDK), then whichever toolkit loads first will use its default, and then 
the other one will pick up the already loaded library.

-- Kevin


Phil Race wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8198649
> Webrev: http://cr.openjdk.java.net/~prr/8198649/
>
> This is a very small change to switch the default GTK library loaded
> from GTK 2.2 to GTK 3.
>
> Both are supported as of JDK 9 but it still defaults to 2.2 and you use
> jdk.gtk.version=3 to switch.
>
> Since only one of these can be loaded a switch is necessary in case
> auto-detect fails or JDK get to load its version first, but making 
> GTK3 load
> by default will help with SWT interop as shown here  where we load
> Swing's GTK L+F followed by SWT
>
> ---
> import javax.swing.UIManager;
> import org.eclipse.swt.widgets.Display;
>
> public class SWT_Swing {
>  public static void main(String[] args) throws Exception {
> UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
>         Display display = new Display();
>  }
> }
>
> -- 
>
> /jdk9/bin/java -Djdk.gtk.verbose=true  -cp swt.jar:. SWT_Swing Looking 
> for GTK2 library...
> GTK2 library loaded.
>
> (java:21435): GLib-GObject-WARNING **: cannot register existing type 
> 'GdkDisplayManager'
>
> (java:21435): GLib-CRITICAL **: g_once_init_leave: assertion 'result 
> != 0' failed
>
> (java:21435): GLib-GObject-CRITICAL **: g_object_new: assertion 
> 'G_TYPE_IS_OBJECT (object_type)' failed
>
> ---
>
> As you can see SWT now cannot work since JDK loaded GTK 2.2 by default
> and unlike JDK SWT has no detection code or automatic fall back
>
> But with the proposed change we get no error :
> ~/jdk-11/build/linux-x86_64-normal-server-release/jdk/bin/java 
> -Djdk.gtk.verbose=true  -cp swt.jar:. SWT_Swing
> Looking for GTK3 library...
> GTK3 library loaded.
>
> Granted, the reverse problem would happen for apps that depend on GTK 2.2
> but that is looking backwards ..
>
> I have also run the SwingSet2 demo in the various cases and it is fine.
>
> We expect to make the same switch for JavaFX.
>
> -phil.
>
>
>


From prasanta.sadhukhan at oracle.com  Sat Mar 17 07:17:58 2018
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Sat, 17 Mar 2018 12:47:58 +0530
Subject: <Swing Dev> RFR: 8198649 : Switch AWT/Swing's default GTK
 version to 3
In-Reply-To: <da7a00f5-389a-a532-12f0-433063e9aceb@oracle.com>
References: <da7a00f5-389a-a532-12f0-433063e9aceb@oracle.com>
Message-ID: <9d3e17ab-4a72-d971-52c4-ff0b20e77d6d@oracle.com>

+1

Regards
Prasanta
On 3/16/2018 11:04 PM, Phil Race wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8198649
> Webrev: http://cr.openjdk.java.net/~prr/8198649/
>
> This is a very small change to switch the default GTK library loaded
> from GTK 2.2 to GTK 3.
>
> Both are supported as of JDK 9 but it still defaults to 2.2 and you use
> jdk.gtk.version=3 to switch.
>
> Since only one of these can be loaded a switch is necessary in case
> auto-detect fails or JDK get to load its version first, but making 
> GTK3 load
> by default will help with SWT interop as shown here? where we load
> Swing's GTK L+F followed by SWT
>
> ---
> import javax.swing.UIManager;
> import org.eclipse.swt.widgets.Display;
>
> public class SWT_Swing {
> ?public static void main(String[] args) throws Exception {
> UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
> ??????? Display display = new Display();
> ?}
> }
>
> -- 
>
> /jdk9/bin/java -Djdk.gtk.verbose=true? -cp swt.jar:. SWT_Swing Looking 
> for GTK2 library...
> GTK2 library loaded.
>
> (java:21435): GLib-GObject-WARNING **: cannot register existing type 
> 'GdkDisplayManager'
>
> (java:21435): GLib-CRITICAL **: g_once_init_leave: assertion 'result 
> != 0' failed
>
> (java:21435): GLib-GObject-CRITICAL **: g_object_new: assertion 
> 'G_TYPE_IS_OBJECT (object_type)' failed
>
> ---
>
> As you can see SWT now cannot work since JDK loaded GTK 2.2 by default
> and unlike JDK SWT has no detection code or automatic fall back
>
> But with the proposed change we get no error :
> ~/jdk-11/build/linux-x86_64-normal-server-release/jdk/bin/java 
> -Djdk.gtk.verbose=true? -cp swt.jar:. SWT_Swing
> Looking for GTK3 library...
> GTK3 library loaded.
>
> Granted, the reverse problem would happen for apps that depend on GTK 2.2
> but that is looking backwards ..
>
> I have also run the SwingSet2 demo in the various cases and it is fine.
>
> We expect to make the same switch for JavaFX.
>
> -phil.
>
>
>



From Sergey.Bylokhov at oracle.com  Mon Mar 19 19:06:11 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 19 Mar 2018 12:06:11 -0700
Subject: <Swing Dev> RFR: 8198897: Compilation errors in
 jdk.accessibility with VS 2017
In-Reply-To: <b6df5c2f-27e3-4aa7-b6e0-a97df2f659d7@default>
References: <9362320d-bcb5-8aaf-4826-a2089a70c748@oracle.com>
 <b6df5c2f-27e3-4aa7-b6e0-a97df2f659d7@default>
Message-ID: <6d9e68e4-dfdc-e11b-e9b2-ce54cd56ef2c@oracle.com>

On 14/03/2018 18:36, Krishna Addepalli wrote:
> Hi Phil,
> 
> The changes look fine.
+1

-- 
Best regards, Sergey.


From prasanta.sadhukhan at oracle.com  Tue Mar 20 07:30:47 2018
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Tue, 20 Mar 2018 13:00:47 +0530
Subject: <Swing Dev> [11] RFR JDK-8189687:Swing: Invalid position of
 candidate pop-up of InputMethod in Hi-DPI on Windows
Message-ID: <5e0216fa-11ba-9408-864c-0d54f819d073@oracle.com>

Hi All,

Please review a fix for an issue where it is seen that
for Japanese IME on windows 10 with scaleFactor 1.5, when we enter text 
using IME popup, the popup is positioned on top of text, thereby 
obscuring it
as seen in this screenshot.


Proposed fix is to apply the scaleFactor on the candidate's popup 
positional coordinates x,y to generate proper coordinates to show this popup
webrev: http://cr.openjdk.java.net/~psadhukhan/8189687/webrev.00/

The screenshot after the fix is


Regards
Prasanta
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20180320/f547292e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fhflfajhelegbpce.png
Type: image/png
Size: 22174 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20180320/f547292e/fhflfajhelegbpce.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mjcnnlhcclknakic.png
Type: image/png
Size: 24597 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20180320/f547292e/mjcnnlhcclknakic.png>

From krishna.addepalli at oracle.com  Tue Mar 20 09:10:37 2018
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Tue, 20 Mar 2018 02:10:37 -0700 (PDT)
Subject: <Swing Dev> [11] RFR JDK-8189687:Swing: Invalid position of
 candidate pop-up of InputMethod in Hi-DPI on Windows
In-Reply-To: <5e0216fa-11ba-9408-864c-0d54f819d073@oracle.com>
References: <5e0216fa-11ba-9408-864c-0d54f819d073@oracle.com>
Message-ID: <c0f29625-7c8c-4571-89dd-67d61cd1d8c5@default>

Hi Prasanta,

?

I have couple questions regarding your fix:

1.?????? The AffineTransform object should be retrieved from the Screen on which the window is showing, whereas in your fix, you are directly getting it from the default screen. In multi screen environment, it may not be aligned correctly.

2.?????? Is there any reason to retrieve the object in the top. I mean, the AffineTransform object can be declared inside the ?if (haveActiveClient())? block, at the point of use.

Thanks,

Krishna

?

From: Prasanta Sadhukhan 
Sent: Tuesday, March 20, 2018 1:01 PM
To: swing-dev at openjdk.java.net
Subject: <Swing Dev> [11] RFR JDK-8189687:Swing: Invalid position of candidate pop-up of InputMethod in Hi-DPI on Windows

?

Hi All,

Please review a fix for an issue where it is seen that 
for Japanese IME on windows 10 with scaleFactor 1.5, when we enter text using IME popup, the popup is positioned on top of text, thereby obscuring it
as seen in this screenshot.


Proposed fix is to apply the scaleFactor on the candidate's popup positional coordinates x,y to generate proper coordinates to show this popup
webrev: http://cr.openjdk.java.net/~psadhukhan/8189687/webrev.00/

The screenshot after the fix is


Regards
Prasanta
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20180320/05b76819/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 22174 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20180320/05b76819/image001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 24597 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20180320/05b76819/image002.png>

From prasanta.sadhukhan at oracle.com  Tue Mar 20 11:34:16 2018
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Tue, 20 Mar 2018 17:04:16 +0530
Subject: <Swing Dev> [11] RFR JDK-8189687:Swing: Invalid position of
 candidate pop-up of InputMethod in Hi-DPI on Windows
In-Reply-To: <c0f29625-7c8c-4571-89dd-67d61cd1d8c5@default>
References: <5e0216fa-11ba-9408-864c-0d54f819d073@oracle.com>
 <c0f29625-7c8c-4571-89dd-67d61cd1d8c5@default>
Message-ID: <56e2135b-5b54-fce0-df1b-7deda03e9b44@oracle.com>

Thanks Krishna for your comment. Modified webrev catering to retrieval 
of scalefactor of the active monitor being shown

http://cr.openjdk.java.net/~psadhukhan/8189687/webrev.01/

Regards
Prasanta
On 3/20/2018 2:40 PM, Krishna Addepalli wrote:
>
> Hi Prasanta,
>
> I have couple questions regarding your fix:
>
> 1.The AffineTransform object should be retrieved from the Screen on 
> which the window is showing, whereas in your fix, you are directly 
> getting it from the default screen. In multi screen environment, it 
> may not be aligned correctly.
>
> 2.Is there any reason to retrieve the object in the top. I mean, the 
> AffineTransform object can be declared inside the ?if 
> (haveActiveClient())? block, at the point of use.
>
> Thanks,
>
> Krishna
>
> *From:*Prasanta Sadhukhan
> *Sent:* Tuesday, March 20, 2018 1:01 PM
> *To:* swing-dev at openjdk.java.net
> *Subject:* <Swing Dev> [11] RFR JDK-8189687:Swing: Invalid position of 
> candidate pop-up of InputMethod in Hi-DPI on Windows
>
> Hi All,
>
> Please review a fix for an issue where it is seen that
> for Japanese IME on windows 10 with scaleFactor 1.5, when we enter 
> text using IME popup, the popup is positioned on top of text, thereby 
> obscuring it
> as seen in this screenshot.
>
>
> Proposed fix is to apply the scaleFactor on the candidate's popup 
> positional coordinates x,y to generate proper coordinates to show this 
> popup
> webrev: http://cr.openjdk.java.net/~psadhukhan/8189687/webrev.00/ 
> <http://cr.openjdk.java.net/%7Epsadhukhan/8189687/webrev.00/>
>
> The screenshot after the fix is
>
>
> Regards
> Prasanta
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20180320/a28b9c5f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 22174 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20180320/a28b9c5f/image001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 24597 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20180320/a28b9c5f/image002.png>

From krishna.addepalli at oracle.com  Tue Mar 20 15:12:20 2018
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Tue, 20 Mar 2018 08:12:20 -0700 (PDT)
Subject: <Swing Dev> [11] RFR JDK-8189687:Swing: Invalid position of
 candidate pop-up of InputMethod in Hi-DPI on Windows
In-Reply-To: <56e2135b-5b54-fce0-df1b-7deda03e9b44@oracle.com>
References: <5e0216fa-11ba-9408-864c-0d54f819d073@oracle.com>
 <c0f29625-7c8c-4571-89dd-67d61cd1d8c5@default>
 <56e2135b-5b54-fce0-df1b-7deda03e9b44@oracle.com>
Message-ID: <bc9977cb-88f7-4abc-972f-3f6110bc10e7@default>

Hi Prasanta, 

?

Now the changes look fine. However, I noticed that there is no testcase associated with this fix. Is that intentional?

?

Thanks,

Krishna

?

From: Prasanta Sadhukhan 
Sent: Tuesday, March 20, 2018 5:04 PM
To: Krishna Addepalli <krishna.addepalli at oracle.com>; swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [11] RFR JDK-8189687:Swing: Invalid position of candidate pop-up of InputMethod in Hi-DPI on Windows

?

Thanks Krishna for your comment. Modified webrev catering to retrieval of scalefactor of the active monitor being shown 

http://cr.openjdk.java.net/~psadhukhan/8189687/webrev.01/

Regards
Prasanta

On 3/20/2018 2:40 PM, Krishna Addepalli wrote:

Hi Prasanta,

?

I have couple questions regarding your fix:

1.????? The AffineTransform object should be retrieved from the Screen on which the window is showing, whereas in your fix, you are directly getting it from the default screen. In multi screen environment, it may not be aligned correctly.

2.????? Is there any reason to retrieve the object in the top. I mean, the AffineTransform object can be declared inside the ?if (haveActiveClient())? block, at the point of use.

Thanks,

Krishna

?

From: Prasanta Sadhukhan 
Sent: Tuesday, March 20, 2018 1:01 PM
To: HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: <Swing Dev> [11] RFR JDK-8189687:Swing: Invalid position of candidate pop-up of InputMethod in Hi-DPI on Windows

?

Hi All,

Please review a fix for an issue where it is seen that 
for Japanese IME on windows 10 with scaleFactor 1.5, when we enter text using IME popup, the popup is positioned on top of text, thereby obscuring it
as seen in this screenshot.


Proposed fix is to apply the scaleFactor on the candidate's popup positional coordinates x,y to generate proper coordinates to show this popup
webrev: HYPERLINK "http://cr.openjdk.java.net/%7Epsadhukhan/8189687/webrev.00/"http://cr.openjdk.java.net/~psadhukhan/8189687/webrev.00/

The screenshot after the fix is


Regards
Prasanta

?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20180320/7191803f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 22174 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20180320/7191803f/image001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 24597 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20180320/7191803f/image002.png>

From pankaj.b.bansal at oracle.com  Tue Mar 20 17:40:30 2018
From: pankaj.b.bansal at oracle.com (Pankaj Bansal)
Date: Tue, 20 Mar 2018 10:40:30 -0700 (PDT)
Subject: <Swing Dev> [11] JDK-8191957: JFileChooser shows empty name for
 external drives shown under Desktop
In-Reply-To: <81badaad-78d4-4e71-8d4d-47a3a3067802@default>
References: <81badaad-78d4-4e71-8d4d-47a3a3067802@default>
Message-ID: <40611eeb-7142-4aaf-b782-0957e6506101@default>

Hi All, 

Does anyone else have any feedback on this?

Regards,
Pankaj Bansal

-----Original Message-----
From: Krishna Addepalli 
Sent: Friday, March 16, 2018 4:48 PM
To: Pankaj Bansal; swing-dev at openjdk.java.net
Subject: RE: <Swing Dev> [11] JDK-8191957: JFileChooser shows empty name for external drives shown under Desktop

Hi Pankaj,

The changes look fine to me.

Thanks,
Krishna

-----Original Message-----
From: Pankaj Bansal 
Sent: Friday, March 16, 2018 4:42 PM
To: Krishna Addepalli <krishna.addepalli at oracle.com>; swing-dev at openjdk.java.net
Subject: RE: <Swing Dev> [11] JDK-8191957: JFileChooser shows empty name

Hi Krishna,

Thanks for the review.

I have incorporated the review comments. Please have a look.
Webrev: http://cr.openjdk.java.net/~pbansal/8191957/webrev.01/

Regards,
Pankaj Bansal

-----Original Message-----
From: Krishna Addepalli 
Sent: Friday, March 16, 2018 4:03 PM
To: swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [11] JDK-8191957: JFileChooser shows empty name

Hi Pankaj,

The fix looks fine to me. However I have couple points:

1. Please put a comment at the line of fix, about how Windows 10 treats the Desktop folder.
2. The test case can be a headless one, since you are not creating any gui components.

Thanks,
Krishna


-----Original Message-----
From: swing-dev-request at openjdk.java.net <swing-dev-request at openjdk.java.net> 
Sent: Monday, March 12, 2018 5:30 PM
To: swing-dev at openjdk.java.net
Subject: swing-dev Digest, Vol 131, Issue 25

Send swing-dev mailing list submissions to
	swing-dev at openjdk.java.net

To subscribe or unsubscribe via the World Wide Web, visit
	http://mail.openjdk.java.net/mailman/listinfo/swing-dev
or, via email, send a message with subject or body 'help' to
	swing-dev-request at openjdk.java.net

You can reach the person managing the list at
	swing-dev-owner at openjdk.java.net

When replying, please edit your Subject line so it is more specific than "Re: Contents of swing-dev digest..."


Today's Topics:

   1.  [11] JDK-8191957: JFileChooser shows empty name for external
      drives shown under Desktop (Pankaj Bansal)


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

Message: 1
Date: Mon, 12 Mar 2018 01:52:35 -0700 (PDT)
From: Pankaj Bansal <pankaj.b.bansal at oracle.com>
To: swing-dev at openjdk.java.net
Subject: <Swing Dev> [11] JDK-8191957: JFileChooser shows empty name
	for external drives shown under Desktop
Message-ID: <065d066f-810c-4284-9de6-059f4235e61b at default>
Content-Type: text/plain; charset="us-ascii"

Hi All,

 

Please review the test only fix for JDK 11.

 

Bug:

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

 	

webrev:

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

 

Issue:

In windows 10, the "External Drives" or "Removable drives" names are empty when root directory "Desktop" is selected in JFileChooser. Only the icon is shown and name is empty.

Fix:

The system folder names are found by calling FileSystemView.getSystemDisplayName, which in turn calls  Win32ShellFolderManager2.isFileSystemRoot. Here it was wrongly assumed that a drive will always be child of "DRIVES" or "MY PC". But in windows 10, the external drives are also shown as children of root directory "Desktop". Made changes to consider drives names which are children of "Desktop".

 

Note:

This is a windows 10 specific issues. 

You will need an removable drive attached to you system to test this.

 

Regards,

Pankaj Bansal

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

End of swing-dev Digest, Vol 131, Issue 25
******************************************


From jayathirth.d.v at oracle.com  Tue Mar 20 18:35:36 2018
From: jayathirth.d.v at oracle.com (Jayathirth D V)
Date: Tue, 20 Mar 2018 11:35:36 -0700 (PDT)
Subject: <Swing Dev> [11] JDK-8191957: JFileChooser shows empty name for
 external drives shown under Desktop
In-Reply-To: <40611eeb-7142-4aaf-b782-0957e6506101@default>
References: <81badaad-78d4-4e71-8d4d-47a3a3067802@default>
 <40611eeb-7142-4aaf-b782-0957e6506101@default>
Message-ID: <9c30f76b-3dbe-4575-bc12-8b6cf0e284af@default>

Hi Pankaj,

I see that you have mentioned this bug is specific to Windows 10 and test case needs to be run with some Removable drive.
It better to capture this information in test case also as a comment or in jtreg summary.

In test case we have verification part like :
                if (fsv.getSystemDisplayName(file).isEmpty()) {
                    throw new RuntimeException(
                            "External Disk " + file + "name is empty");
                }
This code runs throw all the files under Desktop in my Windows 7 PC. So do we have any property in FileSystemView using which we can know that the file is of type external drive and then just check system display name for the same.

If we can't determine the file type as external drive using some property in FileSystemView, still the RuntimeException message you are throwing("External Disk " + file + "name is empty") can be misleading. I would recommend you to throw an Exception like -  "System display name for" + file + "is empty".

Also you have missed opening quote for the (Desktop") part of comment in Win32ShellFolderManager2.java.

Thanks,
Jay

-----Original Message-----
From: Pankaj Bansal 
Sent: Tuesday, March 20, 2018 11:11 PM
To: swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [11] JDK-8191957: JFileChooser shows empty name for external drives shown under Desktop

Hi All, 

Does anyone else have any feedback on this?

Regards,
Pankaj Bansal

-----Original Message-----
From: Krishna Addepalli 
Sent: Friday, March 16, 2018 4:48 PM
To: Pankaj Bansal; swing-dev at openjdk.java.net
Subject: RE: <Swing Dev> [11] JDK-8191957: JFileChooser shows empty name for external drives shown under Desktop

Hi Pankaj,

The changes look fine to me.

Thanks,
Krishna

-----Original Message-----
From: Pankaj Bansal 
Sent: Friday, March 16, 2018 4:42 PM
To: Krishna Addepalli <krishna.addepalli at oracle.com>; swing-dev at openjdk.java.net
Subject: RE: <Swing Dev> [11] JDK-8191957: JFileChooser shows empty name

Hi Krishna,

Thanks for the review.

I have incorporated the review comments. Please have a look.
Webrev: http://cr.openjdk.java.net/~pbansal/8191957/webrev.01/

Regards,
Pankaj Bansal

-----Original Message-----
From: Krishna Addepalli 
Sent: Friday, March 16, 2018 4:03 PM
To: swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [11] JDK-8191957: JFileChooser shows empty name

Hi Pankaj,

The fix looks fine to me. However I have couple points:

1. Please put a comment at the line of fix, about how Windows 10 treats the Desktop folder.
2. The test case can be a headless one, since you are not creating any gui components.

Thanks,
Krishna


-----Original Message-----
From: swing-dev-request at openjdk.java.net <swing-dev-request at openjdk.java.net> 
Sent: Monday, March 12, 2018 5:30 PM
To: swing-dev at openjdk.java.net
Subject: swing-dev Digest, Vol 131, Issue 25

Send swing-dev mailing list submissions to
	swing-dev at openjdk.java.net

To subscribe or unsubscribe via the World Wide Web, visit
	http://mail.openjdk.java.net/mailman/listinfo/swing-dev
or, via email, send a message with subject or body 'help' to
	swing-dev-request at openjdk.java.net

You can reach the person managing the list at
	swing-dev-owner at openjdk.java.net

When replying, please edit your Subject line so it is more specific than "Re: Contents of swing-dev digest..."


Today's Topics:

   1.  [11] JDK-8191957: JFileChooser shows empty name for external
      drives shown under Desktop (Pankaj Bansal)


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

Message: 1
Date: Mon, 12 Mar 2018 01:52:35 -0700 (PDT)
From: Pankaj Bansal <pankaj.b.bansal at oracle.com>
To: swing-dev at openjdk.java.net
Subject: <Swing Dev> [11] JDK-8191957: JFileChooser shows empty name
	for external drives shown under Desktop
Message-ID: <065d066f-810c-4284-9de6-059f4235e61b at default>
Content-Type: text/plain; charset="us-ascii"

Hi All,

 

Please review the test only fix for JDK 11.

 

Bug:

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

 	

webrev:

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

 

Issue:

In windows 10, the "External Drives" or "Removable drives" names are empty when root directory "Desktop" is selected in JFileChooser. Only the icon is shown and name is empty.

Fix:

The system folder names are found by calling FileSystemView.getSystemDisplayName, which in turn calls  Win32ShellFolderManager2.isFileSystemRoot. Here it was wrongly assumed that a drive will always be child of "DRIVES" or "MY PC". But in windows 10, the external drives are also shown as children of root directory "Desktop". Made changes to consider drives names which are children of "Desktop".

 

Note:

This is a windows 10 specific issues. 

You will need an removable drive attached to you system to test this.

 

Regards,

Pankaj Bansal

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

End of swing-dev Digest, Vol 131, Issue 25
******************************************


From jayathirth.d.v at oracle.com  Tue Mar 20 19:15:27 2018
From: jayathirth.d.v at oracle.com (Jayathirth D V)
Date: Tue, 20 Mar 2018 12:15:27 -0700 (PDT)
Subject: <Swing Dev> [11] JDK-8191957: JFileChooser shows empty name for
 external drives shown under Desktop
In-Reply-To: <9c30f76b-3dbe-4575-bc12-8b6cf0e284af@default>
References: <81badaad-78d4-4e71-8d4d-47a3a3067802@default>
 <40611eeb-7142-4aaf-b782-0957e6506101@default>
 <9c30f76b-3dbe-4575-bc12-8b6cf0e284af@default>
Message-ID: <47be1bb1-be13-488a-a9af-c43696032824@default>

Hi Pankaj,

More inputs:
Since the test case is valid only when we have windows 10 system with some external drive making the test case manual is also a good idea.

Thanks,
Jay

-----Original Message-----
From: Jayathirth D V 
Sent: Wednesday, March 21, 2018 12:06 AM
To: Pankaj Bansal; swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [11] JDK-8191957: JFileChooser shows empty name for external drives shown under Desktop

Hi Pankaj,

I see that you have mentioned this bug is specific to Windows 10 and test case needs to be run with some Removable drive.
It better to capture this information in test case also as a comment or in jtreg summary.

In test case we have verification part like :
                if (fsv.getSystemDisplayName(file).isEmpty()) {
                    throw new RuntimeException(
                            "External Disk " + file + "name is empty");
                }
This code runs throw all the files under Desktop in my Windows 7 PC. So do we have any property in FileSystemView using which we can know that the file is of type external drive and then just check system display name for the same.

If we can't determine the file type as external drive using some property in FileSystemView, still the RuntimeException message you are throwing("External Disk " + file + "name is empty") can be misleading. I would recommend you to throw an Exception like -  "System display name for" + file + "is empty".

Also you have missed opening quote for the (Desktop") part of comment in Win32ShellFolderManager2.java.

Thanks,
Jay

-----Original Message-----
From: Pankaj Bansal 
Sent: Tuesday, March 20, 2018 11:11 PM
To: swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [11] JDK-8191957: JFileChooser shows empty name for external drives shown under Desktop

Hi All, 

Does anyone else have any feedback on this?

Regards,
Pankaj Bansal

-----Original Message-----
From: Krishna Addepalli 
Sent: Friday, March 16, 2018 4:48 PM
To: Pankaj Bansal; swing-dev at openjdk.java.net
Subject: RE: <Swing Dev> [11] JDK-8191957: JFileChooser shows empty name for external drives shown under Desktop

Hi Pankaj,

The changes look fine to me.

Thanks,
Krishna

-----Original Message-----
From: Pankaj Bansal 
Sent: Friday, March 16, 2018 4:42 PM
To: Krishna Addepalli <krishna.addepalli at oracle.com>; swing-dev at openjdk.java.net
Subject: RE: <Swing Dev> [11] JDK-8191957: JFileChooser shows empty name

Hi Krishna,

Thanks for the review.

I have incorporated the review comments. Please have a look.
Webrev: http://cr.openjdk.java.net/~pbansal/8191957/webrev.01/

Regards,
Pankaj Bansal

-----Original Message-----
From: Krishna Addepalli 
Sent: Friday, March 16, 2018 4:03 PM
To: swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [11] JDK-8191957: JFileChooser shows empty name

Hi Pankaj,

The fix looks fine to me. However I have couple points:

1. Please put a comment at the line of fix, about how Windows 10 treats the Desktop folder.
2. The test case can be a headless one, since you are not creating any gui components.

Thanks,
Krishna


-----Original Message-----
From: swing-dev-request at openjdk.java.net <swing-dev-request at openjdk.java.net> 
Sent: Monday, March 12, 2018 5:30 PM
To: swing-dev at openjdk.java.net
Subject: swing-dev Digest, Vol 131, Issue 25

Send swing-dev mailing list submissions to
	swing-dev at openjdk.java.net

To subscribe or unsubscribe via the World Wide Web, visit
	http://mail.openjdk.java.net/mailman/listinfo/swing-dev
or, via email, send a message with subject or body 'help' to
	swing-dev-request at openjdk.java.net

You can reach the person managing the list at
	swing-dev-owner at openjdk.java.net

When replying, please edit your Subject line so it is more specific than "Re: Contents of swing-dev digest..."


Today's Topics:

   1.  [11] JDK-8191957: JFileChooser shows empty name for external
      drives shown under Desktop (Pankaj Bansal)


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

Message: 1
Date: Mon, 12 Mar 2018 01:52:35 -0700 (PDT)
From: Pankaj Bansal <pankaj.b.bansal at oracle.com>
To: swing-dev at openjdk.java.net
Subject: <Swing Dev> [11] JDK-8191957: JFileChooser shows empty name
	for external drives shown under Desktop
Message-ID: <065d066f-810c-4284-9de6-059f4235e61b at default>
Content-Type: text/plain; charset="us-ascii"

Hi All,

 

Please review the test only fix for JDK 11.

 

Bug:

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

 	

webrev:

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

 

Issue:

In windows 10, the "External Drives" or "Removable drives" names are empty when root directory "Desktop" is selected in JFileChooser. Only the icon is shown and name is empty.

Fix:

The system folder names are found by calling FileSystemView.getSystemDisplayName, which in turn calls  Win32ShellFolderManager2.isFileSystemRoot. Here it was wrongly assumed that a drive will always be child of "DRIVES" or "MY PC". But in windows 10, the external drives are also shown as children of root directory "Desktop". Made changes to consider drives names which are children of "Desktop".

 

Note:

This is a windows 10 specific issues. 

You will need an removable drive attached to you system to test this.

 

Regards,

Pankaj Bansal

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

End of swing-dev Digest, Vol 131, Issue 25
******************************************


From philip.race at oracle.com  Tue Mar 20 19:55:01 2018
From: philip.race at oracle.com (Phil Race)
Date: Tue, 20 Mar 2018 12:55:01 -0700
Subject: <Swing Dev> RFR: 8198990 : Move SwingSet2 from closed to OpenJDK
Message-ID: <9cec067c-7795-03c6-8f8a-3b5c508c71fa@oracle.com>

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

SwingSet2 has always been in closed, mostly because of some
images that could not be moved to OpenJDK.

Due diligence has been done and replacements have been found.
This new version has already been reviewed internally.

I will be removing the closed version at the same time as pushing this.

-phil.





From prasanta.sadhukhan at oracle.com  Wed Mar 21 05:17:33 2018
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Wed, 21 Mar 2018 10:47:33 +0530
Subject: <Swing Dev> [11] RFR JDK-8189687:Swing: Invalid position of
 candidate pop-up of InputMethod in Hi-DPI on Windows
In-Reply-To: <bc9977cb-88f7-4abc-972f-3f6110bc10e7@default>
References: <5e0216fa-11ba-9408-864c-0d54f819d073@oracle.com>
 <c0f29625-7c8c-4571-89dd-67d61cd1d8c5@default>
 <56e2135b-5b54-fce0-df1b-7deda03e9b44@oracle.com>
 <bc9977cb-88f7-4abc-972f-3f6110bc10e7@default>
Message-ID: <a8fa809c-3c83-7ef5-8783-03150b565b76@oracle.com>

Hi Krishna,

Yes, I did not provide any since the testcase needs to be manual and 
would have to contain lots of instructions of how to install Japanese 
language and changing the input mode to hiragana
and also similar fix of input method earlier did not have a testcase for 
similar reason.

Regards
Prasanta
On 3/20/2018 8:42 PM, Krishna Addepalli wrote:
>
> Hi Prasanta,
>
> Now the changes look fine. However, I noticed that there is no 
> testcase associated with this fix. Is that intentional?
>
> Thanks,
>
> Krishna
>
> *From:*Prasanta Sadhukhan
> *Sent:* Tuesday, March 20, 2018 5:04 PM
> *To:* Krishna Addepalli <krishna.addepalli at oracle.com>; 
> swing-dev at openjdk.java.net
> *Subject:* Re: <Swing Dev> [11] RFR JDK-8189687:Swing: Invalid 
> position of candidate pop-up of InputMethod in Hi-DPI on Windows
>
> Thanks Krishna for your comment. Modified webrev catering to retrieval 
> of scalefactor of the active monitor being shown
>
> http://cr.openjdk.java.net/~psadhukhan/8189687/webrev.01/ 
> <http://cr.openjdk.java.net/%7Epsadhukhan/8189687/webrev.01/>
>
> Regards
> Prasanta
>
> On 3/20/2018 2:40 PM, Krishna Addepalli wrote:
>
>     Hi Prasanta,
>
>     I have couple questions regarding your fix:
>
>     1.The AffineTransform object should be retrieved from the Screen
>     on which the window is showing, whereas in your fix, you are
>     directly getting it from the default screen. In multi screen
>     environment, it may not be aligned correctly.
>
>     2.Is there any reason to retrieve the object in the top. I mean,
>     the AffineTransform object can be declared inside the ?if
>     (haveActiveClient())? block, at the point of use.
>
>     Thanks,
>
>     Krishna
>
>     *From:*Prasanta Sadhukhan
>     *Sent:* Tuesday, March 20, 2018 1:01 PM
>     *To:* swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>
>     *Subject:* <Swing Dev> [11] RFR JDK-8189687:Swing: Invalid
>     position of candidate pop-up of InputMethod in Hi-DPI on Windows
>
>     Hi All,
>
>     Please review a fix for an issue where it is seen that
>     for Japanese IME on windows 10 with scaleFactor 1.5, when we enter
>     text using IME popup, the popup is positioned on top of text,
>     thereby obscuring it
>     as seen in this screenshot.
>
>
>     Proposed fix is to apply the scaleFactor on the candidate's popup
>     positional coordinates x,y to generate proper coordinates to show
>     this popup
>     webrev: http://cr.openjdk.java.net/~psadhukhan/8189687/webrev.00/
>     <http://cr.openjdk.java.net/%7Epsadhukhan/8189687/webrev.00/>
>
>     The screenshot after the fix is
>
>
>     Regards
>     Prasanta
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20180321/7289461b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 22174 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20180321/7289461b/image001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 24597 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20180321/7289461b/image002.png>

From krishna.addepalli at oracle.com  Wed Mar 21 06:03:26 2018
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Wed, 21 Mar 2018 11:33:26 +0530
Subject: <Swing Dev> [11] RFR JDK-8189687:Swing: Invalid position of
 candidate pop-up of InputMethod in Hi-DPI on Windows
In-Reply-To: <a8fa809c-3c83-7ef5-8783-03150b565b76@oracle.com>
References: <5e0216fa-11ba-9408-864c-0d54f819d073@oracle.com>
 <c0f29625-7c8c-4571-89dd-67d61cd1d8c5@default>
 <56e2135b-5b54-fce0-df1b-7deda03e9b44@oracle.com>
 <bc9977cb-88f7-4abc-972f-3f6110bc10e7@default>
 <a8fa809c-3c83-7ef5-8783-03150b565b76@oracle.com>
Message-ID: <27A631E6-18CD-4F75-889E-89E7D7B45242@oracle.com>

+1

> On 21-Mar-2018, at 10:47 AM, Prasanta Sadhukhan <prasanta.sadhukhan at oracle.com> wrote:
> 
> Hi Krishna,
> 
> Yes, I did not provide any since the testcase needs to be manual and would have to contain lots of instructions of how to install Japanese language and changing the input mode to hiragana
> and also similar fix of input method earlier did not have a testcase for similar reason.
> 
> Regards
> Prasanta
> On 3/20/2018 8:42 PM, Krishna Addepalli wrote:
>> Hi Prasanta, 
>>  
>> Now the changes look fine. However, I noticed that there is no testcase associated with this fix. Is that intentional?
>>  
>> Thanks,
>> Krishna
>> ? <>
>> From: Prasanta Sadhukhan 
>> Sent: Tuesday, March 20, 2018 5:04 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> [11] RFR JDK-8189687:Swing: Invalid position of candidate pop-up of InputMethod in Hi-DPI on Windows
>>  
>> Thanks Krishna for your comment. Modified webrev catering to retrieval of scalefactor of the active monitor being shown 
>> 
>> http://cr.openjdk.java.net/~psadhukhan/8189687/webrev.01/ <http://cr.openjdk.java.net/%7Epsadhukhan/8189687/webrev.01/>
>> Regards
>> Prasanta
>> On 3/20/2018 2:40 PM, Krishna Addepalli wrote:
>> Hi Prasanta,
>>  
>> I have couple questions regarding your fix:
>> 1.      The AffineTransform object should be retrieved from the Screen on which the window is showing, whereas in your fix, you are directly getting it from the default screen. In multi screen environment, it may not be aligned correctly.
>> 2.      Is there any reason to retrieve the object in the top. I mean, the AffineTransform object can be declared inside the ?if (haveActiveClient())? block, at the point of use.
>> Thanks,
>> Krishna
>>  
>> From: Prasanta Sadhukhan 
>> Sent: Tuesday, March 20, 2018 1:01 PM
>> To: swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>
>> Subject: <Swing Dev> [11] RFR JDK-8189687:Swing: Invalid position of candidate pop-up of InputMethod in Hi-DPI on Windows
>>  
>> Hi All,
>> 
>> Please review a fix for an issue where it is seen that 
>> for Japanese IME on windows 10 with scaleFactor 1.5, when we enter text using IME popup, the popup is positioned on top of text, thereby obscuring it
>> as seen in this screenshot.
>> <image001.png>
>> 
>> Proposed fix is to apply the scaleFactor on the candidate's popup positional coordinates x,y to generate proper coordinates to show this popup
>> webrev: http://cr.openjdk.java.net/~psadhukhan/8189687/webrev.00/ <http://cr.openjdk.java.net/%7Epsadhukhan/8189687/webrev.00/>
>> 
>> The screenshot after the fix is
>> <image002.png>
>> 
>> Regards
>> Prasanta
>>  
> 
> 

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

From krishna.addepalli at oracle.com  Wed Mar 21 06:45:03 2018
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Tue, 20 Mar 2018 23:45:03 -0700 (PDT)
Subject: <Swing Dev> RFR: 8198990 : Move SwingSet2 from closed to OpenJDK
In-Reply-To: <9cec067c-7795-03c6-8f8a-3b5c508c71fa@oracle.com>
References: <9cec067c-7795-03c6-8f8a-3b5c508c71fa@oracle.com>
Message-ID: <78fe181c-3775-4225-9589-c87b6a761162@default>

Hi Phil,

I see that there are these files in the patch: 

src/demo/share/jfc/SwingSet2/SwingSet2.java.orig
src/demo/share/jfc/SwingSet2/resources/images/About.jpg.orig
src/demo/share/jfc/SwingSet2/resources/images/tooltip/cow.gif.orig

As per my understanding, these files get created when there are any merge conflicts in the source.
Not sure about their purpose here.

Thanks,
Krishna

-----Original Message-----
From: Phil Race 
Sent: Wednesday, March 21, 2018 1:25 AM
To: swing-dev at openjdk.java.net
Subject: <Swing Dev> RFR: 8198990 : Move SwingSet2 from closed to OpenJDK

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

SwingSet2 has always been in closed, mostly because of some images that could not be moved to OpenJDK.

Due diligence has been done and replacements have been found.
This new version has already been reviewed internally.

I will be removing the closed version at the same time as pushing this.

-phil.





From chen.j.patrick at gmail.com  Wed Mar 21 08:54:37 2018
From: chen.j.patrick at gmail.com (Patrick Chen)
Date: Wed, 21 Mar 2018 09:54:37 +0100
Subject: <Swing Dev> [11] JDK-8191957: JFileChooser shows empty name
In-Reply-To: <6a7c2496-a678-44de-9e2b-e8d035d45e8c@default>
References: <c796237f-069c-4f7a-ac43-2db74342b72a@default>
 <6a7c2496-a678-44de-9e2b-e8d035d45e8c@default>
Message-ID: <CANmuJ8sjF=Xk4gPekL_kkDD=EbUGekQBZHD18AN=37axbb0iwA@mail.gmail.com>

Hi,
In your webreview :

dir.getPath() is depreciated since java 8.0

cheers

Pc



2018-03-16 12:11 GMT+01:00 Pankaj Bansal <pankaj.b.bansal at oracle.com>:

> Hi Krishna,
>
> Thanks for the review.
>
> I have incorporated the review comments. Please have a look.
> Webrev: http://cr.openjdk.java.net/~pbansal/8191957/webrev.01/
>
> Regards,
> Pankaj Bansal
>
> -----Original Message-----
> From: Krishna Addepalli
> Sent: Friday, March 16, 2018 4:03 PM
> To: swing-dev at openjdk.java.net
> Subject: Re: <Swing Dev> [11] JDK-8191957: JFileChooser shows empty name
>
> Hi Pankaj,
>
> The fix looks fine to me. However I have couple points:
>
> 1. Please put a comment at the line of fix, about how Windows 10 treats
> the Desktop folder.
> 2. The test case can be a headless one, since you are not creating any gui
> components.
>
> Thanks,
> Krishna
>
>
> -----Original Message-----
> From: swing-dev-request at openjdk.java.net <swing-dev-request at openjdk.
> java.net>
> Sent: Monday, March 12, 2018 5:30 PM
> To: swing-dev at openjdk.java.net
> Subject: swing-dev Digest, Vol 131, Issue 25
>
> Send swing-dev mailing list submissions to
>         swing-dev at openjdk.java.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://mail.openjdk.java.net/mailman/listinfo/swing-dev
> or, via email, send a message with subject or body 'help' to
>         swing-dev-request at openjdk.java.net
>
> You can reach the person managing the list at
>         swing-dev-owner at openjdk.java.net
>
> When replying, please edit your Subject line so it is more specific than
> "Re: Contents of swing-dev digest..."
>
>
> Today's Topics:
>
>    1.  [11] JDK-8191957: JFileChooser shows empty name for external
>       drives shown under Desktop (Pankaj Bansal)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 12 Mar 2018 01:52:35 -0700 (PDT)
> From: Pankaj Bansal <pankaj.b.bansal at oracle.com>
> To: swing-dev at openjdk.java.net
> Subject: <Swing Dev> [11] JDK-8191957: JFileChooser shows empty name
>         for external drives shown under Desktop
> Message-ID: <065d066f-810c-4284-9de6-059f4235e61b at default>
> Content-Type: text/plain; charset="us-ascii"
>
> Hi All,
>
>
>
> Please review the test only fix for JDK 11.
>
>
>
> Bug:
>
> https://bugs.openjdk.java.net/browse/JDK-8191957
>
>
>
> webrev:
>
> http://cr.openjdk.java.net/~pbansal/8191957/webrev.00/
>
>
>
> Issue:
>
> In windows 10, the "External Drives" or "Removable drives" names are empty
> when root directory "Desktop" is selected in JFileChooser. Only the icon is
> shown and name is empty.
>
> Fix:
>
> The system folder names are found by calling FileSystemView.getSystemDisplayName,
> which in turn calls  Win32ShellFolderManager2.isFileSystemRoot. Here it
> was wrongly assumed that a drive will always be child of "DRIVES" or "MY
> PC". But in windows 10, the external drives are also shown as children of
> root directory "Desktop". Made changes to consider drives names which are
> children of "Desktop".
>
>
>
> Note:
>
> This is a windows 10 specific issues.
>
> You will need an removable drive attached to you system to test this.
>
>
>
> Regards,
>
> Pankaj Bansal
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://mail.openjdk.java.net/pipermail/swing-dev/
> attachments/20180312/784cc456/attachment-0001.html>
>
> End of swing-dev Digest, Vol 131, Issue 25
> ******************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20180321/ab398fc0/attachment.html>

From pankaj.b.bansal at oracle.com  Wed Mar 21 17:02:45 2018
From: pankaj.b.bansal at oracle.com (Pankaj Bansal)
Date: Wed, 21 Mar 2018 10:02:45 -0700 (PDT)
Subject: <Swing Dev> [11] JDK-8191957: JFileChooser shows empty name for
 external drives shown under Desktop
In-Reply-To: <47be1bb1-be13-488a-a9af-c43696032824@default>
References: <81badaad-78d4-4e71-8d4d-47a3a3067802@default>
 <40611eeb-7142-4aaf-b782-0957e6506101@default>
 <9c30f76b-3dbe-4575-bc12-8b6cf0e284af@default>
 <47be1bb1-be13-488a-a9af-c43696032824@default>
Message-ID: <de96aa77-987c-4cc9-a5d5-c79a7c8d5407@default>

Hi Jay/Patrick,

Thanks for the review.

@jay
<< More inputs:
<<Since the test case is valid only when we have windows 10 system with some external drive making the test case manual is also a good idea.
Done. I have updated the webrev with the manual test case.

@Patrick
<<In your webreview : 
<<dir.getPath() is depreciated since java 8.0
I looked at the documentation for the File.getPath. I could not find anything related to this being deprecated. Could you please point out where did you find that this is deprecated?
Also, just to point out this function was being used earlier also. I have not added a new call to this function.

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


Regards,
Pankaj Bansal
-----Original Message-----
From: Jayathirth D V 
Sent: Wednesday, March 21, 2018 12:45 AM
To: Pankaj Bansal; swing-dev at openjdk.java.net
Subject: RE: <Swing Dev> [11] JDK-8191957: JFileChooser shows empty name for external drives shown under Desktop

Hi Pankaj,

More inputs:
Since the test case is valid only when we have windows 10 system with some external drive making the test case manual is also a good idea.

Thanks,
Jay

-----Original Message-----
From: Jayathirth D V 
Sent: Wednesday, March 21, 2018 12:06 AM
To: Pankaj Bansal; swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [11] JDK-8191957: JFileChooser shows empty name for external drives shown under Desktop

Hi Pankaj,

I see that you have mentioned this bug is specific to Windows 10 and test case needs to be run with some Removable drive.
It better to capture this information in test case also as a comment or in jtreg summary.

In test case we have verification part like :
                if (fsv.getSystemDisplayName(file).isEmpty()) {
                    throw new RuntimeException(
                            "External Disk " + file + "name is empty");
                }
This code runs throw all the files under Desktop in my Windows 7 PC. So do we have any property in FileSystemView using which we can know that the file is of type external drive and then just check system display name for the same.

If we can't determine the file type as external drive using some property in FileSystemView, still the RuntimeException message you are throwing("External Disk " + file + "name is empty") can be misleading. I would recommend you to throw an Exception like -  "System display name for" + file + "is empty".

Also you have missed opening quote for the (Desktop") part of comment in Win32ShellFolderManager2.java.

Thanks,
Jay

-----Original Message-----
From: Pankaj Bansal 
Sent: Tuesday, March 20, 2018 11:11 PM
To: swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [11] JDK-8191957: JFileChooser shows empty name for external drives shown under Desktop

Hi All, 

Does anyone else have any feedback on this?

Regards,
Pankaj Bansal

-----Original Message-----
From: Krishna Addepalli 
Sent: Friday, March 16, 2018 4:48 PM
To: Pankaj Bansal; swing-dev at openjdk.java.net
Subject: RE: <Swing Dev> [11] JDK-8191957: JFileChooser shows empty name for external drives shown under Desktop

Hi Pankaj,

The changes look fine to me.

Thanks,
Krishna

-----Original Message-----
From: Pankaj Bansal 
Sent: Friday, March 16, 2018 4:42 PM
To: Krishna Addepalli <krishna.addepalli at oracle.com>; swing-dev at openjdk.java.net
Subject: RE: <Swing Dev> [11] JDK-8191957: JFileChooser shows empty name

Hi Krishna,

Thanks for the review.

I have incorporated the review comments. Please have a look.
Webrev: http://cr.openjdk.java.net/~pbansal/8191957/webrev.01/

Regards,
Pankaj Bansal

-----Original Message-----
From: Krishna Addepalli 
Sent: Friday, March 16, 2018 4:03 PM
To: swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [11] JDK-8191957: JFileChooser shows empty name

Hi Pankaj,

The fix looks fine to me. However I have couple points:

1. Please put a comment at the line of fix, about how Windows 10 treats the Desktop folder.
2. The test case can be a headless one, since you are not creating any gui components.

Thanks,
Krishna


-----Original Message-----
From: swing-dev-request at openjdk.java.net <swing-dev-request at openjdk.java.net> 
Sent: Monday, March 12, 2018 5:30 PM
To: swing-dev at openjdk.java.net
Subject: swing-dev Digest, Vol 131, Issue 25

Send swing-dev mailing list submissions to
	swing-dev at openjdk.java.net

To subscribe or unsubscribe via the World Wide Web, visit
	http://mail.openjdk.java.net/mailman/listinfo/swing-dev
or, via email, send a message with subject or body 'help' to
	swing-dev-request at openjdk.java.net

You can reach the person managing the list at
	swing-dev-owner at openjdk.java.net

When replying, please edit your Subject line so it is more specific than "Re: Contents of swing-dev digest..."


Today's Topics:

   1.  [11] JDK-8191957: JFileChooser shows empty name for external
      drives shown under Desktop (Pankaj Bansal)


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

Message: 1
Date: Mon, 12 Mar 2018 01:52:35 -0700 (PDT)
From: Pankaj Bansal <pankaj.b.bansal at oracle.com>
To: swing-dev at openjdk.java.net
Subject: <Swing Dev> [11] JDK-8191957: JFileChooser shows empty name
	for external drives shown under Desktop
Message-ID: <065d066f-810c-4284-9de6-059f4235e61b at default>
Content-Type: text/plain; charset="us-ascii"

Hi All,

 

Please review the test only fix for JDK 11.

 

Bug:

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

 	

webrev:

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

 

Issue:

In windows 10, the "External Drives" or "Removable drives" names are empty when root directory "Desktop" is selected in JFileChooser. Only the icon is shown and name is empty.

Fix:

The system folder names are found by calling FileSystemView.getSystemDisplayName, which in turn calls  Win32ShellFolderManager2.isFileSystemRoot. Here it was wrongly assumed that a drive will always be child of "DRIVES" or "MY PC". But in windows 10, the external drives are also shown as children of root directory "Desktop". Made changes to consider drives names which are children of "Desktop".

 

Note:

This is a windows 10 specific issues. 

You will need an removable drive attached to you system to test this.

 

Regards,

Pankaj Bansal

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

End of swing-dev Digest, Vol 131, Issue 25
******************************************


From prasanta.sadhukhan at oracle.com  Thu Mar 22 10:12:08 2018
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Thu, 22 Mar 2018 15:42:08 +0530
Subject: <Swing Dev> [11] RFR JDK-8199900:JEditorPane scrollToReference
 should support html5
Message-ID: <419ec876-98ae-bed0-075c-4fec5d07ae9a@oracle.com>

Hi All,

It needs to be noted that html <a name> tag is obsolete in html5? as per 
https://www.w3.org/TR/2011/WD-html-markup-20110405/a.html#a.attrs.name
and so we should use "id" attribute instead in 
JEditorPane.scrollToReference to conform to html5 specification.
As per https://www.w3schools.com/tags/att_global_id.asp, In HTML5, the 
id attribute can be used on *any* HTML element .

So, the proposed fix is to also check for "id" attribute to scroll to 
reference and not just rely on "name" attribute.

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

Not sure of how to approach for a testcase for this html5 addition. 
However, existing JEditorPane jtreg tests passed.

Regards
Prasanta

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

From jayathirth.d.v at oracle.com  Thu Mar 22 10:12:36 2018
From: jayathirth.d.v at oracle.com (Jayathirth D V)
Date: Thu, 22 Mar 2018 03:12:36 -0700 (PDT)
Subject: <Swing Dev> [11] JDK-8191957: JFileChooser shows empty name for
 external drives shown under Desktop
In-Reply-To: <de96aa77-987c-4cc9-a5d5-c79a7c8d5407@default>
References: <81badaad-78d4-4e71-8d4d-47a3a3067802@default>
 <40611eeb-7142-4aaf-b782-0957e6506101@default>
 <9c30f76b-3dbe-4575-bc12-8b6cf0e284af@default>
 <47be1bb1-be13-488a-a9af-c43696032824@default>
 <de96aa77-987c-4cc9-a5d5-c79a7c8d5407@default>
Message-ID: <9f82be9a-6335-4e8f-b6c2-b5d6274b67bf@default>

Hi Pankaj,

Instructions present in test case is :
        String instructions
        = "INSTRUCTIONS:" +
        "\n 1. This is a Windows 10 specific test. If you not on " +
        "Windows 10, just press Pass." +
        "\n 2. Make sure you have an External Drive attached to your " +
        "computer." +
        "\n 3. Open a JFileChooser by clicking on launch button." +
        "\n 4. In JFileChooser dropdown, there are two Desktop " +
        "locations." +
        "\n 5. One Desktop is child of My PC and one is parent of it." +
        "\n 6. Open the parent Desktop folder." +
        "\n 7. You should see the External Drive in the list of " +
        "files." +
        "\n 8. If the External drive name is empty (it does not have " +
        "any name), the name is incorrect, else it is correct." +
        "\n 9. Press Pass or Press Fail depending upon, whether the " +
        "External Drive name was correct or incorrect.";

Point 1 : Should be "This is a Windows 10 specific test. If you are not on Windows 10, just press Pass."
Point 8 & 9 is little bit confusing we can simplify it as : If the External drive name is empty (it does not have any name), press fail otherwise press pass.

Also as previously pointed out  "Also you have missed opening quote for the (Desktop") part of comment in Win32ShellFolderManager2.java." Needs to be corrected.

Thanks,
Jay

-----Original Message-----
From: Pankaj Bansal 
Sent: Wednesday, March 21, 2018 10:33 PM
To: Jayathirth D V; swing-dev at openjdk.java.net; Patrick Chen
Subject: RE: <Swing Dev> [11] JDK-8191957: JFileChooser shows empty name for external drives shown under Desktop

Hi Jay/Patrick,

Thanks for the review.

@jay
<< More inputs:
<<Since the test case is valid only when we have windows 10 system with some external drive making the test case manual is also a good idea.
Done. I have updated the webrev with the manual test case.

@Patrick
<<In your webreview : 
<<dir.getPath() is depreciated since java 8.0 I looked at the documentation for the File.getPath. I could not find anything related to this being deprecated. Could you please point out where did you find that this is deprecated?
Also, just to point out this function was being used earlier also. I have not added a new call to this function.

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


Regards,
Pankaj Bansal
-----Original Message-----
From: Jayathirth D V
Sent: Wednesday, March 21, 2018 12:45 AM
To: Pankaj Bansal; swing-dev at openjdk.java.net
Subject: RE: <Swing Dev> [11] JDK-8191957: JFileChooser shows empty name for external drives shown under Desktop

Hi Pankaj,

More inputs:
Since the test case is valid only when we have windows 10 system with some external drive making the test case manual is also a good idea.

Thanks,
Jay

-----Original Message-----
From: Jayathirth D V
Sent: Wednesday, March 21, 2018 12:06 AM
To: Pankaj Bansal; swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [11] JDK-8191957: JFileChooser shows empty name for external drives shown under Desktop

Hi Pankaj,

I see that you have mentioned this bug is specific to Windows 10 and test case needs to be run with some Removable drive.
It better to capture this information in test case also as a comment or in jtreg summary.

In test case we have verification part like :
                if (fsv.getSystemDisplayName(file).isEmpty()) {
                    throw new RuntimeException(
                            "External Disk " + file + "name is empty");
                }
This code runs throw all the files under Desktop in my Windows 7 PC. So do we have any property in FileSystemView using which we can know that the file is of type external drive and then just check system display name for the same.

If we can't determine the file type as external drive using some property in FileSystemView, still the RuntimeException message you are throwing("External Disk " + file + "name is empty") can be misleading. I would recommend you to throw an Exception like -  "System display name for" + file + "is empty".

Also you have missed opening quote for the (Desktop") part of comment in Win32ShellFolderManager2.java.

Thanks,
Jay

-----Original Message-----
From: Pankaj Bansal
Sent: Tuesday, March 20, 2018 11:11 PM
To: swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [11] JDK-8191957: JFileChooser shows empty name for external drives shown under Desktop

Hi All, 

Does anyone else have any feedback on this?

Regards,
Pankaj Bansal

-----Original Message-----
From: Krishna Addepalli
Sent: Friday, March 16, 2018 4:48 PM
To: Pankaj Bansal; swing-dev at openjdk.java.net
Subject: RE: <Swing Dev> [11] JDK-8191957: JFileChooser shows empty name for external drives shown under Desktop

Hi Pankaj,

The changes look fine to me.

Thanks,
Krishna

-----Original Message-----
From: Pankaj Bansal
Sent: Friday, March 16, 2018 4:42 PM
To: Krishna Addepalli <krishna.addepalli at oracle.com>; swing-dev at openjdk.java.net
Subject: RE: <Swing Dev> [11] JDK-8191957: JFileChooser shows empty name

Hi Krishna,

Thanks for the review.

I have incorporated the review comments. Please have a look.
Webrev: http://cr.openjdk.java.net/~pbansal/8191957/webrev.01/

Regards,
Pankaj Bansal

-----Original Message-----
From: Krishna Addepalli
Sent: Friday, March 16, 2018 4:03 PM
To: swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [11] JDK-8191957: JFileChooser shows empty name

Hi Pankaj,

The fix looks fine to me. However I have couple points:

1. Please put a comment at the line of fix, about how Windows 10 treats the Desktop folder.
2. The test case can be a headless one, since you are not creating any gui components.

Thanks,
Krishna


-----Original Message-----
From: swing-dev-request at openjdk.java.net <swing-dev-request at openjdk.java.net>
Sent: Monday, March 12, 2018 5:30 PM
To: swing-dev at openjdk.java.net
Subject: swing-dev Digest, Vol 131, Issue 25

Send swing-dev mailing list submissions to
	swing-dev at openjdk.java.net

To subscribe or unsubscribe via the World Wide Web, visit
	http://mail.openjdk.java.net/mailman/listinfo/swing-dev
or, via email, send a message with subject or body 'help' to
	swing-dev-request at openjdk.java.net

You can reach the person managing the list at
	swing-dev-owner at openjdk.java.net

When replying, please edit your Subject line so it is more specific than "Re: Contents of swing-dev digest..."


Today's Topics:

   1.  [11] JDK-8191957: JFileChooser shows empty name for external
      drives shown under Desktop (Pankaj Bansal)


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

Message: 1
Date: Mon, 12 Mar 2018 01:52:35 -0700 (PDT)
From: Pankaj Bansal <pankaj.b.bansal at oracle.com>
To: swing-dev at openjdk.java.net
Subject: <Swing Dev> [11] JDK-8191957: JFileChooser shows empty name
	for external drives shown under Desktop
Message-ID: <065d066f-810c-4284-9de6-059f4235e61b at default>
Content-Type: text/plain; charset="us-ascii"

Hi All,

 

Please review the test only fix for JDK 11.

 

Bug:

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

 	

webrev:

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

 

Issue:

In windows 10, the "External Drives" or "Removable drives" names are empty when root directory "Desktop" is selected in JFileChooser. Only the icon is shown and name is empty.

Fix:

The system folder names are found by calling FileSystemView.getSystemDisplayName, which in turn calls  Win32ShellFolderManager2.isFileSystemRoot. Here it was wrongly assumed that a drive will always be child of "DRIVES" or "MY PC". But in windows 10, the external drives are also shown as children of root directory "Desktop". Made changes to consider drives names which are children of "Desktop".

 

Note:

This is a windows 10 specific issues. 

You will need an removable drive attached to you system to test this.

 

Regards,

Pankaj Bansal

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

End of swing-dev Digest, Vol 131, Issue 25
******************************************


From jayathirth.d.v at oracle.com  Thu Mar 22 10:15:17 2018
From: jayathirth.d.v at oracle.com (Jayathirth D V)
Date: Thu, 22 Mar 2018 03:15:17 -0700 (PDT)
Subject: <Swing Dev> [11] JDK-8191957: JFileChooser shows empty name for
 external drives shown under Desktop
In-Reply-To: <9f82be9a-6335-4e8f-b6c2-b5d6274b67bf@default>
References: <81badaad-78d4-4e71-8d4d-47a3a3067802@default>
 <40611eeb-7142-4aaf-b782-0957e6506101@default>
 <9c30f76b-3dbe-4575-bc12-8b6cf0e284af@default>
 <47be1bb1-be13-488a-a9af-c43696032824@default>
 <de96aa77-987c-4cc9-a5d5-c79a7c8d5407@default>
 <9f82be9a-6335-4e8f-b6c2-b5d6274b67bf@default>
Message-ID: <ca87ee26-2a26-4c78-9c20-8d2ec653999c@default>

Hi Pankaj,

Also I think we need to add @key headful tag in jtreg comment.

Thanks,
Jay

-----Original Message-----
From: Jayathirth D V 
Sent: Thursday, March 22, 2018 3:43 PM
To: Pankaj Bansal; swing-dev at openjdk.java.net; Patrick Chen
Subject: Re: <Swing Dev> [11] JDK-8191957: JFileChooser shows empty name for external drives shown under Desktop

Hi Pankaj,

Instructions present in test case is :
        String instructions
        = "INSTRUCTIONS:" +
        "\n 1. This is a Windows 10 specific test. If you not on " +
        "Windows 10, just press Pass." +
        "\n 2. Make sure you have an External Drive attached to your " +
        "computer." +
        "\n 3. Open a JFileChooser by clicking on launch button." +
        "\n 4. In JFileChooser dropdown, there are two Desktop " +
        "locations." +
        "\n 5. One Desktop is child of My PC and one is parent of it." +
        "\n 6. Open the parent Desktop folder." +
        "\n 7. You should see the External Drive in the list of " +
        "files." +
        "\n 8. If the External drive name is empty (it does not have " +
        "any name), the name is incorrect, else it is correct." +
        "\n 9. Press Pass or Press Fail depending upon, whether the " +
        "External Drive name was correct or incorrect.";

Point 1 : Should be "This is a Windows 10 specific test. If you are not on Windows 10, just press Pass."
Point 8 & 9 is little bit confusing we can simplify it as : If the External drive name is empty (it does not have any name), press fail otherwise press pass.

Also as previously pointed out  "Also you have missed opening quote for the (Desktop") part of comment in Win32ShellFolderManager2.java." Needs to be corrected.

Thanks,
Jay

-----Original Message-----
From: Pankaj Bansal 
Sent: Wednesday, March 21, 2018 10:33 PM
To: Jayathirth D V; swing-dev at openjdk.java.net; Patrick Chen
Subject: RE: <Swing Dev> [11] JDK-8191957: JFileChooser shows empty name for external drives shown under Desktop

Hi Jay/Patrick,

Thanks for the review.

@jay
<< More inputs:
<<Since the test case is valid only when we have windows 10 system with some external drive making the test case manual is also a good idea.
Done. I have updated the webrev with the manual test case.

@Patrick
<<In your webreview : 
<<dir.getPath() is depreciated since java 8.0 I looked at the documentation for the File.getPath. I could not find anything related to this being deprecated. Could you please point out where did you find that this is deprecated?
Also, just to point out this function was being used earlier also. I have not added a new call to this function.

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


Regards,
Pankaj Bansal
-----Original Message-----
From: Jayathirth D V
Sent: Wednesday, March 21, 2018 12:45 AM
To: Pankaj Bansal; swing-dev at openjdk.java.net
Subject: RE: <Swing Dev> [11] JDK-8191957: JFileChooser shows empty name for external drives shown under Desktop

Hi Pankaj,

More inputs:
Since the test case is valid only when we have windows 10 system with some external drive making the test case manual is also a good idea.

Thanks,
Jay

-----Original Message-----
From: Jayathirth D V
Sent: Wednesday, March 21, 2018 12:06 AM
To: Pankaj Bansal; swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [11] JDK-8191957: JFileChooser shows empty name for external drives shown under Desktop

Hi Pankaj,

I see that you have mentioned this bug is specific to Windows 10 and test case needs to be run with some Removable drive.
It better to capture this information in test case also as a comment or in jtreg summary.

In test case we have verification part like :
                if (fsv.getSystemDisplayName(file).isEmpty()) {
                    throw new RuntimeException(
                            "External Disk " + file + "name is empty");
                }
This code runs throw all the files under Desktop in my Windows 7 PC. So do we have any property in FileSystemView using which we can know that the file is of type external drive and then just check system display name for the same.

If we can't determine the file type as external drive using some property in FileSystemView, still the RuntimeException message you are throwing("External Disk " + file + "name is empty") can be misleading. I would recommend you to throw an Exception like -  "System display name for" + file + "is empty".

Also you have missed opening quote for the (Desktop") part of comment in Win32ShellFolderManager2.java.

Thanks,
Jay

-----Original Message-----
From: Pankaj Bansal
Sent: Tuesday, March 20, 2018 11:11 PM
To: swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [11] JDK-8191957: JFileChooser shows empty name for external drives shown under Desktop

Hi All, 

Does anyone else have any feedback on this?

Regards,
Pankaj Bansal

-----Original Message-----
From: Krishna Addepalli
Sent: Friday, March 16, 2018 4:48 PM
To: Pankaj Bansal; swing-dev at openjdk.java.net
Subject: RE: <Swing Dev> [11] JDK-8191957: JFileChooser shows empty name for external drives shown under Desktop

Hi Pankaj,

The changes look fine to me.

Thanks,
Krishna

-----Original Message-----
From: Pankaj Bansal
Sent: Friday, March 16, 2018 4:42 PM
To: Krishna Addepalli <krishna.addepalli at oracle.com>; swing-dev at openjdk.java.net
Subject: RE: <Swing Dev> [11] JDK-8191957: JFileChooser shows empty name

Hi Krishna,

Thanks for the review.

I have incorporated the review comments. Please have a look.
Webrev: http://cr.openjdk.java.net/~pbansal/8191957/webrev.01/

Regards,
Pankaj Bansal

-----Original Message-----
From: Krishna Addepalli
Sent: Friday, March 16, 2018 4:03 PM
To: swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [11] JDK-8191957: JFileChooser shows empty name

Hi Pankaj,

The fix looks fine to me. However I have couple points:

1. Please put a comment at the line of fix, about how Windows 10 treats the Desktop folder.
2. The test case can be a headless one, since you are not creating any gui components.

Thanks,
Krishna


-----Original Message-----
From: swing-dev-request at openjdk.java.net <swing-dev-request at openjdk.java.net>
Sent: Monday, March 12, 2018 5:30 PM
To: swing-dev at openjdk.java.net
Subject: swing-dev Digest, Vol 131, Issue 25

Send swing-dev mailing list submissions to
	swing-dev at openjdk.java.net

To subscribe or unsubscribe via the World Wide Web, visit
	http://mail.openjdk.java.net/mailman/listinfo/swing-dev
or, via email, send a message with subject or body 'help' to
	swing-dev-request at openjdk.java.net

You can reach the person managing the list at
	swing-dev-owner at openjdk.java.net

When replying, please edit your Subject line so it is more specific than "Re: Contents of swing-dev digest..."


Today's Topics:

   1.  [11] JDK-8191957: JFileChooser shows empty name for external
      drives shown under Desktop (Pankaj Bansal)


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

Message: 1
Date: Mon, 12 Mar 2018 01:52:35 -0700 (PDT)
From: Pankaj Bansal <pankaj.b.bansal at oracle.com>
To: swing-dev at openjdk.java.net
Subject: <Swing Dev> [11] JDK-8191957: JFileChooser shows empty name
	for external drives shown under Desktop
Message-ID: <065d066f-810c-4284-9de6-059f4235e61b at default>
Content-Type: text/plain; charset="us-ascii"

Hi All,

 

Please review the test only fix for JDK 11.

 

Bug:

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

 	

webrev:

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

 

Issue:

In windows 10, the "External Drives" or "Removable drives" names are empty when root directory "Desktop" is selected in JFileChooser. Only the icon is shown and name is empty.

Fix:

The system folder names are found by calling FileSystemView.getSystemDisplayName, which in turn calls  Win32ShellFolderManager2.isFileSystemRoot. Here it was wrongly assumed that a drive will always be child of "DRIVES" or "MY PC". But in windows 10, the external drives are also shown as children of root directory "Desktop". Made changes to consider drives names which are children of "Desktop".

 

Note:

This is a windows 10 specific issues. 

You will need an removable drive attached to you system to test this.

 

Regards,

Pankaj Bansal

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

End of swing-dev Digest, Vol 131, Issue 25
******************************************


From pankaj.b.bansal at oracle.com  Thu Mar 22 12:09:23 2018
From: pankaj.b.bansal at oracle.com (Pankaj Bansal)
Date: Thu, 22 Mar 2018 05:09:23 -0700 (PDT)
Subject: <Swing Dev> [11] JDK-8191957: JFileChooser shows empty name for
 external drives shown under Desktop
In-Reply-To: <ca87ee26-2a26-4c78-9c20-8d2ec653999c@default>
References: <81badaad-78d4-4e71-8d4d-47a3a3067802@default>
 <40611eeb-7142-4aaf-b782-0957e6506101@default>
 <9c30f76b-3dbe-4575-bc12-8b6cf0e284af@default>
 <47be1bb1-be13-488a-a9af-c43696032824@default>
 <de96aa77-987c-4cc9-a5d5-c79a7c8d5407@default>
 <9f82be9a-6335-4e8f-b6c2-b5d6274b67bf@default>
 <ca87ee26-2a26-4c78-9c20-8d2ec653999c@default>
Message-ID: <a6d515f7-4f88-4953-940d-684a90fa50f7@default>

Hi Jay,

Thanks for the review.

I have incorporated the review comments. Please have a look.
Webrev:
http://cr.openjdk.java.net/~pbansal/8191957/webrev.03/

Regards,
Pankaj Bansal

-----Original Message-----
From: Jayathirth D V 
Sent: Thursday, March 22, 2018 3:45 PM
To: Pankaj Bansal; swing-dev at openjdk.java.net; Patrick Chen
Subject: RE: <Swing Dev> [11] JDK-8191957: JFileChooser shows empty name for external drives shown under Desktop

Hi Pankaj,

Also I think we need to add @key headful tag in jtreg comment.

Thanks,
Jay

-----Original Message-----
From: Jayathirth D V 
Sent: Thursday, March 22, 2018 3:43 PM
To: Pankaj Bansal; swing-dev at openjdk.java.net; Patrick Chen
Subject: Re: <Swing Dev> [11] JDK-8191957: JFileChooser shows empty name for external drives shown under Desktop

Hi Pankaj,

Instructions present in test case is :
        String instructions
        = "INSTRUCTIONS:" +
        "\n 1. This is a Windows 10 specific test. If you not on " +
        "Windows 10, just press Pass." +
        "\n 2. Make sure you have an External Drive attached to your " +
        "computer." +
        "\n 3. Open a JFileChooser by clicking on launch button." +
        "\n 4. In JFileChooser dropdown, there are two Desktop " +
        "locations." +
        "\n 5. One Desktop is child of My PC and one is parent of it." +
        "\n 6. Open the parent Desktop folder." +
        "\n 7. You should see the External Drive in the list of " +
        "files." +
        "\n 8. If the External drive name is empty (it does not have " +
        "any name), the name is incorrect, else it is correct." +
        "\n 9. Press Pass or Press Fail depending upon, whether the " +
        "External Drive name was correct or incorrect.";

Point 1 : Should be "This is a Windows 10 specific test. If you are not on Windows 10, just press Pass."
Point 8 & 9 is little bit confusing we can simplify it as : If the External drive name is empty (it does not have any name), press fail otherwise press pass.

Also as previously pointed out  "Also you have missed opening quote for the (Desktop") part of comment in Win32ShellFolderManager2.java." Needs to be corrected.

Thanks,
Jay

-----Original Message-----
From: Pankaj Bansal 
Sent: Wednesday, March 21, 2018 10:33 PM
To: Jayathirth D V; swing-dev at openjdk.java.net; Patrick Chen
Subject: RE: <Swing Dev> [11] JDK-8191957: JFileChooser shows empty name for external drives shown under Desktop

Hi Jay/Patrick,

Thanks for the review.

@jay
<< More inputs:
<<Since the test case is valid only when we have windows 10 system with some external drive making the test case manual is also a good idea.
Done. I have updated the webrev with the manual test case.

@Patrick
<<In your webreview : 
<<dir.getPath() is depreciated since java 8.0 I looked at the documentation for the File.getPath. I could not find anything related to this being deprecated. Could you please point out where did you find that this is deprecated?
Also, just to point out this function was being used earlier also. I have not added a new call to this function.

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


Regards,
Pankaj Bansal
-----Original Message-----
From: Jayathirth D V
Sent: Wednesday, March 21, 2018 12:45 AM
To: Pankaj Bansal; swing-dev at openjdk.java.net
Subject: RE: <Swing Dev> [11] JDK-8191957: JFileChooser shows empty name for external drives shown under Desktop

Hi Pankaj,

More inputs:
Since the test case is valid only when we have windows 10 system with some external drive making the test case manual is also a good idea.

Thanks,
Jay

-----Original Message-----
From: Jayathirth D V
Sent: Wednesday, March 21, 2018 12:06 AM
To: Pankaj Bansal; swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [11] JDK-8191957: JFileChooser shows empty name for external drives shown under Desktop

Hi Pankaj,

I see that you have mentioned this bug is specific to Windows 10 and test case needs to be run with some Removable drive.
It better to capture this information in test case also as a comment or in jtreg summary.

In test case we have verification part like :
                if (fsv.getSystemDisplayName(file).isEmpty()) {
                    throw new RuntimeException(
                            "External Disk " + file + "name is empty");
                }
This code runs throw all the files under Desktop in my Windows 7 PC. So do we have any property in FileSystemView using which we can know that the file is of type external drive and then just check system display name for the same.

If we can't determine the file type as external drive using some property in FileSystemView, still the RuntimeException message you are throwing("External Disk " + file + "name is empty") can be misleading. I would recommend you to throw an Exception like -  "System display name for" + file + "is empty".

Also you have missed opening quote for the (Desktop") part of comment in Win32ShellFolderManager2.java.

Thanks,
Jay

-----Original Message-----
From: Pankaj Bansal
Sent: Tuesday, March 20, 2018 11:11 PM
To: swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [11] JDK-8191957: JFileChooser shows empty name for external drives shown under Desktop

Hi All, 

Does anyone else have any feedback on this?

Regards,
Pankaj Bansal

-----Original Message-----
From: Krishna Addepalli
Sent: Friday, March 16, 2018 4:48 PM
To: Pankaj Bansal; swing-dev at openjdk.java.net
Subject: RE: <Swing Dev> [11] JDK-8191957: JFileChooser shows empty name for external drives shown under Desktop

Hi Pankaj,

The changes look fine to me.

Thanks,
Krishna

-----Original Message-----
From: Pankaj Bansal
Sent: Friday, March 16, 2018 4:42 PM
To: Krishna Addepalli <krishna.addepalli at oracle.com>; swing-dev at openjdk.java.net
Subject: RE: <Swing Dev> [11] JDK-8191957: JFileChooser shows empty name

Hi Krishna,

Thanks for the review.

I have incorporated the review comments. Please have a look.
Webrev: http://cr.openjdk.java.net/~pbansal/8191957/webrev.01/

Regards,
Pankaj Bansal

-----Original Message-----
From: Krishna Addepalli
Sent: Friday, March 16, 2018 4:03 PM
To: swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [11] JDK-8191957: JFileChooser shows empty name

Hi Pankaj,

The fix looks fine to me. However I have couple points:

1. Please put a comment at the line of fix, about how Windows 10 treats the Desktop folder.
2. The test case can be a headless one, since you are not creating any gui components.

Thanks,
Krishna


-----Original Message-----
From: swing-dev-request at openjdk.java.net <swing-dev-request at openjdk.java.net>
Sent: Monday, March 12, 2018 5:30 PM
To: swing-dev at openjdk.java.net
Subject: swing-dev Digest, Vol 131, Issue 25

Send swing-dev mailing list submissions to
	swing-dev at openjdk.java.net

To subscribe or unsubscribe via the World Wide Web, visit
	http://mail.openjdk.java.net/mailman/listinfo/swing-dev
or, via email, send a message with subject or body 'help' to
	swing-dev-request at openjdk.java.net

You can reach the person managing the list at
	swing-dev-owner at openjdk.java.net

When replying, please edit your Subject line so it is more specific than "Re: Contents of swing-dev digest..."


Today's Topics:

   1.  [11] JDK-8191957: JFileChooser shows empty name for external
      drives shown under Desktop (Pankaj Bansal)


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

Message: 1
Date: Mon, 12 Mar 2018 01:52:35 -0700 (PDT)
From: Pankaj Bansal <pankaj.b.bansal at oracle.com>
To: swing-dev at openjdk.java.net
Subject: <Swing Dev> [11] JDK-8191957: JFileChooser shows empty name
	for external drives shown under Desktop
Message-ID: <065d066f-810c-4284-9de6-059f4235e61b at default>
Content-Type: text/plain; charset="us-ascii"

Hi All,

 

Please review the test only fix for JDK 11.

 

Bug:

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

 	

webrev:

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

 

Issue:

In windows 10, the "External Drives" or "Removable drives" names are empty when root directory "Desktop" is selected in JFileChooser. Only the icon is shown and name is empty.

Fix:

The system folder names are found by calling FileSystemView.getSystemDisplayName, which in turn calls  Win32ShellFolderManager2.isFileSystemRoot. Here it was wrongly assumed that a drive will always be child of "DRIVES" or "MY PC". But in windows 10, the external drives are also shown as children of root directory "Desktop". Made changes to consider drives names which are children of "Desktop".

 

Note:

This is a windows 10 specific issues. 

You will need an removable drive attached to you system to test this.

 

Regards,

Pankaj Bansal

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

End of swing-dev Digest, Vol 131, Issue 25
******************************************


From jayathirth.d.v at oracle.com  Thu Mar 22 13:06:50 2018
From: jayathirth.d.v at oracle.com (Jayathirth D V)
Date: Thu, 22 Mar 2018 06:06:50 -0700 (PDT)
Subject: <Swing Dev> [11] JDK-8191957: JFileChooser shows empty name for
 external drives shown under Desktop
In-Reply-To: <a6d515f7-4f88-4953-940d-684a90fa50f7@default>
References: <81badaad-78d4-4e71-8d4d-47a3a3067802@default>
 <40611eeb-7142-4aaf-b782-0957e6506101@default>
 <9c30f76b-3dbe-4575-bc12-8b6cf0e284af@default>
 <47be1bb1-be13-488a-a9af-c43696032824@default>
 <de96aa77-987c-4cc9-a5d5-c79a7c8d5407@default>
 <9f82be9a-6335-4e8f-b6c2-b5d6274b67bf@default>
 <ca87ee26-2a26-4c78-9c20-8d2ec653999c@default>
 <a6d515f7-4f88-4953-940d-684a90fa50f7@default>
Message-ID: <93b186a6-d5cc-435f-a873-000758b99a50@default>

Hi Pankaj,

Changes are fine.

Thanks,
Jay

-----Original Message-----
From: Pankaj Bansal 
Sent: Thursday, March 22, 2018 5:39 PM
To: Jayathirth D V; swing-dev at openjdk.java.net
Subject: RE: <Swing Dev> [11] JDK-8191957: JFileChooser shows empty name for external drives shown under Desktop

Hi Jay,

Thanks for the review.

I have incorporated the review comments. Please have a look.
Webrev:
http://cr.openjdk.java.net/~pbansal/8191957/webrev.03/

Regards,
Pankaj Bansal

-----Original Message-----
From: Jayathirth D V 
Sent: Thursday, March 22, 2018 3:45 PM
To: Pankaj Bansal; swing-dev at openjdk.java.net; Patrick Chen
Subject: RE: <Swing Dev> [11] JDK-8191957: JFileChooser shows empty name for external drives shown under Desktop

Hi Pankaj,

Also I think we need to add @key headful tag in jtreg comment.

Thanks,
Jay

-----Original Message-----
From: Jayathirth D V 
Sent: Thursday, March 22, 2018 3:43 PM
To: Pankaj Bansal; swing-dev at openjdk.java.net; Patrick Chen
Subject: Re: <Swing Dev> [11] JDK-8191957: JFileChooser shows empty name for external drives shown under Desktop

Hi Pankaj,

Instructions present in test case is :
        String instructions
        = "INSTRUCTIONS:" +
        "\n 1. This is a Windows 10 specific test. If you not on " +
        "Windows 10, just press Pass." +
        "\n 2. Make sure you have an External Drive attached to your " +
        "computer." +
        "\n 3. Open a JFileChooser by clicking on launch button." +
        "\n 4. In JFileChooser dropdown, there are two Desktop " +
        "locations." +
        "\n 5. One Desktop is child of My PC and one is parent of it." +
        "\n 6. Open the parent Desktop folder." +
        "\n 7. You should see the External Drive in the list of " +
        "files." +
        "\n 8. If the External drive name is empty (it does not have " +
        "any name), the name is incorrect, else it is correct." +
        "\n 9. Press Pass or Press Fail depending upon, whether the " +
        "External Drive name was correct or incorrect.";

Point 1 : Should be "This is a Windows 10 specific test. If you are not on Windows 10, just press Pass."
Point 8 & 9 is little bit confusing we can simplify it as : If the External drive name is empty (it does not have any name), press fail otherwise press pass.

Also as previously pointed out  "Also you have missed opening quote for the (Desktop") part of comment in Win32ShellFolderManager2.java." Needs to be corrected.

Thanks,
Jay

-----Original Message-----
From: Pankaj Bansal 
Sent: Wednesday, March 21, 2018 10:33 PM
To: Jayathirth D V; swing-dev at openjdk.java.net; Patrick Chen
Subject: RE: <Swing Dev> [11] JDK-8191957: JFileChooser shows empty name for external drives shown under Desktop

Hi Jay/Patrick,

Thanks for the review.

@jay
<< More inputs:
<<Since the test case is valid only when we have windows 10 system with some external drive making the test case manual is also a good idea.
Done. I have updated the webrev with the manual test case.

@Patrick
<<In your webreview : 
<<dir.getPath() is depreciated since java 8.0 I looked at the documentation for the File.getPath. I could not find anything related to this being deprecated. Could you please point out where did you find that this is deprecated?
Also, just to point out this function was being used earlier also. I have not added a new call to this function.

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


Regards,
Pankaj Bansal
-----Original Message-----
From: Jayathirth D V
Sent: Wednesday, March 21, 2018 12:45 AM
To: Pankaj Bansal; swing-dev at openjdk.java.net
Subject: RE: <Swing Dev> [11] JDK-8191957: JFileChooser shows empty name for external drives shown under Desktop

Hi Pankaj,

More inputs:
Since the test case is valid only when we have windows 10 system with some external drive making the test case manual is also a good idea.

Thanks,
Jay

-----Original Message-----
From: Jayathirth D V
Sent: Wednesday, March 21, 2018 12:06 AM
To: Pankaj Bansal; swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [11] JDK-8191957: JFileChooser shows empty name for external drives shown under Desktop

Hi Pankaj,

I see that you have mentioned this bug is specific to Windows 10 and test case needs to be run with some Removable drive.
It better to capture this information in test case also as a comment or in jtreg summary.

In test case we have verification part like :
                if (fsv.getSystemDisplayName(file).isEmpty()) {
                    throw new RuntimeException(
                            "External Disk " + file + "name is empty");
                }
This code runs throw all the files under Desktop in my Windows 7 PC. So do we have any property in FileSystemView using which we can know that the file is of type external drive and then just check system display name for the same.

If we can't determine the file type as external drive using some property in FileSystemView, still the RuntimeException message you are throwing("External Disk " + file + "name is empty") can be misleading. I would recommend you to throw an Exception like -  "System display name for" + file + "is empty".

Also you have missed opening quote for the (Desktop") part of comment in Win32ShellFolderManager2.java.

Thanks,
Jay

-----Original Message-----
From: Pankaj Bansal
Sent: Tuesday, March 20, 2018 11:11 PM
To: swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [11] JDK-8191957: JFileChooser shows empty name for external drives shown under Desktop

Hi All, 

Does anyone else have any feedback on this?

Regards,
Pankaj Bansal

-----Original Message-----
From: Krishna Addepalli
Sent: Friday, March 16, 2018 4:48 PM
To: Pankaj Bansal; swing-dev at openjdk.java.net
Subject: RE: <Swing Dev> [11] JDK-8191957: JFileChooser shows empty name for external drives shown under Desktop

Hi Pankaj,

The changes look fine to me.

Thanks,
Krishna

-----Original Message-----
From: Pankaj Bansal
Sent: Friday, March 16, 2018 4:42 PM
To: Krishna Addepalli <krishna.addepalli at oracle.com>; swing-dev at openjdk.java.net
Subject: RE: <Swing Dev> [11] JDK-8191957: JFileChooser shows empty name

Hi Krishna,

Thanks for the review.

I have incorporated the review comments. Please have a look.
Webrev: http://cr.openjdk.java.net/~pbansal/8191957/webrev.01/

Regards,
Pankaj Bansal

-----Original Message-----
From: Krishna Addepalli
Sent: Friday, March 16, 2018 4:03 PM
To: swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [11] JDK-8191957: JFileChooser shows empty name

Hi Pankaj,

The fix looks fine to me. However I have couple points:

1. Please put a comment at the line of fix, about how Windows 10 treats the Desktop folder.
2. The test case can be a headless one, since you are not creating any gui components.

Thanks,
Krishna


-----Original Message-----
From: swing-dev-request at openjdk.java.net <swing-dev-request at openjdk.java.net>
Sent: Monday, March 12, 2018 5:30 PM
To: swing-dev at openjdk.java.net
Subject: swing-dev Digest, Vol 131, Issue 25

Send swing-dev mailing list submissions to
	swing-dev at openjdk.java.net

To subscribe or unsubscribe via the World Wide Web, visit
	http://mail.openjdk.java.net/mailman/listinfo/swing-dev
or, via email, send a message with subject or body 'help' to
	swing-dev-request at openjdk.java.net

You can reach the person managing the list at
	swing-dev-owner at openjdk.java.net

When replying, please edit your Subject line so it is more specific than "Re: Contents of swing-dev digest..."


Today's Topics:

   1.  [11] JDK-8191957: JFileChooser shows empty name for external
      drives shown under Desktop (Pankaj Bansal)


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

Message: 1
Date: Mon, 12 Mar 2018 01:52:35 -0700 (PDT)
From: Pankaj Bansal <pankaj.b.bansal at oracle.com>
To: swing-dev at openjdk.java.net
Subject: <Swing Dev> [11] JDK-8191957: JFileChooser shows empty name
	for external drives shown under Desktop
Message-ID: <065d066f-810c-4284-9de6-059f4235e61b at default>
Content-Type: text/plain; charset="us-ascii"

Hi All,

 

Please review the test only fix for JDK 11.

 

Bug:

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

 	

webrev:

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

 

Issue:

In windows 10, the "External Drives" or "Removable drives" names are empty when root directory "Desktop" is selected in JFileChooser. Only the icon is shown and name is empty.

Fix:

The system folder names are found by calling FileSystemView.getSystemDisplayName, which in turn calls  Win32ShellFolderManager2.isFileSystemRoot. Here it was wrongly assumed that a drive will always be child of "DRIVES" or "MY PC". But in windows 10, the external drives are also shown as children of root directory "Desktop". Made changes to consider drives names which are children of "Desktop".

 

Note:

This is a windows 10 specific issues. 

You will need an removable drive attached to you system to test this.

 

Regards,

Pankaj Bansal

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

End of swing-dev Digest, Vol 131, Issue 25
******************************************


From philip.race at oracle.com  Thu Mar 22 18:51:34 2018
From: philip.race at oracle.com (Phil Race)
Date: Thu, 22 Mar 2018 11:51:34 -0700
Subject: <Swing Dev> RFR: 8198990 : Move SwingSet2 from closed to OpenJDK
In-Reply-To: <78fe181c-3775-4225-9589-c87b6a761162@default>
References: <9cec067c-7795-03c6-8f8a-3b5c508c71fa@oracle.com>
 <78fe181c-3775-4225-9589-c87b6a761162@default>
Message-ID: <de341ab7-39ed-547c-f9e3-c0030ac40524@oracle.com>

They get created when you revert, they aren't there because of any conflict.
They should not be in the patch .. just got caught up in the file list.
Here's a webrev that excludes them

http://cr.openjdk.java.net/~prr/8198990.1

-phil.


On 03/20/2018 11:45 PM, Krishna Addepalli wrote:
> Hi Phil,
>
> I see that there are these files in the patch:
>
> src/demo/share/jfc/SwingSet2/SwingSet2.java.orig
> src/demo/share/jfc/SwingSet2/resources/images/About.jpg.orig
> src/demo/share/jfc/SwingSet2/resources/images/tooltip/cow.gif.orig
>
> As per my understanding, these files get created when there are any merge conflicts in the source.
> Not sure about their purpose here.
>
> Thanks,
> Krishna
>
> -----Original Message-----
> From: Phil Race
> Sent: Wednesday, March 21, 2018 1:25 AM
> To: swing-dev at openjdk.java.net
> Subject: <Swing Dev> RFR: 8198990 : Move SwingSet2 from closed to OpenJDK
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8198990
> Webrev: http://cr.openjdk.java.net/~prr/8198990/
>
> SwingSet2 has always been in closed, mostly because of some images that could not be moved to OpenJDK.
>
> Due diligence has been done and replacements have been found.
> This new version has already been reviewed internally.
>
> I will be removing the closed version at the same time as pushing this.
>
> -phil.
>
>
>



From Sergey.Bylokhov at oracle.com  Thu Mar 22 22:14:19 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 22 Mar 2018 15:14:19 -0700
Subject: <Swing Dev> [11] RFR JDK-8189687:Swing: Invalid position of
 candidate pop-up of InputMethod in Hi-DPI on Windows
In-Reply-To: <a8fa809c-3c83-7ef5-8783-03150b565b76@oracle.com>
References: <5e0216fa-11ba-9408-864c-0d54f819d073@oracle.com>
 <c0f29625-7c8c-4571-89dd-67d61cd1d8c5@default>
 <56e2135b-5b54-fce0-df1b-7deda03e9b44@oracle.com>
 <bc9977cb-88f7-4abc-972f-3f6110bc10e7@default>
 <a8fa809c-3c83-7ef5-8783-03150b565b76@oracle.com>
Message-ID: <e868ccf9-0af6-7caa-2869-d8cb22e794a9@oracle.com>

Hi, Prasanta.
Did you check why the "InputMethodContext.getTextLocation()" returns 
non-scaled rectangle? Maybe we should do this inside InputMethodContext()?

On 20/03/2018 22:17, Prasanta Sadhukhan wrote:
> Hi Krishna,
> 
> Yes, I did not provide any since the testcase needs to be manual and 
> would have to contain lots of instructions of how to install Japanese 
> language and changing the input mode to hiragana
> and also similar fix of input method earlier did not have a testcase for 
> similar reason.
> 
> Regards
> Prasanta
> On 3/20/2018 8:42 PM, Krishna Addepalli wrote:
>>
>> Hi Prasanta,
>>
>> Now the changes look fine. However, I noticed that there is no 
>> testcase associated with this fix. Is that intentional?
>>
>> Thanks,
>>
>> Krishna
>>
>> *From:*Prasanta Sadhukhan
>> *Sent:* Tuesday, March 20, 2018 5:04 PM
>> *To:* Krishna Addepalli <krishna.addepalli at oracle.com>; 
>> swing-dev at openjdk.java.net
>> *Subject:* Re: <Swing Dev> [11] RFR JDK-8189687:Swing: Invalid 
>> position of candidate pop-up of InputMethod in Hi-DPI on Windows
>>
>> Thanks Krishna for your comment. Modified webrev catering to retrieval 
>> of scalefactor of the active monitor being shown
>>
>> http://cr.openjdk.java.net/~psadhukhan/8189687/webrev.01/ 
>> <http://cr.openjdk.java.net/%7Epsadhukhan/8189687/webrev.01/>
>>
>> Regards
>> Prasanta
>>
>> On 3/20/2018 2:40 PM, Krishna Addepalli wrote:
>>
>>     Hi Prasanta,
>>
>>     I have couple questions regarding your fix:
>>
>>     1.The AffineTransform object should be retrieved from the Screen
>>     on which the window is showing, whereas in your fix, you are
>>     directly getting it from the default screen. In multi screen
>>     environment, it may not be aligned correctly.
>>
>>     2.Is there any reason to retrieve the object in the top. I mean,
>>     the AffineTransform object can be declared inside the ?if
>>     (haveActiveClient())? block, at the point of use.
>>
>>     Thanks,
>>
>>     Krishna
>>
>>     *From:*Prasanta Sadhukhan
>>     *Sent:* Tuesday, March 20, 2018 1:01 PM
>>     *To:* swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>
>>     *Subject:* <Swing Dev> [11] RFR JDK-8189687:Swing: Invalid
>>     position of candidate pop-up of InputMethod in Hi-DPI on Windows
>>
>>     Hi All,
>>
>>     Please review a fix for an issue where it is seen that
>>     for Japanese IME on windows 10 with scaleFactor 1.5, when we enter
>>     text using IME popup, the popup is positioned on top of text,
>>     thereby obscuring it
>>     as seen in this screenshot.
>>
>>
>>     Proposed fix is to apply the scaleFactor on the candidate's popup
>>     positional coordinates x,y to generate proper coordinates to show
>>     this popup
>>     webrev: http://cr.openjdk.java.net/~psadhukhan/8189687/webrev.00/
>>     <http://cr.openjdk.java.net/%7Epsadhukhan/8189687/webrev.00/>
>>
>>     The screenshot after the fix is
>>
>>
>>     Regards
>>     Prasanta
>>
> 


-- 
Best regards, Sergey.


From krishna.addepalli at oracle.com  Fri Mar 23 09:01:40 2018
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Fri, 23 Mar 2018 02:01:40 -0700 (PDT)
Subject: <Swing Dev> RFR: 8198990 : Move SwingSet2 from closed to OpenJDK
In-Reply-To: <de341ab7-39ed-547c-f9e3-c0030ac40524@oracle.com>
References: <9cec067c-7795-03c6-8f8a-3b5c508c71fa@oracle.com>
 <78fe181c-3775-4225-9589-c87b6a761162@default>
 <de341ab7-39ed-547c-f9e3-c0030ac40524@oracle.com>
Message-ID: <1bd2083e-9c98-4a45-8b3b-5900eeec70b6@default>

+1

-----Original Message-----
From: Phil Race 
Sent: Friday, March 23, 2018 12:22 AM
To: Krishna Addepalli <krishna.addepalli at oracle.com>; swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> RFR: 8198990 : Move SwingSet2 from closed to OpenJDK

They get created when you revert, they aren't there because of any conflict.
They should not be in the patch .. just got caught up in the file list.
Here's a webrev that excludes them

http://cr.openjdk.java.net/~prr/8198990.1

-phil.


On 03/20/2018 11:45 PM, Krishna Addepalli wrote:
> Hi Phil,
>
> I see that there are these files in the patch:
>
> src/demo/share/jfc/SwingSet2/SwingSet2.java.orig
> src/demo/share/jfc/SwingSet2/resources/images/About.jpg.orig
> src/demo/share/jfc/SwingSet2/resources/images/tooltip/cow.gif.orig
>
> As per my understanding, these files get created when there are any merge conflicts in the source.
> Not sure about their purpose here.
>
> Thanks,
> Krishna
>
> -----Original Message-----
> From: Phil Race
> Sent: Wednesday, March 21, 2018 1:25 AM
> To: swing-dev at openjdk.java.net
> Subject: <Swing Dev> RFR: 8198990 : Move SwingSet2 from closed to OpenJDK
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8198990
> Webrev: http://cr.openjdk.java.net/~prr/8198990/
>
> SwingSet2 has always been in closed, mostly because of some images that could not be moved to OpenJDK.
>
> Due diligence has been done and replacements have been found.
> This new version has already been reviewed internally.
>
> I will be removing the closed version at the same time as pushing this.
>
> -phil.
>
>
>



From Sergey.Bylokhov at oracle.com  Fri Mar 23 18:46:55 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 23 Mar 2018 11:46:55 -0700
Subject: <Swing Dev> RFR: 8198990 : Move SwingSet2 from closed to OpenJDK
In-Reply-To: <1bd2083e-9c98-4a45-8b3b-5900eeec70b6@default>
References: <9cec067c-7795-03c6-8f8a-3b5c508c71fa@oracle.com>
 <78fe181c-3775-4225-9589-c87b6a761162@default>
 <de341ab7-39ed-547c-f9e3-c0030ac40524@oracle.com>
 <1bd2083e-9c98-4a45-8b3b-5900eeec70b6@default>
Message-ID: <8921d3ae-3c21-d9b3-dd2b-7df6d9acb769@oracle.com>

+1

On 23/03/2018 02:01, Krishna Addepalli wrote:
> +1
> 
> -----Original Message-----
> From: Phil Race
> Sent: Friday, March 23, 2018 12:22 AM
> To: Krishna Addepalli <krishna.addepalli at oracle.com>; swing-dev at openjdk.java.net
> Subject: Re: <Swing Dev> RFR: 8198990 : Move SwingSet2 from closed to OpenJDK
> 
> They get created when you revert, they aren't there because of any conflict.
> They should not be in the patch .. just got caught up in the file list.
> Here's a webrev that excludes them
> 
> http://cr.openjdk.java.net/~prr/8198990.1
> 
> -phil.
> 
> 
> On 03/20/2018 11:45 PM, Krishna Addepalli wrote:
>> Hi Phil,
>>
>> I see that there are these files in the patch:
>>
>> src/demo/share/jfc/SwingSet2/SwingSet2.java.orig
>> src/demo/share/jfc/SwingSet2/resources/images/About.jpg.orig
>> src/demo/share/jfc/SwingSet2/resources/images/tooltip/cow.gif.orig
>>
>> As per my understanding, these files get created when there are any merge conflicts in the source.
>> Not sure about their purpose here.
>>
>> Thanks,
>> Krishna
>>
>> -----Original Message-----
>> From: Phil Race
>> Sent: Wednesday, March 21, 2018 1:25 AM
>> To: swing-dev at openjdk.java.net
>> Subject: <Swing Dev> RFR: 8198990 : Move SwingSet2 from closed to OpenJDK
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8198990
>> Webrev: http://cr.openjdk.java.net/~prr/8198990/
>>
>> SwingSet2 has always been in closed, mostly because of some images that could not be moved to OpenJDK.
>>
>> Due diligence has been done and replacements have been found.
>> This new version has already been reviewed internally.
>>
>> I will be removing the closed version at the same time as pushing this.
>>
>> -phil.
>>
>>
>>
> 


-- 
Best regards, Sergey.


From volker.simonis at gmail.com  Sat Mar 24 22:24:32 2018
From: volker.simonis at gmail.com (Volker Simonis)
Date: Sat, 24 Mar 2018 22:24:32 +0000
Subject: <Swing Dev> RFR: 8198990 : Move SwingSet2 from closed to OpenJDK
In-Reply-To: <9cec067c-7795-03c6-8f8a-3b5c508c71fa@oracle.com>
References: <9cec067c-7795-03c6-8f8a-3b5c508c71fa@oracle.com>
Message-ID: <CA+3eh119vDwmqSu+g315u3UWAvxzwy4K3V1TTUZUuJZf=kfY9A@mail.gmail.com>

Hi Phil,

thanks for finally releasing the SwingSet2 Demo into the open! Just last
week I had an intern who should play around with Java/Swing/OpenJDK. I
thought I let him look at the SwingSet demo before I realized (yet another
time) that it was not included in the OpenJDK.

Regards,
Volker

Phil Race <philip.race at oracle.com> schrieb am Di. 20. M?rz 2018 um 20:55:

> Bug: https://bugs.openjdk.java.net/browse/JDK-8198990
> Webrev: http://cr.openjdk.java.net/~prr/8198990/
>
> SwingSet2 has always been in closed, mostly because of some
> images that could not be moved to OpenJDK.
>
> Due diligence has been done and replacements have been found.
> This new version has already been reviewed internally.
>
> I will be removing the closed version at the same time as pushing this.
>
> -phil.
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20180324/300b67cf/attachment.html>

From philip.race at oracle.com  Sun Mar 25 01:14:08 2018
From: philip.race at oracle.com (Phil Race)
Date: Sat, 24 Mar 2018 18:14:08 -0700
Subject: <Swing Dev> RFR: 8198990 : Move SwingSet2 from closed to OpenJDK
In-Reply-To: <CA+3eh119vDwmqSu+g315u3UWAvxzwy4K3V1TTUZUuJZf=kfY9A@mail.gmail.com>
References: <9cec067c-7795-03c6-8f8a-3b5c508c71fa@oracle.com>
 <CA+3eh119vDwmqSu+g315u3UWAvxzwy4K3V1TTUZUuJZf=kfY9A@mail.gmail.com>
Message-ID: <57A9E618-FE65-4E79-94E4-878894FBE6B8@oracle.com>

You are welcome. It is one of those things which we did not have time to address in 2007 (!) due to higher priorities with the product code itself and after that the momentum was lost. A lot of the credit goes to Jeff Dinkins for the work on the images.

-Phil.

> On Mar 24, 2018, at 3:24 PM, Volker Simonis <volker.simonis at gmail.com> wrote:
> 
> Hi Phil,
> 
> thanks for finally releasing the SwingSet2 Demo into the open! Just last week I had an intern who should play around with Java/Swing/OpenJDK. I thought I let him look at the SwingSet demo before I realized (yet another time) that it was not included in the OpenJDK.
> 
> Regards,
> Volker
> 
> Phil Race <philip.race at oracle.com> schrieb am Di. 20. M?rz 2018 um 20:55:
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8198990
>> Webrev: http://cr.openjdk.java.net/~prr/8198990/
>> 
>> SwingSet2 has always been in closed, mostly because of some
>> images that could not be moved to OpenJDK.
>> 
>> Due diligence has been done and replacements have been found.
>> This new version has already been reviewed internally.
>> 
>> I will be removing the closed version at the same time as pushing this.
>> 
>> -phil.
>> 
>> 
>> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20180324/b513c64f/attachment.html>

From prasanta.sadhukhan at oracle.com  Mon Mar 26 07:51:10 2018
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Mon, 26 Mar 2018 13:21:10 +0530
Subject: <Swing Dev> [11] RFR JDK-8189687:Swing: Invalid position of
 candidate pop-up of InputMethod in Hi-DPI on Windows
In-Reply-To: <e868ccf9-0af6-7caa-2869-d8cb22e794a9@oracle.com>
References: <5e0216fa-11ba-9408-864c-0d54f819d073@oracle.com>
 <c0f29625-7c8c-4571-89dd-67d61cd1d8c5@default>
 <56e2135b-5b54-fce0-df1b-7deda03e9b44@oracle.com>
 <bc9977cb-88f7-4abc-972f-3f6110bc10e7@default>
 <a8fa809c-3c83-7ef5-8783-03150b565b76@oracle.com>
 <e868ccf9-0af6-7caa-2869-d8cb22e794a9@oracle.com>
Message-ID: <a940317b-0286-4af9-14e0-a9aa87beb755@oracle.com>

Hi Sergey,

On 3/23/2018 3:44 AM, Sergey Bylokhov wrote:
> Hi, Prasanta.
> Did you check why the "InputMethodContext.getTextLocation()" returns 
> non-scaled rectangle? Maybe we should do this inside 
> InputMethodContext()?
>
Yes, this code 
http://hg.openjdk.java.net/jdk/client/annotate/f46bfa7a2956/src/java.desktop/windows/native/libawt/windows/awt_Component.cpp#l5673
scales down x,y as part of JDK-8073320 fix.
I have moved the fix to InputMethodContext as suggested
http://cr.openjdk.java.net/~psadhukhan/8189687/webrev.02/

Regards
Prasanta
> On 20/03/2018 22:17, Prasanta Sadhukhan wrote:
>> Hi Krishna,
>>
>> Yes, I did not provide any since the testcase needs to be manual and 
>> would have to contain lots of instructions of how to install Japanese 
>> language and changing the input mode to hiragana
>> and also similar fix of input method earlier did not have a testcase 
>> for similar reason.
>>
>> Regards
>> Prasanta
>> On 3/20/2018 8:42 PM, Krishna Addepalli wrote:
>>>
>>> Hi Prasanta,
>>>
>>> Now the changes look fine. However, I noticed that there is no 
>>> testcase associated with this fix. Is that intentional?
>>>
>>> Thanks,
>>>
>>> Krishna
>>>
>>> *From:*Prasanta Sadhukhan
>>> *Sent:* Tuesday, March 20, 2018 5:04 PM
>>> *To:* Krishna Addepalli <krishna.addepalli at oracle.com>; 
>>> swing-dev at openjdk.java.net
>>> *Subject:* Re: <Swing Dev> [11] RFR JDK-8189687:Swing: Invalid 
>>> position of candidate pop-up of InputMethod in Hi-DPI on Windows
>>>
>>> Thanks Krishna for your comment. Modified webrev catering to 
>>> retrieval of scalefactor of the active monitor being shown
>>>
>>> http://cr.openjdk.java.net/~psadhukhan/8189687/webrev.01/ 
>>> <http://cr.openjdk.java.net/%7Epsadhukhan/8189687/webrev.01/>
>>>
>>> Regards
>>> Prasanta
>>>
>>> On 3/20/2018 2:40 PM, Krishna Addepalli wrote:
>>>
>>> ??? Hi Prasanta,
>>>
>>> ??? I have couple questions regarding your fix:
>>>
>>> ??? 1.The AffineTransform object should be retrieved from the Screen
>>> ??? on which the window is showing, whereas in your fix, you are
>>> ??? directly getting it from the default screen. In multi screen
>>> ??? environment, it may not be aligned correctly.
>>>
>>> ??? 2.Is there any reason to retrieve the object in the top. I mean,
>>> ??? the AffineTransform object can be declared inside the ?if
>>> ??? (haveActiveClient())? block, at the point of use.
>>>
>>> ??? Thanks,
>>>
>>> ??? Krishna
>>>
>>> ??? *From:*Prasanta Sadhukhan
>>> ??? *Sent:* Tuesday, March 20, 2018 1:01 PM
>>> ??? *To:* swing-dev at openjdk.java.net 
>>> <mailto:swing-dev at openjdk.java.net>
>>> ??? *Subject:* <Swing Dev> [11] RFR JDK-8189687:Swing: Invalid
>>> ??? position of candidate pop-up of InputMethod in Hi-DPI on Windows
>>>
>>> ??? Hi All,
>>>
>>> ??? Please review a fix for an issue where it is seen that
>>> ??? for Japanese IME on windows 10 with scaleFactor 1.5, when we enter
>>> ??? text using IME popup, the popup is positioned on top of text,
>>> ??? thereby obscuring it
>>> ??? as seen in this screenshot.
>>>
>>>
>>> ??? Proposed fix is to apply the scaleFactor on the candidate's popup
>>> ??? positional coordinates x,y to generate proper coordinates to show
>>> ??? this popup
>>> ??? webrev: http://cr.openjdk.java.net/~psadhukhan/8189687/webrev.00/
>>> <http://cr.openjdk.java.net/%7Epsadhukhan/8189687/webrev.00/>
>>>
>>> ??? The screenshot after the fix is
>>>
>>>
>>> ??? Regards
>>> ??? Prasanta
>>>
>>
>
>



From pankaj.b.bansal at oracle.com  Mon Mar 26 12:06:46 2018
From: pankaj.b.bansal at oracle.com (Pankaj Bansal)
Date: Mon, 26 Mar 2018 05:06:46 -0700 (PDT)
Subject: <Swing Dev> [11] JDK-8194873: right ALT key hotkeys no longer work
 in Swing components
Message-ID: <a76ec42d-9c7b-4954-827b-ea219b126ec5@default>

Hi All,

 

Please review the test only fix for JDK 11.

 

Bug:

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

 

webrev:

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

 

 

Issue:

The right ALT key is not working as mnemonic for some Swing components like JMenu or JOptionsPane. The left ALT key works fine.

 

Fix:

This issue was introduced when a check for VK_RMENU was added in GetJavaModifiers function in awt_Component.cpp. Windows gives true for both VK_MENU and VK_RMENU when right ALT (ALT_GRAPH ) key is pressed. Due to which extra bits are set on modifiers. So the mnemonic bindings should be updated to work with both ALT and (ALT+ALT_GRAPH) modifiers. Changes have been made in mnemonic bindings.  

 

Regards,

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

From prasanta.sadhukhan at oracle.com  Wed Mar 28 05:39:27 2018
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Wed, 28 Mar 2018 11:09:27 +0530
Subject: <Swing Dev> [11] RFR JDK-8189687:Swing: Invalid position of
 candidate pop-up of InputMethod in Hi-DPI on Windows
In-Reply-To: <a940317b-0286-4af9-14e0-a9aa87beb755@oracle.com>
References: <5e0216fa-11ba-9408-864c-0d54f819d073@oracle.com>
 <c0f29625-7c8c-4571-89dd-67d61cd1d8c5@default>
 <56e2135b-5b54-fce0-df1b-7deda03e9b44@oracle.com>
 <bc9977cb-88f7-4abc-972f-3f6110bc10e7@default>
 <a8fa809c-3c83-7ef5-8783-03150b565b76@oracle.com>
 <e868ccf9-0af6-7caa-2869-d8cb22e794a9@oracle.com>
 <a940317b-0286-4af9-14e0-a9aa87beb755@oracle.com>
Message-ID: <48c67ad5-275f-3556-a0cf-6997813aca15@oracle.com>

Any more comments?

Regards
Prasanta
On 3/26/2018 1:21 PM, Prasanta Sadhukhan wrote:
> Hi Sergey,
>
> On 3/23/2018 3:44 AM, Sergey Bylokhov wrote:
>> Hi, Prasanta.
>> Did you check why the "InputMethodContext.getTextLocation()" returns 
>> non-scaled rectangle? Maybe we should do this inside 
>> InputMethodContext()?
>>
> Yes, this code 
> http://hg.openjdk.java.net/jdk/client/annotate/f46bfa7a2956/src/java.desktop/windows/native/libawt/windows/awt_Component.cpp#l5673
> scales down x,y as part of JDK-8073320 fix.
> I have moved the fix to InputMethodContext as suggested
> http://cr.openjdk.java.net/~psadhukhan/8189687/webrev.02/
>
> Regards
> Prasanta
>> On 20/03/2018 22:17, Prasanta Sadhukhan wrote:
>>> Hi Krishna,
>>>
>>> Yes, I did not provide any since the testcase needs to be manual and 
>>> would have to contain lots of instructions of how to install 
>>> Japanese language and changing the input mode to hiragana
>>> and also similar fix of input method earlier did not have a testcase 
>>> for similar reason.
>>>
>>> Regards
>>> Prasanta
>>> On 3/20/2018 8:42 PM, Krishna Addepalli wrote:
>>>>
>>>> Hi Prasanta,
>>>>
>>>> Now the changes look fine. However, I noticed that there is no 
>>>> testcase associated with this fix. Is that intentional?
>>>>
>>>> Thanks,
>>>>
>>>> Krishna
>>>>
>>>> *From:*Prasanta Sadhukhan
>>>> *Sent:* Tuesday, March 20, 2018 5:04 PM
>>>> *To:* Krishna Addepalli <krishna.addepalli at oracle.com>; 
>>>> swing-dev at openjdk.java.net
>>>> *Subject:* Re: <Swing Dev> [11] RFR JDK-8189687:Swing: Invalid 
>>>> position of candidate pop-up of InputMethod in Hi-DPI on Windows
>>>>
>>>> Thanks Krishna for your comment. Modified webrev catering to 
>>>> retrieval of scalefactor of the active monitor being shown
>>>>
>>>> http://cr.openjdk.java.net/~psadhukhan/8189687/webrev.01/ 
>>>> <http://cr.openjdk.java.net/%7Epsadhukhan/8189687/webrev.01/>
>>>>
>>>> Regards
>>>> Prasanta
>>>>
>>>> On 3/20/2018 2:40 PM, Krishna Addepalli wrote:
>>>>
>>>> ??? Hi Prasanta,
>>>>
>>>> ??? I have couple questions regarding your fix:
>>>>
>>>> ??? 1.The AffineTransform object should be retrieved from the Screen
>>>> ??? on which the window is showing, whereas in your fix, you are
>>>> ??? directly getting it from the default screen. In multi screen
>>>> ??? environment, it may not be aligned correctly.
>>>>
>>>> ??? 2.Is there any reason to retrieve the object in the top. I mean,
>>>> ??? the AffineTransform object can be declared inside the ?if
>>>> ??? (haveActiveClient())? block, at the point of use.
>>>>
>>>> ??? Thanks,
>>>>
>>>> ??? Krishna
>>>>
>>>> ??? *From:*Prasanta Sadhukhan
>>>> ??? *Sent:* Tuesday, March 20, 2018 1:01 PM
>>>> ??? *To:* swing-dev at openjdk.java.net 
>>>> <mailto:swing-dev at openjdk.java.net>
>>>> ??? *Subject:* <Swing Dev> [11] RFR JDK-8189687:Swing: Invalid
>>>> ??? position of candidate pop-up of InputMethod in Hi-DPI on Windows
>>>>
>>>> ??? Hi All,
>>>>
>>>> ??? Please review a fix for an issue where it is seen that
>>>> ??? for Japanese IME on windows 10 with scaleFactor 1.5, when we enter
>>>> ??? text using IME popup, the popup is positioned on top of text,
>>>> ??? thereby obscuring it
>>>> ??? as seen in this screenshot.
>>>>
>>>>
>>>> ??? Proposed fix is to apply the scaleFactor on the candidate's popup
>>>> ??? positional coordinates x,y to generate proper coordinates to show
>>>> ??? this popup
>>>> ??? webrev: http://cr.openjdk.java.net/~psadhukhan/8189687/webrev.00/
>>>> <http://cr.openjdk.java.net/%7Epsadhukhan/8189687/webrev.00/>
>>>>
>>>> ??? The screenshot after the fix is
>>>>
>>>>
>>>> ??? Regards
>>>> ??? Prasanta
>>>>
>>>
>>
>>
>



From prasanta.sadhukhan at oracle.com  Wed Mar 28 08:21:49 2018
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Wed, 28 Mar 2018 13:51:49 +0530
Subject: <Swing Dev> [11] JDK-8194873: right ALT key hotkeys no longer
 work in Swing components
In-Reply-To: <a76ec42d-9c7b-4954-827b-ea219b126ec5@default>
References: <a76ec42d-9c7b-4954-827b-ea219b126ec5@default>
Message-ID: <599a8976-bd25-5ead-013a-e05f9ce696d4@oracle.com>

Hi Pankaj,

Have you checked for JMenuItem too? It seems we have similar 
updateMnemonicBinding in BasicMenuUI too which is not modified.

Regarding the test, I think it will be good if you create the option 
pane dialog "when" JMenu is selected and not "after". Also, you can 
probably iterate for different installed look and feels instead of 
testing only the default L&F.

Regards
Prasanta
On 3/26/2018 5:36 PM, Pankaj Bansal wrote:
>
> Hi All,
>
> Please review the test only fix for JDK 11.
>
> Bug:
>
> https://bugs.openjdk.java.net/browse/JDK-8194873
>
> webrev:
>
> http://cr.openjdk.java.net/~pbansal/8194873/webrev.00/ 
> <http://cr.openjdk.java.net/%7Epbansal/8194873/webrev.00/>
>
> Issue:
>
> The right ALT key is not working as mnemonic for some Swing components 
> like JMenu or JOptionsPane. The left ALT key works fine.
>
> Fix:
>
> This issue was introduced when a check for VK_RMENU was added in 
> GetJavaModifiers function in awt_Component.cpp. Windows gives true for 
> both VK_MENU and VK_RMENU when right ALT (ALT_GRAPH ) key is pressed. 
> Due to which extra bits are set on modifiers. So the mnemonic bindings 
> should be updated to work with both ALT and (ALT+ALT_GRAPH) modifiers. 
> Changes have been made in mnemonic bindings.
>
> Regards,
>
> Pankaj Bansal
>

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

From Sergey.Bylokhov at oracle.com  Wed Mar 28 15:17:21 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 28 Mar 2018 08:17:21 -0700
Subject: <Swing Dev> [11] RFR JDK-8199900:JEditorPane scrollToReference
 should support html5
In-Reply-To: <419ec876-98ae-bed0-075c-4fec5d07ae9a@oracle.com>
References: <419ec876-98ae-bed0-075c-4fec5d07ae9a@oracle.com>
Message-ID: <37c27b6d-8d3a-0487-9172-1ca996afdebd@oracle.com>

Hi, Prasanta.
On 22/03/2018 03:12, Prasanta Sadhukhan wrote:
> Not sure of how to approach for a testcase for this html5 addition. 
You can create JEditorPane inside JScrollPane, then set the type of 
content to "text/html" and set the text of the JScrollPane to an html 
which contains lots of <br> tags and one <a> tag at the end. Then you 
can request the position of scroll bar from JScrollPane. You can test 
both cases when "name=xxx" is set or when "id=xxx" is set.

-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Wed Mar 28 15:36:43 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 28 Mar 2018 08:36:43 -0700
Subject: <Swing Dev> [11] RFR JDK-8189687:Swing: Invalid position of
 candidate pop-up of InputMethod in Hi-DPI on Windows
In-Reply-To: <48c67ad5-275f-3556-a0cf-6997813aca15@oracle.com>
References: <5e0216fa-11ba-9408-864c-0d54f819d073@oracle.com>
 <c0f29625-7c8c-4571-89dd-67d61cd1d8c5@default>
 <56e2135b-5b54-fce0-df1b-7deda03e9b44@oracle.com>
 <bc9977cb-88f7-4abc-972f-3f6110bc10e7@default>
 <a8fa809c-3c83-7ef5-8783-03150b565b76@oracle.com>
 <e868ccf9-0af6-7caa-2869-d8cb22e794a9@oracle.com>
 <a940317b-0286-4af9-14e0-a9aa87beb755@oracle.com>
 <48c67ad5-275f-3556-a0cf-6997813aca15@oracle.com>
Message-ID: <1df3993f-ec7d-04e6-3712-7fe1bf439405@oracle.com>

Hi, Prasanta.
The same question about this code:
281         Rectangle r = getReq().getTextLocation(offset);

The getReq() returns InputMethodRequests which is implemented by a 
number of classes, and I think one of them "InputMethodRequestsHandler" 
returns scaled values from "getTextLocation()" already.
Some of these classes may return some stubs which should not be scaled, 
like in CompositionAreaHandler:
// passive client, no composed text, so fake a rectangle
return new Rectangle(0, 0, 0, 10);


On 27/03/2018 22:39, Prasanta Sadhukhan wrote:
> Any more comments?
> 
> Regards
> Prasanta
> On 3/26/2018 1:21 PM, Prasanta Sadhukhan wrote:
>> Hi Sergey,
>>
>> On 3/23/2018 3:44 AM, Sergey Bylokhov wrote:
>>> Hi, Prasanta.
>>> Did you check why the "InputMethodContext.getTextLocation()" returns 
>>> non-scaled rectangle? Maybe we should do this inside 
>>> InputMethodContext()?
>>>
>> Yes, this code 
>> http://hg.openjdk.java.net/jdk/client/annotate/f46bfa7a2956/src/java.desktop/windows/native/libawt/windows/awt_Component.cpp#l5673 
>>
>> scales down x,y as part of JDK-8073320 fix.
>> I have moved the fix to InputMethodContext as suggested
>> http://cr.openjdk.java.net/~psadhukhan/8189687/webrev.02/
>>
>> Regards
>> Prasanta
>>> On 20/03/2018 22:17, Prasanta Sadhukhan wrote:
>>>> Hi Krishna,
>>>>
>>>> Yes, I did not provide any since the testcase needs to be manual and 
>>>> would have to contain lots of instructions of how to install 
>>>> Japanese language and changing the input mode to hiragana
>>>> and also similar fix of input method earlier did not have a testcase 
>>>> for similar reason.
>>>>
>>>> Regards
>>>> Prasanta
>>>> On 3/20/2018 8:42 PM, Krishna Addepalli wrote:
>>>>>
>>>>> Hi Prasanta,
>>>>>
>>>>> Now the changes look fine. However, I noticed that there is no 
>>>>> testcase associated with this fix. Is that intentional?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Krishna
>>>>>
>>>>> *From:*Prasanta Sadhukhan
>>>>> *Sent:* Tuesday, March 20, 2018 5:04 PM
>>>>> *To:* Krishna Addepalli <krishna.addepalli at oracle.com>; 
>>>>> swing-dev at openjdk.java.net
>>>>> *Subject:* Re: <Swing Dev> [11] RFR JDK-8189687:Swing: Invalid 
>>>>> position of candidate pop-up of InputMethod in Hi-DPI on Windows
>>>>>
>>>>> Thanks Krishna for your comment. Modified webrev catering to 
>>>>> retrieval of scalefactor of the active monitor being shown
>>>>>
>>>>> http://cr.openjdk.java.net/~psadhukhan/8189687/webrev.01/ 
>>>>> <http://cr.openjdk.java.net/%7Epsadhukhan/8189687/webrev.01/>
>>>>>
>>>>> Regards
>>>>> Prasanta
>>>>>
>>>>> On 3/20/2018 2:40 PM, Krishna Addepalli wrote:
>>>>>
>>>>> ??? Hi Prasanta,
>>>>>
>>>>> ??? I have couple questions regarding your fix:
>>>>>
>>>>> ??? 1.The AffineTransform object should be retrieved from the Screen
>>>>> ??? on which the window is showing, whereas in your fix, you are
>>>>> ??? directly getting it from the default screen. In multi screen
>>>>> ??? environment, it may not be aligned correctly.
>>>>>
>>>>> ??? 2.Is there any reason to retrieve the object in the top. I mean,
>>>>> ??? the AffineTransform object can be declared inside the ?if
>>>>> ??? (haveActiveClient())? block, at the point of use.
>>>>>
>>>>> ??? Thanks,
>>>>>
>>>>> ??? Krishna
>>>>>
>>>>> ??? *From:*Prasanta Sadhukhan
>>>>> ??? *Sent:* Tuesday, March 20, 2018 1:01 PM
>>>>> ??? *To:* swing-dev at openjdk.java.net 
>>>>> <mailto:swing-dev at openjdk.java.net>
>>>>> ??? *Subject:* <Swing Dev> [11] RFR JDK-8189687:Swing: Invalid
>>>>> ??? position of candidate pop-up of InputMethod in Hi-DPI on Windows
>>>>>
>>>>> ??? Hi All,
>>>>>
>>>>> ??? Please review a fix for an issue where it is seen that
>>>>> ??? for Japanese IME on windows 10 with scaleFactor 1.5, when we enter
>>>>> ??? text using IME popup, the popup is positioned on top of text,
>>>>> ??? thereby obscuring it
>>>>> ??? as seen in this screenshot.
>>>>>
>>>>>
>>>>> ??? Proposed fix is to apply the scaleFactor on the candidate's popup
>>>>> ??? positional coordinates x,y to generate proper coordinates to show
>>>>> ??? this popup
>>>>> ??? webrev: http://cr.openjdk.java.net/~psadhukhan/8189687/webrev.00/
>>>>> <http://cr.openjdk.java.net/%7Epsadhukhan/8189687/webrev.00/>
>>>>>
>>>>> ??? The screenshot after the fix is
>>>>>
>>>>>
>>>>> ??? Regards
>>>>> ??? Prasanta
>>>>>
>>>>
>>>
>>>
>>
> 


-- 
Best regards, Sergey.


From prasanta.sadhukhan at oracle.com  Thu Mar 29 05:02:39 2018
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Thu, 29 Mar 2018 10:32:39 +0530
Subject: <Swing Dev> [11] RFR JDK-8189687:Swing: Invalid position of
 candidate pop-up of InputMethod in Hi-DPI on Windows
In-Reply-To: <1df3993f-ec7d-04e6-3712-7fe1bf439405@oracle.com>
References: <5e0216fa-11ba-9408-864c-0d54f819d073@oracle.com>
 <c0f29625-7c8c-4571-89dd-67d61cd1d8c5@default>
 <56e2135b-5b54-fce0-df1b-7deda03e9b44@oracle.com>
 <bc9977cb-88f7-4abc-972f-3f6110bc10e7@default>
 <a8fa809c-3c83-7ef5-8783-03150b565b76@oracle.com>
 <e868ccf9-0af6-7caa-2869-d8cb22e794a9@oracle.com>
 <a940317b-0286-4af9-14e0-a9aa87beb755@oracle.com>
 <48c67ad5-275f-3556-a0cf-6997813aca15@oracle.com>
 <1df3993f-ec7d-04e6-3712-7fe1bf439405@oracle.com>
Message-ID: <41d9fba6-f9fc-ff15-1868-031a50bec89e@oracle.com>

Hi Sergey,

The code flows to JTextComponent.getTextLocation() which does not return 
a scaled rectangle as it uses awt_Component.cpp#_GetLocationOnScreen 
where it is scaled down. Do you want me to move the code to 
JTextComponent.getTextLocation() instead?

Regards
Prasanta
On 3/28/2018 9:06 PM, Sergey Bylokhov wrote:
> Hi, Prasanta.
> The same question about this code:
> 281???????? Rectangle r = getReq().getTextLocation(offset);
>
> The getReq() returns InputMethodRequests which is implemented by a 
> number of classes, and I think one of them 
> "InputMethodRequestsHandler" returns scaled values from 
> "getTextLocation()" already.
> Some of these classes may return some stubs which should not be 
> scaled, like in CompositionAreaHandler:
> // passive client, no composed text, so fake a rectangle
> return new Rectangle(0, 0, 0, 10);
>

>
> On 27/03/2018 22:39, Prasanta Sadhukhan wrote:
>> Any more comments?
>>
>> Regards
>> Prasanta
>> On 3/26/2018 1:21 PM, Prasanta Sadhukhan wrote:
>>> Hi Sergey,
>>>
>>> On 3/23/2018 3:44 AM, Sergey Bylokhov wrote:
>>>> Hi, Prasanta.
>>>> Did you check why the "InputMethodContext.getTextLocation()" 
>>>> returns non-scaled rectangle? Maybe we should do this inside 
>>>> InputMethodContext()?
>>>>
>>> Yes, this code 
>>> http://hg.openjdk.java.net/jdk/client/annotate/f46bfa7a2956/src/java.desktop/windows/native/libawt/windows/awt_Component.cpp#l5673 
>>>
>>> scales down x,y as part of JDK-8073320 fix.
>>> I have moved the fix to InputMethodContext as suggested
>>> http://cr.openjdk.java.net/~psadhukhan/8189687/webrev.02/
>>>
>>> Regards
>>> Prasanta
>>>> On 20/03/2018 22:17, Prasanta Sadhukhan wrote:
>>>>> Hi Krishna,
>>>>>
>>>>> Yes, I did not provide any since the testcase needs to be manual 
>>>>> and would have to contain lots of instructions of how to install 
>>>>> Japanese language and changing the input mode to hiragana
>>>>> and also similar fix of input method earlier did not have a 
>>>>> testcase for similar reason.
>>>>>
>>>>> Regards
>>>>> Prasanta
>>>>> On 3/20/2018 8:42 PM, Krishna Addepalli wrote:
>>>>>>
>>>>>> Hi Prasanta,
>>>>>>
>>>>>> Now the changes look fine. However, I noticed that there is no 
>>>>>> testcase associated with this fix. Is that intentional?
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Krishna
>>>>>>
>>>>>> *From:*Prasanta Sadhukhan
>>>>>> *Sent:* Tuesday, March 20, 2018 5:04 PM
>>>>>> *To:* Krishna Addepalli <krishna.addepalli at oracle.com>; 
>>>>>> swing-dev at openjdk.java.net
>>>>>> *Subject:* Re: <Swing Dev> [11] RFR JDK-8189687:Swing: Invalid 
>>>>>> position of candidate pop-up of InputMethod in Hi-DPI on Windows
>>>>>>
>>>>>> Thanks Krishna for your comment. Modified webrev catering to 
>>>>>> retrieval of scalefactor of the active monitor being shown
>>>>>>
>>>>>> http://cr.openjdk.java.net/~psadhukhan/8189687/webrev.01/ 
>>>>>> <http://cr.openjdk.java.net/%7Epsadhukhan/8189687/webrev.01/>
>>>>>>
>>>>>> Regards
>>>>>> Prasanta
>>>>>>
>>>>>> On 3/20/2018 2:40 PM, Krishna Addepalli wrote:
>>>>>>
>>>>>> ??? Hi Prasanta,
>>>>>>
>>>>>> ??? I have couple questions regarding your fix:
>>>>>>
>>>>>> ??? 1.The AffineTransform object should be retrieved from the Screen
>>>>>> ??? on which the window is showing, whereas in your fix, you are
>>>>>> ??? directly getting it from the default screen. In multi screen
>>>>>> ??? environment, it may not be aligned correctly.
>>>>>>
>>>>>> ??? 2.Is there any reason to retrieve the object in the top. I mean,
>>>>>> ??? the AffineTransform object can be declared inside the ?if
>>>>>> ??? (haveActiveClient())? block, at the point of use.
>>>>>>
>>>>>> ??? Thanks,
>>>>>>
>>>>>> ??? Krishna
>>>>>>
>>>>>> ??? *From:*Prasanta Sadhukhan
>>>>>> ??? *Sent:* Tuesday, March 20, 2018 1:01 PM
>>>>>> ??? *To:* swing-dev at openjdk.java.net 
>>>>>> <mailto:swing-dev at openjdk.java.net>
>>>>>> ??? *Subject:* <Swing Dev> [11] RFR JDK-8189687:Swing: Invalid
>>>>>> ??? position of candidate pop-up of InputMethod in Hi-DPI on Windows
>>>>>>
>>>>>> ??? Hi All,
>>>>>>
>>>>>> ??? Please review a fix for an issue where it is seen that
>>>>>> ??? for Japanese IME on windows 10 with scaleFactor 1.5, when we 
>>>>>> enter
>>>>>> ??? text using IME popup, the popup is positioned on top of text,
>>>>>> ??? thereby obscuring it
>>>>>> ??? as seen in this screenshot.
>>>>>>
>>>>>>
>>>>>> ??? Proposed fix is to apply the scaleFactor on the candidate's 
>>>>>> popup
>>>>>> ??? positional coordinates x,y to generate proper coordinates to 
>>>>>> show
>>>>>> ??? this popup
>>>>>> ??? webrev: 
>>>>>> http://cr.openjdk.java.net/~psadhukhan/8189687/webrev.00/
>>>>>> <http://cr.openjdk.java.net/%7Epsadhukhan/8189687/webrev.00/>
>>>>>>
>>>>>> ??? The screenshot after the fix is
>>>>>>
>>>>>>
>>>>>> ??? Regards
>>>>>> ??? Prasanta
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>
>



From krishna.addepalli at oracle.com  Fri Mar 30 12:30:48 2018
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Fri, 30 Mar 2018 05:30:48 -0700 (PDT)
Subject: <Swing Dev> [11]JDK-8200343: Minor JViewport documentation typo
Message-ID: <75a13efd-9ed9-4483-94bf-88f8824b64e4@default>

Hi All,

 

Please review a simple correction for the documentation of JViewport.

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

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

 

Thanks,

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

From Sergey.Bylokhov at oracle.com  Fri Mar 30 20:50:24 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 30 Mar 2018 13:50:24 -0700
Subject: <Swing Dev> [11]JDK-8200343: Minor JViewport documentation typo
In-Reply-To: <75a13efd-9ed9-4483-94bf-88f8824b64e4@default>
References: <75a13efd-9ed9-4483-94bf-88f8824b64e4@default>
Message-ID: <6f503563-fbc0-6838-e61f-8bef0ce5b8df@oracle.com>

+1

On 30/03/2018 05:30, Krishna Addepalli wrote:
> Hi All,
> 
> Please review a simple correction for the documentation of JViewport.
> 
> Webrev: http://cr.openjdk.java.net/~kaddepalli/8200343/webrev00/
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8200343
> 
> Thanks,
> 
> Krishna
> 


-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Sat Mar 31 01:21:18 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 30 Mar 2018 18:21:18 -0700
Subject: <Swing Dev> [11] RFR JDK-8189687:Swing: Invalid position of
 candidate pop-up of InputMethod in Hi-DPI on Windows
In-Reply-To: <41d9fba6-f9fc-ff15-1868-031a50bec89e@oracle.com>
References: <5e0216fa-11ba-9408-864c-0d54f819d073@oracle.com>
 <c0f29625-7c8c-4571-89dd-67d61cd1d8c5@default>
 <56e2135b-5b54-fce0-df1b-7deda03e9b44@oracle.com>
 <bc9977cb-88f7-4abc-972f-3f6110bc10e7@default>
 <a8fa809c-3c83-7ef5-8783-03150b565b76@oracle.com>
 <e868ccf9-0af6-7caa-2869-d8cb22e794a9@oracle.com>
 <a940317b-0286-4af9-14e0-a9aa87beb755@oracle.com>
 <48c67ad5-275f-3556-a0cf-6997813aca15@oracle.com>
 <1df3993f-ec7d-04e6-3712-7fe1bf439405@oracle.com>
 <41d9fba6-f9fc-ff15-1868-031a50bec89e@oracle.com>
Message-ID: <d8c2632e-06ad-0d7c-ad2d-52d6434a2608@oracle.com>

I guess we need to check it again.
We have two coordinate spaces in awt/swing:
  - User-space which is used by all(most) of our API in awt/swing. It 
means that all methods like setSize/setBounds/getLocationOnScreen etc 
use this coordinate space.
  - Device-space which is used by the native system. It is used when we 
show something on the screen, when we get some notification from the OS etc.

So for the example if we try to set the bounds of the window then we 
convert the size from the user-space to device-space. But when we get 
some notification from the native system then we will convert 
device-space to the user-space.

In this bug we use wrong location of candidate window. It means that we 
lost some conversion.

So if we start from the first iteration of the fix:
http://cr.openjdk.java.net/~psadhukhan/8189687/webrev.00/src/java.desktop/windows/classes/sun/awt/windows/WInputMethod.java.sdiff.html

We calculate the x,y in two places using getTextLocation() and 
getLocationOnScreen(). Both functions should return coordinates in the 
user-space because both are public API in AWT. If some of these methods 
use wrong device space it should be updated(in the place where we get 
such coordinates from the native).

We show the candidate window using openCandidateWindow() method, this 
method uses x,y coordinates. In which coordinate system x,y should be?
If it uses device space then we should convert both - results of 
getTextLocation() and getLocationOnScreen().


On 28/03/2018 22:02, Prasanta Sadhukhan wrote:
> Hi Sergey,
> 
> The code flows to JTextComponent.getTextLocation() which does not return 
> a scaled rectangle as it uses awt_Component.cpp#_GetLocationOnScreen 
> where it is scaled down. Do you want me to move the code to 
> JTextComponent.getTextLocation() instead?
> 
> Regards
> Prasanta
> On 3/28/2018 9:06 PM, Sergey Bylokhov wrote:
>> Hi, Prasanta.
>> The same question about this code:
>> 281???????? Rectangle r = getReq().getTextLocation(offset);
>>
>> The getReq() returns InputMethodRequests which is implemented by a 
>> number of classes, and I think one of them 
>> "InputMethodRequestsHandler" returns scaled values from 
>> "getTextLocation()" already.
>> Some of these classes may return some stubs which should not be 
>> scaled, like in CompositionAreaHandler:
>> // passive client, no composed text, so fake a rectangle
>> return new Rectangle(0, 0, 0, 10);
>>
> 
>>
>> On 27/03/2018 22:39, Prasanta Sadhukhan wrote:
>>> Any more comments?
>>>
>>> Regards
>>> Prasanta
>>> On 3/26/2018 1:21 PM, Prasanta Sadhukhan wrote:
>>>> Hi Sergey,
>>>>
>>>> On 3/23/2018 3:44 AM, Sergey Bylokhov wrote:
>>>>> Hi, Prasanta.
>>>>> Did you check why the "InputMethodContext.getTextLocation()" 
>>>>> returns non-scaled rectangle? Maybe we should do this inside 
>>>>> InputMethodContext()?
>>>>>
>>>> Yes, this code 
>>>> http://hg.openjdk.java.net/jdk/client/annotate/f46bfa7a2956/src/java.desktop/windows/native/libawt/windows/awt_Component.cpp#l5673 
>>>>
>>>> scales down x,y as part of JDK-8073320 fix.
>>>> I have moved the fix to InputMethodContext as suggested
>>>> http://cr.openjdk.java.net/~psadhukhan/8189687/webrev.02/
>>>>
>>>> Regards
>>>> Prasanta
>>>>> On 20/03/2018 22:17, Prasanta Sadhukhan wrote:
>>>>>> Hi Krishna,
>>>>>>
>>>>>> Yes, I did not provide any since the testcase needs to be manual 
>>>>>> and would have to contain lots of instructions of how to install 
>>>>>> Japanese language and changing the input mode to hiragana
>>>>>> and also similar fix of input method earlier did not have a 
>>>>>> testcase for similar reason.
>>>>>>
>>>>>> Regards
>>>>>> Prasanta
>>>>>> On 3/20/2018 8:42 PM, Krishna Addepalli wrote:
>>>>>>>
>>>>>>> Hi Prasanta,
>>>>>>>
>>>>>>> Now the changes look fine. However, I noticed that there is no 
>>>>>>> testcase associated with this fix. Is that intentional?
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Krishna
>>>>>>>
>>>>>>> *From:*Prasanta Sadhukhan
>>>>>>> *Sent:* Tuesday, March 20, 2018 5:04 PM
>>>>>>> *To:* Krishna Addepalli <krishna.addepalli at oracle.com>; 
>>>>>>> swing-dev at openjdk.java.net
>>>>>>> *Subject:* Re: <Swing Dev> [11] RFR JDK-8189687:Swing: Invalid 
>>>>>>> position of candidate pop-up of InputMethod in Hi-DPI on Windows
>>>>>>>
>>>>>>> Thanks Krishna for your comment. Modified webrev catering to 
>>>>>>> retrieval of scalefactor of the active monitor being shown
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8189687/webrev.01/ 
>>>>>>> <http://cr.openjdk.java.net/%7Epsadhukhan/8189687/webrev.01/>
>>>>>>>
>>>>>>> Regards
>>>>>>> Prasanta
>>>>>>>
>>>>>>> On 3/20/2018 2:40 PM, Krishna Addepalli wrote:
>>>>>>>
>>>>>>> ??? Hi Prasanta,
>>>>>>>
>>>>>>> ??? I have couple questions regarding your fix:
>>>>>>>
>>>>>>> ??? 1.The AffineTransform object should be retrieved from the Screen
>>>>>>> ??? on which the window is showing, whereas in your fix, you are
>>>>>>> ??? directly getting it from the default screen. In multi screen
>>>>>>> ??? environment, it may not be aligned correctly.
>>>>>>>
>>>>>>> ??? 2.Is there any reason to retrieve the object in the top. I mean,
>>>>>>> ??? the AffineTransform object can be declared inside the ?if
>>>>>>> ??? (haveActiveClient())? block, at the point of use.
>>>>>>>
>>>>>>> ??? Thanks,
>>>>>>>
>>>>>>> ??? Krishna
>>>>>>>
>>>>>>> ??? *From:*Prasanta Sadhukhan
>>>>>>> ??? *Sent:* Tuesday, March 20, 2018 1:01 PM
>>>>>>> ??? *To:* swing-dev at openjdk.java.net 
>>>>>>> <mailto:swing-dev at openjdk.java.net>
>>>>>>> ??? *Subject:* <Swing Dev> [11] RFR JDK-8189687:Swing: Invalid
>>>>>>> ??? position of candidate pop-up of InputMethod in Hi-DPI on Windows
>>>>>>>
>>>>>>> ??? Hi All,
>>>>>>>
>>>>>>> ??? Please review a fix for an issue where it is seen that
>>>>>>> ??? for Japanese IME on windows 10 with scaleFactor 1.5, when we 
>>>>>>> enter
>>>>>>> ??? text using IME popup, the popup is positioned on top of text,
>>>>>>> ??? thereby obscuring it
>>>>>>> ??? as seen in this screenshot.
>>>>>>>
>>>>>>>
>>>>>>> ??? Proposed fix is to apply the scaleFactor on the candidate's 
>>>>>>> popup
>>>>>>> ??? positional coordinates x,y to generate proper coordinates to 
>>>>>>> show
>>>>>>> ??? this popup
>>>>>>> ??? webrev: 
>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8189687/webrev.00/
>>>>>>> <http://cr.openjdk.java.net/%7Epsadhukhan/8189687/webrev.00/>
>>>>>>>
>>>>>>> ??? The screenshot after the fix is
>>>>>>>
>>>>>>>
>>>>>>> ??? Regards
>>>>>>> ??? Prasanta
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>>
> 


-- 
Best regards, Sergey.


From pquiring at gmail.com  Sat Mar  3 14:16:34 2018
From: pquiring at gmail.com (Peter Quiring)
Date: Sat, 03 Mar 2018 14:16:34 -0000
Subject: <Swing Dev> Bug # 8194873
Message-ID: <CA+3dX1zOLRm-txeHkk+Oz+hZ291Z6OsM5emOSZ0Rioc3Q_264A@mail.gmail.com>

I found a bug in swing that was introduced in Java9.

See bug # 8194873

The problem is the addition of checking for VM_RMENU

http://hg.openjdk.java.net/jdk/jdk/file/ba545e52b932/src/java.desktop/windows/native/libawt/windows/awt_Component.cpp#l2718

Please remove this check or find another way to check for it.  This
new bit causes the right ALT shortcut keys to fail in Swing
components.

I believe the left ALT generates VK_MENU and the right alt generates
VM_MENU and VK_RMENU in Windows so the check is redudant.

Thanks.

-- 
Peter Quiring