From Sergey.Bylokhov at oracle.com  Fri Dec  1 03:41:48 2017
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 30 Nov 2017 19:41:48 -0800
Subject: <Swing Dev> RFR: 8191767: Memory leak in JabSwitch
In-Reply-To: <b65ce8d8-333a-c253-f02e-d29e29357dea@oracle.com>
References: <b65ce8d8-333a-c253-f02e-d29e29357dea@oracle.com>
Message-ID: <d37552bd-4b24-7cd8-677e-e1489378a01a@oracle.com>

Looks fine.

On 30/11/2017 12:55, Phil Race wrote:
> This is a one line fix for a potential small leak .. the char* variable 
> profilePath will not
> be freed in the case that when used it would make too long a path.
> 
> bug: https://bugs.openjdk.java.net/browse/JDK-8191767
> webrev: http://cr.openjdk.java.net/~prr/8191767/
> 
> 
> -phil.
> 


-- 
Best regards, Sergey.


From pankaj.b.bansal at oracle.com  Fri Dec  1 09:31:35 2017
From: pankaj.b.bansal at oracle.com (Pankaj Bansal)
Date: Fri, 1 Dec 2017 01:31:35 -0800 (PST)
Subject: <Swing Dev> [10] Review Request: JDK-7108280 :
 JList.getSelectedValuesList fails if JList.setSelectionInterval larger than
 list
Message-ID: <36332afd-a4fb-4760-8919-211e91520bc3@default>

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

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

From jayathirth.d.v at oracle.com  Fri Dec  1 10:47:01 2017
From: jayathirth.d.v at oracle.com (Jayathirth D V)
Date: Fri, 1 Dec 2017 02:47:01 -0800 (PST)
Subject: <Swing Dev> [10] Review Request: JDK-7108280 :
 JList.getSelectedValuesList fails if JList.setSelectionInterval larger than
 list
In-Reply-To: <36332afd-a4fb-4760-8919-211e91520bc3@default>
References: <36332afd-a4fb-4760-8919-211e91520bc3@default>
Message-ID: <e4bc267e-c2c0-4a91-a835-35ff59b37ae8@default>

Hello Pankaj,

 

Please find my observation:

 

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.

 

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

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

From pankaj.b.bansal at oracle.com  Fri Dec  1 16:06:03 2017
From: pankaj.b.bansal at oracle.com (Pankaj Bansal)
Date: Fri, 1 Dec 2017 08:06:03 -0800 (PST)
Subject: <Swing Dev> [10] Review Request: JDK-7108280 :
 JList.getSelectedValuesList fails if JList.setSelectionInterval larger than
 list
In-Reply-To: <e4bc267e-c2c0-4a91-a835-35ff59b37ae8@default>
References: <36332afd-a4fb-4760-8919-211e91520bc3@default>
 <e4bc267e-c2c0-4a91-a835-35ff59b37ae8@default>
Message-ID: <e9aade0c-86f4-4776-9d28-2c1803fab994@default>

Hi Jay,

 

Thanks for the review.

 

<<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.

No, the JCK test expects the selection to be actually set to the given interval irrespective of the number of items in the List. Following test case is failing

    

public Status JList2067() {

        JList c = new JList(); // Create JList object

        c.setSelectionInterval(10, 0);

        if (c.getSelectedIndices().length != 11) {

            ref.println("Wrong selection");

            return Status.failed("FAILED");

        }

 

 

<<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.

Yes, I think we have to check the condition for both anchor and lead both as they both can be greater than size of the List. I will make that change if we decide to go this route depending upon the other reviewers comments. But I feel not making the change in setSelectionInterval and addSelectionInterval is the preferred way as we will anyway have the checks in the getSelectedValuesList as wrong selection can be directly set using DefaultListSelectionModel.

 

Regards

Pankaj Bansal

 

 

Regards

Pankaj Bansal

From: Jayathirth D V 
Sent: Friday, December 1, 2017 4:17 PM
To: Pankaj Bansal; swing-dev at openjdk.java.net; Sergey Bylokhov; Semyon Sadetsky
Subject: RE: <Swing Dev> [10] Review Request: JDK-7108280 : JList.getSelectedValuesList fails if JList.setSelectionInterval larger than list

 

Hello Pankaj,

 

Please find my observation:

 

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.

 

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: HYPERLINK "mailto:swing-dev at openjdk.java.net"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

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

From prasanta.sadhukhan at oracle.com  Mon Dec  4 06:33:49 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Mon, 4 Dec 2017 12:03:49 +0530
Subject: <Swing Dev> [10] RFR JDK-8191639:NPE from
 BasicListUI.Actions.getNextPageIndex
In-Reply-To: <b9c2c89c-023f-4fd2-fe42-666320cca389@oracle.com>
References: <ebb5a8d1-dc89-dcde-12fe-887a9de18cba@oracle.com>
 <db748ca6-7268-b51c-507d-ad70d8cea7b7@oracle.com>
 <620a1883-fca0-6217-f0b8-8e4551a56037@oracle.com>
 <cebf117e-6318-b079-d110-8b5f22762ad3@oracle.com>
 <26e23ed9-1e7c-5547-279e-edbad34cbbd2@oracle.com>
 <e1b523eb-7a9d-7735-9c35-c0734a146e07@oracle.com>
 <e52400eb-b1f5-ee21-23e6-99f442c9925b@oracle.com>
 <b9c2c89c-023f-4fd2-fe42-666320cca389@oracle.com>
Message-ID: <5060a448-4152-00f4-ed3d-726131f10896@oracle.com>

HI Semyon,

I guess app can also override getCellBounds and return null (maybe 
mistakenly) so we need to check for return null.

Regards
Prasanta
On 11/29/2017 10:39 PM, Semyon Sadetsky wrote:
> Hi Prasanta,
>
> I suggest to call list.getCellBounds() only if index != -1 since the 
> result will be always null in that case.
>
> --Semyon
>
>
> On 11/29/2017 01:04 AM, Prasanta Sadhukhan wrote:
>> OK. http://cr.openjdk.java.net/~psadhukhan/8191639/webrev.03/
>>
>> Regards
>> Prasanta
>>
>>
>> On 11/29/2017 12:35 AM, Sergey Bylokhov wrote:
>>> On 27/11/2017 23:45, Prasanta Sadhukhan wrote:
>>>> Ok. I have added the check for scrollRectToVisible() too.
>>>>
>>>> http://cr.openjdk.java.net/~psadhukhan/8191639/webrev.02
>>>
>>> Should the test use some specific L&F? Currently it is pass on macOS 
>>> and Aqua L&F before the fix.
>>>
>>>>
>>>> Regards
>>>> Prasanta
>>>> On 11/28/2017 1:01 PM, Sergey Bylokhov wrote:
>>>>> On 27/11/2017 22:40, Prasanta Sadhukhan wrote:
>>>>>> On 11/28/2017 3:33 AM, Sergey Bylokhov wrote:
>>>>>>> Hi, Prasanta.
>>>>>>> A few notes about the fix:
>>>>>>> ?- Can we get an NPE in adjustScrollPositionIfNecessary at
>>>>>>> ?????? 2391 list.scrollRectToVisible(cellBounds); Not sure that 
>>>>>>> scrollRectToVisible is ready for null.
>>>>>> cellBounds is not null for this call due to this check in
>>>>>>
>>>>>> 2308???????????? if (cellBounds != null && 
>>>>>> !visRect.contains(cellBounds)) {
>>>>>
>>>>> In the fix you added a check at line
>>>>> 2384 if (cellBounds != null) {
>>>>>
>>>>> And later you will pass the cellBounds as a parameter:
>>>>> 2393???????????????? list.scrollRectToVisible(cellBounds);
>>>>>
>>>>> So either cellBounds can be null or the new check is not needed.
>>>>>
>>>>>
>>>>>>
>>>>>>> ?- I think the assignment below can be simplified
>>>>>>> ?????? cellBounds = startRect != null ? startRect : null;
>>>>>>> ?- In the getNextPageIndex() probably we can "return index" 
>>>>>>> immediately instead of additional indentation?
>>>>>>>
>>>>>> Done. Modified webrev
>>>>>> http://cr.openjdk.java.net/~psadhukhan/8191639/webrev.01/
>>>>>>
>>>>>> Regards
>>>>>> Prasanta
>>>>>>> On 22/11/2017 03:05, Prasanta Sadhukhan wrote:
>>>>>>>> Hi All,
>>>>>>>>
>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8191639
>>>>>>>>
>>>>>>>> It is seen that when JList.locationToIndex() or getCellBounds() 
>>>>>>>> is overridden to return -1 or null respectively,
>>>>>>>> it causes NPE when PageUp/PageDown is pressed in JList.
>>>>>>>>
>>>>>>>> ?From the spec 
>>>>>>>> [https://docs.oracle.com/javase/9/docs/api/javax/swing/JList.html#getCellBounds-int-int-] 
>>>>>>>>
>>>>>>>> of getCellBounds(), it is seen that it can return null under 
>>>>>>>> some circumstances. But, JList jdk code assumes it is always 
>>>>>>>> non-null.
>>>>>>>>
>>>>>>>> Proposed fix is to check for null return value of 
>>>>>>>> getCellBounds() and bail out.
>>>>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8191639/webrev.00/
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> Prasanta
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>



From abdul.kolarkunnu at oracle.com  Mon Dec  4 06:54:29 2017
From: abdul.kolarkunnu at oracle.com (Muneer Kolarkunnu)
Date: Sun, 3 Dec 2017 22:54:29 -0800 (PST)
Subject: <Swing Dev> [10] RFR JDK-8191803 : [TEST_BUG] :
 sanity/client/SwingSet/src/ProgressBarDemoTest.java failed with "Wait
 "greater then 1349" state to be reached
Message-ID: <6b5970f5-fc14-45c4-83ad-48566767cec0@default>

Hi,

 

Please review the fix for JDK-8191803.

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

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

 

Issue: In usual ways itself, it is taking 30-40 seconds to complete the progress bar. So in slow machines it may take more time. Default timeout is 1 minute. Also in the screen shots, it is visible that demo is not blocked anywhere, it is still continuing, but failed due to timeout.

Fix: Increase the progress bar timeout from 1 min to 3 min.

 

Regards,

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

From semyon.sadetsky at oracle.com  Mon Dec  4 16:09:05 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Mon, 4 Dec 2017 08:09:05 -0800
Subject: <Swing Dev> [10] RFR JDK-8191639:NPE from
 BasicListUI.Actions.getNextPageIndex
In-Reply-To: <5060a448-4152-00f4-ed3d-726131f10896@oracle.com>
References: <ebb5a8d1-dc89-dcde-12fe-887a9de18cba@oracle.com>
 <db748ca6-7268-b51c-507d-ad70d8cea7b7@oracle.com>
 <620a1883-fca0-6217-f0b8-8e4551a56037@oracle.com>
 <cebf117e-6318-b079-d110-8b5f22762ad3@oracle.com>
 <26e23ed9-1e7c-5547-279e-edbad34cbbd2@oracle.com>
 <e1b523eb-7a9d-7735-9c35-c0734a146e07@oracle.com>
 <e52400eb-b1f5-ee21-23e6-99f442c9925b@oracle.com>
 <b9c2c89c-023f-4fd2-fe42-666320cca389@oracle.com>
 <5060a448-4152-00f4-ed3d-726131f10896@oracle.com>
Message-ID: <d42e5386-c4d9-bb16-9ca4-0f17c652dec3@oracle.com>

Hi Prasanta,

I'm not suggesting to remove the null check. I suggested to add check 
for -1 since the bounds of the cell with index -1 should never exists 
and it doesn't make scene to call the method to calculate its bounds.

--Semyon


On 12/03/2017 10:33 PM, Prasanta Sadhukhan wrote:
> HI Semyon,
>
> I guess app can also override getCellBounds and return null (maybe 
> mistakenly) so we need to check for return null.
>
> Regards
> Prasanta
> On 11/29/2017 10:39 PM, Semyon Sadetsky wrote:
>> Hi Prasanta,
>>
>> I suggest to call list.getCellBounds() only if index != -1 since the 
>> result will be always null in that case.
>>
>> --Semyon
>>
>>
>> On 11/29/2017 01:04 AM, Prasanta Sadhukhan wrote:
>>> OK. http://cr.openjdk.java.net/~psadhukhan/8191639/webrev.03/
>>>
>>> Regards
>>> Prasanta
>>>
>>>
>>> On 11/29/2017 12:35 AM, Sergey Bylokhov wrote:
>>>> On 27/11/2017 23:45, Prasanta Sadhukhan wrote:
>>>>> Ok. I have added the check for scrollRectToVisible() too.
>>>>>
>>>>> http://cr.openjdk.java.net/~psadhukhan/8191639/webrev.02
>>>>
>>>> Should the test use some specific L&F? Currently it is pass on 
>>>> macOS and Aqua L&F before the fix.
>>>>
>>>>>
>>>>> Regards
>>>>> Prasanta
>>>>> On 11/28/2017 1:01 PM, Sergey Bylokhov wrote:
>>>>>> On 27/11/2017 22:40, Prasanta Sadhukhan wrote:
>>>>>>> On 11/28/2017 3:33 AM, Sergey Bylokhov wrote:
>>>>>>>> Hi, Prasanta.
>>>>>>>> A few notes about the fix:
>>>>>>>> ?- Can we get an NPE in adjustScrollPositionIfNecessary at
>>>>>>>> ?????? 2391 list.scrollRectToVisible(cellBounds); Not sure that 
>>>>>>>> scrollRectToVisible is ready for null.
>>>>>>> cellBounds is not null for this call due to this check in
>>>>>>>
>>>>>>> 2308???????????? if (cellBounds != null && 
>>>>>>> !visRect.contains(cellBounds)) {
>>>>>>
>>>>>> In the fix you added a check at line
>>>>>> 2384 if (cellBounds != null) {
>>>>>>
>>>>>> And later you will pass the cellBounds as a parameter:
>>>>>> 2393 list.scrollRectToVisible(cellBounds);
>>>>>>
>>>>>> So either cellBounds can be null or the new check is not needed.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>> ?- I think the assignment below can be simplified
>>>>>>>> ?????? cellBounds = startRect != null ? startRect : null;
>>>>>>>> ?- In the getNextPageIndex() probably we can "return index" 
>>>>>>>> immediately instead of additional indentation?
>>>>>>>>
>>>>>>> Done. Modified webrev
>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8191639/webrev.01/
>>>>>>>
>>>>>>> Regards
>>>>>>> Prasanta
>>>>>>>> On 22/11/2017 03:05, Prasanta Sadhukhan wrote:
>>>>>>>>> Hi All,
>>>>>>>>>
>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8191639
>>>>>>>>>
>>>>>>>>> It is seen that when JList.locationToIndex() or 
>>>>>>>>> getCellBounds() is overridden to return -1 or null respectively,
>>>>>>>>> it causes NPE when PageUp/PageDown is pressed in JList.
>>>>>>>>>
>>>>>>>>> ?From the spec 
>>>>>>>>> [https://docs.oracle.com/javase/9/docs/api/javax/swing/JList.html#getCellBounds-int-int-] 
>>>>>>>>>
>>>>>>>>> of getCellBounds(), it is seen that it can return null under 
>>>>>>>>> some circumstances. But, JList jdk code assumes it is always 
>>>>>>>>> non-null.
>>>>>>>>>
>>>>>>>>> Proposed fix is to check for null return value of 
>>>>>>>>> getCellBounds() and bail out.
>>>>>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8191639/webrev.00/
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>> Prasanta
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>



From Sergey.Bylokhov at oracle.com  Mon Dec  4 18:29:09 2017
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 4 Dec 2017 10:29:09 -0800
Subject: <Swing Dev> [10] RFR JDK-8191803 : [TEST_BUG] :
 sanity/client/SwingSet/src/ProgressBarDemoTest.java failed with "Wait
 "greater then 1349" state to be reached
In-Reply-To: <6b5970f5-fc14-45c4-83ad-48566767cec0@default>
References: <6b5970f5-fc14-45c4-83ad-48566767cec0@default>
Message-ID: <57f1937a-3fd4-10a6-fbd3-dd689e01a58d@oracle.com>

Hello.
On 03/12/2017 22:54, Muneer Kolarkunnu wrote:
> Issue: In usual ways itself, it is taking 30-40 seconds to complete the 
> progress bar. So in slow machines it may take more time. Default timeout 
> is 1 minute. Also in the screen shots, it is visible that demo is not 
> blocked anywhere, it is still continuing, but failed due to timeout.

As far as I know that jtreg by default has 2 minute timeout, should it 
also be changed to 3 minutes?

-- 
Best regards, Sergey.


From philip.race at oracle.com  Mon Dec  4 18:54:47 2017
From: philip.race at oracle.com (Phil Race)
Date: Mon, 4 Dec 2017 10:54:47 -0800
Subject: <Swing Dev> [10] RFR JDK-8191803 : [TEST_BUG] :
 sanity/client/SwingSet/src/ProgressBarDemoTest.java failed with "Wait
 "greater then 1349" state to be reached
In-Reply-To: <57f1937a-3fd4-10a6-fbd3-dd689e01a58d@oracle.com>
References: <6b5970f5-fc14-45c4-83ad-48566767cec0@default>
 <57f1937a-3fd4-10a6-fbd3-dd689e01a58d@oracle.com>
Message-ID: <44dd6a10-8bcf-0cab-45ee-7bff8a5fd8ee@oracle.com>

 From memory, I think Sergey is right that the jtreg default time out is 
2 minutes (120 seconds).
As to changing that to 3 minutes .. that is something that needs to be 
decided at a jtreg ownership level.

A little off topic, but I've sometimes pondered if jtreg ought to have 
an option to avoid running lengthy tests,
when time is of the essence. e.g., any test that specifies a timeout 
greater than the default.
But if only a few percent of tests do that it probably does not make 
enough difference to matter.

-phil.

On 12/04/2017 10:29 AM, Sergey Bylokhov wrote:
> Hello.
> On 03/12/2017 22:54, Muneer Kolarkunnu wrote:
>> Issue: In usual ways itself, it is taking 30-40 seconds to complete 
>> the progress bar. So in slow machines it may take more time. Default 
>> timeout is 1 minute. Also in the screen shots, it is visible that 
>> demo is not blocked anywhere, it is still continuing, but failed due 
>> to timeout.
>
> As far as I know that jtreg by default has 2 minute timeout, should it 
> also be changed to 3 minutes?
>



From alexandre.iline at oracle.com  Mon Dec  4 19:16:49 2017
From: alexandre.iline at oracle.com (Alexandre (Shura) Iline)
Date: Mon, 4 Dec 2017 11:16:49 -0800
Subject: <Swing Dev> [10] RFR JDK-8191803 : [TEST_BUG] :
 sanity/client/SwingSet/src/ProgressBarDemoTest.java failed with "Wait
 "greater then 1349" state to be reached
In-Reply-To: <44dd6a10-8bcf-0cab-45ee-7bff8a5fd8ee@oracle.com>
References: <6b5970f5-fc14-45c4-83ad-48566767cec0@default>
 <57f1937a-3fd4-10a6-fbd3-dd689e01a58d@oracle.com>
 <44dd6a10-8bcf-0cab-45ee-7bff8a5fd8ee@oracle.com>
Message-ID: <C9B3F8CA-F7A1-4E6E-AFF0-0FF0CB8A25EE@oracle.com>



> On Dec 4, 2017, at 10:54 AM, Phil Race <philip.race at oracle.com> wrote:
> 
> From memory, I think Sergey is right that the jtreg default time out is 2 minutes (120 seconds).
> As to changing that to 3 minutes .. that is something that needs to be decided at a jtreg ownership level.

I though that Sergey suggested to change the timeout for this specific test. Per JTreg doc: /timeout=<seconds> could be used. This is a very valid suggestion, IMO.


> 
> A little off topic, but I've sometimes pondered if jtreg ought to have an option to avoid running lengthy tests,
> when time is of the essence. e.g., any test that specifies a timeout greater than the default.

One way would be to mark the slow tests with a keyword, but I did not find any keyword used right now for that.

Client tests - at least those involving simulating user actions - should not be selected at all during such runs, I would expect. Simply because the user input simulation is (usually) accompanied with some waiting. Practically speaking, we should not expect those in rush to run headful tests anyway, and the test in question is marked with @key headful.

Shura

> But if only a few percent of tests do that it probably does not make enough difference to matter.
> 
> -phil.
> 
> On 12/04/2017 10:29 AM, Sergey Bylokhov wrote:
>> Hello.
>> On 03/12/2017 22:54, Muneer Kolarkunnu wrote:
>>> Issue: In usual ways itself, it is taking 30-40 seconds to complete the progress bar. So in slow machines it may take more time. Default timeout is 1 minute. Also in the screen shots, it is visible that demo is not blocked anywhere, it is still continuing, but failed due to timeout.
>> 
>> As far as I know that jtreg by default has 2 minute timeout, should it also be changed to 3 minutes?
>> 
> 



From philip.race at oracle.com  Mon Dec  4 19:52:29 2017
From: philip.race at oracle.com (Philip Race)
Date: Mon, 04 Dec 2017 11:52:29 -0800
Subject: <Swing Dev> [10] Review Request: 8189656 The Windows L&F should
 be moved out from the shared folder
In-Reply-To: <ae2e749b-d775-c04b-95e3-ab63be3f6571@oracle.com>
References: <d1c852bb-0b18-bef1-21e3-29dafd972cea@oracle.com>
 <171f8e59-8f7d-2ae4-a726-06e706297db3@oracle.com>
 <582f2df2-6d44-c092-86e3-81ffdd949965@oracle.com>
 <ae2e749b-d775-c04b-95e3-ab63be3f6571@oracle.com>
Message-ID: <5A25A77D.6060600@oracle.com>


OK .. approved.

-phil.

On 11/28/17, 2:11 PM, Sergey Bylokhov wrote:
> On 28/11/2017 13:38, Phil Race wrote:
>> I see this opens was moved to platform-specific code ... 115 opens 
>> com.sun.java.swing.plaf.windows to
>> 116 jdk.jconsole;
>>
>> So jdk.jconsole definitely accesses this only on Windows ?
>
> Its is accessed under the windows check:
> http://hg.openjdk.java.net/jdk/client/file/ecaa3569ec3d/src/jdk.jconsole/share/classes/sun/tools/jconsole/MaximizableInternalFrame.java#l223 
>
>
>
> String lafName = UIManager.getLookAndFeel().getClass().getName();
> IS_WIN = 
> lafName.equals("com.sun.java.swing.plaf.windows.WindowsLookAndFeel");
>
>
>>
>> -phil.
>>
>> On 11/28/2017 09:28 AM, Erik Joelsson wrote:
>>> From a build point of view, this looks great.
>>>
>>> /Erik
>>>
>>>
>>> On 2017-11-27 18:27, Sergey Bylokhov wrote:
>>>> Hello.
>>>> Please review the fix for jdk10. This is the second attempt to move 
>>>> windows L&F from non-windows platforms. The first attempt 
>>>> JDK-6461834[1] was reverted because of JDK-8184813[2].
>>>> The root cause of those issue was fixed in JDK-8075255[3], and now 
>>>> we can move it again.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8189656
>>>> Webrev can be found at: 
>>>> http://cr.openjdk.java.net/~serb/8189656/webrev.02
>>>>
>>>> The fix contains a few parts:
>>>>  - The code related to win l&f was moved from the "share" to the 
>>>> "windows" folder
>>>>  - The platform-specific export was moved from module-info.java to 
>>>> module-info.java.extra
>>>>  - A number of tests which use windows L&F were marked as 
>>>> windows-specific
>>>>  - The stub "ThemeReader.java" which was used to build win w&f on 
>>>> unix was removed.
>>>>
>>>> [1] https://bugs.openjdk.java.net/browse/JDK-6461834
>>>> [2] https://bugs.openjdk.java.net/browse/JDK-8184813
>>>> [3] https://bugs.openjdk.java.net/browse/JDK-8075255
>>>>
>>>
>>
>
>


From prasanta.sadhukhan at oracle.com  Tue Dec  5 12:51:11 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Tue, 5 Dec 2017 18:21:11 +0530
Subject: <Swing Dev> [10] RFR JDK-8191639:NPE from
 BasicListUI.Actions.getNextPageIndex
In-Reply-To: <d42e5386-c4d9-bb16-9ca4-0f17c652dec3@oracle.com>
References: <ebb5a8d1-dc89-dcde-12fe-887a9de18cba@oracle.com>
 <db748ca6-7268-b51c-507d-ad70d8cea7b7@oracle.com>
 <620a1883-fca0-6217-f0b8-8e4551a56037@oracle.com>
 <cebf117e-6318-b079-d110-8b5f22762ad3@oracle.com>
 <26e23ed9-1e7c-5547-279e-edbad34cbbd2@oracle.com>
 <e1b523eb-7a9d-7735-9c35-c0734a146e07@oracle.com>
 <e52400eb-b1f5-ee21-23e6-99f442c9925b@oracle.com>
 <b9c2c89c-023f-4fd2-fe42-666320cca389@oracle.com>
 <5060a448-4152-00f4-ed3d-726131f10896@oracle.com>
 <d42e5386-c4d9-bb16-9ca4-0f17c652dec3@oracle.com>
Message-ID: <be728b43-b584-05f2-1afe-9e7c25ff3664@oracle.com>

Hi Semyon,

Ok. added index check
and followed previous review comment of returning index immediately 
instead of additional indentation
http://cr.openjdk.java.net/~psadhukhan/8191639/webrev.04/

Regards
Prasanta
On 12/4/2017 9:39 PM, Semyon Sadetsky wrote:
> Hi Prasanta,
>
> I'm not suggesting to remove the null check. I suggested to add check 
> for -1 since the bounds of the cell with index -1 should never exists 
> and it doesn't make scene to call the method to calculate its bounds.
>
> --Semyon
>
>
> On 12/03/2017 10:33 PM, Prasanta Sadhukhan wrote:
>> HI Semyon,
>>
>> I guess app can also override getCellBounds and return null (maybe 
>> mistakenly) so we need to check for return null.
>>
>> Regards
>> Prasanta
>> On 11/29/2017 10:39 PM, Semyon Sadetsky wrote:
>>> Hi Prasanta,
>>>
>>> I suggest to call list.getCellBounds() only if index != -1 since the 
>>> result will be always null in that case.
>>>
>>> --Semyon
>>>
>>>
>>> On 11/29/2017 01:04 AM, Prasanta Sadhukhan wrote:
>>>> OK. http://cr.openjdk.java.net/~psadhukhan/8191639/webrev.03/
>>>>
>>>> Regards
>>>> Prasanta
>>>>
>>>>
>>>> On 11/29/2017 12:35 AM, Sergey Bylokhov wrote:
>>>>> On 27/11/2017 23:45, Prasanta Sadhukhan wrote:
>>>>>> Ok. I have added the check for scrollRectToVisible() too.
>>>>>>
>>>>>> http://cr.openjdk.java.net/~psadhukhan/8191639/webrev.02
>>>>>
>>>>> Should the test use some specific L&F? Currently it is pass on 
>>>>> macOS and Aqua L&F before the fix.
>>>>>
>>>>>>
>>>>>> Regards
>>>>>> Prasanta
>>>>>> On 11/28/2017 1:01 PM, Sergey Bylokhov wrote:
>>>>>>> On 27/11/2017 22:40, Prasanta Sadhukhan wrote:
>>>>>>>> On 11/28/2017 3:33 AM, Sergey Bylokhov wrote:
>>>>>>>>> Hi, Prasanta.
>>>>>>>>> A few notes about the fix:
>>>>>>>>> ?- Can we get an NPE in adjustScrollPositionIfNecessary at
>>>>>>>>> ?????? 2391 list.scrollRectToVisible(cellBounds); Not sure 
>>>>>>>>> that scrollRectToVisible is ready for null.
>>>>>>>> cellBounds is not null for this call due to this check in
>>>>>>>>
>>>>>>>> 2308???????????? if (cellBounds != null && 
>>>>>>>> !visRect.contains(cellBounds)) {
>>>>>>>
>>>>>>> In the fix you added a check at line
>>>>>>> 2384 if (cellBounds != null) {
>>>>>>>
>>>>>>> And later you will pass the cellBounds as a parameter:
>>>>>>> 2393 list.scrollRectToVisible(cellBounds);
>>>>>>>
>>>>>>> So either cellBounds can be null or the new check is not needed.
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>> ?- I think the assignment below can be simplified
>>>>>>>>> ?????? cellBounds = startRect != null ? startRect : null;
>>>>>>>>> ?- In the getNextPageIndex() probably we can "return index" 
>>>>>>>>> immediately instead of additional indentation?
>>>>>>>>>
>>>>>>>> Done. Modified webrev
>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8191639/webrev.01/
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> Prasanta
>>>>>>>>> On 22/11/2017 03:05, Prasanta Sadhukhan wrote:
>>>>>>>>>> Hi All,
>>>>>>>>>>
>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8191639
>>>>>>>>>>
>>>>>>>>>> It is seen that when JList.locationToIndex() or 
>>>>>>>>>> getCellBounds() is overridden to return -1 or null respectively,
>>>>>>>>>> it causes NPE when PageUp/PageDown is pressed in JList.
>>>>>>>>>>
>>>>>>>>>> ?From the spec 
>>>>>>>>>> [https://docs.oracle.com/javase/9/docs/api/javax/swing/JList.html#getCellBounds-int-int-] 
>>>>>>>>>>
>>>>>>>>>> of getCellBounds(), it is seen that it can return null under 
>>>>>>>>>> some circumstances. But, JList jdk code assumes it is always 
>>>>>>>>>> non-null.
>>>>>>>>>>
>>>>>>>>>> Proposed fix is to check for null return value of 
>>>>>>>>>> getCellBounds() and bail out.
>>>>>>>>>> webrev: 
>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8191639/webrev.00/
>>>>>>>>>>
>>>>>>>>>> Regards
>>>>>>>>>> Prasanta
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>



From semyon.sadetsky at oracle.com  Tue Dec  5 16:30:41 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Tue, 5 Dec 2017 08:30:41 -0800
Subject: <Swing Dev> [10] RFR JDK-8191639:NPE from
 BasicListUI.Actions.getNextPageIndex
In-Reply-To: <be728b43-b584-05f2-1afe-9e7c25ff3664@oracle.com>
References: <ebb5a8d1-dc89-dcde-12fe-887a9de18cba@oracle.com>
 <db748ca6-7268-b51c-507d-ad70d8cea7b7@oracle.com>
 <620a1883-fca0-6217-f0b8-8e4551a56037@oracle.com>
 <cebf117e-6318-b079-d110-8b5f22762ad3@oracle.com>
 <26e23ed9-1e7c-5547-279e-edbad34cbbd2@oracle.com>
 <e1b523eb-7a9d-7735-9c35-c0734a146e07@oracle.com>
 <e52400eb-b1f5-ee21-23e6-99f442c9925b@oracle.com>
 <b9c2c89c-023f-4fd2-fe42-666320cca389@oracle.com>
 <5060a448-4152-00f4-ed3d-726131f10896@oracle.com>
 <d42e5386-c4d9-bb16-9ca4-0f17c652dec3@oracle.com>
 <be728b43-b584-05f2-1afe-9e7c25ff3664@oracle.com>
Message-ID: <2eb012d4-9dc7-449f-6f07-23bd61afbcf6@oracle.com>

+1

--Semyon


On 12/05/2017 04:51 AM, Prasanta Sadhukhan wrote:
> Hi Semyon,
>
> Ok. added index check
> and followed previous review comment of returning index immediately 
> instead of additional indentation
> http://cr.openjdk.java.net/~psadhukhan/8191639/webrev.04/
>
> Regards
> Prasanta
> On 12/4/2017 9:39 PM, Semyon Sadetsky wrote:
>> Hi Prasanta,
>>
>> I'm not suggesting to remove the null check. I suggested to add check 
>> for -1 since the bounds of the cell with index -1 should never exists 
>> and it doesn't make scene to call the method to calculate its bounds.
>>
>> --Semyon
>>
>>
>> On 12/03/2017 10:33 PM, Prasanta Sadhukhan wrote:
>>> HI Semyon,
>>>
>>> I guess app can also override getCellBounds and return null (maybe 
>>> mistakenly) so we need to check for return null.
>>>
>>> Regards
>>> Prasanta
>>> On 11/29/2017 10:39 PM, Semyon Sadetsky wrote:
>>>> Hi Prasanta,
>>>>
>>>> I suggest to call list.getCellBounds() only if index != -1 since 
>>>> the result will be always null in that case.
>>>>
>>>> --Semyon
>>>>
>>>>
>>>> On 11/29/2017 01:04 AM, Prasanta Sadhukhan wrote:
>>>>> OK. http://cr.openjdk.java.net/~psadhukhan/8191639/webrev.03/
>>>>>
>>>>> Regards
>>>>> Prasanta
>>>>>
>>>>>
>>>>> On 11/29/2017 12:35 AM, Sergey Bylokhov wrote:
>>>>>> On 27/11/2017 23:45, Prasanta Sadhukhan wrote:
>>>>>>> Ok. I have added the check for scrollRectToVisible() too.
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8191639/webrev.02
>>>>>>
>>>>>> Should the test use some specific L&F? Currently it is pass on 
>>>>>> macOS and Aqua L&F before the fix.
>>>>>>
>>>>>>>
>>>>>>> Regards
>>>>>>> Prasanta
>>>>>>> On 11/28/2017 1:01 PM, Sergey Bylokhov wrote:
>>>>>>>> On 27/11/2017 22:40, Prasanta Sadhukhan wrote:
>>>>>>>>> On 11/28/2017 3:33 AM, Sergey Bylokhov wrote:
>>>>>>>>>> Hi, Prasanta.
>>>>>>>>>> A few notes about the fix:
>>>>>>>>>> ?- Can we get an NPE in adjustScrollPositionIfNecessary at
>>>>>>>>>> ?????? 2391 list.scrollRectToVisible(cellBounds); Not sure 
>>>>>>>>>> that scrollRectToVisible is ready for null.
>>>>>>>>> cellBounds is not null for this call due to this check in
>>>>>>>>>
>>>>>>>>> 2308???????????? if (cellBounds != null && 
>>>>>>>>> !visRect.contains(cellBounds)) {
>>>>>>>>
>>>>>>>> In the fix you added a check at line
>>>>>>>> 2384 if (cellBounds != null) {
>>>>>>>>
>>>>>>>> And later you will pass the cellBounds as a parameter:
>>>>>>>> 2393 list.scrollRectToVisible(cellBounds);
>>>>>>>>
>>>>>>>> So either cellBounds can be null or the new check is not needed.
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> ?- I think the assignment below can be simplified
>>>>>>>>>> ?????? cellBounds = startRect != null ? startRect : null;
>>>>>>>>>> ?- In the getNextPageIndex() probably we can "return index" 
>>>>>>>>>> immediately instead of additional indentation?
>>>>>>>>>>
>>>>>>>>> Done. Modified webrev
>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8191639/webrev.01/
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>> Prasanta
>>>>>>>>>> On 22/11/2017 03:05, Prasanta Sadhukhan wrote:
>>>>>>>>>>> Hi All,
>>>>>>>>>>>
>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8191639
>>>>>>>>>>>
>>>>>>>>>>> It is seen that when JList.locationToIndex() or 
>>>>>>>>>>> getCellBounds() is overridden to return -1 or null 
>>>>>>>>>>> respectively,
>>>>>>>>>>> it causes NPE when PageUp/PageDown is pressed in JList.
>>>>>>>>>>>
>>>>>>>>>>> ?From the spec 
>>>>>>>>>>> [https://docs.oracle.com/javase/9/docs/api/javax/swing/JList.html#getCellBounds-int-int-] 
>>>>>>>>>>>
>>>>>>>>>>> of getCellBounds(), it is seen that it can return null under 
>>>>>>>>>>> some circumstances. But, JList jdk code assumes it is always 
>>>>>>>>>>> non-null.
>>>>>>>>>>>
>>>>>>>>>>> Proposed fix is to check for null return value of 
>>>>>>>>>>> getCellBounds() and bail out.
>>>>>>>>>>> webrev: 
>>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8191639/webrev.00/
>>>>>>>>>>>
>>>>>>>>>>> Regards
>>>>>>>>>>> Prasanta
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>



From Sergey.Bylokhov at oracle.com  Tue Dec  5 22:29:28 2017
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 5 Dec 2017 14:29:28 -0800
Subject: <Swing Dev> [10] Review Request: JDK-7108280 :
 JList.getSelectedValuesList fails if JList.setSelectionInterval larger than
 list
In-Reply-To: <e4bc267e-c2c0-4a91-a835-35ff59b37ae8@default>
References: <36332afd-a4fb-4760-8919-211e91520bc3@default>
 <e4bc267e-c2c0-4a91-a835-35ff59b37ae8@default>
Message-ID: <47487c2a-6e8f-fb35-cd70-3c8c7213e79b@oracle.com>

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 Dec  6 06:23:06 2017
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Tue, 5 Dec 2017 22:23:06 -0800 (PST)
Subject: <Swing Dev> [10][JDK-8075084] JOptionPane.showMessageDialog
 causes JScrollBar to move
In-Reply-To: <99ac9a25-5eb2-4f58-b591-50f0e7f1c0f0@default>
References: <619c955e-ce29-440c-959c-2e84f350d6be@default>
 <8d29331d-477f-4a5a-a9c5-4c4c88ad0385@default>
 <<5279e2de-5122-4a5d-805d-6d98a49eaacb@default>
 <DM5PR1801MB1945925E5D38079A4F9D54AB839C0@DM5PR1801MB1945.namprd18.prod.outlook.com>
 <ec0d0030-b5e6-43b2-bd8d-da0acb74dd6a@default>
 <74d627c0-cf80-4bda-bc3e-a00a42afc3e3@default>
 <1bc482bc-1737-3d11-aa57-aebb72e5ef8f@oracle.com>
 <7e5c2bb9-e088-4ab8-b1d8-2a6f9eeeedad@default>
 <a3fb7f46-53e2-7d2c-88b8-18c08f748506@oracle.com>
 <99ac9a25-5eb2-4f58-b591-50f0e7f1c0f0@default>
Message-ID: <2666f39a-e9df-4acd-b606-6ca292779cac@default>

Hi Sergey,

Per our conversation, I have tried to re-create the same behavior as posted in the previous mail: namely, trying to create a ModalEventFilter, and pass that to the EventDispatchThread, and then take over the events. 
But, the ModalEventFilter and its base class EventFilter are internal classes, which cannot be accessed outside the awt package.
Another point is, the function "createSecondaryLoop" has two signatures, one without parameters and one that takes the EventFilter parameter.
The one without parameters is what can be created at the application level and that does not install any overriding EventFilters, so the events continue to goto the old window as well.
Whereas in the case of the ModalEventFilter, the event will be consumed by the top-level Dialog, and the underlying dialog doesnot even get the event notification.

With this in mind, I think to recreate the problem with JFrame, I guess, we need to copy the functionality of Dialog.show() into JFrame.
Let me know your thoughts on this.

Thanks,
Krishna

-----Original Message-----
From: Krishna Addepalli 
Sent: Monday, November 20, 2017 5:10 PM
To: Sergey Bylokhov <sergey.bylokhov at oracle.com>; Semyon Sadetsky <semyon.sadetsky at oracle.com>; swing-dev at openjdk.java.net
Subject: RE: <Swing Dev> [10][JDK-8075084] JOptionPane.showMessageDialog causes JScrollBar to move

Hi Sergey,

I have analyzed it further, and found a possible root cause for the difference in the behavior.
It has to do with the way the "show()" function is written for JDialog/Dialog and a JFrame.
In the case of Dialog, there is the below code which takes control of the EventQueue in its show call:

                    modalityPushed();
                    try {
                        final EventQueue eventQueue = AccessController.doPrivileged(
                                (PrivilegedAction<EventQueue>) Toolkit.getDefaultToolkit()::getSystemEventQueue);
                        secondaryLoop = eventQueue.createSecondaryLoop(() -> true, modalFilter, 0);
                        if (!secondaryLoop.enter()) {
                            secondaryLoop = null;
                        }
                    } finally {
                        modalityPopped();
                    }
Here, when the "secondaryLoop.enter()", starts, it pumps all the events to the modal Dialog, rather than the underlying window (which could be another Dialog/Frame). 
For the case of JFrame, the check is only to see if it is blocked by another Dialog on top of it, but it does not stop the existing EventQueue, and start a secondaryLoop like in JDialog.

Hope this clarifies the difference in the behavioral difference between JDialog and JFrame in the testcase.

Thanks,
Krishna

-----Original Message-----
From: Sergey Bylokhov
Sent: Wednesday, November 15, 2017 4:18 AM
To: Krishna Addepalli <krishna.addepalli at oracle.com>; Semyon Sadetsky <semyon.sadetsky at oracle.com>; swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10][JDK-8075084] JOptionPane.showMessageDialog causes JScrollBar to move

Hi, Krishna.
Last time in the discussion we had a question why it is not possible to reproduce the bug using JFrame and focus manipulation in the same way as "JOptionPane.showMessageDialog" works. Did you check why it works in one case and does not work in another?

On 12/11/2017 22:41, Krishna Addepalli wrote:
> Hi Semyon,
> 
> There has already been extensive analysis about this, in the original thread. I'll loop you in that conversation, so that you could suggest the way ahead.
> 
> Thanks,
> Krishna
> 
> -----Original Message-----
> From: Semyon Sadetsky
> Sent: Wednesday, November 8, 2017 11:25 PM
> To: Krishna Addepalli <krishna.addepalli at oracle.com>; 
> swing-dev at openjdk.java.net; Sergey Bylokhov 
> <sergey.bylokhov at oracle.com>
> Subject: Re: <Swing Dev> [10][JDK-8075084] 
> JOptionPane.showMessageDialog causes JScrollBar to move
> 
> This fix was already published on Swing alias:
> 
> http://mail.openjdk.java.net/pipermail/swing-dev/2016-October/006808.h
> tml
> 
> Please continue your discussions in the original thread.
> 
> --Semyon
> 
> 
> On 11/08/2017 06:51 AM, Krishna Addepalli wrote:
>> Any update on this Sergey?
>>
>> -----Original Message-----
>> From: Krishna Addepalli
>> Sent: Thursday, October 26, 2017 2:13 PM
>> To: swing-dev at openjdk.java.net; Sergey Bylokhov 
>> <sergey.bylokhov at oracle.com>
>> Subject: RE: <Swing Dev> [10][JDK-8075084] 
>> JOptionPane.showMessageDialog causes JScrollBar to move
>>
>> Hi Sergey,
>>
>> I have recreated the webrev for JDK-10 consolidated repo:
>>
>> http://cr.openjdk.java.net/~kaddepalli/8075084/webrev01/
>>
>> Please review and let me know your comments.
>>
>> Thanks,
>> Krishna
>>
>> -----Original Message-----
>> From: Jason Mehrens [mailto:jason_mehrens at hotmail.com]
>> Sent: Wednesday, August 30, 2017 7:54 PM
>> To: Krishna Addepalli <krishna.addepalli at oracle.com>; 
>> swing-dev at openjdk.java.net
>> Subject: Re: <Swing Dev> [10][JDK-8075084] 
>> JOptionPane.showMessageDialog causes JScrollBar to move
>>
>> Related bug: 
>> http://mail.openjdk.java.net/pipermail/swing-dev/2014-April/003394.ht
>> ml
>>
>> ________________________________________
>> From: swing-dev <swing-dev-bounces at openjdk.java.net> on behalf of 
>> Krishna Addepalli <krishna.addepalli at oracle.com>
>> Sent: Tuesday, August 29, 2017 3:17 AM
>> To: swing-dev at openjdk.java.net
>> Subject: Re: <Swing Dev> [10][JDK-8075084] 
>> JOptionPane.showMessageDialog causes JScrollBar to move
>>
>> Hi Sergey,
>>
>> Can we have the fix pushed in, as per our conversation?
>>
>> Thanks,
>> Krishna
>>
>> From: Krishna Addepalli
>> Sent: Wednesday, July 26, 2017 3:07 PM
>> To: swing-dev at openjdk.java.net
>> Cc: Prasanta Sadhukhan <prasanta.sadhukhan at oracle.com>; Sergey 
>> Bylokhov <sergey.bylokhov at oracle.com>
>> Subject: [10][JDK-8075084] JOptionPane.showMessageDialog causes 
>> JScrollBar to move
>>
>> Hi All,
>>
>> Please review the fix for bug:
>>
>> Bug: JDK- 8075084  https://bugs.openjdk.java.net/browse/JDK-8075084
>>
>> JDK 10 Webrev : 
>> http://cr.openjdk.java.net/~psadhukhan/8075084/webrev00/
>>
>> Summary:
>> This is an interesting test case written by Drew Jetter (http://webbugs.us.oracle.com/IMWeb/incidentReportView.do?incidentID=2688093). The test shows a vertical scroll bar, and whenever the user clicks on the arrow buttons, it pops up a message dialog. The moment user clicks on "OK" button, the movement of the scrollbar doesnot stop, and it keeps showing up the dialog box again and again, while also moving the scroll bar till it reaches the end.
>>
>> This issue has already been root-caused here : http://mail.openjdk.java.net/pipermail/swing-dev/2016-November/006938.html , just reiterating here again:
>>
>> The problem is that once a Modal dialog is shown on top of the scrollbar, it loses focus, and hence doesnot get the mouse release event (which is swallowed by the DialogBox). For the mouse press event, the scrollbar would have started a timer, which keeps firing and generating the move events, which is why the slider moves repeatedly.
>>
>> Proposed fix is, once the scroll bar has moved by unit distance, check if it is still in focus, and only then start the timer. Otherwise *do not* start the timer, and also set the button press to false.
>>
>> PS: This could be a design decision as well, since the use case is not that common for scrollbar to lose focus on mouse press, so I decided to check out the behavior in Qt 5.9.1, and found that it too behaves the same way. Of course it's not binding that Java should behave the same way as Qt, but it was interesting to know that Qt also had similar behavior.
>>
>> Thanks,
>> Krishna
>>
>>
> 


--
Best regards, Sergey.


From andrej.golovnin at gmail.com  Wed Dec  6 08:29:56 2017
From: andrej.golovnin at gmail.com (Andrej Golovnin)
Date: Wed, 6 Dec 2017 09:29:56 +0100
Subject: <Swing Dev> [10] Review Request: JDK-7108280 :
 JList.getSelectedValuesList fails if JList.setSelectionInterval larger than
 list
In-Reply-To: <47487c2a-6e8f-fb35-cd70-3c8c7213e79b@oracle.com>
References: <36332afd-a4fb-4760-8919-211e91520bc3@default>
 <e4bc267e-c2c0-4a91-a835-35ff59b37ae8@default>
 <47487c2a-6e8f-fb35-cd70-3c8c7213e79b@oracle.com>
Message-ID: <CAM6ZMz-n4tdYVich=_aJgwhKVD_z7Mog=v1CKeaAGnsM5yU=uw@mail.gmail.com>

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 Dec  6 09:13:28 2017
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Wed, 6 Dec 2017 01:13:28 -0800 (PST)
Subject: <Swing Dev> [10][JDK-8190281] Code cleanup in
 src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java
Message-ID: <d76a18e3-c363-4159-834f-3ba81aa5a443@default>

Hi All,

 

Please review the fix for bug:

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

JDK 10 Webrev: http://cr.openjdk.java.net/~kaddepalli/8190281/webrev00/

 

This bug was created while root causing JDK-8187936, and the following refactoring points have been addressed:

 

1. Line 927: Uninitialized variables, checking for trivial reject case multiple times. 
2. Line 999: Traditional code written to find maximum size of components, which can be done without any local variables and explicit looping by replacing with streams. 
3. Line 1365: Code repetition for differenct conditions, which can be ored together to reduce the repetition. 
4. Line 1482: A large code block gets repeated only because of different values need to be passed in one line. This can be moved to a variable initialization, and the repeating code blocks can be reduced to one. 
5. Line 1505: Variable initialization can be simplified by combining different conditions. 
6. Line 1540: An explicit loop to apply a function over a collection, can be achieved in one line by a forEach construct.  - This is producing some visual artifacts, so ignored.
7. Line 1747: Combine all the trivial reject cases into one condition, and also, a potential bug which increments the "nextIndex" value beyond the length of the containing elements. The increment should happen only if the trivial reject case fails.

 

Thanks,

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

From abdul.kolarkunnu at oracle.com  Wed Dec  6 13:20:28 2017
From: abdul.kolarkunnu at oracle.com (Muneer Kolarkunnu)
Date: Wed, 6 Dec 2017 05:20:28 -0800 (PST)
Subject: <Swing Dev> [10] RFR JDK-8191803 : [TEST_BUG] :
 sanity/client/SwingSet/src/ProgressBarDemoTest.java failed with "Wait
 "greater then 1349" state to be reached
In-Reply-To: <57f1937a-3fd4-10a6-fbd3-dd689e01a58d@oracle.com>
References: <6b5970f5-fc14-45c4-83ad-48566767cec0@default>
 <57f1937a-3fd4-10a6-fbd3-dd689e01a58d@oracle.com>
Message-ID: <dfb248fa-81d1-45ab-ac3c-bee187df08c0@default>

Hi Sergey,

I updated the webrev to incorporate your comment.
New webrev: http://cr.openjdk.java.net/~akolarkunnu/8191803/webrev/webrev.01/
I kept jtreg timeout as 4 minute by considering all other operations of the test case.

Regards,
Muneer

-----Original Message-----
From: Sergey Bylokhov 
Sent: Monday, December 04, 2017 11:59 PM
To: Muneer Kolarkunnu <abdul.kolarkunnu at oracle.com>; swing-dev at openjdk.java.net
Cc: Aleksandre Iline <alexandre.iline at oracle.com>
Subject: Re: <Swing Dev> [10] RFR JDK-8191803 : [TEST_BUG] : sanity/client/SwingSet/src/ProgressBarDemoTest.java failed with "Wait "greater then 1349" state to be reached

Hello.
On 03/12/2017 22:54, Muneer Kolarkunnu wrote:
> Issue: In usual ways itself, it is taking 30-40 seconds to complete 
> the progress bar. So in slow machines it may take more time. Default 
> timeout is 1 minute. Also in the screen shots, it is visible that demo 
> is not blocked anywhere, it is still continuing, but failed due to timeout.

As far as I know that jtreg by default has 2 minute timeout, should it also be changed to 3 minutes?

--
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Wed Dec  6 14:59:24 2017
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 6 Dec 2017 06:59:24 -0800
Subject: <Swing Dev> [10] RFR JDK-8191803 : [TEST_BUG] :
 sanity/client/SwingSet/src/ProgressBarDemoTest.java failed with "Wait
 "greater then 1349" state to be reached
In-Reply-To: <dfb248fa-81d1-45ab-ac3c-bee187df08c0@default>
References: <6b5970f5-fc14-45c4-83ad-48566767cec0@default>
 <57f1937a-3fd4-10a6-fbd3-dd689e01a58d@oracle.com>
 <dfb248fa-81d1-45ab-ac3c-bee187df08c0@default>
Message-ID: <20853a11-61c9-f5b0-e22b-9054791c83fb@oracle.com>

Looks fine.

On 06/12/2017 05:20, Muneer Kolarkunnu wrote:
> Hi Sergey,
> 
> I updated the webrev to incorporate your comment.
> New webrev: http://cr.openjdk.java.net/~akolarkunnu/8191803/webrev/webrev.01/
> I kept jtreg timeout as 4 minute by considering all other operations of the test case.
> 
> Regards,
> Muneer
> 
> -----Original Message-----
> From: Sergey Bylokhov
> Sent: Monday, December 04, 2017 11:59 PM
> To: Muneer Kolarkunnu <abdul.kolarkunnu at oracle.com>; swing-dev at openjdk.java.net
> Cc: Aleksandre Iline <alexandre.iline at oracle.com>
> Subject: Re: <Swing Dev> [10] RFR JDK-8191803 : [TEST_BUG] : sanity/client/SwingSet/src/ProgressBarDemoTest.java failed with "Wait "greater then 1349" state to be reached
> 
> Hello.
> On 03/12/2017 22:54, Muneer Kolarkunnu wrote:
>> Issue: In usual ways itself, it is taking 30-40 seconds to complete
>> the progress bar. So in slow machines it may take more time. Default
>> timeout is 1 minute. Also in the screen shots, it is visible that demo
>> is not blocked anywhere, it is still continuing, but failed due to timeout.
> 
> As far as I know that jtreg by default has 2 minute timeout, should it also be changed to 3 minutes?
> 
> --
> Best regards, Sergey.
> 


-- 
Best regards, Sergey.


From philip.race at oracle.com  Wed Dec  6 16:33:18 2017
From: philip.race at oracle.com (Phil Race)
Date: Wed, 6 Dec 2017 08:33:18 -0800
Subject: <Swing Dev> [10] Review request for 8182041: File Chooser
 Shortcut Panel folders under on JDK 9
In-Reply-To: <8ec1366f-c6bc-08bb-7552-63b8ee7e1455@oracle.com>
References: <db72d1e4-9bdd-1aac-46e9-cb596e8d00a8@oracle.com>
 <8ec1366f-c6bc-08bb-7552-63b8ee7e1455@oracle.com>
Message-ID: <70745340-e93c-66cc-7ba6-3c5cfdf8dfb0@oracle.com>

Hi,
I have some additional comments on this old review thread. Hopefully we 
can close it out soon
although it will need a CSR whatever ..

Since the implementation of ShellFolderManager filters out inaccessible 
files we
should document this somewhere.
I suggest either on the class or relevant methods saying something like
"Files or resources which are not accessible in the current security 
context
may be filtered out from the returned set".

The word "may" is key here ..

If we are sure that this is always the case then it would follow that 
SecurityException
does not need to be documented.
Consistency would suggest that then this policy would extend to the 
other methods
added in JDK 9 which declare that exception. So all or none.
Being a RuntimeException that is not checked I think we can compatibly 
remove those.

-phil.


On 10/24/2017 09:22 PM, Alexander Zvegintsev wrote:
>
> Hi Semyon,
>
> the fix looks good to me, but I found a minor typo in the test:
>
> testShortcatPanelFiles -> testShortcutPanelFiles
>
> no need for a new webrev
>
> Thanks,
> Alexander.
> On 04/10/2017 00:41, Semyon Sadetsky wrote:
>> Hello,
>>
>> Please review fix for JDK10 (the changes involve AWT and Swing):
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8182041
>>
>> webrev: http://cr.openjdk.java.net/~ssadetsky/8182041/webrev.00/
>>
>> New API method was added letting to query shortcut panel entries for 
>> JFileChooser.
>>
>> --Semyon
>>
>

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

From philip.race at oracle.com  Wed Dec  6 16:47:28 2017
From: philip.race at oracle.com (Phil Race)
Date: Wed, 6 Dec 2017 08:47:28 -0800
Subject: <Swing Dev> [10][JDK-8187936] Automatically selecting a new
 JTree node in a model listener can cause unusual behavior.
In-Reply-To: <671eee33-370b-4a81-bacf-b5ab54b1ea3e@default>
References: <d4a9eb4b-245f-493f-ba92-fa02c08001d7@default>
 <0970ee11-25c8-4282-b0d7-2a007e53a2ac@default>
 <cb76bcd6-4bde-4be9-a712-56d5ca01e4b5@default>
 <9a4accda-215e-340a-1db4-9b7aa029e459@oracle.com>
 <671eee33-370b-4a81-bacf-b5ab54b1ea3e@default>
Message-ID: <34064286-e7de-175b-7b18-e67ce268b2d5@oracle.com>

So you seem to be saying that the listeners installed by the UI 
component itself
can process events directly on the EDT thread, but application code must 
use invokeLater ?
This is particularly important for events which cause structural updates 
to the model and the UI.


May I then suggest the following version of text on the package description:
--

Although it is generally safe to make updates to the UI immediately,
when executing on the event dispatch thread, there is an exception :
if a model listener tries to further change the UI before the UI has 
been updated to
reflect a pending change then the UI may render incorrectly.

This can happen if an application installed listener needs to update the 
UI in response
to an event which will cause a change in the model structure. It is 
important to first allow
component installed listeners to process this change, since there is no 
guarantee of the order
in which listeners may be called.

The solution is for the application listener to make the change using 
{@link SwingUtilities.invokeLater}
so that any changes to UI rendering will be done post processing all the 
model listeners
installed by the component.
---

-phil.


On 11/17/2017 06:11 PM, Krishna Addepalli wrote:
>
> Hi Phil,
>
> I have attached the code for your reference. However, the problem is 
> specifically in this function:
>
> @Override
> public void treeNodesInserted(final TreeModelEvent event) {
>                 SwingUtilities./invokeLater/(() -> {
> final TreePath pathToLastInsertedChild =
> event.getTreePath().pathByAddingChild(event.getChildren()[event.getChildren().length 
> - 1]);
> tree.setSelectionPath(pathToLastInsertedChild);
> });
>
> //                final TreePath pathToLastInsertedChild =
> // 
> event.getTreePath().pathByAddingChild(event.getChildren()[event.getChildren().length 
> - 1]);
> // tree.setSelectionPath(pathToLastInsertedChild);
> }
>
> This is part of the TreeModelListener class, which receives callbacks 
> for any changes to the underlying model of the tree ? like insertion, 
> deletion, structural changes etc. Now, the catch is even JTree has its 
> own ModelListener which listens to changes so that it can adapt its GUI.
>
> In this case, the listeners seem to be called from last to first ? 
> meaning the application registered listener will be called first and 
> then the components own ModelListener.
>
> In the above function, the application (commented out code) tries to 
> highlight the path to the newly inserted node, which JTree has not yet 
> seen since its listener is not called yet. This leads to inconsistent 
> UI rendering, since it would be trying to show some node which is not 
> present.
>
> For such cases, it is recommended to use ?SwingUtilities.invokeLater?, 
> so that, the new UI event will be processed after JTree has had a 
> chance to update itself to the changes in the model.
>
> Here is the code that is calling the listeners (in DefaultTreeModel.java):
>
> protected void fireTreeNodesInserted(Object source, Object[] path, 
>                                     int[] childIndices, Object[] 
> children) { // Guaranteed to return a non-null array Object[] 
> listeners = listenerList.getListenerList(); TreeModelEvent e = null; 
> // Process the listeners last to first, notifying     // those that 
> are interested in this event for (int i = listeners.length-2; i>=0; 
> i-=2) { if (listeners[i]==TreeModelListener.class) { // Lazily create 
> the event: if (e == null)                 e = new 
> TreeModelEvent(source, path, childIndices, children); 
> ((TreeModelListener)listeners[i+1]).treeNodesInserted(e); }     } }
>
> Thanks,
>
> Krishna
>
> *From:*Phil Race
> *Sent:* Saturday, November 18, 2017 3:29 AM
> *To:* Krishna Addepalli <krishna.addepalli at oracle.com>; 
> swing-dev at openjdk.java.net
> *Subject:* Re: <Swing Dev> [10][JDK-8187936] Automatically selecting a 
> new JTree node in a model listener can cause unusual behavior.
>
> Hi,
>
> Whilst I could perhaps provide some very minor tweaks to the wording you
> are adding, I would first like to understand the details of why the 
> rendering
> becomes broken here since there doesn't seem to be anything intrinsically
> wrong - only the model is being updated.
> I've found that commenting out one of the other listener methods
> BasicTreeUI.Handler.treeNodesInserted - "cures" it.
> So what we seem to be saying here, is that when you get notification
> of a change in the model, you must not make further changes in the model
> until any UI listener has processed the first change .. and throwing this
> on the queue via invokeLater is the obvious way to do that.
>
> But I've run out of time to look at quite where the rendering breaks
> and I'm not sure if this is as general a problem as the new comment
> would imply.
>
> So can you say something about why we miss rendering some nodes
> and quite why BasicTreeUI.Handler.treeNodesInserted is breaking it.
>
> -phil.
>
>
> On 11/12/2017 11:07 PM, Krishna Addepalli wrote:
>
>     Hi Sergey,
>
>     Gentle reminder. Could you review?
>
>     Thanks,
>
>     Krishna
>
>     *From:* Krishna Addepalli
>     *Sent:* Wednesday, November 8, 2017 8:22 PM
>     *To:* swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>
>     *Subject:* RE: [10][JDK-8187936] Automatically selecting a new
>     JTree node in a model listener can cause unusual behavior.
>
>     Hi Sergey,
>
>     Could you review this and let me know your feedback?
>
>     Thanks,
>
>     Krishna
>
>     *From:* Krishna Addepalli
>     *Sent:* Friday, October 27, 2017 4:43 PM
>     *To:* swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>
>     *Subject:* [10][JDK-8187936] Automatically selecting a new JTree
>     node in a model listener can cause unusual behavior.
>
>     Hi All,
>
>     Please review the help text that is updated for this bug:
>
>     Bug: JDK-8187936: https://bugs.openjdk.java.net/browse/JDK-8187936
>
>     Webrev: http://cr.openjdk.java.net/~kaddepalli/8187936/webrev00/
>     <http://cr.openjdk.java.net/%7Ekaddepalli/8187936/webrev00/>
>
>     Summary:
>
>     As the bug title mentions, this is an unrecommended way of using
>     the model listeners. The code posted in the bug tries to update
>     the JTree path in the model listener callback, and since the JTree
>     is yet to change itself to the underlying model, it results in
>     weird UI behavior.
>
>     Attached code in the bug is corrected and re-uploaded.
>
>     This typically happens since listeners are called in a particular
>     order (either last to first or first to last in the order of
>     registration), and if the model listener tries to change the GUI
>     before the GUI has had a chance to react itself to the changes in
>     the underlying model. For example, highlighting a selection path
>     for a node added in the JTree, in the TreeModelListener callback
>     could lead to an extra node being added or existing nodes not
>     being shown, since JTree would not have yet updated its state
>     based on the model changes.
>
>     In such cases it is recommended to wrap the callback function
>     contents into a lambda, and invoke it through
>     ?SwingUtilities.invokeLater?. This ensures that all the UI
>     elements have had a chance to react to the model changes, and any
>     UI actions will be guaranteed to operate on the updated widgets.
>
>     Similar update has been done in package-info.java for Swing, so
>     that it acts as a reference.
>
>     Thanks,
>
>     Krishna
>

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

From semyon.sadetsky at oracle.com  Wed Dec  6 17:39:34 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Wed, 6 Dec 2017 09:39:34 -0800
Subject: <Swing Dev> [10] Review request for 8182041: File Chooser
 Shortcut Panel folders under on JDK 9
In-Reply-To: <70745340-e93c-66cc-7ba6-3c5cfdf8dfb0@oracle.com>
References: <db72d1e4-9bdd-1aac-46e9-cb596e8d00a8@oracle.com>
 <8ec1366f-c6bc-08bb-7552-63b8ee7e1455@oracle.com>
 <70745340-e93c-66cc-7ba6-3c5cfdf8dfb0@oracle.com>
Message-ID: <daca5637-9b6f-2bd4-4614-d54d02991d33@oracle.com>

On 12/06/2017 08:33 AM, Phil Race wrote:

> Hi,
> I have some additional comments on this old review thread. Hopefully 
> we can close it out soon
> although it will need a CSR whatever ..
>
> Since the implementation of ShellFolderManager filters out 
> inaccessible files we
> should document this somewhere.
> I suggest either on the class or relevant methods saying something like
> "Files or resources which are not accessible in the current security 
> context
> may be filtered out from the returned set".
>
> The word "may" is key here ..
This looks to me like implementation details. I agree that it is worth 
to mention this problematic in the method spec but since it is a generic 
method for different platforms it probably should be given in a 
different form than a particular platform specific solution. If the 
entries of the list are virtual they may not have any file system 
permissions at all.
>
> If we are sure that this is always the case then it would follow that 
> SecurityException
> does not need to be documented.
> Consistency would suggest that then this policy would extend to the 
> other methods
> added in JDK 9 which declare that exception. So all or none.
> Being a RuntimeException that is not checked I think we can compatibly 
> remove those.
This is not consistent with other JDK classes in which the 
SecurityException is always mentioned, for example, the java.awt.Desktop 
class and there are many others. I think it would be non-practical to 
rewrite all other specs because you've changed your mind in this 
particular fix review.
Also, in this fix review [1]? you brought an opposite point of view.

[1] 
http://mail.openjdk.java.net/pipermail/swing-dev/2015-October/005073.html

--Semyon

>
> -phil.
>
>
> On 10/24/2017 09:22 PM, Alexander Zvegintsev wrote:
>>
>> Hi Semyon,
>>
>> the fix looks good to me, but I found a minor typo in the test:
>>
>> testShortcatPanelFiles -> testShortcutPanelFiles
>>
>> no need for a new webrev
>>
>> Thanks,
>> Alexander.
>> On 04/10/2017 00:41, Semyon Sadetsky wrote:
>>> Hello,
>>>
>>> Please review fix for JDK10 (the changes involve AWT and Swing):
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8182041
>>>
>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8182041/webrev.00/
>>>
>>> New API method was added letting to query shortcut panel entries for 
>>> JFileChooser.
>>>
>>> --Semyon
>>>
>>
>

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

From philip.race at oracle.com  Wed Dec  6 17:56:10 2017
From: philip.race at oracle.com (Phil Race)
Date: Wed, 6 Dec 2017 09:56:10 -0800
Subject: <Swing Dev> [10] Review request for 8182041: File Chooser
 Shortcut Panel folders under on JDK 9
In-Reply-To: <daca5637-9b6f-2bd4-4614-d54d02991d33@oracle.com>
References: <db72d1e4-9bdd-1aac-46e9-cb596e8d00a8@oracle.com>
 <8ec1366f-c6bc-08bb-7552-63b8ee7e1455@oracle.com>
 <70745340-e93c-66cc-7ba6-3c5cfdf8dfb0@oracle.com>
 <daca5637-9b6f-2bd4-4614-d54d02991d33@oracle.com>
Message-ID: <738414ab-3666-5ec8-3154-1f7702d03d88@oracle.com>



On 12/06/2017 09:39 AM, Semyon Sadetsky wrote:
>
> On 12/06/2017 08:33 AM, Phil Race wrote:
>
>> Hi,
>> I have some additional comments on this old review thread. Hopefully 
>> we can close it out soon
>> although it will need a CSR whatever ..
>>
>> Since the implementation of ShellFolderManager filters out 
>> inaccessible files we
>> should document this somewhere.
>> I suggest either on the class or relevant methods saying something like
>> "Files or resources which are not accessible in the current security 
>> context
>> may be filtered out from the returned set".
>>
>> The word "may" is key here ..
> This looks to me like implementation details.

No. On the contrary. It can be specified.

> I agree that it is worth to mention this problematic in the method 
> spec but since it is a generic method for different platforms it 
> probably should be given in a different form than a particular 
> platform specific solution. If the entries of the list are virtual 
> they may not have any file system permissions at all.
>>
>> If we are sure that this is always the case then it would follow that 
>> SecurityException
>> does not need to be documented.
>> Consistency would suggest that then this policy would extend to the 
>> other methods
>> added in JDK 9 which declare that exception. So all or none.
>> Being a RuntimeException that is not checked I think we can 
>> compatibly remove those.
> This is not consistent with other JDK classes in which the 
> SecurityException is always mentioned, for example, the 
> java.awt.Desktop class and there are many others. I think it would be 
> non-practical to rewrite all other specs because you've changed your 
> mind in this particular fix review.

The API contract of some other class such as Desktop is not relevant.

I am saying FileSystemView should be internally consistent


> Also, in this fix review [1]  you brought an opposite point of view.
>
> [1] 
> http://mail.openjdk.java.net/pipermail/swing-dev/2015-October/005073.html

That was because no one told me at the time that we were filtering out 
to prevent leakage.
i.e I have new information.


-phil.
>
> --Semyon
>
>>
>> -phil.
>>
>>
>> On 10/24/2017 09:22 PM, Alexander Zvegintsev wrote:
>>>
>>> Hi Semyon,
>>>
>>> the fix looks good to me, but I found a minor typo in the test:
>>>
>>> testShortcatPanelFiles -> testShortcutPanelFiles
>>>
>>> no need for a new webrev
>>>
>>> Thanks,
>>> Alexander.
>>> On 04/10/2017 00:41, Semyon Sadetsky wrote:
>>>> Hello,
>>>>
>>>> Please review fix for JDK10 (the changes involve AWT and Swing):
>>>>
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8182041
>>>>
>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8182041/webrev.00/
>>>>
>>>> New API method was added letting to query shortcut panel entries 
>>>> for JFileChooser.
>>>>
>>>> --Semyon
>>>>
>>>
>>
>

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

From krishna.addepalli at oracle.com  Thu Dec  7 11:11:54 2017
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Thu, 7 Dec 2017 03:11:54 -0800 (PST)
Subject: <Swing Dev> [10][JDK-8190281] Code cleanup in
 src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java
In-Reply-To: <d76a18e3-c363-4159-834f-3ba81aa5a443@default>
References: <d76a18e3-c363-4159-834f-3ba81aa5a443@default>
Message-ID: <8ff212fc-7c49-4963-99af-477ac4a0f4e1@default>

Hi Sergey,

 

Per our conversation, I have done the following changes:

1.       Found that the .class size increases by 1kb when streams are used, so reverted the changes related to it.

2.       Moved the "++nextIndex" into the conditional, so that there is no logical change.

Here is the updated webrev: http://cr.openjdk.java.net/~kaddepalli/8190281/webrev01/

 

Thanks,

Krishna

 

From: Krishna Addepalli 
Sent: Wednesday, December 6, 2017 2:43 PM
To: swing-dev at openjdk.java.net
Subject: [10][JDK-8190281] Code cleanup in src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java

 

Hi All,

 

Please review the fix for bug:

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

JDK 10 Webrev: http://cr.openjdk.java.net/~kaddepalli/8190281/webrev00/

 

This bug was created while root causing JDK-8187936, and the following refactoring points have been addressed:

 

1. Line 927: Uninitialized variables, checking for trivial reject case multiple times. 
2. Line 999: Traditional code written to find maximum size of components, which can be done without any local variables and explicit looping by replacing with streams. 
3. Line 1365: Code repetition for differenct conditions, which can be ored together to reduce the repetition. 
4. Line 1482: A large code block gets repeated only because of different values need to be passed in one line. This can be moved to a variable initialization, and the repeating code blocks can be reduced to one. 
5. Line 1505: Variable initialization can be simplified by combining different conditions. 
6. Line 1540: An explicit loop to apply a function over a collection, can be achieved in one line by a forEach construct.  - This is producing some visual artifacts, so ignored.
7. Line 1747: Combine all the trivial reject cases into one condition, and also, a potential bug which increments the "nextIndex" value beyond the length of the containing elements. The increment should happen only if the trivial reject case fails.

 

Thanks,

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

From krishna.addepalli at oracle.com  Thu Dec  7 11:39:27 2017
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Thu, 7 Dec 2017 03:39:27 -0800 (PST)
Subject: <Swing Dev> [10][JDK-8187936] Automatically selecting a new
 JTree node in a model listener can cause unusual behavior.
In-Reply-To: <34064286-e7de-175b-7b18-e67ce268b2d5@oracle.com>
References: <d4a9eb4b-245f-493f-ba92-fa02c08001d7@default>
 <0970ee11-25c8-4282-b0d7-2a007e53a2ac@default>
 <cb76bcd6-4bde-4be9-a712-56d5ca01e4b5@default>
 <9a4accda-215e-340a-1db4-9b7aa029e459@oracle.com>
 <671eee33-370b-4a81-bacf-b5ab54b1ea3e@default>
 <34064286-e7de-175b-7b18-e67ce268b2d5@oracle.com>
Message-ID: <dacf24b4-d938-41d3-aaad-8d69a5ade565@default>

Hi Phil

 

Thank you for your time in understanding the issue and rephrasing the text. I have created a new webrev, with the text you mentioned, and here it is: http://cr.openjdk.java.net/~kaddepalli/8187936/webrev01/

 

Regards,

Krishna

 

From: Phil Race 
Sent: Wednesday, December 6, 2017 10:17 PM
To: Krishna Addepalli <krishna.addepalli at oracle.com>; swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10][JDK-8187936] Automatically selecting a new JTree node in a model listener can cause unusual behavior.

 

So you seem to be saying that the listeners installed by the UI component itself
can process events directly on the EDT thread, but application code must use invokeLater ?
This is particularly important for events which cause structural updates to the model and the UI.


May I then suggest the following version of text on the package description:
--

Although it is generally safe to make updates to the UI immediately,
when executing on the event dispatch thread, there is an exception :
if a model listener tries to further change the UI before the UI has been updated to
reflect a pending change then the UI may render incorrectly.

This can happen if an application installed listener needs to update the UI in response
to an event which will cause a change in the model structure. It is important to first allow
component installed listeners to process this change, since there is no guarantee of the order
in which listeners may be called.

The solution is for the application listener to make the change using {@link SwingUtilities.invokeLater}
so that any changes to  UI rendering will be done post processing all the model listeners
installed by the component.
---

-phil.



On 11/17/2017 06:11 PM, Krishna Addepalli wrote:

Hi Phil,

 

I have attached the code for your reference. However, the problem is specifically in this function: 

 

            @Override
            public void treeNodesInserted(final TreeModelEvent event) {
                SwingUtilities.invokeLater(() -> {
                    final TreePath pathToLastInsertedChild =
                            event.getTreePath().pathByAddingChild(event.getChildren()[event.getChildren().length - 1]);
                    tree.setSelectionPath(pathToLastInsertedChild);
                });

//                final TreePath pathToLastInsertedChild =
//                        event.getTreePath().pathByAddingChild(event.getChildren()[event.getChildren().length - 1]);
//                tree.setSelectionPath(pathToLastInsertedChild);
            }

 

This is part of the TreeModelListener class, which receives callbacks for any changes to the underlying model of the tree - like insertion, deletion, structural changes etc. Now, the catch is even JTree has its own ModelListener which listens to changes so that it can adapt its GUI. 

In this case, the listeners seem to be called from last to first - meaning the application registered listener will be called first and then the components own ModelListener.

In the above function, the application (commented out code) tries to highlight the path to the newly inserted node, which JTree has not yet seen since its listener is not called yet. This leads to inconsistent UI rendering, since it would be trying to show some node which is not present.

For such cases, it is recommended to use "SwingUtilities.invokeLater", so that, the new UI event will be processed after JTree has had a chance to update itself to the changes in the model.

 

Here is the code that is calling the listeners (in DefaultTreeModel.java):

protected void fireTreeNodesInserted(Object source, Object[] path,
                                    int[] childIndices,
                                    Object[] children) {
    // Guaranteed to return a non-null array
    Object[] listeners = listenerList.getListenerList();
    TreeModelEvent e = null;
    // Process the listeners last to first, notifying
    // those that are interested in this event
    for (int i = listeners.length-2; i>=0; i-=2) {
        if (listeners[i]==TreeModelListener.class) {
            // Lazily create the event:
            if (e == null)
                e = new TreeModelEvent(source, path,
                                       childIndices, children);
            ((TreeModelListener)listeners[i+1]).treeNodesInserted(e);
        }
    }
}

 

 

Thanks,

Krishna

 

 

From: Phil Race 
Sent: Saturday, November 18, 2017 3:29 AM
To: Krishna Addepalli HYPERLINK "mailto:krishna.addepalli at oracle.com"<krishna.addepalli at oracle.com>; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10][JDK-8187936] Automatically selecting a new JTree node in a model listener can cause unusual behavior.

 

Hi,

Whilst I could perhaps provide some very minor tweaks to the wording you
are adding, I would first like to understand the details of why the rendering
becomes broken here since there doesn't seem to be anything intrinsically
wrong - only the model is being updated.
I've found that commenting out one of the other listener methods
BasicTreeUI.Handler.treeNodesInserted - "cures" it.
So what we seem to be saying here, is that when you get notification
of a change in the model, you must not make further changes in the model
until any UI listener has processed the first change .. and throwing this
on the queue via invokeLater is the obvious way to do that.

But I've run out of time to look at quite where the rendering breaks
and I'm not sure if this is as general a problem as the new comment
would imply.

So can you say something about why we miss rendering some nodes
and quite why BasicTreeUI.Handler.treeNodesInserted is breaking it.

-phil.





On 11/12/2017 11:07 PM, Krishna Addepalli wrote:

Hi Sergey,

 

Gentle reminder. Could you review?

 

Thanks,

Krishna

 

From: Krishna Addepalli 
Sent: Wednesday, November 8, 2017 8:22 PM
To: HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: RE: [10][JDK-8187936] Automatically selecting a new JTree node in a model listener can cause unusual behavior.

 

Hi Sergey,

Could you review this and let me know your feedback?

 

Thanks,

Krishna

 

From: Krishna Addepalli 
Sent: Friday, October 27, 2017 4:43 PM
To: HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: [10][JDK-8187936] Automatically selecting a new JTree node in a model listener can cause unusual behavior.

 

Hi All,

Please review the help text that is updated for this bug:

 

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

 

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

 

Summary:

As the bug title mentions, this is an unrecommended way of using the model listeners. The code posted in the bug tries to update the JTree path in the model listener callback, and since the JTree is yet to change itself to the underlying model, it results in weird UI behavior.

Attached code in the bug is corrected and re-uploaded. 

 

This typically happens since listeners are called in a particular order (either last to first or first to last in the order of registration), and if the model listener tries to change the GUI before the GUI has had a chance to react itself to the changes in the underlying model. For example, highlighting a selection path for a node added in the JTree, in the TreeModelListener callback could lead to an extra node being added or existing nodes not being shown, since JTree would not have yet updated its state based on the model changes.

 

In such cases it is recommended to wrap the callback function contents into a lambda, and invoke it through "SwingUtilities.invokeLater". This ensures that all the UI elements have had a chance to react to the model changes, and any UI actions will be guaranteed to operate on the updated widgets.

 

Similar update has been done in package-info.java for Swing, so that it acts as a reference.

 

Thanks,

Krishna

 

 

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

From philip.race at oracle.com  Thu Dec  7 19:45:59 2017
From: philip.race at oracle.com (Phil Race)
Date: Thu, 7 Dec 2017 11:45:59 -0800
Subject: <Swing Dev> RFR: 8193211 : Update jtreg TEST.groups and ProblemList
 for client-libs
Message-ID: <302f904d-1391-caff-0b4f-134ca407abd9@oracle.com>

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

adds jdk_swing_core and jdk_desktop_core test groups to jtreg

Also problem lists many (by no means all) of the known jtreg failures.

-phil



From philip.race at oracle.com  Thu Dec  7 20:54:14 2017
From: philip.race at oracle.com (Phil Race)
Date: Thu, 7 Dec 2017 12:54:14 -0800
Subject: <Swing Dev> RFR: 8189809: Large performance regression in Swing
	text layout.
Message-ID: <3afdaac9-4ce3-661d-d6d6-5efc25e4bfb6@oracle.com>

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

This partially addresses a slow-down in Swing.

Swing now usually calls Font.getStringBounds() instead of 
FontMetrics().stringWidth for text measurement.

The latter has a fast-path for latin-only simple text.

The former does not .. and at a minimum uses GlyphVector.

This fix provides a similar fast path and for direct calls to these 
methods (micro benchmarks)
that is latin text they are now very similar .. at least for typical 
strings.

In this fix as well as making this change in the font code, I updated 
Swing to more
be a little more efficient.

Before this fix I always saw Swing  coming in with a char[] .. then 
constructing a String from it.
Then it passes it to the font measurement code, which then decomposes 
the string back into a char[]
If Swing directly uses the API that takes a char[] then we save some 
overhead.


It does not get back all of the loss by Swing since

1) Swing has other overhead elsewhere - it seems

2) Swing is making 90% of these calls for a single char.
This could be from where Swing naively tries to add up char advances 
itself to
get a string advance.

     We may have to come back to that later. Perhaps with new public API.

-phil.




From prasanta.sadhukhan at oracle.com  Fri Dec  8 04:35:30 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Fri, 8 Dec 2017 10:05:30 +0530
Subject: <Swing Dev> RFR: 8193211 : Update jtreg TEST.groups and
 ProblemList for client-libs
In-Reply-To: <302f904d-1391-caff-0b4f-134ca407abd9@oracle.com>
References: <302f904d-1391-caff-0b4f-134ca407abd9@oracle.com>
Message-ID: <22f61f55-6c6d-658e-5b3b-c8ddd361e449@oracle.com>

+1

Regards
Prasanta
On 12/8/2017 1:15 AM, Phil Race wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8193211
> Webrev: http://cr.openjdk.java.net/~prr/8193211/
>
> adds jdk_swing_core and jdk_desktop_core test groups to jtreg
>
> Also problem lists many (by no means all) of the known jtreg failures.
>
> -phil
>



From abdul.kolarkunnu at oracle.com  Fri Dec  8 05:15:16 2017
From: abdul.kolarkunnu at oracle.com (Muneer Kolarkunnu)
Date: Thu, 7 Dec 2017 21:15:16 -0800 (PST)
Subject: <Swing Dev> RFR: 8193211 : Update jtreg TEST.groups and
 ProblemList for client-libs
In-Reply-To: <302f904d-1391-caff-0b4f-134ca407abd9@oracle.com>
References: <302f904d-1391-caff-0b4f-134ca407abd9@oracle.com>
Message-ID: <c96725d3-bf43-43f8-ae93-2d0376d01d11@default>

Hi Phil,

jdk/internal/util \ has already removed by task https://bugs.openjdk.java.net/browse/JDK-8192958 .

I think better to use group name "jdk_client_sanity" instead of "sanity/client/SwingSet \" at line no:358.

Typo " commuonly" at line no: 355.

Regards,
Muneer

-----Original Message-----
From: Phil Race 
Sent: Friday, December 08, 2017 1:16 AM
To: awt-dev at openjdk.java.net; swing-dev at openjdk.java.net
Subject: <Swing Dev> RFR: 8193211 : Update jtreg TEST.groups and ProblemList for client-libs

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

adds jdk_swing_core and jdk_desktop_core test groups to jtreg

Also problem lists many (by no means all) of the known jtreg failures.

-phil



From philip.race at oracle.com  Fri Dec  8 05:45:21 2017
From: philip.race at oracle.com (Philip Race)
Date: Thu, 07 Dec 2017 21:45:21 -0800
Subject: <Swing Dev> RFR: 8193211 : Update jtreg TEST.groups and
 ProblemList for client-libs
In-Reply-To: <c96725d3-bf43-43f8-ae93-2d0376d01d11@default>
References: <302f904d-1391-caff-0b4f-134ca407abd9@oracle.com>
 <c96725d3-bf43-43f8-ae93-2d0376d01d11@default>
Message-ID: <5A2A26F1.9020503@oracle.com>



On 12/7/17, 9:15 PM, Muneer Kolarkunnu wrote:
> Hi Phil,
>
> jdk/internal/util \ has already removed by task https://bugs.openjdk.java.net/browse/JDK-8192958 .

Fixed 9 hours ago  ? .. so not when I did this work !
Anyway it is redundant so I will not need to do this.
>
> I think better to use group name "jdk_client_sanity" instead of "sanity/client/SwingSet \" at line no:358.

I agree.
>
> Typo " commuonly" at line no: 355.

Noted.

-phil
>
> Regards,
> Muneer
>
> -----Original Message-----
> From: Phil Race
> Sent: Friday, December 08, 2017 1:16 AM
> To: awt-dev at openjdk.java.net; swing-dev at openjdk.java.net
> Subject:<Swing Dev>  RFR: 8193211 : Update jtreg TEST.groups and ProblemList for client-libs
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8193211
> Webrev: http://cr.openjdk.java.net/~prr/8193211/
>
> adds jdk_swing_core and jdk_desktop_core test groups to jtreg
>
> Also problem lists many (by no means all) of the known jtreg failures.
>
> -phil
>


From pankaj.b.bansal at oracle.com  Fri Dec  8 07:13:14 2017
From: pankaj.b.bansal at oracle.com (Pankaj Bansal)
Date: Thu, 7 Dec 2017 23:13:14 -0800 (PST)
Subject: <Swing Dev> [10] Review Request: JDK-7108280 :
 JList.getSelectedValuesList fails if JList.setSelectionInterval larger than
 list
In-Reply-To: <CAM6ZMz-n4tdYVich=_aJgwhKVD_z7Mog=v1CKeaAGnsM5yU=uw@mail.gmail.com>
References: <36332afd-a4fb-4760-8919-211e91520bc3@default>
 <e4bc267e-c2c0-4a91-a835-35ff59b37ae8@default>
 <47487c2a-6e8f-fb35-cd70-3c8c7213e79b@oracle.com>
 <CAM6ZMz-n4tdYVich=_aJgwhKVD_z7Mog=v1CKeaAGnsM5yU=uw@mail.gmail.com>
Message-ID: <9e468958-5ae9-4696-897f-ab4c65f4bbda@default>

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 andrej.golovnin at gmail.com  Fri Dec  8 07:39:30 2017
From: andrej.golovnin at gmail.com (Andrej Golovnin)
Date: Fri, 8 Dec 2017 08:39:30 +0100
Subject: <Swing Dev> [10] Review Request: JDK-7108280 :
 JList.getSelectedValuesList fails if JList.setSelectionInterval larger than
 list
In-Reply-To: <9e468958-5ae9-4696-897f-ab4c65f4bbda@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>
Message-ID: <CAM6ZMz9qoiJQYDA_PMShafiZHbyGB3s5wHWAyZ6HXag=t6qwUQ@mail.gmail.com>

Hi all,

there is one more option:

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

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

Just my 2 cents.

Best regards,
Andrej Golovnin

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


From prasanta.sadhukhan at oracle.com  Fri Dec  8 09:53:57 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Fri, 8 Dec 2017 15:23:57 +0530
Subject: <Swing Dev> [10] RFR JDK-8191803 : [TEST_BUG] :
 sanity/client/SwingSet/src/ProgressBarDemoTest.java failed with "Wait
 "greater then 1349" state to be reached
In-Reply-To: <20853a11-61c9-f5b0-e22b-9054791c83fb@oracle.com>
References: <6b5970f5-fc14-45c4-83ad-48566767cec0@default>
 <57f1937a-3fd4-10a6-fbd3-dd689e01a58d@oracle.com>
 <dfb248fa-81d1-45ab-ac3c-bee187df08c0@default>
 <20853a11-61c9-f5b0-e22b-9054791c83fb@oracle.com>
Message-ID: <36b391ff-9440-13c0-5603-444e646535a2@oracle.com>

+1

Regards
Prasanta
On 12/6/2017 8:29 PM, Sergey Bylokhov wrote:
> Looks fine.
>
> On 06/12/2017 05:20, Muneer Kolarkunnu wrote:
>> Hi Sergey,
>>
>> I updated the webrev to incorporate your comment.
>> New webrev: 
>> http://cr.openjdk.java.net/~akolarkunnu/8191803/webrev/webrev.01/
>> I kept jtreg timeout as 4 minute by considering all other operations 
>> of the test case.
>>
>> Regards,
>> Muneer
>>
>> -----Original Message-----
>> From: Sergey Bylokhov
>> Sent: Monday, December 04, 2017 11:59 PM
>> To: Muneer Kolarkunnu <abdul.kolarkunnu at oracle.com>; 
>> swing-dev at openjdk.java.net
>> Cc: Aleksandre Iline <alexandre.iline at oracle.com>
>> Subject: Re: <Swing Dev> [10] RFR JDK-8191803 : [TEST_BUG] : 
>> sanity/client/SwingSet/src/ProgressBarDemoTest.java failed with "Wait 
>> "greater then 1349" state to be reached
>>
>> Hello.
>> On 03/12/2017 22:54, Muneer Kolarkunnu wrote:
>>> Issue: In usual ways itself, it is taking 30-40 seconds to complete
>>> the progress bar. So in slow machines it may take more time. Default
>>> timeout is 1 minute. Also in the screen shots, it is visible that demo
>>> is not blocked anywhere, it is still continuing, but failed due to 
>>> timeout.
>>
>> As far as I know that jtreg by default has 2 minute timeout, should 
>> it also be changed to 3 minutes?
>>
>> -- 
>> Best regards, Sergey.
>>
>
>



From manajit.halder at oracle.com  Fri Dec  8 13:53:51 2017
From: manajit.halder at oracle.com (Manajit Halder)
Date: Fri, 8 Dec 2017 19:23:51 +0530
Subject: <Swing Dev> Swing dev>[10] Review request for JDK-8189253: [macos]
 JPopupMenu is inadvertently shown when using setComponentPopupMenu
Message-ID: <E1445698-445B-4542-98C1-1D82A4A182C9@oracle.com>

Hi All,

Kindly review the following Swing fix.

Bug: https://bugs.openjdk.java.net/browse/JDK-8189253 <https://bugs.openjdk.java.net/browse/JDK-8189253>
Webrev: http://cr.openjdk.java.net/~mhalder/8189253/webrev.00/ <http://cr.openjdk.java.net/~mhalder/8189253/webrev.00/>

Cause: 
	Issue was due to retargeting of mouse enter exit events. 
	MOUSE_ENTER and MOUSE_EXIT events were sent on the parent window (JFrame) in between MOUSE_PRESS and MOUSE_RELEASE events on the modeless JDialog.

Fix:
	Retargeting of events is not done in-between MOUSE_PRESS and MOUSE_RELEASE.

Regards,
Manajit

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

From semyon.sadetsky at oracle.com  Fri Dec  8 16:25:17 2017
From: semyon.sadetsky at oracle.com (semyon.sadetsky at oracle.com)
Date: Fri, 8 Dec 2017 08:25:17 -0800
Subject: <Swing Dev> Swing dev>[10] Review request for JDK-8189253:
 [macos] JPopupMenu is inadvertently shown when using setComponentPopupMenu
In-Reply-To: <E1445698-445B-4542-98C1-1D82A4A182C9@oracle.com>
References: <E1445698-445B-4542-98C1-1D82A4A182C9@oracle.com>
Message-ID: <4ed5cbcf-c1f7-f615-6404-ebe13c47b8da@oracle.com>

Hi Manajit,

Can you provide information which fix caused the regression?

--Semyon


On 12/8/17 5:53 AM, Manajit Halder wrote:
> Hi All,
>
> Kindly review the following Swing fix.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8189253
> Webrev: http://cr.openjdk.java.net/~mhalder/8189253/webrev.00/ 
> <http://cr.openjdk.java.net/%7Emhalder/8189253/webrev.00/>
>
> Cause:
> Issue was due to retargeting of mouse enter exit events.
> MOUSE_ENTER and MOUSE_EXIT events were sent on the parent window 
> (JFrame) in between MOUSE_PRESS and MOUSE_RELEASE events on the 
> modeless JDialog.
>
> Fix:
> Retargeting of events is not done in-between MOUSE_PRESS and 
> MOUSE_RELEASE.
>
> Regards,
> Manajit
>

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

From prasanta.sadhukhan at oracle.com  Sat Dec  9 14:23:43 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Sat, 9 Dec 2017 19:53:43 +0530
Subject: <Swing Dev> [10][JDK-8190281] Code cleanup in
 src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java
In-Reply-To: <8ff212fc-7c49-4963-99af-477ac4a0f4e1@default>
References: <d76a18e3-c363-4159-834f-3ba81aa5a443@default>
 <8ff212fc-7c49-4963-99af-477ac4a0f4e1@default>
Message-ID: <a7046f27-04f7-ac0d-bec1-fa555a842ec1@oracle.com>

Hi Krishna,

This seems good to me except one thing. You are checking getRowCount() 
== 0 but there is a chance of test extending VariableHeightLayoutCache 
and overriding getRowCount to return -ve also as it is an int. In that 
case, I guess this function will not return -1 which spec mandates [If 
there are no rows, -1 is returned] so I guess we should check for <=0.
Also, there is no need of calling getRowCount() twice as it will not 
change between 929, 936.

Regards
Prasanta
On 12/7/2017 4:41 PM, Krishna Addepalli wrote:
>
> Hi Sergey,
>
> Per our conversation, I have done the following changes:
>
> 1.Found that the .class size increases by 1kb when streams are used, 
> so reverted the changes related to it.
>
> 2.Moved the ?++nextIndex? into the conditional, so that there is no 
> logical change.
>
> Here is the updated webrev: 
> http://cr.openjdk.java.net/~kaddepalli/8190281/webrev01/ 
> <http://cr.openjdk.java.net/%7Ekaddepalli/8190281/webrev01/>
>
> Thanks,
>
> Krishna
>
> *From:* Krishna Addepalli
> *Sent:* Wednesday, December 6, 2017 2:43 PM
> *To:* swing-dev at openjdk.java.net
> *Subject:* [10][JDK-8190281] Code cleanup in 
> src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java
>
> Hi All,
>
> Please review the fix for bug:
>
> Bug: JDK-8190281 https://bugs.openjdk.java.net/browse/JDK-8190281
>
> JDK 10 Webrev: 
> http://cr.openjdk.java.net/~kaddepalli/8190281/webrev00/ 
> <http://cr.openjdk.java.net/%7Ekaddepalli/8190281/webrev00/>
>
> This bug was created while root causing JDK-8187936, and the following 
> refactoring points have been addressed:
>
> 1. Line 927: Uninitialized variables, checking for trivial reject case 
> multiple times.
> 2. Line 999: Traditional code written to find maximum size of 
> components, which can be done without any local variables and explicit 
> looping by replacing with streams.
> 3. Line 1365: Code repetition for differenct conditions, which can be 
> ored together to reduce the repetition.
> 4. Line 1482: A large code block gets repeated only because of 
> different values need to be passed in one line. This can be moved to a 
> variable initialization, and the repeating code blocks can be reduced 
> to one.
> 5. Line 1505: Variable initialization can be simplified by combining 
> different conditions.
> 6. Line 1540: An explicit loop to apply a function over a collection, 
> can be achieved in one line by a forEach construct.? ? This is 
> producing some visual artifacts, so ignored.
> 7. Line 1747: Combine all the trivial reject cases into one condition, 
> and also, a potential bug which increments the "nextIndex" value 
> beyond the length of the containing elements. The increment should 
> happen only if the trivial reject case fails.
>
> Thanks,
>
> Krishna
>

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

From krishna.addepalli at oracle.com  Mon Dec 11 09:31:04 2017
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Mon, 11 Dec 2017 01:31:04 -0800 (PST)
Subject: <Swing Dev> [10][JDK-8190281] Code cleanup in
 src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java
In-Reply-To: <a7046f27-04f7-ac0d-bec1-fa555a842ec1@oracle.com>
References: <d76a18e3-c363-4159-834f-3ba81aa5a443@default>
 <8ff212fc-7c49-4963-99af-477ac4a0f4e1@default>
 <a7046f27-04f7-ac0d-bec1-fa555a842ec1@oracle.com>
Message-ID: <e10f0a03-74d4-48da-ac8c-5828147c88ee@default>

Hi Prasanta,

 

Thanks for pointing out the "getRowCount()==0" check. Modified it to "getRowCount() <= 0" in the new webrev: http://cr.openjdk.java.net/~kaddepalli/8190281/webrev02/

 

As for calling the method twice, you are right that we don't need to call it twice, but in the interest of having trivial reject case first, and then start the variable declarations, had to let be there to be called twice. Precisely for the reason you stated, it shouldn't matter if we called it twice.

 

Thanks,

Krishna

 

From: Prasanta Sadhukhan 
Sent: Saturday, December 9, 2017 7:54 PM
To: Krishna Addepalli <krishna.addepalli at oracle.com>; swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10][JDK-8190281] Code cleanup in src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java

 

Hi Krishna,

This seems good to me except one thing. You are checking getRowCount() == 0 but there is a chance of test extending VariableHeightLayoutCache and overriding getRowCount to return -ve also as it is an int. In that case, I guess this function will not return -1 which spec mandates [If there are no rows, -1 is returned] so I guess we should check for <=0. 
Also, there is no need of calling getRowCount() twice as it will not change between 929, 936.

Regards
Prasanta

On 12/7/2017 4:41 PM, Krishna Addepalli wrote:

Hi Sergey,

 

Per our conversation, I have done the following changes:

1.       Found that the .class size increases by 1kb when streams are used, so reverted the changes related to it.

2.       Moved the "++nextIndex" into the conditional, so that there is no logical change.

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

 

Thanks,

Krishna

 

From: Krishna Addepalli 
Sent: Wednesday, December 6, 2017 2:43 PM
To: HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: [10][JDK-8190281] Code cleanup in src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java

 

Hi All,

 

Please review the fix for bug:

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

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

 

This bug was created while root causing JDK-8187936, and the following refactoring points have been addressed:

 

1. Line 927: Uninitialized variables, checking for trivial reject case multiple times. 
2. Line 999: Traditional code written to find maximum size of components, which can be done without any local variables and explicit looping by replacing with streams. 
3. Line 1365: Code repetition for differenct conditions, which can be ored together to reduce the repetition. 
4. Line 1482: A large code block gets repeated only because of different values need to be passed in one line. This can be moved to a variable initialization, and the repeating code blocks can be reduced to one. 
5. Line 1505: Variable initialization can be simplified by combining different conditions. 
6. Line 1540: An explicit loop to apply a function over a collection, can be achieved in one line by a forEach construct.  - This is producing some visual artifacts, so ignored.
7. Line 1747: Combine all the trivial reject cases into one condition, and also, a potential bug which increments the "nextIndex" value beyond the length of the containing elements. The increment should happen only if the trivial reject case fails.

 

Thanks,

Krishna

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

From prasanta.sadhukhan at oracle.com  Mon Dec 11 10:32:14 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Mon, 11 Dec 2017 16:02:14 +0530
Subject: <Swing Dev> [10][JDK-8190281] Code cleanup in
 src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java
In-Reply-To: <e10f0a03-74d4-48da-ac8c-5828147c88ee@default>
References: <d76a18e3-c363-4159-834f-3ba81aa5a443@default>
 <8ff212fc-7c49-4963-99af-477ac4a0f4e1@default>
 <a7046f27-04f7-ac0d-bec1-fa555a842ec1@oracle.com>
 <e10f0a03-74d4-48da-ac8c-5828147c88ee@default>
Message-ID: <500d86a0-53dd-645a-eb8b-a74a4511a2d1@oracle.com>

Hi Krishna,

My point was we can call getRowCount() once at first and store the 
result and use it subsequently. There was no need to call it 2-3 times.

Regards
Prasanta
On 12/11/2017 3:01 PM, Krishna Addepalli wrote:
>
> Hi Prasanta,
>
> Thanks for pointing out the ?getRowCount()==0? check. Modified it to 
> ?getRowCount() <= 0? in the new webrev: 
> http://cr.openjdk.java.net/~kaddepalli/8190281/webrev02/ 
> <http://cr.openjdk.java.net/%7Ekaddepalli/8190281/webrev02/>
>
> As for calling the method twice, you are right that we don?t need to 
> call it twice, but in the interest of having trivial reject case 
> first, and then start the variable declarations, had to let be there 
> to be called twice. Precisely for the reason you stated, it shouldn?t 
> matter if we called it twice.
>
> Thanks,
>
> Krishna
>
> *From:*Prasanta Sadhukhan
> *Sent:* Saturday, December 9, 2017 7:54 PM
> *To:* Krishna Addepalli <krishna.addepalli at oracle.com>; 
> swing-dev at openjdk.java.net
> *Subject:* Re: <Swing Dev> [10][JDK-8190281] Code cleanup in 
> src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java
>
> Hi Krishna,
>
> This seems good to me except one thing. You are checking getRowCount() 
> == 0 but there is a chance of test extending VariableHeightLayoutCache 
> and overriding getRowCount to return -ve also as it is an int. In that 
> case, I guess this function will not return -1 which spec mandates [If 
> there are no rows, -1 is returned] so I guess we should check for <=0.
> Also, there is no need of calling getRowCount() twice as it will not 
> change between 929, 936.
>
> Regards
> Prasanta
>
> On 12/7/2017 4:41 PM, Krishna Addepalli wrote:
>
>     Hi Sergey,
>
>     Per our conversation, I have done the following changes:
>
>     1.Found that the .class size increases by 1kb when streams are
>     used, so reverted the changes related to it.
>
>     2.Moved the ?++nextIndex? into the conditional, so that there is
>     no logical change.
>
>     Here is the updated webrev:
>     http://cr.openjdk.java.net/~kaddepalli/8190281/webrev01/
>     <http://cr.openjdk.java.net/%7Ekaddepalli/8190281/webrev01/>
>
>     Thanks,
>
>     Krishna
>
>     *From:* Krishna Addepalli
>     *Sent:* Wednesday, December 6, 2017 2:43 PM
>     *To:* swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>
>     *Subject:* [10][JDK-8190281] Code cleanup in
>     src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java
>
>     Hi All,
>
>     Please review the fix for bug:
>
>     Bug: JDK-8190281 https://bugs.openjdk.java.net/browse/JDK-8190281
>
>     JDK 10 Webrev:
>     http://cr.openjdk.java.net/~kaddepalli/8190281/webrev00/
>     <http://cr.openjdk.java.net/%7Ekaddepalli/8190281/webrev00/>
>
>     This bug was created while root causing JDK-8187936, and the
>     following refactoring points have been addressed:
>
>     1. Line 927: Uninitialized variables, checking for trivial reject
>     case multiple times.
>     2. Line 999: Traditional code written to find maximum size of
>     components, which can be done without any local variables and
>     explicit looping by replacing with streams.
>     3. Line 1365: Code repetition for differenct conditions, which can
>     be ored together to reduce the repetition.
>     4. Line 1482: A large code block gets repeated only because of
>     different values need to be passed in one line. This can be moved
>     to a variable initialization, and the repeating code blocks can be
>     reduced to one.
>     5. Line 1505: Variable initialization can be simplified by
>     combining different conditions.
>     6. Line 1540: An explicit loop to apply a function over a
>     collection, can be achieved in one line by a forEach construct.? ?
>     This is producing some visual artifacts, so ignored.
>     7. Line 1747: Combine all the trivial reject cases into one
>     condition, and also, a potential bug which increments the
>     "nextIndex" value beyond the length of the containing elements.
>     The increment should happen only if the trivial reject case fails.
>
>     Thanks,
>
>     Krishna
>

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

From krishna.addepalli at oracle.com  Mon Dec 11 10:46:59 2017
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Mon, 11 Dec 2017 02:46:59 -0800 (PST)
Subject: <Swing Dev> [10][JDK-8190281] Code cleanup in
 src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java
In-Reply-To: <500d86a0-53dd-645a-eb8b-a74a4511a2d1@oracle.com>
References: <d76a18e3-c363-4159-834f-3ba81aa5a443@default>
 <8ff212fc-7c49-4963-99af-477ac4a0f4e1@default>
 <a7046f27-04f7-ac0d-bec1-fa555a842ec1@oracle.com>
 <e10f0a03-74d4-48da-ac8c-5828147c88ee@default>
 <500d86a0-53dd-645a-eb8b-a74a4511a2d1@oracle.com>
Message-ID: <d605fbaf-2884-49e4-98fb-6a46e4cd989d@default>

Hi Prasanta,

 

Yes, you are right, but as I mentioned earlier, that would need to make one variable declaration for caching before trivial reject case, which I wanted to avoid.

As for the body of getRowCount() it is just returning "visibleNodes.size()", which shouldn't be a (performance)problem if called 2 times as I understand.

 

Thanks,

Krishna

 

From: Prasanta Sadhukhan 
Sent: Monday, December 11, 2017 4:02 PM
To: Krishna Addepalli <krishna.addepalli at oracle.com>; swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10][JDK-8190281] Code cleanup in src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java

 

Hi Krishna,

My point was we can call getRowCount() once at first and store the result and use it subsequently. There was no need to call it 2-3 times.

Regards
Prasanta

On 12/11/2017 3:01 PM, Krishna Addepalli wrote:

Hi Prasanta,

 

Thanks for pointing out the "getRowCount()==0" check. Modified it to "getRowCount() <= 0" in the new webrev: HYPERLINK "http://cr.openjdk.java.net/%7Ekaddepalli/8190281/webrev02/"http://cr.openjdk.java.net/~kaddepalli/8190281/webrev02/

 

As for calling the method twice, you are right that we don't need to call it twice, but in the interest of having trivial reject case first, and then start the variable declarations, had to let be there to be called twice. Precisely for the reason you stated, it shouldn't matter if we called it twice.

 

Thanks,

Krishna

 

From: Prasanta Sadhukhan 
Sent: Saturday, December 9, 2017 7:54 PM
To: Krishna Addepalli HYPERLINK "mailto:krishna.addepalli at oracle.com"<krishna.addepalli at oracle.com>; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10][JDK-8190281] Code cleanup in src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java

 

Hi Krishna,

This seems good to me except one thing. You are checking getRowCount() == 0 but there is a chance of test extending VariableHeightLayoutCache and overriding getRowCount to return -ve also as it is an int. In that case, I guess this function will not return -1 which spec mandates [If there are no rows, -1 is returned] so I guess we should check for <=0. 
Also, there is no need of calling getRowCount() twice as it will not change between 929, 936.

Regards
Prasanta

On 12/7/2017 4:41 PM, Krishna Addepalli wrote:

Hi Sergey,

 

Per our conversation, I have done the following changes:

1.       Found that the .class size increases by 1kb when streams are used, so reverted the changes related to it.

2.       Moved the "++nextIndex" into the conditional, so that there is no logical change.

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

 

Thanks,

Krishna

 

From: Krishna Addepalli 
Sent: Wednesday, December 6, 2017 2:43 PM
To: HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: [10][JDK-8190281] Code cleanup in src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java

 

Hi All,

 

Please review the fix for bug:

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

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

 

This bug was created while root causing JDK-8187936, and the following refactoring points have been addressed:

 

1. Line 927: Uninitialized variables, checking for trivial reject case multiple times. 
2. Line 999: Traditional code written to find maximum size of components, which can be done without any local variables and explicit looping by replacing with streams. 
3. Line 1365: Code repetition for differenct conditions, which can be ored together to reduce the repetition. 
4. Line 1482: A large code block gets repeated only because of different values need to be passed in one line. This can be moved to a variable initialization, and the repeating code blocks can be reduced to one. 
5. Line 1505: Variable initialization can be simplified by combining different conditions. 
6. Line 1540: An explicit loop to apply a function over a collection, can be achieved in one line by a forEach construct.  - This is producing some visual artifacts, so ignored.
7. Line 1747: Combine all the trivial reject cases into one condition, and also, a potential bug which increments the "nextIndex" value beyond the length of the containing elements. The increment should happen only if the trivial reject case fails.

 

Thanks,

Krishna

 

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

From prahalad.kumar.narayanan at oracle.com  Mon Dec 11 13:10:48 2017
From: prahalad.kumar.narayanan at oracle.com (Prahalad Kumar Narayanan)
Date: Mon, 11 Dec 2017 05:10:48 -0800 (PST)
Subject: <Swing Dev> [OpenJDK 2D-Dev] RFR: 8189809: Large performance
 regression in Swing text layout.
In-Reply-To: <3afdaac9-4ce3-661d-d6d6-5efc25e4bfb6@oracle.com>
References: <3afdaac9-4ce3-661d-d6d6-5efc25e4bfb6@oracle.com>
Message-ID: <332230c2-15b6-4101-b078-74c1ea906e3f@default>

Hello Phil

The change looks good to me.

I found two interesting changes in your webrev. 
. The move to use FontDesignMetrics to compute width should be better than generating GlyphVector for the same.
. Besides, the double conversion from chars[] to String and vice versa has been avoided as well.

Thank you
Have a good day

Prahalad

-----Original Message-----
From: Phil Race 
Sent: Friday, December 08, 2017 2:24 AM
To: 2d-dev; swing-dev at openjdk.java.net
Subject: [OpenJDK 2D-Dev] RFR: 8189809: Large performance regression in Swing text layout.

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

This partially addresses a slow-down in Swing.

Swing now usually calls Font.getStringBounds() instead of FontMetrics().stringWidth for text measurement.

The latter has a fast-path for latin-only simple text.

The former does not .. and at a minimum uses GlyphVector.

This fix provides a similar fast path and for direct calls to these methods (micro benchmarks) that is latin text they are now very similar .. at least for typical strings.

In this fix as well as making this change in the font code, I updated Swing to more be a little more efficient.

Before this fix I always saw Swing  coming in with a char[] .. then constructing a String from it.
Then it passes it to the font measurement code, which then decomposes the string back into a char[] If Swing directly uses the API that takes a char[] then we save some overhead.


It does not get back all of the loss by Swing since

1) Swing has other overhead elsewhere - it seems

2) Swing is making 90% of these calls for a single char.
This could be from where Swing naively tries to add up char advances itself to get a string advance.

     We may have to come back to that later. Perhaps with new public API.

-phil.




From prasanta.sadhukhan at oracle.com  Mon Dec 11 13:53:50 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Mon, 11 Dec 2017 19:23:50 +0530
Subject: <Swing Dev> [10][JDK-8190281] Code cleanup in
 src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java
In-Reply-To: <d605fbaf-2884-49e4-98fb-6a46e4cd989d@default>
References: <d76a18e3-c363-4159-834f-3ba81aa5a443@default>
 <8ff212fc-7c49-4963-99af-477ac4a0f4e1@default>
 <a7046f27-04f7-ac0d-bec1-fa555a842ec1@oracle.com>
 <e10f0a03-74d4-48da-ac8c-5828147c88ee@default>
 <500d86a0-53dd-645a-eb8b-a74a4511a2d1@oracle.com>
 <d605fbaf-2884-49e4-98fb-6a46e4cd989d@default>
Message-ID: <133264f1-5e1c-1999-8f9f-a940d8edbe11@oracle.com>



On 12/11/2017 4:16 PM, Krishna Addepalli wrote:
>
> Hi Prasanta,
>
> Yes, you are right, but as I mentioned earlier, that would need to 
> make one variable declaration for caching before trivial reject case, 
> which I wanted to avoid.
>
> As for the body of getRowCount() it is just returning 
> ?visibleNodes.size()?, which shouldn?t be a (performance)problem if 
> called 2 times as I understand.
>
But, the whole premise of changing getRowCount() <=0? was that it can be 
overridden and return -ve. Left to present implementation, we would not 
have needed "less than" check.
So, if we are changing one case because of the above reason, then we 
cannot forego the 2nd case's problem, as it can have any implementation.

Regards
Prasanta
>
> Thanks,
>
> Krishna
>
> *From:*Prasanta Sadhukhan
> *Sent:* Monday, December 11, 2017 4:02 PM
> *To:* Krishna Addepalli <krishna.addepalli at oracle.com>; 
> swing-dev at openjdk.java.net
> *Subject:* Re: <Swing Dev> [10][JDK-8190281] Code cleanup in 
> src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java
>
> Hi Krishna,
>
> My point was we can call getRowCount() once at first and store the 
> result and use it subsequently. There was no need to call it 2-3 times.
>
> Regards
> Prasanta
>
> On 12/11/2017 3:01 PM, Krishna Addepalli wrote:
>
>     Hi Prasanta,
>
>     Thanks for pointing out the ?getRowCount()==0? check. Modified it
>     to ?getRowCount() <= 0? in the new webrev:
>     http://cr.openjdk.java.net/~kaddepalli/8190281/webrev02/
>     <http://cr.openjdk.java.net/%7Ekaddepalli/8190281/webrev02/>
>
>     As for calling the method twice, you are right that we don?t need
>     to call it twice, but in the interest of having trivial reject
>     case first, and then start the variable declarations, had to let
>     be there to be called twice. Precisely for the reason you stated,
>     it shouldn?t matter if we called it twice.
>
>     Thanks,
>
>     Krishna
>
>     *From:*Prasanta Sadhukhan
>     *Sent:* Saturday, December 9, 2017 7:54 PM
>     *To:* Krishna Addepalli <krishna.addepalli at oracle.com>
>     <mailto:krishna.addepalli at oracle.com>; swing-dev at openjdk.java.net
>     <mailto:swing-dev at openjdk.java.net>
>     *Subject:* Re: <Swing Dev> [10][JDK-8190281] Code cleanup in
>     src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java
>
>     Hi Krishna,
>
>     This seems good to me except one thing. You are checking
>     getRowCount() == 0 but there is a chance of test extending
>     VariableHeightLayoutCache and overriding getRowCount to return -ve
>     also as it is an int. In that case, I guess this function will not
>     return -1 which spec mandates [If there are no rows, -1 is
>     returned] so I guess we should check for <=0.
>     Also, there is no need of calling getRowCount() twice as it will
>     not change between 929, 936.
>
>     Regards
>     Prasanta
>
>     On 12/7/2017 4:41 PM, Krishna Addepalli wrote:
>
>         Hi Sergey,
>
>         Per our conversation, I have done the following changes:
>
>         1.Found that the .class size increases by 1kb when streams are
>         used, so reverted the changes related to it.
>
>         2.Moved the ?++nextIndex? into the conditional, so that there
>         is no logical change.
>
>         Here is the updated webrev:
>         http://cr.openjdk.java.net/~kaddepalli/8190281/webrev01/
>         <http://cr.openjdk.java.net/%7Ekaddepalli/8190281/webrev01/>
>
>         Thanks,
>
>         Krishna
>
>         *From:* Krishna Addepalli
>         *Sent:* Wednesday, December 6, 2017 2:43 PM
>         *To:* swing-dev at openjdk.java.net
>         <mailto:swing-dev at openjdk.java.net>
>         *Subject:* [10][JDK-8190281] Code cleanup in
>         src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java
>
>         Hi All,
>
>         Please review the fix for bug:
>
>         Bug: JDK-8190281 https://bugs.openjdk.java.net/browse/JDK-8190281
>
>         JDK 10 Webrev:
>         http://cr.openjdk.java.net/~kaddepalli/8190281/webrev00/
>         <http://cr.openjdk.java.net/%7Ekaddepalli/8190281/webrev00/>
>
>         This bug was created while root causing JDK-8187936, and the
>         following refactoring points have been addressed:
>
>         1. Line 927: Uninitialized variables, checking for trivial
>         reject case multiple times.
>         2. Line 999: Traditional code written to find maximum size of
>         components, which can be done without any local variables and
>         explicit looping by replacing with streams.
>         3. Line 1365: Code repetition for differenct conditions, which
>         can be ored together to reduce the repetition.
>         4. Line 1482: A large code block gets repeated only because of
>         different values need to be passed in one line. This can be
>         moved to a variable initialization, and the repeating code
>         blocks can be reduced to one.
>         5. Line 1505: Variable initialization can be simplified by
>         combining different conditions.
>         6. Line 1540: An explicit loop to apply a function over a
>         collection, can be achieved in one line by a forEach
>         construct.? ? This is producing some visual artifacts, so ignored.
>         7. Line 1747: Combine all the trivial reject cases into one
>         condition, and also, a potential bug which increments the
>         "nextIndex" value beyond the length of the containing
>         elements. The increment should happen only if the trivial
>         reject case fails.
>
>         Thanks,
>
>         Krishna
>

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

From philip.race at oracle.com  Mon Dec 11 16:52:13 2017
From: philip.race at oracle.com (Phil Race)
Date: Mon, 11 Dec 2017 08:52:13 -0800
Subject: <Swing Dev> [10][JDK-8187936] Automatically selecting a new
 JTree node in a model listener can cause unusual behavior.
In-Reply-To: <dacf24b4-d938-41d3-aaad-8d69a5ade565@default>
References: <d4a9eb4b-245f-493f-ba92-fa02c08001d7@default>
 <0970ee11-25c8-4282-b0d7-2a007e53a2ac@default>
 <cb76bcd6-4bde-4be9-a712-56d5ca01e4b5@default>
 <9a4accda-215e-340a-1db4-9b7aa029e459@oracle.com>
 <671eee33-370b-4a81-bacf-b5ab54b1ea3e@default>
 <34064286-e7de-175b-7b18-e67ce268b2d5@oracle.com>
 <dacf24b4-d938-41d3-aaad-8d69a5ade565@default>
Message-ID: <103943ff-b257-6ab1-5390-1c8b88b78def@oracle.com>

Ok.

-phil.

On 12/07/2017 03:39 AM, Krishna Addepalli wrote:
>
> Hi Phil
>
> Thank you for your time in understanding the issue and rephrasing the 
> text. I have created a new webrev, with the text you mentioned, and 
> here it is: http://cr.openjdk.java.net/~kaddepalli/8187936/webrev01/ 
> <http://cr.openjdk.java.net/%7Ekaddepalli/8187936/webrev01/>
>
> Regards,
>
> Krishna
>
> *From:*Phil Race
> *Sent:* Wednesday, December 6, 2017 10:17 PM
> *To:* Krishna Addepalli <krishna.addepalli at oracle.com>; 
> swing-dev at openjdk.java.net
> *Subject:* Re: <Swing Dev> [10][JDK-8187936] Automatically selecting a 
> new JTree node in a model listener can cause unusual behavior.
>
> So you seem to be saying that the listeners installed by the UI 
> component itself
> can process events directly on the EDT thread, but application code 
> must use invokeLater ?
> This is particularly important for events which cause structural 
> updates to the model and the UI.
>
>
> May I then suggest the following version of text on the package 
> description:
> --
>
> Although it is generally safe to make updates to the UI immediately,
> when executing on the event dispatch thread, there is an exception :
> if a model listener tries to further change the UI before the UI has 
> been updated to
> reflect a pending change then the UI may render incorrectly.
>
> This can happen if an application installed listener needs to update 
> the UI in response
> to an event which will cause a change in the model structure. It is 
> important to first allow
> component installed listeners to process this change, since there is 
> no guarantee of the order
> in which listeners may be called.
>
> The solution is for the application listener to make the change using 
> {@link SwingUtilities.invokeLater}
> so that any changes to  UI rendering will be done post processing all 
> the model listeners
> installed by the component.
> ---
>
> -phil.
>
> On 11/17/2017 06:11 PM, Krishna Addepalli wrote:
>
>     Hi Phil,
>
>     I have attached the code for your reference. However, the problem
>     is specifically in this function:
>
>     @Override
>     public void treeNodesInserted(final TreeModelEvent event) {
>                     SwingUtilities./invokeLater/(() -> {
>     final TreePath pathToLastInsertedChild =
>     event.getTreePath().pathByAddingChild(event.getChildren()[event.getChildren().length
>     - 1]);
>     tree.setSelectionPath(pathToLastInsertedChild);
>     });
>
>     //                final TreePath pathToLastInsertedChild =
>     //
>     event.getTreePath().pathByAddingChild(event.getChildren()[event.getChildren().length
>     - 1]);
>     // tree.setSelectionPath(pathToLastInsertedChild);
>     }
>
>     This is part of the TreeModelListener class, which receives
>     callbacks for any changes to the underlying model of the tree ?
>     like insertion, deletion, structural changes etc. Now, the catch
>     is even JTree has its own ModelListener which listens to changes
>     so that it can adapt its GUI.
>
>     In this case, the listeners seem to be called from last to first ?
>     meaning the application registered listener will be called first
>     and then the components own ModelListener.
>
>     In the above function, the application (commented out code) tries
>     to highlight the path to the newly inserted node, which JTree has
>     not yet seen since its listener is not called yet. This leads to
>     inconsistent UI rendering, since it would be trying to show some
>     node which is not present.
>
>     For such cases, it is recommended to use
>     ?SwingUtilities.invokeLater?, so that, the new UI event will be
>     processed after JTree has had a chance to update itself to the
>     changes in the model.
>
>     Here is the code that is calling the listeners (in
>     DefaultTreeModel.java):
>
>     protected void fireTreeNodesInserted(Object source, Object[] path,
>
>                                         int[] childIndices,
>
>     Object[] children) {
>
>     // Guaranteed to return a non-null array
>
>     Object[] listeners = listenerList.getListenerList();
>
>     TreeModelEvent e = null;
>
>     // Process the listeners last to first, notifying
>
>         // those that are interested in this event
>
>     for (int i = listeners.length-2; i>=0; i-=2) {
>
>     if (listeners[i]==TreeModelListener.class) {
>
>     // Lazily create the event:
>
>     if (e == null)
>
>                     e = new TreeModelEvent(source, path,
>
>     childIndices, children);
>
>     ((TreeModelListener)listeners[i+1]).treeNodesInserted(e);
>
>     }
>
>         }
>
>     }
>
>     Thanks,
>
>     Krishna
>
>     *From:*Phil Race
>     *Sent:* Saturday, November 18, 2017 3:29 AM
>     *To:* Krishna Addepalli <krishna.addepalli at oracle.com>
>     <mailto:krishna.addepalli at oracle.com>; swing-dev at openjdk.java.net
>     <mailto:swing-dev at openjdk.java.net>
>     *Subject:* Re: <Swing Dev> [10][JDK-8187936] Automatically
>     selecting a new JTree node in a model listener can cause unusual
>     behavior.
>
>     Hi,
>
>     Whilst I could perhaps provide some very minor tweaks to the
>     wording you
>     are adding, I would first like to understand the details of why
>     the rendering
>     becomes broken here since there doesn't seem to be anything
>     intrinsically
>     wrong - only the model is being updated.
>     I've found that commenting out one of the other listener methods
>     BasicTreeUI.Handler.treeNodesInserted - "cures" it.
>     So what we seem to be saying here, is that when you get notification
>     of a change in the model, you must not make further changes in the
>     model
>     until any UI listener has processed the first change .. and
>     throwing this
>     on the queue via invokeLater is the obvious way to do that.
>
>     But I've run out of time to look at quite where the rendering breaks
>     and I'm not sure if this is as general a problem as the new comment
>     would imply.
>
>     So can you say something about why we miss rendering some nodes
>     and quite why BasicTreeUI.Handler.treeNodesInserted is breaking it.
>
>     -phil.
>
>
>
>     On 11/12/2017 11:07 PM, Krishna Addepalli wrote:
>
>         Hi Sergey,
>
>         Gentle reminder. Could you review?
>
>         Thanks,
>
>         Krishna
>
>         *From:* Krishna Addepalli
>         *Sent:* Wednesday, November 8, 2017 8:22 PM
>         *To:* swing-dev at openjdk.java.net
>         <mailto:swing-dev at openjdk.java.net>
>         *Subject:* RE: [10][JDK-8187936] Automatically selecting a new
>         JTree node in a model listener can cause unusual behavior.
>
>         Hi Sergey,
>
>         Could you review this and let me know your feedback?
>
>         Thanks,
>
>         Krishna
>
>         *From:* Krishna Addepalli
>         *Sent:* Friday, October 27, 2017 4:43 PM
>         *To:* swing-dev at openjdk.java.net
>         <mailto:swing-dev at openjdk.java.net>
>         *Subject:* [10][JDK-8187936] Automatically selecting a new
>         JTree node in a model listener can cause unusual behavior.
>
>         Hi All,
>
>         Please review the help text that is updated for this bug:
>
>         Bug: JDK-8187936: https://bugs.openjdk.java.net/browse/JDK-8187936
>
>         Webrev:
>         http://cr.openjdk.java.net/~kaddepalli/8187936/webrev00/
>         <http://cr.openjdk.java.net/%7Ekaddepalli/8187936/webrev00/>
>
>         Summary:
>
>         As the bug title mentions, this is an unrecommended way of
>         using the model listeners. The code posted in the bug tries to
>         update the JTree path in the model listener callback, and
>         since the JTree is yet to change itself to the underlying
>         model, it results in weird UI behavior.
>
>         Attached code in the bug is corrected and re-uploaded.
>
>         This typically happens since listeners are called in a
>         particular order (either last to first or first to last in the
>         order of registration), and if the model listener tries to
>         change the GUI before the GUI has had a chance to react itself
>         to the changes in the underlying model. For example,
>         highlighting a selection path for a node added in the JTree,
>         in the TreeModelListener callback could lead to an extra node
>         being added or existing nodes not being shown, since JTree
>         would not have yet updated its state based on the model changes.
>
>         In such cases it is recommended to wrap the callback function
>         contents into a lambda, and invoke it through
>         ?SwingUtilities.invokeLater?. This ensures that all the UI
>         elements have had a chance to react to the model changes, and
>         any UI actions will be guaranteed to operate on the updated
>         widgets.
>
>         Similar update has been done in package-info.java for Swing,
>         so that it acts as a reference.
>
>         Thanks,
>
>         Krishna
>

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

From Sergey.Bylokhov at oracle.com  Mon Dec 11 22:12:21 2017
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 11 Dec 2017 14:12:21 -0800
Subject: <Swing Dev> RFR: 8189809: Large performance regression in Swing
 text layout.
In-Reply-To: <3afdaac9-4ce3-661d-d6d6-5efc25e4bfb6@oracle.com>
References: <3afdaac9-4ce3-661d-d6d6-5efc25e4bfb6@oracle.com>
Message-ID: <3f728086-7545-b844-7ee4-8735593c0136@oracle.com>

Hi, Phil.
The new code will calculate the logical bounds this way:
     541 new Rectangle2D.Float(0f, ascent, width, height);
But previously it was:
     2613 new Rectangle2D.Float(0, -tl.getAscent(),   tl.getAdvance(),
     2614                       tl.getAscent() + tl.getDescent() +
     2615                       tl.getLeading());

Note that the second parameter is negative, is it intentionally changed?


On 07/12/2017 12:54, Phil Race wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8189809
> webrev: http://cr.openjdk.java.net/~prr/8189809/
> 
> This partially addresses a slow-down in Swing.
> 
> Swing now usually calls Font.getStringBounds() instead of 
> FontMetrics().stringWidth for text measurement.
> 
> The latter has a fast-path for latin-only simple text.
> 
> The former does not .. and at a minimum uses GlyphVector.
> 
> This fix provides a similar fast path and for direct calls to these 
> methods (micro benchmarks)
> that is latin text they are now very similar .. at least for typical 
> strings.
> 
> In this fix as well as making this change in the font code, I updated 
> Swing to more
> be a little more efficient.
> 
> Before this fix I always saw Swing? coming in with a char[] .. then 
> constructing a String from it.
> Then it passes it to the font measurement code, which then decomposes 
> the string back into a char[]
> If Swing directly uses the API that takes a char[] then we save some 
> overhead.
> 
> 
> It does not get back all of the loss by Swing since
> 
> 1) Swing has other overhead elsewhere - it seems
> 
> 2) Swing is making 90% of these calls for a single char.
> This could be from where Swing naively tries to add up char advances 
> itself to
> get a string advance.
> 
>  ??? We may have to come back to that later. Perhaps with new public API.
> 
> -phil.
> 
> 


-- 
Best regards, Sergey.


From philip.race at oracle.com  Mon Dec 11 22:39:54 2017
From: philip.race at oracle.com (Phil Race)
Date: Mon, 11 Dec 2017 14:39:54 -0800
Subject: <Swing Dev> RFR: 8189809: Large performance regression in Swing
 text layout.
In-Reply-To: <3f728086-7545-b844-7ee4-8735593c0136@oracle.com>
References: <3afdaac9-4ce3-661d-d6d6-5efc25e4bfb6@oracle.com>
 <3f728086-7545-b844-7ee4-8735593c0136@oracle.com>
Message-ID: <c068df89-7597-2952-367e-d3b0381f1a44@oracle.com>

Yes, it should  be negative since we want to use this as the y origin of 
the rectangle
relative to the baseline. I am using it correctly in the height calculation.

40 float height = ascent + descent + leading;
541 return new Rectangle2D.Float(0f, ascent, width, height);


http://cr.openjdk.java.net/~prr/8189809.1/

-phil.

On 12/11/2017 02:12 PM, Sergey Bylokhov wrote:
> Hi, Phil.
> The new code will calculate the logical bounds this way:
>     541 new Rectangle2D.Float(0f, ascent, width, height);
> But previously it was:
>     2613 new Rectangle2D.Float(0, -tl.getAscent(), tl.getAdvance(),
>     2614                       tl.getAscent() + tl.getDescent() +
>     2615                       tl.getLeading());
>
> Note that the second parameter is negative, is it intentionally changed?
>
>
> On 07/12/2017 12:54, Phil Race wrote:
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8189809
>> webrev: http://cr.openjdk.java.net/~prr/8189809/
>>
>> This partially addresses a slow-down in Swing.
>>
>> Swing now usually calls Font.getStringBounds() instead of 
>> FontMetrics().stringWidth for text measurement.
>>
>> The latter has a fast-path for latin-only simple text.
>>
>> The former does not .. and at a minimum uses GlyphVector.
>>
>> This fix provides a similar fast path and for direct calls to these 
>> methods (micro benchmarks)
>> that is latin text they are now very similar .. at least for typical 
>> strings.
>>
>> In this fix as well as making this change in the font code, I updated 
>> Swing to more
>> be a little more efficient.
>>
>> Before this fix I always saw Swing  coming in with a char[] .. then 
>> constructing a String from it.
>> Then it passes it to the font measurement code, which then decomposes 
>> the string back into a char[]
>> If Swing directly uses the API that takes a char[] then we save some 
>> overhead.
>>
>>
>> It does not get back all of the loss by Swing since
>>
>> 1) Swing has other overhead elsewhere - it seems
>>
>> 2) Swing is making 90% of these calls for a single char.
>> This could be from where Swing naively tries to add up char advances 
>> itself to
>> get a string advance.
>>
>>      We may have to come back to that later. Perhaps with new public 
>> API.
>>
>> -phil.
>>
>>
>
>

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

From Sergey.Bylokhov at oracle.com  Mon Dec 11 22:56:02 2017
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 11 Dec 2017 14:56:02 -0800
Subject: <Swing Dev> RFR: 8189809: Large performance regression in Swing
 text layout.
In-Reply-To: <c068df89-7597-2952-367e-d3b0381f1a44@oracle.com>
References: <3afdaac9-4ce3-661d-d6d6-5efc25e4bfb6@oracle.com>
 <3f728086-7545-b844-7ee4-8735593c0136@oracle.com>
 <c068df89-7597-2952-367e-d3b0381f1a44@oracle.com>
Message-ID: <41ed31d9-8959-28d7-818a-a892a078eef6@oracle.com>

Looks fine.

On 11/12/2017 14:39, Phil Race wrote:
> Yes, it should? be negative since we want to use this as the y origin of 
> the rectangle
> relative to the baseline. I am using it correctly in the height calculation.
> 
> 40 float height = ascent + descent + leading;
> 541 return new Rectangle2D.Float(0f, ascent, width, height);
> 
> 
> http://cr.openjdk.java.net/~prr/8189809.1/
> 
> -phil.
> 
> On 12/11/2017 02:12 PM, Sergey Bylokhov wrote:
>> Hi, Phil.
>> The new code will calculate the logical bounds this way:
>> ??? 541 new Rectangle2D.Float(0f, ascent, width, height);
>> But previously it was:
>> ??? 2613 new Rectangle2D.Float(0, -tl.getAscent(), tl.getAdvance(),
>> ??? 2614?????????????????????? tl.getAscent() + tl.getDescent() +
>> ??? 2615?????????????????????? tl.getLeading());
>>
>> Note that the second parameter is negative, is it intentionally changed?
>>
>>
>> On 07/12/2017 12:54, Phil Race wrote:
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8189809
>>> webrev: http://cr.openjdk.java.net/~prr/8189809/
>>>
>>> This partially addresses a slow-down in Swing.
>>>
>>> Swing now usually calls Font.getStringBounds() instead of 
>>> FontMetrics().stringWidth for text measurement.
>>>
>>> The latter has a fast-path for latin-only simple text.
>>>
>>> The former does not .. and at a minimum uses GlyphVector.
>>>
>>> This fix provides a similar fast path and for direct calls to these 
>>> methods (micro benchmarks)
>>> that is latin text they are now very similar .. at least for typical 
>>> strings.
>>>
>>> In this fix as well as making this change in the font code, I updated 
>>> Swing to more
>>> be a little more efficient.
>>>
>>> Before this fix I always saw Swing? coming in with a char[] .. then 
>>> constructing a String from it.
>>> Then it passes it to the font measurement code, which then decomposes 
>>> the string back into a char[]
>>> If Swing directly uses the API that takes a char[] then we save some 
>>> overhead.
>>>
>>>
>>> It does not get back all of the loss by Swing since
>>>
>>> 1) Swing has other overhead elsewhere - it seems
>>>
>>> 2) Swing is making 90% of these calls for a single char.
>>> This could be from where Swing naively tries to add up char advances 
>>> itself to
>>> get a string advance.
>>>
>>> ???? We may have to come back to that later. Perhaps with new public 
>>> API.
>>>
>>> -phil.
>>>
>>>
>>
>>
> 


-- 
Best regards, Sergey.


From krishna.addepalli at oracle.com  Tue Dec 12 11:51:02 2017
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Tue, 12 Dec 2017 03:51:02 -0800 (PST)
Subject: <Swing Dev> [10][JDK-8190281] Code cleanup in
 src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java
In-Reply-To: <133264f1-5e1c-1999-8f9f-a940d8edbe11@oracle.com>
References: <d76a18e3-c363-4159-834f-3ba81aa5a443@default>
 <8ff212fc-7c49-4963-99af-477ac4a0f4e1@default>
 <a7046f27-04f7-ac0d-bec1-fa555a842ec1@oracle.com>
 <e10f0a03-74d4-48da-ac8c-5828147c88ee@default>
 <500d86a0-53dd-645a-eb8b-a74a4511a2d1@oracle.com>
 <d605fbaf-2884-49e4-98fb-6a46e4cd989d@default>
 <133264f1-5e1c-1999-8f9f-a940d8edbe11@oracle.com>
Message-ID: <6c239b79-9901-4b39-a18f-edbc0f43e013@default>

Hi Prasanta,

 

Did the change for caching the result of calling "getRowCount()" into a variable, as pointed out by you, and here is the new webrev: http://cr.openjdk.java.net/~kaddepalli/8190281/webrev03/

 

Thanks,

Krishna

 

From: Prasanta Sadhukhan 
Sent: Monday, December 11, 2017 7:24 PM
To: Krishna Addepalli <krishna.addepalli at oracle.com>; swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10][JDK-8190281] Code cleanup in src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java

 

 

 

On 12/11/2017 4:16 PM, Krishna Addepalli wrote:

Hi Prasanta,

 

Yes, you are right, but as I mentioned earlier, that would need to make one variable declaration for caching before trivial reject case, which I wanted to avoid.

As for the body of getRowCount() it is just returning "visibleNodes.size()", which shouldn't be a (performance)problem if called 2 times as I understand.

But, the whole premise of changing getRowCount() <=0  was that it can be overridden and return -ve. Left to present implementation, we would not have needed "less than" check. 
So, if we are changing one case because of the above reason, then we cannot forego the 2nd case's problem, as it can have any implementation.

Regards
Prasanta



 

Thanks,

Krishna

 

From: Prasanta Sadhukhan 
Sent: Monday, December 11, 2017 4:02 PM
To: Krishna Addepalli HYPERLINK "mailto:krishna.addepalli at oracle.com"<krishna.addepalli at oracle.com>; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10][JDK-8190281] Code cleanup in src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java

 

Hi Krishna,

My point was we can call getRowCount() once at first and store the result and use it subsequently. There was no need to call it 2-3 times.

Regards
Prasanta

On 12/11/2017 3:01 PM, Krishna Addepalli wrote:

Hi Prasanta,

 

Thanks for pointing out the "getRowCount()==0" check. Modified it to "getRowCount() <= 0" in the new webrev: HYPERLINK "http://cr.openjdk.java.net/%7Ekaddepalli/8190281/webrev02/"http://cr.openjdk.java.net/~kaddepalli/8190281/webrev02/

 

As for calling the method twice, you are right that we don't need to call it twice, but in the interest of having trivial reject case first, and then start the variable declarations, had to let be there to be called twice. Precisely for the reason you stated, it shouldn't matter if we called it twice.

 

Thanks,

Krishna

 

From: Prasanta Sadhukhan 
Sent: Saturday, December 9, 2017 7:54 PM
To: Krishna Addepalli HYPERLINK "mailto:krishna.addepalli at oracle.com"<krishna.addepalli at oracle.com>; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10][JDK-8190281] Code cleanup in src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java

 

Hi Krishna,

This seems good to me except one thing. You are checking getRowCount() == 0 but there is a chance of test extending VariableHeightLayoutCache and overriding getRowCount to return -ve also as it is an int. In that case, I guess this function will not return -1 which spec mandates [If there are no rows, -1 is returned] so I guess we should check for <=0. 
Also, there is no need of calling getRowCount() twice as it will not change between 929, 936.

Regards
Prasanta

On 12/7/2017 4:41 PM, Krishna Addepalli wrote:

Hi Sergey,

 

Per our conversation, I have done the following changes:

1.       Found that the .class size increases by 1kb when streams are used, so reverted the changes related to it.

2.       Moved the "++nextIndex" into the conditional, so that there is no logical change.

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

 

Thanks,

Krishna

 

From: Krishna Addepalli 
Sent: Wednesday, December 6, 2017 2:43 PM
To: HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: [10][JDK-8190281] Code cleanup in src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java

 

Hi All,

 

Please review the fix for bug:

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

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

 

This bug was created while root causing JDK-8187936, and the following refactoring points have been addressed:

 

1. Line 927: Uninitialized variables, checking for trivial reject case multiple times. 
2. Line 999: Traditional code written to find maximum size of components, which can be done without any local variables and explicit looping by replacing with streams. 
3. Line 1365: Code repetition for differenct conditions, which can be ored together to reduce the repetition. 
4. Line 1482: A large code block gets repeated only because of different values need to be passed in one line. This can be moved to a variable initialization, and the repeating code blocks can be reduced to one. 
5. Line 1505: Variable initialization can be simplified by combining different conditions. 
6. Line 1540: An explicit loop to apply a function over a collection, can be achieved in one line by a forEach construct.  - This is producing some visual artifacts, so ignored.
7. Line 1747: Combine all the trivial reject cases into one condition, and also, a potential bug which increments the "nextIndex" value beyond the length of the containing elements. The increment should happen only if the trivial reject case fails.

 

Thanks,

Krishna

 

 

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

From prasanta.sadhukhan at oracle.com  Tue Dec 12 13:34:58 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Tue, 12 Dec 2017 19:04:58 +0530
Subject: <Swing Dev> [10][JDK-8190281] Code cleanup in
 src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java
In-Reply-To: <6c239b79-9901-4b39-a18f-edbc0f43e013@default>
References: <d76a18e3-c363-4159-834f-3ba81aa5a443@default>
 <8ff212fc-7c49-4963-99af-477ac4a0f4e1@default>
 <a7046f27-04f7-ac0d-bec1-fa555a842ec1@oracle.com>
 <e10f0a03-74d4-48da-ac8c-5828147c88ee@default>
 <500d86a0-53dd-645a-eb8b-a74a4511a2d1@oracle.com>
 <d605fbaf-2884-49e4-98fb-6a46e4cd989d@default>
 <133264f1-5e1c-1999-8f9f-a940d8edbe11@oracle.com>
 <6c239b79-9901-4b39-a18f-edbc0f43e013@default>
Message-ID: <01961a4f-9f7d-ae78-f32e-a2ba7ea9f4c9@oracle.com>

You missed using the variable at l933

Regards
Prasanta
On 12/12/2017 5:21 PM, Krishna Addepalli wrote:
>
> Hi Prasanta,
>
> Did the change for caching the result of calling ?getRowCount()? into 
> a variable, as pointed out by you, and here is the new webrev: 
> http://cr.openjdk.java.net/~kaddepalli/8190281/webrev03/ 
> <http://cr.openjdk.java.net/%7Ekaddepalli/8190281/webrev03/>
>
> Thanks,
>
> Krishna
>
> *From:*Prasanta Sadhukhan
> *Sent:* Monday, December 11, 2017 7:24 PM
> *To:* Krishna Addepalli <krishna.addepalli at oracle.com>; 
> swing-dev at openjdk.java.net
> *Subject:* Re: <Swing Dev> [10][JDK-8190281] Code cleanup in 
> src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java
>
> On 12/11/2017 4:16 PM, Krishna Addepalli wrote:
>
>     Hi Prasanta,
>
>     Yes, you are right, but as I mentioned earlier, that would need to
>     make one variable declaration for caching before trivial reject
>     case, which I wanted to avoid.
>
>     As for the body of getRowCount() it is just returning
>     ?visibleNodes.size()?, which shouldn?t be a (performance)problem
>     if called 2 times as I understand.
>
> But, the whole premise of changing getRowCount() <=0? was that it can 
> be overridden and return -ve. Left to present implementation, we would 
> not have needed "less than" check.
> So, if we are changing one case because of the above reason, then we 
> cannot forego the 2nd case's problem, as it can have any implementation.
>
> Regards
> Prasanta
>
>     Thanks,
>
>     Krishna
>
>     *From:*Prasanta Sadhukhan
>     *Sent:* Monday, December 11, 2017 4:02 PM
>     *To:* Krishna Addepalli <krishna.addepalli at oracle.com>
>     <mailto:krishna.addepalli at oracle.com>; swing-dev at openjdk.java.net
>     <mailto:swing-dev at openjdk.java.net>
>     *Subject:* Re: <Swing Dev> [10][JDK-8190281] Code cleanup in
>     src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java
>
>     Hi Krishna,
>
>     My point was we can call getRowCount() once at first and store the
>     result and use it subsequently. There was no need to call it 2-3
>     times.
>
>     Regards
>     Prasanta
>
>     On 12/11/2017 3:01 PM, Krishna Addepalli wrote:
>
>         Hi Prasanta,
>
>         Thanks for pointing out the ?getRowCount()==0? check. Modified
>         it to ?getRowCount() <= 0? in the new webrev:
>         http://cr.openjdk.java.net/~kaddepalli/8190281/webrev02/
>         <http://cr.openjdk.java.net/%7Ekaddepalli/8190281/webrev02/>
>
>         As for calling the method twice, you are right that we don?t
>         need to call it twice, but in the interest of having trivial
>         reject case first, and then start the variable declarations,
>         had to let be there to be called twice. Precisely for the
>         reason you stated, it shouldn?t matter if we called it twice.
>
>         Thanks,
>
>         Krishna
>
>         *From:*Prasanta Sadhukhan
>         *Sent:* Saturday, December 9, 2017 7:54 PM
>         *To:* Krishna Addepalli <krishna.addepalli at oracle.com>
>         <mailto:krishna.addepalli at oracle.com>;
>         swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>
>         *Subject:* Re: <Swing Dev> [10][JDK-8190281] Code cleanup in
>         src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java
>
>         Hi Krishna,
>
>         This seems good to me except one thing. You are checking
>         getRowCount() == 0 but there is a chance of test extending
>         VariableHeightLayoutCache and overriding getRowCount to return
>         -ve also as it is an int. In that case, I guess this function
>         will not return -1 which spec mandates [If there are no rows,
>         -1 is returned] so I guess we should check for <=0.
>         Also, there is no need of calling getRowCount() twice as it
>         will not change between 929, 936.
>
>         Regards
>         Prasanta
>
>         On 12/7/2017 4:41 PM, Krishna Addepalli wrote:
>
>             Hi Sergey,
>
>             Per our conversation, I have done the following changes:
>
>             1.Found that the .class size increases by 1kb when streams
>             are used, so reverted the changes related to it.
>
>             2.Moved the ?++nextIndex? into the conditional, so that
>             there is no logical change.
>
>             Here is the updated webrev:
>             http://cr.openjdk.java.net/~kaddepalli/8190281/webrev01/
>             <http://cr.openjdk.java.net/%7Ekaddepalli/8190281/webrev01/>
>
>             Thanks,
>
>             Krishna
>
>             *From:* Krishna Addepalli
>             *Sent:* Wednesday, December 6, 2017 2:43 PM
>             *To:* swing-dev at openjdk.java.net
>             <mailto:swing-dev at openjdk.java.net>
>             *Subject:* [10][JDK-8190281] Code cleanup in
>             src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java
>
>             Hi All,
>
>             Please review the fix for bug:
>
>             Bug: JDK-8190281
>             https://bugs.openjdk.java.net/browse/JDK-8190281
>
>             JDK 10 Webrev:
>             http://cr.openjdk.java.net/~kaddepalli/8190281/webrev00/
>             <http://cr.openjdk.java.net/%7Ekaddepalli/8190281/webrev00/>
>
>             This bug was created while root causing JDK-8187936, and
>             the following refactoring points have been addressed:
>
>             1. Line 927: Uninitialized variables, checking for trivial
>             reject case multiple times.
>             2. Line 999: Traditional code written to find maximum size
>             of components, which can be done without any local
>             variables and explicit looping by replacing with streams.
>             3. Line 1365: Code repetition for differenct conditions,
>             which can be ored together to reduce the repetition.
>             4. Line 1482: A large code block gets repeated only
>             because of different values need to be passed in one line.
>             This can be moved to a variable initialization, and the
>             repeating code blocks can be reduced to one.
>             5. Line 1505: Variable initialization can be simplified by
>             combining different conditions.
>             6. Line 1540: An explicit loop to apply a function over a
>             collection, can be achieved in one line by a forEach
>             construct.? ? This is producing some visual artifacts, so
>             ignored.
>             7. Line 1747: Combine all the trivial reject cases into
>             one condition, and also, a potential bug which increments
>             the "nextIndex" value beyond the length of the containing
>             elements. The increment should happen only if the trivial
>             reject case fails.
>
>             Thanks,
>
>             Krishna
>

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

From prasanta.sadhukhan at oracle.com  Tue Dec 12 13:36:43 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Tue, 12 Dec 2017 19:06:43 +0530
Subject: <Swing Dev> [10][JDK-8190281] Code cleanup in
 src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java
In-Reply-To: <01961a4f-9f7d-ae78-f32e-a2ba7ea9f4c9@oracle.com>
References: <d76a18e3-c363-4159-834f-3ba81aa5a443@default>
 <8ff212fc-7c49-4963-99af-477ac4a0f4e1@default>
 <a7046f27-04f7-ac0d-bec1-fa555a842ec1@oracle.com>
 <e10f0a03-74d4-48da-ac8c-5828147c88ee@default>
 <500d86a0-53dd-645a-eb8b-a74a4511a2d1@oracle.com>
 <d605fbaf-2884-49e4-98fb-6a46e4cd989d@default>
 <133264f1-5e1c-1999-8f9f-a940d8edbe11@oracle.com>
 <6c239b79-9901-4b39-a18f-edbc0f43e013@default>
 <01961a4f-9f7d-ae78-f32e-a2ba7ea9f4c9@oracle.com>
Message-ID: <f6cf2671-b000-c76d-4a84-06a8ca8b4eca@oracle.com>



On 12/12/2017 7:04 PM, Prasanta Sadhukhan wrote:
>
> You missed using the variable at l933
>
and l955,956
>
> Regards
> Prasanta
> On 12/12/2017 5:21 PM, Krishna Addepalli wrote:
>>
>> Hi Prasanta,
>>
>> ?
>>
>> Did the change for caching the result of calling ?getRowCount()? into 
>> a variable, as pointed out by you, and here is the new webrev: 
>> http://cr.openjdk.java.net/~kaddepalli/8190281/webrev03/ 
>> <http://cr.openjdk.java.net/%7Ekaddepalli/8190281/webrev03/>
>>
>> ?
>>
>> Thanks,
>>
>> Krishna
>>
>> ?
>>
>> *From:*Prasanta Sadhukhan
>> *Sent:* Monday, December 11, 2017 7:24 PM
>> *To:* Krishna Addepalli <krishna.addepalli at oracle.com>; 
>> swing-dev at openjdk.java.net
>> *Subject:* Re: <Swing Dev> [10][JDK-8190281] Code cleanup in 
>> src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java
>>
>> ?
>>
>> ?
>>
>> ?
>>
>> On 12/11/2017 4:16 PM, Krishna Addepalli wrote:
>>
>>     Hi Prasanta,
>>
>>     ?
>>
>>     Yes, you are right, but as I mentioned earlier, that would need
>>     to make one variable declaration for caching before trivial
>>     reject case, which I wanted to avoid.
>>
>>     As for the body of getRowCount() it is just returning
>>     ?visibleNodes.size()?, which shouldn?t be a (performance)problem
>>     if called 2 times as I understand.
>>
>> But, the whole premise of changing getRowCount() <=0? was that it can 
>> be overridden and return -ve. Left to present implementation, we 
>> would not have needed "less than" check.
>> So, if we are changing one case because of the above reason, then we 
>> cannot forego the 2nd case's problem, as it can have any implementation.
>>
>> Regards
>> Prasanta
>>
>>     ?
>>
>>     Thanks,
>>
>>     Krishna
>>
>>     ?
>>
>>     *From:*Prasanta Sadhukhan
>>     *Sent:* Monday, December 11, 2017 4:02 PM
>>     *To:* Krishna Addepalli <krishna.addepalli at oracle.com>
>>     <mailto:krishna.addepalli at oracle.com>; swing-dev at openjdk.java.net
>>     <mailto:swing-dev at openjdk.java.net>
>>     *Subject:* Re: <Swing Dev> [10][JDK-8190281] Code cleanup in
>>     src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java
>>
>>     ?
>>
>>     Hi Krishna,
>>
>>     My point was we can call getRowCount() once at first and store
>>     the result and use it subsequently. There was no need to call it
>>     2-3 times.
>>
>>     Regards
>>     Prasanta
>>
>>     On 12/11/2017 3:01 PM, Krishna Addepalli wrote:
>>
>>         Hi Prasanta,
>>
>>         ?
>>
>>         Thanks for pointing out the ?getRowCount()==0? check.
>>         Modified it to ?getRowCount() <= 0? in the new webrev:
>>         http://cr.openjdk.java.net/~kaddepalli/8190281/webrev02/
>>         <http://cr.openjdk.java.net/%7Ekaddepalli/8190281/webrev02/>
>>
>>         ?
>>
>>         As for calling the method twice, you are right that we don?t
>>         need to call it twice, but in the interest of having trivial
>>         reject case first, and then start the variable declarations,
>>         had to let be there to be called twice. Precisely for the
>>         reason you stated, it shouldn?t matter if we called it twice.
>>
>>         ?
>>
>>         Thanks,
>>
>>         Krishna
>>
>>         ?
>>
>>         *From:*Prasanta Sadhukhan
>>         *Sent:* Saturday, December 9, 2017 7:54 PM
>>         *To:* Krishna Addepalli <krishna.addepalli at oracle.com>
>>         <mailto:krishna.addepalli at oracle.com>;
>>         swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>
>>         *Subject:* Re: <Swing Dev> [10][JDK-8190281] Code cleanup in
>>         src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java
>>
>>         ?
>>
>>         Hi Krishna,
>>
>>         This seems good to me except one thing. You are checking
>>         getRowCount() == 0 but there is a chance of test extending
>>         VariableHeightLayoutCache and overriding getRowCount to
>>         return -ve also as it is an int. In that case, I guess this
>>         function will not return -1 which spec mandates [If there are
>>         no rows, -1 is returned] so I guess we should check for <=0.
>>         Also, there is no need of calling getRowCount() twice as it
>>         will not change between 929, 936.
>>
>>         Regards
>>         Prasanta
>>
>>         On 12/7/2017 4:41 PM, Krishna Addepalli wrote:
>>
>>             Hi Sergey,
>>
>>             ?
>>
>>             Per our conversation, I have done the following changes:
>>
>>             1.?????? Found that the .class size increases by 1kb when
>>             streams are used, so reverted the changes related to it.
>>
>>             2.?????? Moved the ?++nextIndex? into the conditional, so
>>             that there is no logical change.
>>
>>             Here is the updated webrev:
>>             http://cr.openjdk.java.net/~kaddepalli/8190281/webrev01/
>>             <http://cr.openjdk.java.net/%7Ekaddepalli/8190281/webrev01/>
>>
>>             ?
>>
>>             Thanks,
>>
>>             Krishna
>>
>>             ?
>>
>>             *From:* Krishna Addepalli
>>             *Sent:* Wednesday, December 6, 2017 2:43 PM
>>             *To:* swing-dev at openjdk.java.net
>>             <mailto:swing-dev at openjdk.java.net>
>>             *Subject:* [10][JDK-8190281] Code cleanup in
>>             src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java
>>
>>             ?
>>
>>             Hi All,
>>
>>             ?
>>
>>             Please review the fix for bug:
>>
>>             Bug: JDK-8190281
>>             https://bugs.openjdk.java.net/browse/JDK-8190281
>>
>>             JDK 10 Webrev:
>>             http://cr.openjdk.java.net/~kaddepalli/8190281/webrev00/
>>             <http://cr.openjdk.java.net/%7Ekaddepalli/8190281/webrev00/>
>>
>>             ?
>>
>>             This bug was created while root causing JDK-8187936, and
>>             the following refactoring points have been addressed:
>>
>>             ?
>>
>>             1. Line 927: Uninitialized variables, checking for
>>             trivial reject case multiple times.?
>>             2. Line 999: Traditional code written to find maximum
>>             size of components, which can be done without any local
>>             variables and explicit looping by replacing with streams.?
>>             3. Line 1365: Code repetition for differenct conditions,
>>             which can be ored together to reduce the repetition.?
>>             4. Line 1482: A large code block gets repeated only
>>             because of different values need to be passed in one
>>             line. This can be moved to a variable initialization, and
>>             the repeating code blocks can be reduced to one.?
>>             5. Line 1505: Variable initialization can be simplified
>>             by combining different conditions.?
>>             6. Line 1540: An explicit loop to apply a function over a
>>             collection, can be achieved in one line by a forEach
>>             construct.? ? This is producing some visual artifacts, so
>>             ignored.
>>             7. Line 1747: Combine all the trivial reject cases into
>>             one condition, and also, a potential bug which increments
>>             the "nextIndex" value beyond the length of the containing
>>             elements. The increment should happen only if the trivial
>>             reject case fails.
>>
>>             ?
>>
>>             Thanks,
>>
>>             Krishna
>>
>>         ?
>>
>>     ?
>>
>> ?
>>
>

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

From krishna.addepalli at oracle.com  Tue Dec 12 14:07:56 2017
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Tue, 12 Dec 2017 06:07:56 -0800 (PST)
Subject: <Swing Dev> [10][JDK-8190281] Code cleanup in
 src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java
In-Reply-To: <01961a4f-9f7d-ae78-f32e-a2ba7ea9f4c9@oracle.com>
References: <d76a18e3-c363-4159-834f-3ba81aa5a443@default>
 <8ff212fc-7c49-4963-99af-477ac4a0f4e1@default>
 <a7046f27-04f7-ac0d-bec1-fa555a842ec1@oracle.com>
 <e10f0a03-74d4-48da-ac8c-5828147c88ee@default>
 <500d86a0-53dd-645a-eb8b-a74a4511a2d1@oracle.com>
 <d605fbaf-2884-49e4-98fb-6a46e4cd989d@default>
 <133264f1-5e1c-1999-8f9f-a940d8edbe11@oracle.com>
 <6c239b79-9901-4b39-a18f-edbc0f43e013@default>
 <01961a4f-9f7d-ae78-f32e-a2ba7ea9f4c9@oracle.com>
Message-ID: <02dbfb86-71dd-4813-9624-c6d80e74691e@default>

Oops! My bad. Created a new webrev here with the correction: http://cr.openjdk.java.net/~kaddepalli/8190281/webrev04/

 

From: Prasanta Sadhukhan 
Sent: Tuesday, December 12, 2017 7:05 PM
To: Krishna Addepalli <krishna.addepalli at oracle.com>; swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10][JDK-8190281] Code cleanup in src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java

 

You missed using the variable at l933

Regards
Prasanta

On 12/12/2017 5:21 PM, Krishna Addepalli wrote:

Hi Prasanta,

 

Did the change for caching the result of calling "getRowCount()" into a variable, as pointed out by you, and here is the new webrev: HYPERLINK "http://cr.openjdk.java.net/%7Ekaddepalli/8190281/webrev03/"http://cr.openjdk.java.net/~kaddepalli/8190281/webrev03/

 

Thanks,

Krishna

 

From: Prasanta Sadhukhan 
Sent: Monday, December 11, 2017 7:24 PM
To: Krishna Addepalli HYPERLINK "mailto:krishna.addepalli at oracle.com"<krishna.addepalli at oracle.com>; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10][JDK-8190281] Code cleanup in src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java

 

 

 

On 12/11/2017 4:16 PM, Krishna Addepalli wrote:

Hi Prasanta,

 

Yes, you are right, but as I mentioned earlier, that would need to make one variable declaration for caching before trivial reject case, which I wanted to avoid.

As for the body of getRowCount() it is just returning "visibleNodes.size()", which shouldn't be a (performance)problem if called 2 times as I understand.

But, the whole premise of changing getRowCount() <=0  was that it can be overridden and return -ve. Left to present implementation, we would not have needed "less than" check. 
So, if we are changing one case because of the above reason, then we cannot forego the 2nd case's problem, as it can have any implementation.

Regards
Prasanta




 

Thanks,

Krishna

 

From: Prasanta Sadhukhan 
Sent: Monday, December 11, 2017 4:02 PM
To: Krishna Addepalli HYPERLINK "mailto:krishna.addepalli at oracle.com"<krishna.addepalli at oracle.com>; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10][JDK-8190281] Code cleanup in src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java

 

Hi Krishna,

My point was we can call getRowCount() once at first and store the result and use it subsequently. There was no need to call it 2-3 times.

Regards
Prasanta

On 12/11/2017 3:01 PM, Krishna Addepalli wrote:

Hi Prasanta,

 

Thanks for pointing out the "getRowCount()==0" check. Modified it to "getRowCount() <= 0" in the new webrev: HYPERLINK "http://cr.openjdk.java.net/%7Ekaddepalli/8190281/webrev02/"http://cr.openjdk.java.net/~kaddepalli/8190281/webrev02/

 

As for calling the method twice, you are right that we don't need to call it twice, but in the interest of having trivial reject case first, and then start the variable declarations, had to let be there to be called twice. Precisely for the reason you stated, it shouldn't matter if we called it twice.

 

Thanks,

Krishna

 

From: Prasanta Sadhukhan 
Sent: Saturday, December 9, 2017 7:54 PM
To: Krishna Addepalli HYPERLINK "mailto:krishna.addepalli at oracle.com"<krishna.addepalli at oracle.com>; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10][JDK-8190281] Code cleanup in src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java

 

Hi Krishna,

This seems good to me except one thing. You are checking getRowCount() == 0 but there is a chance of test extending VariableHeightLayoutCache and overriding getRowCount to return -ve also as it is an int. In that case, I guess this function will not return -1 which spec mandates [If there are no rows, -1 is returned] so I guess we should check for <=0. 
Also, there is no need of calling getRowCount() twice as it will not change between 929, 936.

Regards
Prasanta

On 12/7/2017 4:41 PM, Krishna Addepalli wrote:

Hi Sergey,

 

Per our conversation, I have done the following changes:

1.       Found that the .class size increases by 1kb when streams are used, so reverted the changes related to it.

2.       Moved the "++nextIndex" into the conditional, so that there is no logical change.

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

 

Thanks,

Krishna

 

From: Krishna Addepalli 
Sent: Wednesday, December 6, 2017 2:43 PM
To: HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: [10][JDK-8190281] Code cleanup in src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java

 

Hi All,

 

Please review the fix for bug:

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

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

 

This bug was created while root causing JDK-8187936, and the following refactoring points have been addressed:

 

1. Line 927: Uninitialized variables, checking for trivial reject case multiple times. 
2. Line 999: Traditional code written to find maximum size of components, which can be done without any local variables and explicit looping by replacing with streams. 
3. Line 1365: Code repetition for differenct conditions, which can be ored together to reduce the repetition. 
4. Line 1482: A large code block gets repeated only because of different values need to be passed in one line. This can be moved to a variable initialization, and the repeating code blocks can be reduced to one. 
5. Line 1505: Variable initialization can be simplified by combining different conditions. 
6. Line 1540: An explicit loop to apply a function over a collection, can be achieved in one line by a forEach construct.  - This is producing some visual artifacts, so ignored.
7. Line 1747: Combine all the trivial reject cases into one condition, and also, a potential bug which increments the "nextIndex" value beyond the length of the containing elements. The increment should happen only if the trivial reject case fails.

 

Thanks,

Krishna

 

 

 

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

From prasanta.sadhukhan at oracle.com  Tue Dec 12 14:38:20 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Tue, 12 Dec 2017 20:08:20 +0530
Subject: <Swing Dev> [10][JDK-8190281] Code cleanup in
 src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java
In-Reply-To: <02dbfb86-71dd-4813-9624-c6d80e74691e@default>
References: <d76a18e3-c363-4159-834f-3ba81aa5a443@default>
 <8ff212fc-7c49-4963-99af-477ac4a0f4e1@default>
 <a7046f27-04f7-ac0d-bec1-fa555a842ec1@oracle.com>
 <e10f0a03-74d4-48da-ac8c-5828147c88ee@default>
 <500d86a0-53dd-645a-eb8b-a74a4511a2d1@oracle.com>
 <d605fbaf-2884-49e4-98fb-6a46e4cd989d@default>
 <133264f1-5e1c-1999-8f9f-a940d8edbe11@oracle.com>
 <6c239b79-9901-4b39-a18f-edbc0f43e013@default>
 <01961a4f-9f7d-ae78-f32e-a2ba7ea9f4c9@oracle.com>
 <02dbfb86-71dd-4813-9624-c6d80e74691e@default>
Message-ID: <6593bd1e-3f24-3120-37fe-2b2f07288f41@oracle.com>

As told, you overlooked l955,956

Regards
Prasanta
On 12/12/2017 7:37 PM, Krishna Addepalli wrote:
>
> Oops! My bad. Created a new webrev here with the correction: 
> http://cr.openjdk.java.net/~kaddepalli/8190281/webrev04/ 
> <http://cr.openjdk.java.net/%7Ekaddepalli/8190281/webrev04/>
>
> *From:*Prasanta Sadhukhan
> *Sent:* Tuesday, December 12, 2017 7:05 PM
> *To:* Krishna Addepalli <krishna.addepalli at oracle.com>; 
> swing-dev at openjdk.java.net
> *Subject:* Re: <Swing Dev> [10][JDK-8190281] Code cleanup in 
> src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java
>
> You missed using the variable at l933
>
> Regards
> Prasanta
>
> On 12/12/2017 5:21 PM, Krishna Addepalli wrote:
>
>     Hi Prasanta,
>
>     Did the change for caching the result of calling ?getRowCount()?
>     into a variable, as pointed out by you, and here is the new
>     webrev: http://cr.openjdk.java.net/~kaddepalli/8190281/webrev03/
>     <http://cr.openjdk.java.net/%7Ekaddepalli/8190281/webrev03/>
>
>     Thanks,
>
>     Krishna
>
>     *From:*Prasanta Sadhukhan
>     *Sent:* Monday, December 11, 2017 7:24 PM
>     *To:* Krishna Addepalli <krishna.addepalli at oracle.com>
>     <mailto:krishna.addepalli at oracle.com>; swing-dev at openjdk.java.net
>     <mailto:swing-dev at openjdk.java.net>
>     *Subject:* Re: <Swing Dev> [10][JDK-8190281] Code cleanup in
>     src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java
>
>     On 12/11/2017 4:16 PM, Krishna Addepalli wrote:
>
>         Hi Prasanta,
>
>         Yes, you are right, but as I mentioned earlier, that would
>         need to make one variable declaration for caching before
>         trivial reject case, which I wanted to avoid.
>
>         As for the body of getRowCount() it is just returning
>         ?visibleNodes.size()?, which shouldn?t be a
>         (performance)problem if called 2 times as I understand.
>
>     But, the whole premise of changing getRowCount() <=0? was that it
>     can be overridden and return -ve. Left to present implementation,
>     we would not have needed "less than" check.
>     So, if we are changing one case because of the above reason, then
>     we cannot forego the 2nd case's problem, as it can have any
>     implementation.
>
>     Regards
>     Prasanta
>
>
>         Thanks,
>
>         Krishna
>
>         *From:*Prasanta Sadhukhan
>         *Sent:* Monday, December 11, 2017 4:02 PM
>         *To:* Krishna Addepalli <krishna.addepalli at oracle.com>
>         <mailto:krishna.addepalli at oracle.com>;
>         swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>
>         *Subject:* Re: <Swing Dev> [10][JDK-8190281] Code cleanup in
>         src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java
>
>         Hi Krishna,
>
>         My point was we can call getRowCount() once at first and store
>         the result and use it subsequently. There was no need to call
>         it 2-3 times.
>
>         Regards
>         Prasanta
>
>         On 12/11/2017 3:01 PM, Krishna Addepalli wrote:
>
>             Hi Prasanta,
>
>             Thanks for pointing out the ?getRowCount()==0? check.
>             Modified it to ?getRowCount() <= 0? in the new webrev:
>             http://cr.openjdk.java.net/~kaddepalli/8190281/webrev02/
>             <http://cr.openjdk.java.net/%7Ekaddepalli/8190281/webrev02/>
>
>             As for calling the method twice, you are right that we
>             don?t need to call it twice, but in the interest of having
>             trivial reject case first, and then start the variable
>             declarations, had to let be there to be called twice.
>             Precisely for the reason you stated, it shouldn?t matter
>             if we called it twice.
>
>             Thanks,
>
>             Krishna
>
>             *From:*Prasanta Sadhukhan
>             *Sent:* Saturday, December 9, 2017 7:54 PM
>             *To:* Krishna Addepalli <krishna.addepalli at oracle.com>
>             <mailto:krishna.addepalli at oracle.com>;
>             swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>
>             *Subject:* Re: <Swing Dev> [10][JDK-8190281] Code cleanup
>             in
>             src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java
>
>             Hi Krishna,
>
>             This seems good to me except one thing. You are checking
>             getRowCount() == 0 but there is a chance of test extending
>             VariableHeightLayoutCache and overriding getRowCount to
>             return -ve also as it is an int. In that case, I guess
>             this function will not return -1 which spec mandates [If
>             there are no rows, -1 is returned] so I guess we should
>             check for <=0.
>             Also, there is no need of calling getRowCount() twice as
>             it will not change between 929, 936.
>
>             Regards
>             Prasanta
>
>             On 12/7/2017 4:41 PM, Krishna Addepalli wrote:
>
>                 Hi Sergey,
>
>                 Per our conversation, I have done the following changes:
>
>                 1.Found that the .class size increases by 1kb when
>                 streams are used, so reverted the changes related to it.
>
>                 2.Moved the ?++nextIndex? into the conditional, so
>                 that there is no logical change.
>
>                 Here is the updated webrev:
>                 http://cr.openjdk.java.net/~kaddepalli/8190281/webrev01/
>                 <http://cr.openjdk.java.net/%7Ekaddepalli/8190281/webrev01/>
>
>                 Thanks,
>
>                 Krishna
>
>                 *From:* Krishna Addepalli
>                 *Sent:* Wednesday, December 6, 2017 2:43 PM
>                 *To:* swing-dev at openjdk.java.net
>                 <mailto:swing-dev at openjdk.java.net>
>                 *Subject:* [10][JDK-8190281] Code cleanup in
>                 src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java
>
>                 Hi All,
>
>                 Please review the fix for bug:
>
>                 Bug: JDK-8190281
>                 https://bugs.openjdk.java.net/browse/JDK-8190281
>
>                 JDK 10 Webrev:
>                 http://cr.openjdk.java.net/~kaddepalli/8190281/webrev00/
>                 <http://cr.openjdk.java.net/%7Ekaddepalli/8190281/webrev00/>
>
>                 This bug was created while root causing JDK-8187936,
>                 and the following refactoring points have been addressed:
>
>                 1. Line 927: Uninitialized variables, checking for
>                 trivial reject case multiple times.
>                 2. Line 999: Traditional code written to find maximum
>                 size of components, which can be done without any
>                 local variables and explicit looping by replacing with
>                 streams.
>                 3. Line 1365: Code repetition for differenct
>                 conditions, which can be ored together to reduce the
>                 repetition.
>                 4. Line 1482: A large code block gets repeated only
>                 because of different values need to be passed in one
>                 line. This can be moved to a variable initialization,
>                 and the repeating code blocks can be reduced to one.
>                 5. Line 1505: Variable initialization can be
>                 simplified by combining different conditions.
>                 6. Line 1540: An explicit loop to apply a function
>                 over a collection, can be achieved in one line by a
>                 forEach construct.? ? This is producing some visual
>                 artifacts, so ignored.
>                 7. Line 1747: Combine all the trivial reject cases
>                 into one condition, and also, a potential bug which
>                 increments the "nextIndex" value beyond the length of
>                 the containing elements. The increment should happen
>                 only if the trivial reject case fails.
>
>                 Thanks,
>
>                 Krishna
>

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

From krishna.addepalli at oracle.com  Tue Dec 12 16:21:17 2017
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Tue, 12 Dec 2017 08:21:17 -0800 (PST)
Subject: <Swing Dev> [10][JDK-8190281] Code cleanup in
 src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java
In-Reply-To: <6593bd1e-3f24-3120-37fe-2b2f07288f41@oracle.com>
References: <d76a18e3-c363-4159-834f-3ba81aa5a443@default>
 <8ff212fc-7c49-4963-99af-477ac4a0f4e1@default>
 <a7046f27-04f7-ac0d-bec1-fa555a842ec1@oracle.com>
 <e10f0a03-74d4-48da-ac8c-5828147c88ee@default>
 <500d86a0-53dd-645a-eb8b-a74a4511a2d1@oracle.com>
 <d605fbaf-2884-49e4-98fb-6a46e4cd989d@default>
 <133264f1-5e1c-1999-8f9f-a940d8edbe11@oracle.com>
 <6c239b79-9901-4b39-a18f-edbc0f43e013@default>
 <01961a4f-9f7d-ae78-f32e-a2ba7ea9f4c9@oracle.com>
 <02dbfb86-71dd-4813-9624-c6d80e74691e@default>
 <6593bd1e-3f24-3120-37fe-2b2f07288f41@oracle.com>
Message-ID: <e75fdfb5-2bef-4a62-b895-8054b27c34c2@default>

Hi Prasanta,

 

The getRowCount() calls l955,956 cannot be removed, since max variable is getting modified in the while loop at l945. There is no guarantee that max will still hold the getRowCount() after the loop exits. So, those calls cannot be removed.

 

Thanks,

Krishna

 

From: Prasanta Sadhukhan 
Sent: Tuesday, December 12, 2017 8:08 PM
To: Krishna Addepalli <krishna.addepalli at oracle.com>; swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10][JDK-8190281] Code cleanup in src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java

 

As told, you overlooked l955,956

Regards
Prasanta

On 12/12/2017 7:37 PM, Krishna Addepalli wrote:

Oops! My bad. Created a new webrev here with the correction: HYPERLINK "http://cr.openjdk.java.net/%7Ekaddepalli/8190281/webrev04/"http://cr.openjdk.java.net/~kaddepalli/8190281/webrev04/

 

From: Prasanta Sadhukhan 
Sent: Tuesday, December 12, 2017 7:05 PM
To: Krishna Addepalli HYPERLINK "mailto:krishna.addepalli at oracle.com"<krishna.addepalli at oracle.com>; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10][JDK-8190281] Code cleanup in src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java

 

You missed using the variable at l933

Regards
Prasanta

On 12/12/2017 5:21 PM, Krishna Addepalli wrote:

Hi Prasanta,

 

Did the change for caching the result of calling "getRowCount()" into a variable, as pointed out by you, and here is the new webrev: HYPERLINK "http://cr.openjdk.java.net/%7Ekaddepalli/8190281/webrev03/"http://cr.openjdk.java.net/~kaddepalli/8190281/webrev03/

 

Thanks,

Krishna

 

From: Prasanta Sadhukhan 
Sent: Monday, December 11, 2017 7:24 PM
To: Krishna Addepalli HYPERLINK "mailto:krishna.addepalli at oracle.com"<krishna.addepalli at oracle.com>; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10][JDK-8190281] Code cleanup in src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java

 

 

 

On 12/11/2017 4:16 PM, Krishna Addepalli wrote:

Hi Prasanta,

 

Yes, you are right, but as I mentioned earlier, that would need to make one variable declaration for caching before trivial reject case, which I wanted to avoid.

As for the body of getRowCount() it is just returning "visibleNodes.size()", which shouldn't be a (performance)problem if called 2 times as I understand.

But, the whole premise of changing getRowCount() <=0  was that it can be overridden and return -ve. Left to present implementation, we would not have needed "less than" check. 
So, if we are changing one case because of the above reason, then we cannot forego the 2nd case's problem, as it can have any implementation.

Regards
Prasanta





 

Thanks,

Krishna

 

From: Prasanta Sadhukhan 
Sent: Monday, December 11, 2017 4:02 PM
To: Krishna Addepalli HYPERLINK "mailto:krishna.addepalli at oracle.com"<krishna.addepalli at oracle.com>; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10][JDK-8190281] Code cleanup in src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java

 

Hi Krishna,

My point was we can call getRowCount() once at first and store the result and use it subsequently. There was no need to call it 2-3 times.

Regards
Prasanta

On 12/11/2017 3:01 PM, Krishna Addepalli wrote:

Hi Prasanta,

 

Thanks for pointing out the "getRowCount()==0" check. Modified it to "getRowCount() <= 0" in the new webrev: HYPERLINK "http://cr.openjdk.java.net/%7Ekaddepalli/8190281/webrev02/"http://cr.openjdk.java.net/~kaddepalli/8190281/webrev02/

 

As for calling the method twice, you are right that we don't need to call it twice, but in the interest of having trivial reject case first, and then start the variable declarations, had to let be there to be called twice. Precisely for the reason you stated, it shouldn't matter if we called it twice.

 

Thanks,

Krishna

 

From: Prasanta Sadhukhan 
Sent: Saturday, December 9, 2017 7:54 PM
To: Krishna Addepalli HYPERLINK "mailto:krishna.addepalli at oracle.com"<krishna.addepalli at oracle.com>; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10][JDK-8190281] Code cleanup in src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java

 

Hi Krishna,

This seems good to me except one thing. You are checking getRowCount() == 0 but there is a chance of test extending VariableHeightLayoutCache and overriding getRowCount to return -ve also as it is an int. In that case, I guess this function will not return -1 which spec mandates [If there are no rows, -1 is returned] so I guess we should check for <=0. 
Also, there is no need of calling getRowCount() twice as it will not change between 929, 936.

Regards
Prasanta

On 12/7/2017 4:41 PM, Krishna Addepalli wrote:

Hi Sergey,

 

Per our conversation, I have done the following changes:

1.       Found that the .class size increases by 1kb when streams are used, so reverted the changes related to it.

2.       Moved the "++nextIndex" into the conditional, so that there is no logical change.

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

 

Thanks,

Krishna

 

From: Krishna Addepalli 
Sent: Wednesday, December 6, 2017 2:43 PM
To: HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: [10][JDK-8190281] Code cleanup in src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java

 

Hi All,

 

Please review the fix for bug:

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

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

 

This bug was created while root causing JDK-8187936, and the following refactoring points have been addressed:

 

1. Line 927: Uninitialized variables, checking for trivial reject case multiple times. 
2. Line 999: Traditional code written to find maximum size of components, which can be done without any local variables and explicit looping by replacing with streams. 
3. Line 1365: Code repetition for differenct conditions, which can be ored together to reduce the repetition. 
4. Line 1482: A large code block gets repeated only because of different values need to be passed in one line. This can be moved to a variable initialization, and the repeating code blocks can be reduced to one. 
5. Line 1505: Variable initialization can be simplified by combining different conditions. 
6. Line 1540: An explicit loop to apply a function over a collection, can be achieved in one line by a forEach construct.  - This is producing some visual artifacts, so ignored.
7. Line 1747: Combine all the trivial reject cases into one condition, and also, a potential bug which increments the "nextIndex" value beyond the length of the containing elements. The increment should happen only if the trivial reject case fails.

 

Thanks,

Krishna

 

 

 

 

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

From prasanta.sadhukhan at oracle.com  Wed Dec 13 05:11:33 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Wed, 13 Dec 2017 10:41:33 +0530
Subject: <Swing Dev> [10][JDK-8190281] Code cleanup in
 src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java
In-Reply-To: <e75fdfb5-2bef-4a62-b895-8054b27c34c2@default>
References: <d76a18e3-c363-4159-834f-3ba81aa5a443@default>
 <8ff212fc-7c49-4963-99af-477ac4a0f4e1@default>
 <a7046f27-04f7-ac0d-bec1-fa555a842ec1@oracle.com>
 <e10f0a03-74d4-48da-ac8c-5828147c88ee@default>
 <500d86a0-53dd-645a-eb8b-a74a4511a2d1@oracle.com>
 <d605fbaf-2884-49e4-98fb-6a46e4cd989d@default>
 <133264f1-5e1c-1999-8f9f-a940d8edbe11@oracle.com>
 <6c239b79-9901-4b39-a18f-edbc0f43e013@default>
 <01961a4f-9f7d-ae78-f32e-a2ba7ea9f4c9@oracle.com>
 <02dbfb86-71dd-4813-9624-c6d80e74691e@default>
 <6593bd1e-3f24-3120-37fe-2b2f07288f41@oracle.com>
 <e75fdfb5-2bef-4a62-b895-8054b27c34c2@default>
Message-ID: <0467651b-d9dd-9e2e-1820-19b4041b53a7@oracle.com>

But there is no compulsion that we need to store getRowCount() in "max". 
You can store in some other variable and then "max" point to that in the 
loop.

Regards
Prasanta
On 12/12/2017 9:51 PM, Krishna Addepalli wrote:
>
> Hi Prasanta,
>
> The getRowCount() calls l955,956 cannot be removed, since max variable 
> is getting modified in the while loop at l945. There is no guarantee 
> that max will still hold the getRowCount() after the loop exits. So, 
> those calls cannot be removed.
>
> Thanks,
>
> Krishna
>
> *From:*Prasanta Sadhukhan
> *Sent:* Tuesday, December 12, 2017 8:08 PM
> *To:* Krishna Addepalli <krishna.addepalli at oracle.com>; 
> swing-dev at openjdk.java.net
> *Subject:* Re: <Swing Dev> [10][JDK-8190281] Code cleanup in 
> src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java
>
> As told, you overlooked l955,956
>
> Regards
> Prasanta
>
> On 12/12/2017 7:37 PM, Krishna Addepalli wrote:
>
>     Oops! My bad. Created a new webrev here with the correction:
>     http://cr.openjdk.java.net/~kaddepalli/8190281/webrev04/
>     <http://cr.openjdk.java.net/%7Ekaddepalli/8190281/webrev04/>
>
>     *From:*Prasanta Sadhukhan
>     *Sent:* Tuesday, December 12, 2017 7:05 PM
>     *To:* Krishna Addepalli <krishna.addepalli at oracle.com>
>     <mailto:krishna.addepalli at oracle.com>; swing-dev at openjdk.java.net
>     <mailto:swing-dev at openjdk.java.net>
>     *Subject:* Re: <Swing Dev> [10][JDK-8190281] Code cleanup in
>     src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java
>
>     You missed using the variable at l933
>
>     Regards
>     Prasanta
>
>     On 12/12/2017 5:21 PM, Krishna Addepalli wrote:
>
>         Hi Prasanta,
>
>         Did the change for caching the result of calling
>         ?getRowCount()? into a variable, as pointed out by you, and
>         here is the new webrev:
>         http://cr.openjdk.java.net/~kaddepalli/8190281/webrev03/
>         <http://cr.openjdk.java.net/%7Ekaddepalli/8190281/webrev03/>
>
>         Thanks,
>
>         Krishna
>
>         *From:*Prasanta Sadhukhan
>         *Sent:* Monday, December 11, 2017 7:24 PM
>         *To:* Krishna Addepalli <krishna.addepalli at oracle.com>
>         <mailto:krishna.addepalli at oracle.com>;
>         swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>
>         *Subject:* Re: <Swing Dev> [10][JDK-8190281] Code cleanup in
>         src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java
>
>         On 12/11/2017 4:16 PM, Krishna Addepalli wrote:
>
>             Hi Prasanta,
>
>             Yes, you are right, but as I mentioned earlier, that would
>             need to make one variable declaration for caching before
>             trivial reject case, which I wanted to avoid.
>
>             As for the body of getRowCount() it is just returning
>             ?visibleNodes.size()?, which shouldn?t be a
>             (performance)problem if called 2 times as I understand.
>
>         But, the whole premise of changing getRowCount() <=0? was that
>         it can be overridden and return -ve. Left to present
>         implementation, we would not have needed "less than" check.
>         So, if we are changing one case because of the above reason,
>         then we cannot forego the 2nd case's problem, as it can have
>         any implementation.
>
>         Regards
>         Prasanta
>
>
>
>             Thanks,
>
>             Krishna
>
>             *From:*Prasanta Sadhukhan
>             *Sent:* Monday, December 11, 2017 4:02 PM
>             *To:* Krishna Addepalli <krishna.addepalli at oracle.com>
>             <mailto:krishna.addepalli at oracle.com>;
>             swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>
>             *Subject:* Re: <Swing Dev> [10][JDK-8190281] Code cleanup
>             in
>             src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java
>
>             Hi Krishna,
>
>             My point was we can call getRowCount() once at first and
>             store the result and use it subsequently. There was no
>             need to call it 2-3 times.
>
>             Regards
>             Prasanta
>
>             On 12/11/2017 3:01 PM, Krishna Addepalli wrote:
>
>                 Hi Prasanta,
>
>                 Thanks for pointing out the ?getRowCount()==0? check.
>                 Modified it to ?getRowCount() <= 0? in the new webrev:
>                 http://cr.openjdk.java.net/~kaddepalli/8190281/webrev02/
>                 <http://cr.openjdk.java.net/%7Ekaddepalli/8190281/webrev02/>
>
>                 As for calling the method twice, you are right that we
>                 don?t need to call it twice, but in the interest of
>                 having trivial reject case first, and then start the
>                 variable declarations, had to let be there to be
>                 called twice. Precisely for the reason you stated, it
>                 shouldn?t matter if we called it twice.
>
>                 Thanks,
>
>                 Krishna
>
>                 *From:*Prasanta Sadhukhan
>                 *Sent:* Saturday, December 9, 2017 7:54 PM
>                 *To:* Krishna Addepalli <krishna.addepalli at oracle.com>
>                 <mailto:krishna.addepalli at oracle.com>;
>                 swing-dev at openjdk.java.net
>                 <mailto:swing-dev at openjdk.java.net>
>                 *Subject:* Re: <Swing Dev> [10][JDK-8190281] Code
>                 cleanup in
>                 src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java
>
>                 Hi Krishna,
>
>                 This seems good to me except one thing. You are
>                 checking getRowCount() == 0 but there is a chance of
>                 test extending VariableHeightLayoutCache and
>                 overriding getRowCount to return -ve also as it is an
>                 int. In that case, I guess this function will not
>                 return -1 which spec mandates [If there are no rows,
>                 -1 is returned] so I guess we should check for <=0.
>                 Also, there is no need of calling getRowCount() twice
>                 as it will not change between 929, 936.
>
>                 Regards
>                 Prasanta
>
>                 On 12/7/2017 4:41 PM, Krishna Addepalli wrote:
>
>                     Hi Sergey,
>
>                     Per our conversation, I have done the following
>                     changes:
>
>                     1.Found that the .class size increases by 1kb when
>                     streams are used, so reverted the changes related
>                     to it.
>
>                     2.Moved the ?++nextIndex? into the conditional, so
>                     that there is no logical change.
>
>                     Here is the updated webrev:
>                     http://cr.openjdk.java.net/~kaddepalli/8190281/webrev01/
>                     <http://cr.openjdk.java.net/%7Ekaddepalli/8190281/webrev01/>
>
>                     Thanks,
>
>                     Krishna
>
>                     *From:* Krishna Addepalli
>                     *Sent:* Wednesday, December 6, 2017 2:43 PM
>                     *To:* swing-dev at openjdk.java.net
>                     <mailto:swing-dev at openjdk.java.net>
>                     *Subject:* [10][JDK-8190281] Code cleanup in
>                     src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java
>
>                     Hi All,
>
>                     Please review the fix for bug:
>
>                     Bug: JDK-8190281
>                     https://bugs.openjdk.java.net/browse/JDK-8190281
>
>                     JDK 10 Webrev:
>                     http://cr.openjdk.java.net/~kaddepalli/8190281/webrev00/
>                     <http://cr.openjdk.java.net/%7Ekaddepalli/8190281/webrev00/>
>
>                     This bug was created while root causing
>                     JDK-8187936, and the following refactoring points
>                     have been addressed:
>
>                     1. Line 927: Uninitialized variables, checking for
>                     trivial reject case multiple times.
>                     2. Line 999: Traditional code written to find
>                     maximum size of components, which can be done
>                     without any local variables and explicit looping
>                     by replacing with streams.
>                     3. Line 1365: Code repetition for differenct
>                     conditions, which can be ored together to reduce
>                     the repetition.
>                     4. Line 1482: A large code block gets repeated
>                     only because of different values need to be passed
>                     in one line. This can be moved to a variable
>                     initialization, and the repeating code blocks can
>                     be reduced to one.
>                     5. Line 1505: Variable initialization can be
>                     simplified by combining different conditions.
>                     6. Line 1540: An explicit loop to apply a function
>                     over a collection, can be achieved in one line by
>                     a forEach construct.? ? This is producing some
>                     visual artifacts, so ignored.
>                     7. Line 1747: Combine all the trivial reject cases
>                     into one condition, and also, a potential bug
>                     which increments the "nextIndex" value beyond the
>                     length of the containing elements. The increment
>                     should happen only if the trivial reject case fails.
>
>                     Thanks,
>
>                     Krishna
>

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

From prasanta.sadhukhan at oracle.com  Wed Dec 13 08:48:00 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Wed, 13 Dec 2017 14:18:00 +0530
Subject: <Swing Dev> [10][JDK-8190281] Code cleanup in
 src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java
In-Reply-To: <19864cc6-d723-4b5d-902f-4623720d5d71@default>
References: <d76a18e3-c363-4159-834f-3ba81aa5a443@default>
 <8ff212fc-7c49-4963-99af-477ac4a0f4e1@default>
 <a7046f27-04f7-ac0d-bec1-fa555a842ec1@oracle.com>
 <e10f0a03-74d4-48da-ac8c-5828147c88ee@default>
 <500d86a0-53dd-645a-eb8b-a74a4511a2d1@oracle.com>
 <d605fbaf-2884-49e4-98fb-6a46e4cd989d@default>
 <133264f1-5e1c-1999-8f9f-a940d8edbe11@oracle.com>
 <6c239b79-9901-4b39-a18f-edbc0f43e013@default>
 <01961a4f-9f7d-ae78-f32e-a2ba7ea9f4c9@oracle.com>
 <02dbfb86-71dd-4813-9624-c6d80e74691e@default>
 <6593bd1e-3f24-3120-37fe-2b2f07288f41@oracle.com>
 <e75fdfb5-2bef-4a62-b895-8054b27c34c2@default>
 <0467651b-d9dd-9e2e-1820-19b4041b53a7@oracle.com>
 <19864cc6-d723-4b5d-902f-4623720d5d71@default>
Message-ID: <9ea66293-2b7f-76ac-a076-805760db9bd3@oracle.com>

+1

Regards
Prasanta
On 12/13/2017 2:12 PM, Krishna Addepalli wrote:
>
> Hi Prasanta,
>
> Here is the webrev with suggested changes: 
> http://cr.openjdk.java.net/~kaddepalli/8190281/webrev05/ 
> <http://cr.openjdk.java.net/%7Ekaddepalli/8190281/webrev05/>
>
> Thanks,
>
> Krishna
>
> *From:*Prasanta Sadhukhan
> *Sent:* Wednesday, December 13, 2017 10:42 AM
> *To:* Krishna Addepalli <krishna.addepalli at oracle.com>; 
> swing-dev at openjdk.java.net
> *Subject:* Re: <Swing Dev> [10][JDK-8190281] Code cleanup in 
> src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java
>
> But there is no compulsion that we need to store getRowCount() in 
> "max". You can store in some other variable and then "max" point to 
> that in the loop.
>
> Regards
> Prasanta
>
> On 12/12/2017 9:51 PM, Krishna Addepalli wrote:
>
>     Hi Prasanta,
>
>     The getRowCount() calls l955,956 cannot be removed, since max
>     variable is getting modified in the while loop at l945. There is
>     no guarantee that max will still hold the getRowCount() after the
>     loop exits. So, those calls cannot be removed.
>
>     Thanks,
>
>     Krishna
>
>     *From:*Prasanta Sadhukhan
>     *Sent:* Tuesday, December 12, 2017 8:08 PM
>     *To:* Krishna Addepalli <krishna.addepalli at oracle.com>
>     <mailto:krishna.addepalli at oracle.com>; swing-dev at openjdk.java.net
>     <mailto:swing-dev at openjdk.java.net>
>     *Subject:* Re: <Swing Dev> [10][JDK-8190281] Code cleanup in
>     src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java
>
>     As told, you overlooked l955,956
>
>     Regards
>     Prasanta
>
>     On 12/12/2017 7:37 PM, Krishna Addepalli wrote:
>
>         Oops! My bad. Created a new webrev here with the correction:
>         http://cr.openjdk.java.net/~kaddepalli/8190281/webrev04/
>         <http://cr.openjdk.java.net/%7Ekaddepalli/8190281/webrev04/>
>
>         *From:*Prasanta Sadhukhan
>         *Sent:* Tuesday, December 12, 2017 7:05 PM
>         *To:* Krishna Addepalli <krishna.addepalli at oracle.com>
>         <mailto:krishna.addepalli at oracle.com>;
>         swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>
>         *Subject:* Re: <Swing Dev> [10][JDK-8190281] Code cleanup in
>         src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java
>
>         You missed using the variable at l933
>
>         Regards
>         Prasanta
>
>         On 12/12/2017 5:21 PM, Krishna Addepalli wrote:
>
>             Hi Prasanta,
>
>             Did the change for caching the result of calling
>             ?getRowCount()? into a variable, as pointed out by you,
>             and here is the new webrev:
>             http://cr.openjdk.java.net/~kaddepalli/8190281/webrev03/
>             <http://cr.openjdk.java.net/%7Ekaddepalli/8190281/webrev03/>
>
>             Thanks,
>
>             Krishna
>
>             *From:*Prasanta Sadhukhan
>             *Sent:* Monday, December 11, 2017 7:24 PM
>             *To:* Krishna Addepalli <krishna.addepalli at oracle.com>
>             <mailto:krishna.addepalli at oracle.com>;
>             swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>
>             *Subject:* Re: <Swing Dev> [10][JDK-8190281] Code cleanup
>             in
>             src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java
>
>             On 12/11/2017 4:16 PM, Krishna Addepalli wrote:
>
>                 Hi Prasanta,
>
>                 Yes, you are right, but as I mentioned earlier, that
>                 would need to make one variable declaration for
>                 caching before trivial reject case, which I wanted to
>                 avoid.
>
>                 As for the body of getRowCount() it is just returning
>                 ?visibleNodes.size()?, which shouldn?t be a
>                 (performance)problem if called 2 times as I understand.
>
>             But, the whole premise of changing getRowCount() <=0? was
>             that it can be overridden and return -ve. Left to present
>             implementation, we would not have needed "less than" check.
>             So, if we are changing one case because of the above
>             reason, then we cannot forego the 2nd case's problem, as
>             it can have any implementation.
>
>             Regards
>             Prasanta
>
>
>
>
>                 Thanks,
>
>                 Krishna
>
>                 *From:*Prasanta Sadhukhan
>                 *Sent:* Monday, December 11, 2017 4:02 PM
>                 *To:* Krishna Addepalli <krishna.addepalli at oracle.com>
>                 <mailto:krishna.addepalli at oracle.com>;
>                 swing-dev at openjdk.java.net
>                 <mailto:swing-dev at openjdk.java.net>
>                 *Subject:* Re: <Swing Dev> [10][JDK-8190281] Code
>                 cleanup in
>                 src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java
>
>                 Hi Krishna,
>
>                 My point was we can call getRowCount() once at first
>                 and store the result and use it subsequently. There
>                 was no need to call it 2-3 times.
>
>                 Regards
>                 Prasanta
>
>                 On 12/11/2017 3:01 PM, Krishna Addepalli wrote:
>
>                     Hi Prasanta,
>
>                     Thanks for pointing out the ?getRowCount()==0?
>                     check. Modified it to ?getRowCount() <= 0? in the
>                     new webrev:
>                     http://cr.openjdk.java.net/~kaddepalli/8190281/webrev02/
>                     <http://cr.openjdk.java.net/%7Ekaddepalli/8190281/webrev02/>
>
>                     As for calling the method twice, you are right
>                     that we don?t need to call it twice, but in the
>                     interest of having trivial reject case first, and
>                     then start the variable declarations, had to let
>                     be there to be called twice. Precisely for the
>                     reason you stated, it shouldn?t matter if we
>                     called it twice.
>
>                     Thanks,
>
>                     Krishna
>
>                     *From:*Prasanta Sadhukhan
>                     *Sent:* Saturday, December 9, 2017 7:54 PM
>                     *To:* Krishna Addepalli
>                     <krishna.addepalli at oracle.com>
>                     <mailto:krishna.addepalli at oracle.com>;
>                     swing-dev at openjdk.java.net
>                     <mailto:swing-dev at openjdk.java.net>
>                     *Subject:* Re: <Swing Dev> [10][JDK-8190281] Code
>                     cleanup in
>                     src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java
>
>                     Hi Krishna,
>
>                     This seems good to me except one thing. You are
>                     checking getRowCount() == 0 but there is a chance
>                     of test extending VariableHeightLayoutCache and
>                     overriding getRowCount to return -ve also as it is
>                     an int. In that case, I guess this function will
>                     not return -1 which spec mandates [If there are no
>                     rows, -1 is returned] so I guess we should check
>                     for <=0.
>                     Also, there is no need of calling getRowCount()
>                     twice as it will not change between 929, 936.
>
>                     Regards
>                     Prasanta
>
>                     On 12/7/2017 4:41 PM, Krishna Addepalli wrote:
>
>                         Hi Sergey,
>
>                         Per our conversation, I have done the
>                         following changes:
>
>                         1.Found that the .class size increases by 1kb
>                         when streams are used, so reverted the changes
>                         related to it.
>
>                         2.Moved the ?++nextIndex? into the
>                         conditional, so that there is no logical change.
>
>                         Here is the updated webrev:
>                         http://cr.openjdk.java.net/~kaddepalli/8190281/webrev01/
>                         <http://cr.openjdk.java.net/%7Ekaddepalli/8190281/webrev01/>
>
>                         Thanks,
>
>                         Krishna
>
>                         *From:* Krishna Addepalli
>                         *Sent:* Wednesday, December 6, 2017 2:43 PM
>                         *To:* swing-dev at openjdk.java.net
>                         <mailto:swing-dev at openjdk.java.net>
>                         *Subject:* [10][JDK-8190281] Code cleanup in
>                         src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java
>
>                         Hi All,
>
>                         Please review the fix for bug:
>
>                         Bug: JDK-8190281
>                         https://bugs.openjdk.java.net/browse/JDK-8190281
>
>                         JDK 10 Webrev:
>                         http://cr.openjdk.java.net/~kaddepalli/8190281/webrev00/
>                         <http://cr.openjdk.java.net/%7Ekaddepalli/8190281/webrev00/>
>
>                         This bug was created while root causing
>                         JDK-8187936, and the following refactoring
>                         points have been addressed:
>
>                         1. Line 927: Uninitialized variables, checking
>                         for trivial reject case multiple times.
>                         2. Line 999: Traditional code written to find
>                         maximum size of components, which can be done
>                         without any local variables and explicit
>                         looping by replacing with streams.
>                         3. Line 1365: Code repetition for differenct
>                         conditions, which can be ored together to
>                         reduce the repetition.
>                         4. Line 1482: A large code block gets repeated
>                         only because of different values need to be
>                         passed in one line. This can be moved to a
>                         variable initialization, and the repeating
>                         code blocks can be reduced to one.
>                         5. Line 1505: Variable initialization can be
>                         simplified by combining different conditions.
>                         6. Line 1540: An explicit loop to apply a
>                         function over a collection, can be achieved in
>                         one line by a forEach construct.? ? This is
>                         producing some visual artifacts, so ignored.
>                         7. Line 1747: Combine all the trivial reject
>                         cases into one condition, and also, a
>                         potential bug which increments the "nextIndex"
>                         value beyond the length of the containing
>                         elements. The increment should happen only if
>                         the trivial reject case fails.
>
>                         Thanks,
>
>                         Krishna
>

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

From krishna.addepalli at oracle.com  Wed Dec 13 08:42:42 2017
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Wed, 13 Dec 2017 00:42:42 -0800 (PST)
Subject: <Swing Dev> [10][JDK-8190281] Code cleanup in
 src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java
In-Reply-To: <0467651b-d9dd-9e2e-1820-19b4041b53a7@oracle.com>
References: <d76a18e3-c363-4159-834f-3ba81aa5a443@default>
 <8ff212fc-7c49-4963-99af-477ac4a0f4e1@default>
 <a7046f27-04f7-ac0d-bec1-fa555a842ec1@oracle.com>
 <e10f0a03-74d4-48da-ac8c-5828147c88ee@default>
 <500d86a0-53dd-645a-eb8b-a74a4511a2d1@oracle.com>
 <d605fbaf-2884-49e4-98fb-6a46e4cd989d@default>
 <133264f1-5e1c-1999-8f9f-a940d8edbe11@oracle.com>
 <6c239b79-9901-4b39-a18f-edbc0f43e013@default>
 <01961a4f-9f7d-ae78-f32e-a2ba7ea9f4c9@oracle.com>
 <02dbfb86-71dd-4813-9624-c6d80e74691e@default>
 <6593bd1e-3f24-3120-37fe-2b2f07288f41@oracle.com>
 <e75fdfb5-2bef-4a62-b895-8054b27c34c2@default>
 <0467651b-d9dd-9e2e-1820-19b4041b53a7@oracle.com>
Message-ID: <19864cc6-d723-4b5d-902f-4623720d5d71@default>

Hi Prasanta,

 

Here is the webrev with suggested changes:  http://cr.openjdk.java.net/~kaddepalli/8190281/webrev05/

 

Thanks,

Krishna

 

From: Prasanta Sadhukhan 
Sent: Wednesday, December 13, 2017 10:42 AM
To: Krishna Addepalli <krishna.addepalli at oracle.com>; swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10][JDK-8190281] Code cleanup in src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java

 

But there is no compulsion that we need to store getRowCount() in "max". You can store in some other variable and then "max" point to that in the loop.

Regards
Prasanta

On 12/12/2017 9:51 PM, Krishna Addepalli wrote:

Hi Prasanta,

 

The getRowCount() calls l955,956 cannot be removed, since max variable is getting modified in the while loop at l945. There is no guarantee that max will still hold the getRowCount() after the loop exits. So, those calls cannot be removed.

 

Thanks,

Krishna

 

From: Prasanta Sadhukhan 
Sent: Tuesday, December 12, 2017 8:08 PM
To: Krishna Addepalli HYPERLINK "mailto:krishna.addepalli at oracle.com"<krishna.addepalli at oracle.com>; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10][JDK-8190281] Code cleanup in src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java

 

As told, you overlooked l955,956

Regards
Prasanta

On 12/12/2017 7:37 PM, Krishna Addepalli wrote:

Oops! My bad. Created a new webrev here with the correction: HYPERLINK "http://cr.openjdk.java.net/%7Ekaddepalli/8190281/webrev04/"http://cr.openjdk.java.net/~kaddepalli/8190281/webrev04/

 

From: Prasanta Sadhukhan 
Sent: Tuesday, December 12, 2017 7:05 PM
To: Krishna Addepalli HYPERLINK "mailto:krishna.addepalli at oracle.com"<krishna.addepalli at oracle.com>; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10][JDK-8190281] Code cleanup in src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java

 

You missed using the variable at l933

Regards
Prasanta

On 12/12/2017 5:21 PM, Krishna Addepalli wrote:

Hi Prasanta,

 

Did the change for caching the result of calling "getRowCount()" into a variable, as pointed out by you, and here is the new webrev: HYPERLINK "http://cr.openjdk.java.net/%7Ekaddepalli/8190281/webrev03/"http://cr.openjdk.java.net/~kaddepalli/8190281/webrev03/

 

Thanks,

Krishna

 

From: Prasanta Sadhukhan 
Sent: Monday, December 11, 2017 7:24 PM
To: Krishna Addepalli HYPERLINK "mailto:krishna.addepalli at oracle.com"<krishna.addepalli at oracle.com>; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10][JDK-8190281] Code cleanup in src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java

 

 

 

On 12/11/2017 4:16 PM, Krishna Addepalli wrote:

Hi Prasanta,

 

Yes, you are right, but as I mentioned earlier, that would need to make one variable declaration for caching before trivial reject case, which I wanted to avoid.

As for the body of getRowCount() it is just returning "visibleNodes.size()", which shouldn't be a (performance)problem if called 2 times as I understand.

But, the whole premise of changing getRowCount() <=0  was that it can be overridden and return -ve. Left to present implementation, we would not have needed "less than" check. 
So, if we are changing one case because of the above reason, then we cannot forego the 2nd case's problem, as it can have any implementation.

Regards
Prasanta






 

Thanks,

Krishna

 

From: Prasanta Sadhukhan 
Sent: Monday, December 11, 2017 4:02 PM
To: Krishna Addepalli HYPERLINK "mailto:krishna.addepalli at oracle.com"<krishna.addepalli at oracle.com>; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10][JDK-8190281] Code cleanup in src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java

 

Hi Krishna,

My point was we can call getRowCount() once at first and store the result and use it subsequently. There was no need to call it 2-3 times.

Regards
Prasanta

On 12/11/2017 3:01 PM, Krishna Addepalli wrote:

Hi Prasanta,

 

Thanks for pointing out the "getRowCount()==0" check. Modified it to "getRowCount() <= 0" in the new webrev: HYPERLINK "http://cr.openjdk.java.net/%7Ekaddepalli/8190281/webrev02/"http://cr.openjdk.java.net/~kaddepalli/8190281/webrev02/

 

As for calling the method twice, you are right that we don't need to call it twice, but in the interest of having trivial reject case first, and then start the variable declarations, had to let be there to be called twice. Precisely for the reason you stated, it shouldn't matter if we called it twice.

 

Thanks,

Krishna

 

From: Prasanta Sadhukhan 
Sent: Saturday, December 9, 2017 7:54 PM
To: Krishna Addepalli HYPERLINK "mailto:krishna.addepalli at oracle.com"<krishna.addepalli at oracle.com>; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10][JDK-8190281] Code cleanup in src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java

 

Hi Krishna,

This seems good to me except one thing. You are checking getRowCount() == 0 but there is a chance of test extending VariableHeightLayoutCache and overriding getRowCount to return -ve also as it is an int. In that case, I guess this function will not return -1 which spec mandates [If there are no rows, -1 is returned] so I guess we should check for <=0. 
Also, there is no need of calling getRowCount() twice as it will not change between 929, 936.

Regards
Prasanta

On 12/7/2017 4:41 PM, Krishna Addepalli wrote:

Hi Sergey,

 

Per our conversation, I have done the following changes:

1.       Found that the .class size increases by 1kb when streams are used, so reverted the changes related to it.

2.       Moved the "++nextIndex" into the conditional, so that there is no logical change.

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

 

Thanks,

Krishna

 

From: Krishna Addepalli 
Sent: Wednesday, December 6, 2017 2:43 PM
To: HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: [10][JDK-8190281] Code cleanup in src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java

 

Hi All,

 

Please review the fix for bug:

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

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

 

This bug was created while root causing JDK-8187936, and the following refactoring points have been addressed:

 

1. Line 927: Uninitialized variables, checking for trivial reject case multiple times. 
2. Line 999: Traditional code written to find maximum size of components, which can be done without any local variables and explicit looping by replacing with streams. 
3. Line 1365: Code repetition for differenct conditions, which can be ored together to reduce the repetition. 
4. Line 1482: A large code block gets repeated only because of different values need to be passed in one line. This can be moved to a variable initialization, and the repeating code blocks can be reduced to one. 
5. Line 1505: Variable initialization can be simplified by combining different conditions. 
6. Line 1540: An explicit loop to apply a function over a collection, can be achieved in one line by a forEach construct.  - This is producing some visual artifacts, so ignored.
7. Line 1747: Combine all the trivial reject cases into one condition, and also, a potential bug which increments the "nextIndex" value beyond the length of the containing elements. The increment should happen only if the trivial reject case fails.

 

Thanks,

Krishna

 

 

 

 

 

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

From krishna.addepalli at oracle.com  Wed Dec 13 09:30:47 2017
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Wed, 13 Dec 2017 01:30:47 -0800 (PST)
Subject: <Swing Dev> [10][JDK-8190281] Code cleanup in
 src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java
In-Reply-To: <9ea66293-2b7f-76ac-a076-805760db9bd3@oracle.com>
References: <d76a18e3-c363-4159-834f-3ba81aa5a443@default>
 <8ff212fc-7c49-4963-99af-477ac4a0f4e1@default>
 <a7046f27-04f7-ac0d-bec1-fa555a842ec1@oracle.com>
 <e10f0a03-74d4-48da-ac8c-5828147c88ee@default>
 <500d86a0-53dd-645a-eb8b-a74a4511a2d1@oracle.com>
 <d605fbaf-2884-49e4-98fb-6a46e4cd989d@default>
 <133264f1-5e1c-1999-8f9f-a940d8edbe11@oracle.com>
 <6c239b79-9901-4b39-a18f-edbc0f43e013@default>
 <01961a4f-9f7d-ae78-f32e-a2ba7ea9f4c9@oracle.com>
 <02dbfb86-71dd-4813-9624-c6d80e74691e@default>
 <6593bd1e-3f24-3120-37fe-2b2f07288f41@oracle.com>
 <e75fdfb5-2bef-4a62-b895-8054b27c34c2@default>
 <0467651b-d9dd-9e2e-1820-19b4041b53a7@oracle.com>
 <19864cc6-d723-4b5d-902f-4623720d5d71@default>
 <9ea66293-2b7f-76ac-a076-805760db9bd3@oracle.com>
Message-ID: <05e30ee1-abf0-429e-b6f5-670e3eeb7331@default>

Thanks Prasanta for taking time and reviewing.

@Sergey, could you also review and provide your comments/approval?

 

Krishna

 

From: Prasanta Sadhukhan 
Sent: Wednesday, December 13, 2017 2:18 PM
To: Krishna Addepalli <krishna.addepalli at oracle.com>; swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10][JDK-8190281] Code cleanup in src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java

 

+1

Regards
Prasanta

On 12/13/2017 2:12 PM, Krishna Addepalli wrote:

Hi Prasanta,

 

Here is the webrev with suggested changes:  HYPERLINK "http://cr.openjdk.java.net/%7Ekaddepalli/8190281/webrev05/"http://cr.openjdk.java.net/~kaddepalli/8190281/webrev05/

 

Thanks,

Krishna

 

From: Prasanta Sadhukhan 
Sent: Wednesday, December 13, 2017 10:42 AM
To: Krishna Addepalli HYPERLINK "mailto:krishna.addepalli at oracle.com"<krishna.addepalli at oracle.com>; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10][JDK-8190281] Code cleanup in src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java

 

But there is no compulsion that we need to store getRowCount() in "max". You can store in some other variable and then "max" point to that in the loop.

Regards
Prasanta

On 12/12/2017 9:51 PM, Krishna Addepalli wrote:

Hi Prasanta,

 

The getRowCount() calls l955,956 cannot be removed, since max variable is getting modified in the while loop at l945. There is no guarantee that max will still hold the getRowCount() after the loop exits. So, those calls cannot be removed.

 

Thanks,

Krishna

 

From: Prasanta Sadhukhan 
Sent: Tuesday, December 12, 2017 8:08 PM
To: Krishna Addepalli HYPERLINK "mailto:krishna.addepalli at oracle.com"<krishna.addepalli at oracle.com>; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10][JDK-8190281] Code cleanup in src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java

 

As told, you overlooked l955,956

Regards
Prasanta

On 12/12/2017 7:37 PM, Krishna Addepalli wrote:

Oops! My bad. Created a new webrev here with the correction: HYPERLINK "http://cr.openjdk.java.net/%7Ekaddepalli/8190281/webrev04/"http://cr.openjdk.java.net/~kaddepalli/8190281/webrev04/

 

From: Prasanta Sadhukhan 
Sent: Tuesday, December 12, 2017 7:05 PM
To: Krishna Addepalli HYPERLINK "mailto:krishna.addepalli at oracle.com"<krishna.addepalli at oracle.com>; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10][JDK-8190281] Code cleanup in src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java

 

You missed using the variable at l933

Regards
Prasanta

On 12/12/2017 5:21 PM, Krishna Addepalli wrote:

Hi Prasanta,

 

Did the change for caching the result of calling "getRowCount()" into a variable, as pointed out by you, and here is the new webrev: HYPERLINK "http://cr.openjdk.java.net/%7Ekaddepalli/8190281/webrev03/"http://cr.openjdk.java.net/~kaddepalli/8190281/webrev03/

 

Thanks,

Krishna

 

From: Prasanta Sadhukhan 
Sent: Monday, December 11, 2017 7:24 PM
To: Krishna Addepalli HYPERLINK "mailto:krishna.addepalli at oracle.com"<krishna.addepalli at oracle.com>; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10][JDK-8190281] Code cleanup in src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java

 

 

 

On 12/11/2017 4:16 PM, Krishna Addepalli wrote:

Hi Prasanta,

 

Yes, you are right, but as I mentioned earlier, that would need to make one variable declaration for caching before trivial reject case, which I wanted to avoid.

As for the body of getRowCount() it is just returning "visibleNodes.size()", which shouldn't be a (performance)problem if called 2 times as I understand.

But, the whole premise of changing getRowCount() <=0  was that it can be overridden and return -ve. Left to present implementation, we would not have needed "less than" check. 
So, if we are changing one case because of the above reason, then we cannot forego the 2nd case's problem, as it can have any implementation.

Regards
Prasanta







 

Thanks,

Krishna

 

From: Prasanta Sadhukhan 
Sent: Monday, December 11, 2017 4:02 PM
To: Krishna Addepalli HYPERLINK "mailto:krishna.addepalli at oracle.com"<krishna.addepalli at oracle.com>; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10][JDK-8190281] Code cleanup in src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java

 

Hi Krishna,

My point was we can call getRowCount() once at first and store the result and use it subsequently. There was no need to call it 2-3 times.

Regards
Prasanta

On 12/11/2017 3:01 PM, Krishna Addepalli wrote:

Hi Prasanta,

 

Thanks for pointing out the "getRowCount()==0" check. Modified it to "getRowCount() <= 0" in the new webrev: HYPERLINK "http://cr.openjdk.java.net/%7Ekaddepalli/8190281/webrev02/"http://cr.openjdk.java.net/~kaddepalli/8190281/webrev02/

 

As for calling the method twice, you are right that we don't need to call it twice, but in the interest of having trivial reject case first, and then start the variable declarations, had to let be there to be called twice. Precisely for the reason you stated, it shouldn't matter if we called it twice.

 

Thanks,

Krishna

 

From: Prasanta Sadhukhan 
Sent: Saturday, December 9, 2017 7:54 PM
To: Krishna Addepalli HYPERLINK "mailto:krishna.addepalli at oracle.com"<krishna.addepalli at oracle.com>; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10][JDK-8190281] Code cleanup in src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java

 

Hi Krishna,

This seems good to me except one thing. You are checking getRowCount() == 0 but there is a chance of test extending VariableHeightLayoutCache and overriding getRowCount to return -ve also as it is an int. In that case, I guess this function will not return -1 which spec mandates [If there are no rows, -1 is returned] so I guess we should check for <=0. 
Also, there is no need of calling getRowCount() twice as it will not change between 929, 936.

Regards
Prasanta

On 12/7/2017 4:41 PM, Krishna Addepalli wrote:

Hi Sergey,

 

Per our conversation, I have done the following changes:

1.       Found that the .class size increases by 1kb when streams are used, so reverted the changes related to it.

2.       Moved the "++nextIndex" into the conditional, so that there is no logical change.

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

 

Thanks,

Krishna

 

From: Krishna Addepalli 
Sent: Wednesday, December 6, 2017 2:43 PM
To: HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: [10][JDK-8190281] Code cleanup in src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java

 

Hi All,

 

Please review the fix for bug:

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

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

 

This bug was created while root causing JDK-8187936, and the following refactoring points have been addressed:

 

1. Line 927: Uninitialized variables, checking for trivial reject case multiple times. 
2. Line 999: Traditional code written to find maximum size of components, which can be done without any local variables and explicit looping by replacing with streams. 
3. Line 1365: Code repetition for differenct conditions, which can be ored together to reduce the repetition. 
4. Line 1482: A large code block gets repeated only because of different values need to be passed in one line. This can be moved to a variable initialization, and the repeating code blocks can be reduced to one. 
5. Line 1505: Variable initialization can be simplified by combining different conditions. 
6. Line 1540: An explicit loop to apply a function over a collection, can be achieved in one line by a forEach construct.  - This is producing some visual artifacts, so ignored.
7. Line 1747: Combine all the trivial reject cases into one condition, and also, a potential bug which increments the "nextIndex" value beyond the length of the containing elements. The increment should happen only if the trivial reject case fails.

 

Thanks,

Krishna

 

 

 

 

 

 

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

From prasanta.sadhukhan at oracle.com  Thu Dec 14 10:16:24 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Thu, 14 Dec 2017 15:46:24 +0530
Subject: <Swing Dev> [11] RFR JDK-8190763:Class cast exception on
 (CompoundEdit) UndoableEditEvent.getEdit()
Message-ID: <cd85aaf2-94a2-f647-9fc9-a22731b1e2bf@oracle.com>

Hi All,

Please review a fix for a regression introduced inJDK-8030702: 
<https://bugs.openjdk.java.net/browse/JDK-8030702>Deadlock between 
subclass of AbstractDocument and UndoManager
where UndoableEditEvent.getEdit() was made to return 
DefaultDocumentEventUndoableWrapper (or UndoableEdit, an interface) 
instead of CompoundEdit (a concrete class)
so when application wants to cast to CompoundEdit, it results in CCE.
Also, it seems the application expects DefaultDocumentEvent instance 
also via UndoableEditEvent.getEdit() so that it can utilise it to get 
offset and length of editable change.

Proposed fix is to make DefaultDocumentEvent implement 
UndoableEditLockSupport (used to prevent deadlock in 8030702 
<https://bugs.openjdk.java.net/browse/JDK-8030702>).
With this, no CCE is seen and the 8030702 
<https://bugs.openjdk.java.net/browse/JDK-8030702> also passed.
http://cr.openjdk.java.net/~psadhukhan/8190763/webrev.00/

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

From semyon.sadetsky at oracle.com  Thu Dec 14 17:22:59 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Thu, 14 Dec 2017 09:22:59 -0800
Subject: <Swing Dev> [11] RFR JDK-8190763:Class cast exception on
 (CompoundEdit) UndoableEditEvent.getEdit()
In-Reply-To: <cd85aaf2-94a2-f647-9fc9-a22731b1e2bf@oracle.com>
References: <cd85aaf2-94a2-f647-9fc9-a22731b1e2bf@oracle.com>
Message-ID: <e618e9e6-647a-8222-1255-9446c0aa38dc@oracle.com>

Hi Prasanta,

This is a compatibility issue.

The complexity of 8030702 is that it had to fix the concurrency issue 
without changing the API. So the only fix that may help here is the one 
that does not change the API.

--Semyon

On 12/14/2017 02:16 AM, Prasanta Sadhukhan wrote:
>
> Hi All,
>
> Please review a fix for a regression introduced inJDK-8030702: 
> <https://bugs.openjdk.java.net/browse/JDK-8030702>Deadlock between 
> subclass of AbstractDocument and UndoManager
> where UndoableEditEvent.getEdit() was made to return 
> DefaultDocumentEventUndoableWrapper (or UndoableEdit, an interface) 
> instead of CompoundEdit (a concrete class)
> so when application wants to cast to CompoundEdit, it results in CCE.
> Also, it seems the application expects DefaultDocumentEvent instance 
> also via UndoableEditEvent.getEdit() so that it can utilise it to get 
> offset and length of editable change.
>
> Proposed fix is to make DefaultDocumentEvent implement 
> UndoableEditLockSupport (used to prevent deadlock in 8030702 
> <https://bugs.openjdk.java.net/browse/JDK-8030702>).
> With this, no CCE is seen and the 8030702 
> <https://bugs.openjdk.java.net/browse/JDK-8030702> also passed.
> http://cr.openjdk.java.net/~psadhukhan/8190763/webrev.00/
>
> Regards
> Prasanta

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

From krishna.addepalli at oracle.com  Fri Dec 15 13:47:33 2017
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Fri, 15 Dec 2017 05:47:33 -0800 (PST)
Subject: <Swing Dev> [10][JDK-8190281] Code cleanup in
 src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java
In-Reply-To: <05e30ee1-abf0-429e-b6f5-670e3eeb7331@default>
References: <d76a18e3-c363-4159-834f-3ba81aa5a443@default>
 <8ff212fc-7c49-4963-99af-477ac4a0f4e1@default>
 <a7046f27-04f7-ac0d-bec1-fa555a842ec1@oracle.com>
 <e10f0a03-74d4-48da-ac8c-5828147c88ee@default>
 <500d86a0-53dd-645a-eb8b-a74a4511a2d1@oracle.com>
 <d605fbaf-2884-49e4-98fb-6a46e4cd989d@default>
 <133264f1-5e1c-1999-8f9f-a940d8edbe11@oracle.com>
 <6c239b79-9901-4b39-a18f-edbc0f43e013@default>
 <01961a4f-9f7d-ae78-f32e-a2ba7ea9f4c9@oracle.com>
 <02dbfb86-71dd-4813-9624-c6d80e74691e@default>
 <6593bd1e-3f24-3120-37fe-2b2f07288f41@oracle.com>
 <e75fdfb5-2bef-4a62-b895-8054b27c34c2@default>
 <0467651b-d9dd-9e2e-1820-19b4041b53a7@oracle.com>
 <19864cc6-d723-4b5d-902f-4623720d5d71@default>
 <9ea66293-2b7f-76ac-a076-805760db9bd3@oracle.com>
 <05e30ee1-abf0-429e-b6f5-670e3eeb7331@default>
Message-ID: <84906dbd-3c49-4c3f-9b65-b91035208f50@default>

Hi Sergey,

 

Did you get a chance to review this?

 

Thanks,

Krishna

 

From: Krishna Addepalli 
Sent: Wednesday, December 13, 2017 3:01 PM
To: Prasanta Sadhukhan <prasanta.sadhukhan at oracle.com>; swing-dev at openjdk.java.net
Subject: RE: <Swing Dev> [10][JDK-8190281] Code cleanup in src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java

 

Thanks Prasanta for taking time and reviewing.

@Sergey, could you also review and provide your comments/approval?

 

Krishna

 

From: Prasanta Sadhukhan 
Sent: Wednesday, December 13, 2017 2:18 PM
To: Krishna Addepalli <HYPERLINK "mailto:krishna.addepalli at oracle.com"krishna.addepalli at oracle.com>; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10][JDK-8190281] Code cleanup in src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java

 

+1

Regards
Prasanta

On 12/13/2017 2:12 PM, Krishna Addepalli wrote:

Hi Prasanta,

 

Here is the webrev with suggested changes:  HYPERLINK "http://cr.openjdk.java.net/%7Ekaddepalli/8190281/webrev05/"http://cr.openjdk.java.net/~kaddepalli/8190281/webrev05/

 

Thanks,

Krishna

 

From: Prasanta Sadhukhan 
Sent: Wednesday, December 13, 2017 10:42 AM
To: Krishna Addepalli HYPERLINK "mailto:krishna.addepalli at oracle.com"<krishna.addepalli at oracle.com>; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10][JDK-8190281] Code cleanup in src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java

 

But there is no compulsion that we need to store getRowCount() in "max". You can store in some other variable and then "max" point to that in the loop.

Regards
Prasanta

On 12/12/2017 9:51 PM, Krishna Addepalli wrote:

Hi Prasanta,

 

The getRowCount() calls l955,956 cannot be removed, since max variable is getting modified in the while loop at l945. There is no guarantee that max will still hold the getRowCount() after the loop exits. So, those calls cannot be removed.

 

Thanks,

Krishna

 

From: Prasanta Sadhukhan 
Sent: Tuesday, December 12, 2017 8:08 PM
To: Krishna Addepalli HYPERLINK "mailto:krishna.addepalli at oracle.com"<krishna.addepalli at oracle.com>; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10][JDK-8190281] Code cleanup in src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java

 

As told, you overlooked l955,956

Regards
Prasanta

On 12/12/2017 7:37 PM, Krishna Addepalli wrote:

Oops! My bad. Created a new webrev here with the correction: HYPERLINK "http://cr.openjdk.java.net/%7Ekaddepalli/8190281/webrev04/"http://cr.openjdk.java.net/~kaddepalli/8190281/webrev04/

 

From: Prasanta Sadhukhan 
Sent: Tuesday, December 12, 2017 7:05 PM
To: Krishna Addepalli HYPERLINK "mailto:krishna.addepalli at oracle.com"<krishna.addepalli at oracle.com>; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10][JDK-8190281] Code cleanup in src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java

 

You missed using the variable at l933

Regards
Prasanta

On 12/12/2017 5:21 PM, Krishna Addepalli wrote:

Hi Prasanta,

 

Did the change for caching the result of calling "getRowCount()" into a variable, as pointed out by you, and here is the new webrev: HYPERLINK "http://cr.openjdk.java.net/%7Ekaddepalli/8190281/webrev03/"http://cr.openjdk.java.net/~kaddepalli/8190281/webrev03/

 

Thanks,

Krishna

 

From: Prasanta Sadhukhan 
Sent: Monday, December 11, 2017 7:24 PM
To: Krishna Addepalli HYPERLINK "mailto:krishna.addepalli at oracle.com"<krishna.addepalli at oracle.com>; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10][JDK-8190281] Code cleanup in src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java

 

 

 

On 12/11/2017 4:16 PM, Krishna Addepalli wrote:

Hi Prasanta,

 

Yes, you are right, but as I mentioned earlier, that would need to make one variable declaration for caching before trivial reject case, which I wanted to avoid.

As for the body of getRowCount() it is just returning "visibleNodes.size()", which shouldn't be a (performance)problem if called 2 times as I understand.

But, the whole premise of changing getRowCount() <=0  was that it can be overridden and return -ve. Left to present implementation, we would not have needed "less than" check. 
So, if we are changing one case because of the above reason, then we cannot forego the 2nd case's problem, as it can have any implementation.

Regards
Prasanta






 

Thanks,

Krishna

 

From: Prasanta Sadhukhan 
Sent: Monday, December 11, 2017 4:02 PM
To: Krishna Addepalli HYPERLINK "mailto:krishna.addepalli at oracle.com"<krishna.addepalli at oracle.com>; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10][JDK-8190281] Code cleanup in src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java

 

Hi Krishna,

My point was we can call getRowCount() once at first and store the result and use it subsequently. There was no need to call it 2-3 times.

Regards
Prasanta

On 12/11/2017 3:01 PM, Krishna Addepalli wrote:

Hi Prasanta,

 

Thanks for pointing out the "getRowCount()==0" check. Modified it to "getRowCount() <= 0" in the new webrev: HYPERLINK "http://cr.openjdk.java.net/%7Ekaddepalli/8190281/webrev02/"http://cr.openjdk.java.net/~kaddepalli/8190281/webrev02/

 

As for calling the method twice, you are right that we don't need to call it twice, but in the interest of having trivial reject case first, and then start the variable declarations, had to let be there to be called twice. Precisely for the reason you stated, it shouldn't matter if we called it twice.

 

Thanks,

Krishna

 

From: Prasanta Sadhukhan 
Sent: Saturday, December 9, 2017 7:54 PM
To: Krishna Addepalli HYPERLINK "mailto:krishna.addepalli at oracle.com"<krishna.addepalli at oracle.com>; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10][JDK-8190281] Code cleanup in src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java

 

Hi Krishna,

This seems good to me except one thing. You are checking getRowCount() == 0 but there is a chance of test extending VariableHeightLayoutCache and overriding getRowCount to return -ve also as it is an int. In that case, I guess this function will not return -1 which spec mandates [If there are no rows, -1 is returned] so I guess we should check for <=0. 
Also, there is no need of calling getRowCount() twice as it will not change between 929, 936.

Regards
Prasanta

On 12/7/2017 4:41 PM, Krishna Addepalli wrote:

Hi Sergey,

 

Per our conversation, I have done the following changes:

1.       Found that the .class size increases by 1kb when streams are used, so reverted the changes related to it.

2.       Moved the "++nextIndex" into the conditional, so that there is no logical change.

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

 

Thanks,

Krishna

 

From: Krishna Addepalli 
Sent: Wednesday, December 6, 2017 2:43 PM
To: HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: [10][JDK-8190281] Code cleanup in src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java

 

Hi All,

 

Please review the fix for bug:

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

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

 

This bug was created while root causing JDK-8187936, and the following refactoring points have been addressed:

 

1. Line 927: Uninitialized variables, checking for trivial reject case multiple times. 
2. Line 999: Traditional code written to find maximum size of components, which can be done without any local variables and explicit looping by replacing with streams. 
3. Line 1365: Code repetition for differenct conditions, which can be ored together to reduce the repetition. 
4. Line 1482: A large code block gets repeated only because of different values need to be passed in one line. This can be moved to a variable initialization, and the repeating code blocks can be reduced to one. 
5. Line 1505: Variable initialization can be simplified by combining different conditions. 
6. Line 1540: An explicit loop to apply a function over a collection, can be achieved in one line by a forEach construct.  - This is producing some visual artifacts, so ignored.
7. Line 1747: Combine all the trivial reject cases into one condition, and also, a potential bug which increments the "nextIndex" value beyond the length of the containing elements. The increment should happen only if the trivial reject case fails.

 

Thanks,

Krishna

 

 

 

 

 

 

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

From semyon.sadetsky at oracle.com  Mon Dec 18 22:26:56 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Mon, 18 Dec 2017 14:26:56 -0800
Subject: <Swing Dev> [10] Review request for 8182041: File Chooser
 Shortcut Panel folders under on JDK 9
In-Reply-To: <738414ab-3666-5ec8-3154-1f7702d03d88@oracle.com>
References: <db72d1e4-9bdd-1aac-46e9-cb596e8d00a8@oracle.com>
 <8ec1366f-c6bc-08bb-7552-63b8ee7e1455@oracle.com>
 <70745340-e93c-66cc-7ba6-3c5cfdf8dfb0@oracle.com>
 <daca5637-9b6f-2bd4-4614-d54d02991d33@oracle.com>
 <738414ab-3666-5ec8-3154-1f7702d03d88@oracle.com>
Message-ID: <03b713c1-2f76-cd9c-b593-d8a9ea0f2a09@oracle.com>

Hi Phil,

On 12/06/2017 09:56 AM, Phil Race wrote:

>
>
> On 12/06/2017 09:39 AM, Semyon Sadetsky wrote:
>>
>> On 12/06/2017 08:33 AM, Phil Race wrote:
>>
>>> Hi,
>>> I have some additional comments on this old review thread. Hopefully 
>>> we can close it out soon
>>> although it will need a CSR whatever ..
>>>
>>> Since the implementation of ShellFolderManager filters out 
>>> inaccessible files we
>>> should document this somewhere.
>>> I suggest either on the class or relevant methods saying something like
>>> "Files or resources which are not accessible in the current security 
>>> context
>>> may be filtered out from the returned set".
>>>
>>> The word "may" is key here ..
>> This looks to me like implementation details.
>
> No. On the contrary. It can be specified.
You are suggesting to describe some solution as a part of a generic 
interface specification which assumes platform specific behavior. But if 
we add this extra details we need to be sure that the proposed generic 
solution is feasible.? At the moment there are no way to set permissions 
for virtual shell folders like "Network" or "Computer" and others but 
they are returned in the list. So, when in? the interface specification 
you are requesting inaccessible elements not to be returned you need to 
be sure that at least the current OpenJDK implementation is in alignment 
with it.
>
>> I agree that it is worth to mention this problematic in the method 
>> spec but since it is a generic method for different platforms it 
>> probably should be given in a different form than a particular 
>> platform specific solution. If the entries of the list are virtual 
>> they may not have any file system permissions at all.
>>>
>>> If we are sure that this is always the case then it would follow 
>>> that SecurityException
>>> does not need to be documented.
>>> Consistency would suggest that then this policy would extend to the 
>>> other methods
>>> added in JDK 9 which declare that exception. So all or none.
>>> Being a RuntimeException that is not checked I think we can 
>>> compatibly remove those.
>> This is not consistent with other JDK classes in which the 
>> SecurityException is always mentioned, for example, the 
>> java.awt.Desktop class and there are many others. I think it would be 
>> non-practical to rewrite all other specs because you've changed your 
>> mind in this particular fix review.
>
> The API contract of some other class such as Desktop is not relevant.
>
> I am saying FileSystemView should be internally consistent
I think more important criterion is the method specification is 
consistent with its own implementation and describes its results in full 
for developer. I have several bugs on my plate which suggest that it is 
important to remind about security exception which may be the result of 
the method otherwise the functionality of the client classes may be broken:
https://bugs.openjdk.java.net/browse/JDK-8193766
https://bugs.openjdk.java.net/browse/JDK-8193563
https://bugs.openjdk.java.net/browse/JDK-8193761

Most of the method specifications of the FileSystemView class *should* 
mention SecurityException as a result of their execution. For example, 
similar java.awt.Desktop class methods which provide access to the OS 
shell extensions all mention SecurityException.

--Semyon
>
>
>> Also, in this fix review [1]? you brought an opposite point of view.
>>
>> [1] 
>> http://mail.openjdk.java.net/pipermail/swing-dev/2015-October/005073.html
>
> That was because no one told me at the time that we were filtering out 
> to prevent leakage.
> i.e I have new information.
>
>
> -phil.
>>
>> --Semyon
>>
>>>
>>> -phil.
>>>
>>>
>>> On 10/24/2017 09:22 PM, Alexander Zvegintsev wrote:
>>>>
>>>> Hi Semyon,
>>>>
>>>> the fix looks good to me, but I found a minor typo in the test:
>>>>
>>>> testShortcatPanelFiles -> testShortcutPanelFiles
>>>>
>>>> no need for a new webrev
>>>>
>>>> Thanks,
>>>> Alexander.
>>>> On 04/10/2017 00:41, Semyon Sadetsky wrote:
>>>>> Hello,
>>>>>
>>>>> Please review fix for JDK10 (the changes involve AWT and Swing):
>>>>>
>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8182041
>>>>>
>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8182041/webrev.00/
>>>>>
>>>>> New API method was added letting to query shortcut panel entries 
>>>>> for JFileChooser.
>>>>>
>>>>> --Semyon
>>>>>
>>>>
>>>
>>
>

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

From Sergey.Bylokhov at oracle.com  Mon Dec 18 23:28:08 2017
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 18 Dec 2017 15:28:08 -0800
Subject: <Swing Dev> [11] Review Request: 6684386 ElementIterator javadoc bug
Message-ID: <dff2a488-612e-ceec-9bf2-cb66ae09fe23@oracle.com>

Hello.
Please review the fix for jdk11.

Bug: https://bugs.openjdk.java.net/browse/JDK-6684386
Webrev can be found at: http://cr.openjdk.java.net/~serb/6684386/webrev.00
Specdiff: 
http://cr.openjdk.java.net/~serb/6684386/specdiff.00/javax/swing/text/ElementIterator.html

Description of the javadoc changes:
  - <pre> tag is added for the code in the example
  - the typo in the code was fixed(it.next(")
  - <ul> tag is added for the list
  - The rest of the file was updated to use a styles used in the 
previous javadoc related fixes.

-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Mon Dec 18 23:35:21 2017
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 18 Dec 2017 15:35:21 -0800
Subject: <Swing Dev> [10][JDK-8190281] Code cleanup in
 src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java
In-Reply-To: <9ea66293-2b7f-76ac-a076-805760db9bd3@oracle.com>
References: <d76a18e3-c363-4159-834f-3ba81aa5a443@default>
 <8ff212fc-7c49-4963-99af-477ac4a0f4e1@default>
 <a7046f27-04f7-ac0d-bec1-fa555a842ec1@oracle.com>
 <e10f0a03-74d4-48da-ac8c-5828147c88ee@default>
 <500d86a0-53dd-645a-eb8b-a74a4511a2d1@oracle.com>
 <d605fbaf-2884-49e4-98fb-6a46e4cd989d@default>
 <133264f1-5e1c-1999-8f9f-a940d8edbe11@oracle.com>
 <6c239b79-9901-4b39-a18f-edbc0f43e013@default>
 <01961a4f-9f7d-ae78-f32e-a2ba7ea9f4c9@oracle.com>
 <02dbfb86-71dd-4813-9624-c6d80e74691e@default>
 <6593bd1e-3f24-3120-37fe-2b2f07288f41@oracle.com>
 <e75fdfb5-2bef-4a62-b895-8054b27c34c2@default>
 <0467651b-d9dd-9e2e-1820-19b4041b53a7@oracle.com>
 <19864cc6-d723-4b5d-902f-4623720d5d71@default>
 <9ea66293-2b7f-76ac-a076-805760db9bd3@oracle.com>
Message-ID: <8179326d-264f-8c6b-9cfa-44df9aa5d697@oracle.com>

Looks fine.

On 13/12/2017 00:48, Prasanta Sadhukhan wrote:
> +1
> 
> Regards
> Prasanta
> On 12/13/2017 2:12 PM, Krishna Addepalli wrote:
>>
>> Hi Prasanta,
>>
>> Here is the webrev with suggested changes: 
>> http://cr.openjdk.java.net/~kaddepalli/8190281/webrev05/ 
>> <http://cr.openjdk.java.net/%7Ekaddepalli/8190281/webrev05/>
>>
>> Thanks,
>>
>> Krishna
>>
>> *From:*Prasanta Sadhukhan
>> *Sent:* Wednesday, December 13, 2017 10:42 AM
>> *To:* Krishna Addepalli <krishna.addepalli at oracle.com>; 
>> swing-dev at openjdk.java.net
>> *Subject:* Re: <Swing Dev> [10][JDK-8190281] Code cleanup in 
>> src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java
>>
>> But there is no compulsion that we need to store getRowCount() in 
>> "max". You can store in some other variable and then "max" point to 
>> that in the loop.
>>
>> Regards
>> Prasanta
>>
>> On 12/12/2017 9:51 PM, Krishna Addepalli wrote:
>>
>>     Hi Prasanta,
>>
>>     The getRowCount() calls l955,956 cannot be removed, since max
>>     variable is getting modified in the while loop at l945. There is
>>     no guarantee that max will still hold the getRowCount() after the
>>     loop exits. So, those calls cannot be removed.
>>
>>     Thanks,
>>
>>     Krishna
>>
>>     *From:*Prasanta Sadhukhan
>>     *Sent:* Tuesday, December 12, 2017 8:08 PM
>>     *To:* Krishna Addepalli <krishna.addepalli at oracle.com>
>>     <mailto:krishna.addepalli at oracle.com>; swing-dev at openjdk.java.net
>>     <mailto:swing-dev at openjdk.java.net>
>>     *Subject:* Re: <Swing Dev> [10][JDK-8190281] Code cleanup in
>>     src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java
>>
>>     As told, you overlooked l955,956
>>
>>     Regards
>>     Prasanta
>>
>>     On 12/12/2017 7:37 PM, Krishna Addepalli wrote:
>>
>>         Oops! My bad. Created a new webrev here with the correction:
>>         http://cr.openjdk.java.net/~kaddepalli/8190281/webrev04/
>>         <http://cr.openjdk.java.net/%7Ekaddepalli/8190281/webrev04/>
>>
>>         *From:*Prasanta Sadhukhan
>>         *Sent:* Tuesday, December 12, 2017 7:05 PM
>>         *To:* Krishna Addepalli <krishna.addepalli at oracle.com>
>>         <mailto:krishna.addepalli at oracle.com>;
>>         swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>
>>         *Subject:* Re: <Swing Dev> [10][JDK-8190281] Code cleanup in
>>         src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java
>>
>>         You missed using the variable at l933
>>
>>         Regards
>>         Prasanta
>>
>>         On 12/12/2017 5:21 PM, Krishna Addepalli wrote:
>>
>>             Hi Prasanta,
>>
>>             Did the change for caching the result of calling
>>             ?getRowCount()? into a variable, as pointed out by you,
>>             and here is the new webrev:
>>             http://cr.openjdk.java.net/~kaddepalli/8190281/webrev03/
>>             <http://cr.openjdk.java.net/%7Ekaddepalli/8190281/webrev03/>
>>
>>             Thanks,
>>
>>             Krishna
>>
>>             *From:*Prasanta Sadhukhan
>>             *Sent:* Monday, December 11, 2017 7:24 PM
>>             *To:* Krishna Addepalli <krishna.addepalli at oracle.com>
>>             <mailto:krishna.addepalli at oracle.com>;
>>             swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>
>>             *Subject:* Re: <Swing Dev> [10][JDK-8190281] Code cleanup
>>             in
>>             src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java
>>
>>             On 12/11/2017 4:16 PM, Krishna Addepalli wrote:
>>
>>                 Hi Prasanta,
>>
>>                 Yes, you are right, but as I mentioned earlier, that
>>                 would need to make one variable declaration for
>>                 caching before trivial reject case, which I wanted to
>>                 avoid.
>>
>>                 As for the body of getRowCount() it is just returning
>>                 ?visibleNodes.size()?, which shouldn?t be a
>>                 (performance)problem if called 2 times as I understand.
>>
>>             But, the whole premise of changing getRowCount() <=0? was
>>             that it can be overridden and return -ve. Left to present
>>             implementation, we would not have needed "less than" check.
>>             So, if we are changing one case because of the above
>>             reason, then we cannot forego the 2nd case's problem, as
>>             it can have any implementation.
>>
>>             Regards
>>             Prasanta
>>
>>
>>
>>
>>                 Thanks,
>>
>>                 Krishna
>>
>>                 *From:*Prasanta Sadhukhan
>>                 *Sent:* Monday, December 11, 2017 4:02 PM
>>                 *To:* Krishna Addepalli <krishna.addepalli at oracle.com>
>>                 <mailto:krishna.addepalli at oracle.com>;
>>                 swing-dev at openjdk.java.net
>>                 <mailto:swing-dev at openjdk.java.net>
>>                 *Subject:* Re: <Swing Dev> [10][JDK-8190281] Code
>>                 cleanup in
>>                 src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java
>>
>>                 Hi Krishna,
>>
>>                 My point was we can call getRowCount() once at first
>>                 and store the result and use it subsequently. There
>>                 was no need to call it 2-3 times.
>>
>>                 Regards
>>                 Prasanta
>>
>>                 On 12/11/2017 3:01 PM, Krishna Addepalli wrote:
>>
>>                     Hi Prasanta,
>>
>>                     Thanks for pointing out the ?getRowCount()==0?
>>                     check. Modified it to ?getRowCount() <= 0? in the
>>                     new webrev:
>>                     http://cr.openjdk.java.net/~kaddepalli/8190281/webrev02/
>>                     <http://cr.openjdk.java.net/%7Ekaddepalli/8190281/webrev02/>
>>
>>                     As for calling the method twice, you are right
>>                     that we don?t need to call it twice, but in the
>>                     interest of having trivial reject case first, and
>>                     then start the variable declarations, had to let
>>                     be there to be called twice. Precisely for the
>>                     reason you stated, it shouldn?t matter if we
>>                     called it twice.
>>
>>                     Thanks,
>>
>>                     Krishna
>>
>>                     *From:*Prasanta Sadhukhan
>>                     *Sent:* Saturday, December 9, 2017 7:54 PM
>>                     *To:* Krishna Addepalli
>>                     <krishna.addepalli at oracle.com>
>>                     <mailto:krishna.addepalli at oracle.com>;
>>                     swing-dev at openjdk.java.net
>>                     <mailto:swing-dev at openjdk.java.net>
>>                     *Subject:* Re: <Swing Dev> [10][JDK-8190281] Code
>>                     cleanup in
>>                     src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java
>>
>>                     Hi Krishna,
>>
>>                     This seems good to me except one thing. You are
>>                     checking getRowCount() == 0 but there is a chance
>>                     of test extending VariableHeightLayoutCache and
>>                     overriding getRowCount to return -ve also as it is
>>                     an int. In that case, I guess this function will
>>                     not return -1 which spec mandates [If there are no
>>                     rows, -1 is returned] so I guess we should check
>>                     for <=0.
>>                     Also, there is no need of calling getRowCount()
>>                     twice as it will not change between 929, 936.
>>
>>                     Regards
>>                     Prasanta
>>
>>                     On 12/7/2017 4:41 PM, Krishna Addepalli wrote:
>>
>>                         Hi Sergey,
>>
>>                         Per our conversation, I have done the
>>                         following changes:
>>
>>                         1.Found that the .class size increases by 1kb
>>                         when streams are used, so reverted the changes
>>                         related to it.
>>
>>                         2.Moved the ?++nextIndex? into the
>>                         conditional, so that there is no logical change.
>>
>>                         Here is the updated webrev:
>>                         http://cr.openjdk.java.net/~kaddepalli/8190281/webrev01/
>>                         <http://cr.openjdk.java.net/%7Ekaddepalli/8190281/webrev01/>
>>
>>                         Thanks,
>>
>>                         Krishna
>>
>>                         *From:* Krishna Addepalli
>>                         *Sent:* Wednesday, December 6, 2017 2:43 PM
>>                         *To:* swing-dev at openjdk.java.net
>>                         <mailto:swing-dev at openjdk.java.net>
>>                         *Subject:* [10][JDK-8190281] Code cleanup in
>>                         src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java
>>
>>                         Hi All,
>>
>>                         Please review the fix for bug:
>>
>>                         Bug: JDK-8190281
>>                         https://bugs.openjdk.java.net/browse/JDK-8190281
>>
>>                         JDK 10 Webrev:
>>                         http://cr.openjdk.java.net/~kaddepalli/8190281/webrev00/
>>                         <http://cr.openjdk.java.net/%7Ekaddepalli/8190281/webrev00/>
>>
>>                         This bug was created while root causing
>>                         JDK-8187936, and the following refactoring
>>                         points have been addressed:
>>
>>                         1. Line 927: Uninitialized variables, checking
>>                         for trivial reject case multiple times.
>>                         2. Line 999: Traditional code written to find
>>                         maximum size of components, which can be done
>>                         without any local variables and explicit
>>                         looping by replacing with streams.
>>                         3. Line 1365: Code repetition for differenct
>>                         conditions, which can be ored together to
>>                         reduce the repetition.
>>                         4. Line 1482: A large code block gets repeated
>>                         only because of different values need to be
>>                         passed in one line. This can be moved to a
>>                         variable initialization, and the repeating
>>                         code blocks can be reduced to one.
>>                         5. Line 1505: Variable initialization can be
>>                         simplified by combining different conditions.
>>                         6. Line 1540: An explicit loop to apply a
>>                         function over a collection, can be achieved in
>>                         one line by a forEach construct.? ? This is
>>                         producing some visual artifacts, so ignored.
>>                         7. Line 1747: Combine all the trivial reject
>>                         cases into one condition, and also, a
>>                         potential bug which increments the "nextIndex"
>>                         value beyond the length of the containing
>>                         elements. The increment should happen only if
>>                         the trivial reject case fails.
>>
>>                         Thanks,
>>
>>                         Krishna
>>
> 


-- 
Best regards, Sergey.


From semyon.sadetsky at oracle.com  Tue Dec 19 01:20:11 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Mon, 18 Dec 2017 17:20:11 -0800
Subject: <Swing Dev> [10][JDK-8190281] Code cleanup in
 src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java
In-Reply-To: <19864cc6-d723-4b5d-902f-4623720d5d71@default>
References: <d76a18e3-c363-4159-834f-3ba81aa5a443@default>
 <8ff212fc-7c49-4963-99af-477ac4a0f4e1@default>
 <a7046f27-04f7-ac0d-bec1-fa555a842ec1@oracle.com>
 <e10f0a03-74d4-48da-ac8c-5828147c88ee@default>
 <500d86a0-53dd-645a-eb8b-a74a4511a2d1@oracle.com>
 <d605fbaf-2884-49e4-98fb-6a46e4cd989d@default>
 <133264f1-5e1c-1999-8f9f-a940d8edbe11@oracle.com>
 <6c239b79-9901-4b39-a18f-edbc0f43e013@default>
 <01961a4f-9f7d-ae78-f32e-a2ba7ea9f4c9@oracle.com>
 <02dbfb86-71dd-4813-9624-c6d80e74691e@default>
 <6593bd1e-3f24-3120-37fe-2b2f07288f41@oracle.com>
 <e75fdfb5-2bef-4a62-b895-8054b27c34c2@default>
 <0467651b-d9dd-9e2e-1820-19b4041b53a7@oracle.com>
 <19864cc6-d723-4b5d-902f-4623720d5d71@default>
Message-ID: <1686f2b4-f23b-7718-22d3-346c58ad7efa@oracle.com>

Hi Krishna,

Which tests did you run to ensure that the functionality was not affected?

Can you also remove variables changedParent (478), newNode(479) and 
oldRow (646) since they are unused.

--Semyon


On 12/13/2017 12:42 AM, Krishna Addepalli wrote:
>
> Hi Prasanta,
>
> Here is the webrev with suggested changes: 
> http://cr.openjdk.java.net/~kaddepalli/8190281/webrev05/ 
> <http://cr.openjdk.java.net/%7Ekaddepalli/8190281/webrev05/>
>
> Thanks,
>
> Krishna
>
> *From:*Prasanta Sadhukhan
> *Sent:* Wednesday, December 13, 2017 10:42 AM
> *To:* Krishna Addepalli <krishna.addepalli at oracle.com>; 
> swing-dev at openjdk.java.net
> *Subject:* Re: <Swing Dev> [10][JDK-8190281] Code cleanup in 
> src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java
>
> But there is no compulsion that we need to store getRowCount() in 
> "max". You can store in some other variable and then "max" point to 
> that in the loop.
>
> Regards
> Prasanta
>
> On 12/12/2017 9:51 PM, Krishna Addepalli wrote:
>
>     Hi Prasanta,
>
>     The getRowCount() calls l955,956 cannot be removed, since max
>     variable is getting modified in the while loop at l945. There is
>     no guarantee that max will still hold the getRowCount() after the
>     loop exits. So, those calls cannot be removed.
>
>     Thanks,
>
>     Krishna
>
>     *From:*Prasanta Sadhukhan
>     *Sent:* Tuesday, December 12, 2017 8:08 PM
>     *To:* Krishna Addepalli <krishna.addepalli at oracle.com>
>     <mailto:krishna.addepalli at oracle.com>; swing-dev at openjdk.java.net
>     <mailto:swing-dev at openjdk.java.net>
>     *Subject:* Re: <Swing Dev> [10][JDK-8190281] Code cleanup in
>     src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java
>
>     As told, you overlooked l955,956
>
>     Regards
>     Prasanta
>
>     On 12/12/2017 7:37 PM, Krishna Addepalli wrote:
>
>         Oops! My bad. Created a new webrev here with the correction:
>         http://cr.openjdk.java.net/~kaddepalli/8190281/webrev04/
>         <http://cr.openjdk.java.net/%7Ekaddepalli/8190281/webrev04/>
>
>         *From:*Prasanta Sadhukhan
>         *Sent:* Tuesday, December 12, 2017 7:05 PM
>         *To:* Krishna Addepalli <krishna.addepalli at oracle.com>
>         <mailto:krishna.addepalli at oracle.com>;
>         swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>
>         *Subject:* Re: <Swing Dev> [10][JDK-8190281] Code cleanup in
>         src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java
>
>         You missed using the variable at l933
>
>         Regards
>         Prasanta
>
>         On 12/12/2017 5:21 PM, Krishna Addepalli wrote:
>
>             Hi Prasanta,
>
>             Did the change for caching the result of calling
>             ?getRowCount()? into a variable, as pointed out by you,
>             and here is the new webrev:
>             http://cr.openjdk.java.net/~kaddepalli/8190281/webrev03/
>             <http://cr.openjdk.java.net/%7Ekaddepalli/8190281/webrev03/>
>
>             Thanks,
>
>             Krishna
>
>             *From:*Prasanta Sadhukhan
>             *Sent:* Monday, December 11, 2017 7:24 PM
>             *To:* Krishna Addepalli <krishna.addepalli at oracle.com>
>             <mailto:krishna.addepalli at oracle.com>;
>             swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>
>             *Subject:* Re: <Swing Dev> [10][JDK-8190281] Code cleanup
>             in
>             src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java
>
>             On 12/11/2017 4:16 PM, Krishna Addepalli wrote:
>
>                 Hi Prasanta,
>
>                 Yes, you are right, but as I mentioned earlier, that
>                 would need to make one variable declaration for
>                 caching before trivial reject case, which I wanted to
>                 avoid.
>
>                 As for the body of getRowCount() it is just returning
>                 ?visibleNodes.size()?, which shouldn?t be a
>                 (performance)problem if called 2 times as I understand.
>
>             But, the whole premise of changing getRowCount() <=0? was
>             that it can be overridden and return -ve. Left to present
>             implementation, we would not have needed "less than" check.
>             So, if we are changing one case because of the above
>             reason, then we cannot forego the 2nd case's problem, as
>             it can have any implementation.
>
>             Regards
>             Prasanta
>
>
>
>
>                 Thanks,
>
>                 Krishna
>
>                 *From:*Prasanta Sadhukhan
>                 *Sent:* Monday, December 11, 2017 4:02 PM
>                 *To:* Krishna Addepalli <krishna.addepalli at oracle.com>
>                 <mailto:krishna.addepalli at oracle.com>;
>                 swing-dev at openjdk.java.net
>                 <mailto:swing-dev at openjdk.java.net>
>                 *Subject:* Re: <Swing Dev> [10][JDK-8190281] Code
>                 cleanup in
>                 src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java
>
>                 Hi Krishna,
>
>                 My point was we can call getRowCount() once at first
>                 and store the result and use it subsequently. There
>                 was no need to call it 2-3 times.
>
>                 Regards
>                 Prasanta
>
>                 On 12/11/2017 3:01 PM, Krishna Addepalli wrote:
>
>                     Hi Prasanta,
>
>                     Thanks for pointing out the ?getRowCount()==0?
>                     check. Modified it to ?getRowCount() <= 0? in the
>                     new webrev:
>                     http://cr.openjdk.java.net/~kaddepalli/8190281/webrev02/
>                     <http://cr.openjdk.java.net/%7Ekaddepalli/8190281/webrev02/>
>
>                     As for calling the method twice, you are right
>                     that we don?t need to call it twice, but in the
>                     interest of having trivial reject case first, and
>                     then start the variable declarations, had to let
>                     be there to be called twice. Precisely for the
>                     reason you stated, it shouldn?t matter if we
>                     called it twice.
>
>                     Thanks,
>
>                     Krishna
>
>                     *From:*Prasanta Sadhukhan
>                     *Sent:* Saturday, December 9, 2017 7:54 PM
>                     *To:* Krishna Addepalli
>                     <krishna.addepalli at oracle.com>
>                     <mailto:krishna.addepalli at oracle.com>;
>                     swing-dev at openjdk.java.net
>                     <mailto:swing-dev at openjdk.java.net>
>                     *Subject:* Re: <Swing Dev> [10][JDK-8190281] Code
>                     cleanup in
>                     src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java
>
>                     Hi Krishna,
>
>                     This seems good to me except one thing. You are
>                     checking getRowCount() == 0 but there is a chance
>                     of test extending VariableHeightLayoutCache and
>                     overriding getRowCount to return -ve also as it is
>                     an int. In that case, I guess this function will
>                     not return -1 which spec mandates [If there are no
>                     rows, -1 is returned] so I guess we should check
>                     for <=0.
>                     Also, there is no need of calling getRowCount()
>                     twice as it will not change between 929, 936.
>
>                     Regards
>                     Prasanta
>
>                     On 12/7/2017 4:41 PM, Krishna Addepalli wrote:
>
>                         Hi Sergey,
>
>                         Per our conversation, I have done the
>                         following changes:
>
>                         1.Found that the .class size increases by 1kb
>                         when streams are used, so reverted the changes
>                         related to it.
>
>                         2.Moved the ?++nextIndex? into the
>                         conditional, so that there is no logical change.
>
>                         Here is the updated webrev:
>                         http://cr.openjdk.java.net/~kaddepalli/8190281/webrev01/
>                         <http://cr.openjdk.java.net/%7Ekaddepalli/8190281/webrev01/>
>
>                         Thanks,
>
>                         Krishna
>
>                         *From:* Krishna Addepalli
>                         *Sent:* Wednesday, December 6, 2017 2:43 PM
>                         *To:* swing-dev at openjdk.java.net
>                         <mailto:swing-dev at openjdk.java.net>
>                         *Subject:* [10][JDK-8190281] Code cleanup in
>                         src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java
>
>                         Hi All,
>
>                         Please review the fix for bug:
>
>                         Bug: JDK-8190281
>                         https://bugs.openjdk.java.net/browse/JDK-8190281
>
>                         JDK 10 Webrev:
>                         http://cr.openjdk.java.net/~kaddepalli/8190281/webrev00/
>                         <http://cr.openjdk.java.net/%7Ekaddepalli/8190281/webrev00/>
>
>                         This bug was created while root causing
>                         JDK-8187936, and the following refactoring
>                         points have been addressed:
>
>                         1. Line 927: Uninitialized variables, checking
>                         for trivial reject case multiple times.
>                         2. Line 999: Traditional code written to find
>                         maximum size of components, which can be done
>                         without any local variables and explicit
>                         looping by replacing with streams.
>                         3. Line 1365: Code repetition for differenct
>                         conditions, which can be ored together to
>                         reduce the repetition.
>                         4. Line 1482: A large code block gets repeated
>                         only because of different values need to be
>                         passed in one line. This can be moved to a
>                         variable initialization, and the repeating
>                         code blocks can be reduced to one.
>                         5. Line 1505: Variable initialization can be
>                         simplified by combining different conditions.
>                         6. Line 1540: An explicit loop to apply a
>                         function over a collection, can be achieved in
>                         one line by a forEach construct.? ? This is
>                         producing some visual artifacts, so ignored.
>                         7. Line 1747: Combine all the trivial reject
>                         cases into one condition, and also, a
>                         potential bug which increments the "nextIndex"
>                         value beyond the length of the containing
>                         elements. The increment should happen only if
>                         the trivial reject case fails.
>
>                         Thanks,
>
>                         Krishna
>

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

From semyon.sadetsky at oracle.com  Tue Dec 19 01:52:19 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Mon, 18 Dec 2017 17:52:19 -0800
Subject: <Swing Dev> [11] Review Request: 6684386 ElementIterator
 javadoc bug
In-Reply-To: <dff2a488-612e-ceec-9bf2-cb66ae09fe23@oracle.com>
References: <dff2a488-612e-ceec-9bf2-cb66ae09fe23@oracle.com>
Message-ID: <6da4eafa-5ec4-6679-c8b1-3ca25a27944b@oracle.com>

Hi Sergey,

Please, surround with <blockquote> the code sample.

All references like

* ...if {@code next()} is called before...

better to replace with

* ...if {@link #next()} is called before...

--Semyon

On 12/18/2017 03:28 PM, Sergey Bylokhov wrote:
> Hello.
> Please review the fix for jdk11.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-6684386
> Webrev can be found at: 
> http://cr.openjdk.java.net/~serb/6684386/webrev.00
> Specdiff: 
> http://cr.openjdk.java.net/~serb/6684386/specdiff.00/javax/swing/text/ElementIterator.html
>
> Description of the javadoc changes:
> ?- <pre> tag is added for the code in the example
> ?- the typo in the code was fixed(it.next(")
> ?- <ul> tag is added for the list
> ?- The rest of the file was updated to use a styles used in the 
> previous javadoc related fixes.
>



From Sergey.Bylokhov at oracle.com  Tue Dec 19 04:20:19 2017
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 18 Dec 2017 20:20:19 -0800
Subject: <Swing Dev> [11] Review Request: 6684386 ElementIterator
 javadoc bug
In-Reply-To: <6da4eafa-5ec4-6679-c8b1-3ca25a27944b@oracle.com>
References: <dff2a488-612e-ceec-9bf2-cb66ae09fe23@oracle.com>
 <6da4eafa-5ec4-6679-c8b1-3ca25a27944b@oracle.com>
Message-ID: <fca8bae2-3781-d596-f4d4-09ed78e1d6f2@oracle.com>

Hi, Semyon.
On 18/12/2017 17:52, Semyon Sadetsky wrote:
> Please, surround with <blockquote> the code sample.

Why <blockquote> should be used since an example is not a "quote" but 
contains code? I guess <pre>{@code} should be enough.

> 
> All references like
> 
> * ...if {@code next()} is called before...
> 
> better to replace with
> 
> * ...if {@link #next()} is called before...

It always confused me when to use @link instead of @code. Currently I 
use @code everywhere except the place where I write something like
"Please see {@link java.beans.XMLEncoder}."
or something like
"Refer to {@link #setValueContainsLiteralCharacters} for details"

In other words @link is necessary when the description of referred 
object has some additional information. Otherwise we had to use @link 
instead of @code everywhere.

> 
> --Semyon
> 
> On 12/18/2017 03:28 PM, Sergey Bylokhov wrote:
>> Hello.
>> Please review the fix for jdk11.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-6684386
>> Webrev can be found at: 
>> http://cr.openjdk.java.net/~serb/6684386/webrev.00
>> Specdiff: 
>> http://cr.openjdk.java.net/~serb/6684386/specdiff.00/javax/swing/text/ElementIterator.html 
>>
>>
>> Description of the javadoc changes:
>> ?- <pre> tag is added for the code in the example
>> ?- the typo in the code was fixed(it.next(")
>> ?- <ul> tag is added for the list
>> ?- The rest of the file was updated to use a styles used in the 
>> previous javadoc related fixes.
>>
> 


-- 
Best regards, Sergey.


From krishna.addepalli at oracle.com  Tue Dec 19 08:46:11 2017
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Tue, 19 Dec 2017 00:46:11 -0800 (PST)
Subject: <Swing Dev> [10][JDK-8190281] Code cleanup in
 src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java
In-Reply-To: <1686f2b4-f23b-7718-22d3-346c58ad7efa@oracle.com>
References: <d76a18e3-c363-4159-834f-3ba81aa5a443@default>
 <8ff212fc-7c49-4963-99af-477ac4a0f4e1@default>
 <a7046f27-04f7-ac0d-bec1-fa555a842ec1@oracle.com>
 <e10f0a03-74d4-48da-ac8c-5828147c88ee@default>
 <500d86a0-53dd-645a-eb8b-a74a4511a2d1@oracle.com>
 <d605fbaf-2884-49e4-98fb-6a46e4cd989d@default>
 <133264f1-5e1c-1999-8f9f-a940d8edbe11@oracle.com>
 <6c239b79-9901-4b39-a18f-edbc0f43e013@default>
 <01961a4f-9f7d-ae78-f32e-a2ba7ea9f4c9@oracle.com>
 <02dbfb86-71dd-4813-9624-c6d80e74691e@default>
 <6593bd1e-3f24-3120-37fe-2b2f07288f41@oracle.com>
 <e75fdfb5-2bef-4a62-b895-8054b27c34c2@default>
 <0467651b-d9dd-9e2e-1820-19b4041b53a7@oracle.com>
 <19864cc6-d723-4b5d-902f-4623720d5d71@default>
 <1686f2b4-f23b-7718-22d3-346c58ad7efa@oracle.com>
Message-ID: <9490043a-ead7-4278-ab44-6c633ca53a7f@default>

Hi Semyon,

 

I have run the tests under JTree and made sure that the same number of tests passed before and after my changes. 

 

Thank you for pointing out additional places to clean up, I have done some additional changes:

1.       Removed the variables as pointed out.

2.       Changed the traditional for loop into a range based loop.

3.       Initialize the variables at the point of declaration in lines 412, 413, 459,460 and 468.

Here is the updated webrev: http://cr.openjdk.java.net/~kaddepalli/8190281/webrev06/

 

Thanks,

Krishna

From: Semyon Sadetsky 
Sent: Tuesday, December 19, 2017 6:50 AM
To: Krishna Addepalli <krishna.addepalli at oracle.com>; swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10][JDK-8190281] Code cleanup in src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java

 

Hi Krishna,

Which tests did you run to ensure that the functionality was not affected?

Can you also remove variables changedParent (478), newNode(479) and oldRow (646) since they are unused. 

--Semyon

 

On 12/13/2017 12:42 AM, Krishna Addepalli wrote:

Hi Prasanta,

 

Here is the webrev with suggested changes:  HYPERLINK "http://cr.openjdk.java.net/%7Ekaddepalli/8190281/webrev05/"http://cr.openjdk.java.net/~kaddepalli/8190281/webrev05/

 

Thanks,

Krishna

 

From: Prasanta Sadhukhan 
Sent: Wednesday, December 13, 2017 10:42 AM
To: Krishna Addepalli HYPERLINK "mailto:krishna.addepalli at oracle.com"<krishna.addepalli at oracle.com>; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10][JDK-8190281] Code cleanup in src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java

 

But there is no compulsion that we need to store getRowCount() in "max". You can store in some other variable and then "max" point to that in the loop.

Regards
Prasanta

On 12/12/2017 9:51 PM, Krishna Addepalli wrote:

Hi Prasanta,

 

The getRowCount() calls l955,956 cannot be removed, since max variable is getting modified in the while loop at l945. There is no guarantee that max will still hold the getRowCount() after the loop exits. So, those calls cannot be removed.

 

Thanks,

Krishna

 

From: Prasanta Sadhukhan 
Sent: Tuesday, December 12, 2017 8:08 PM
To: Krishna Addepalli HYPERLINK "mailto:krishna.addepalli at oracle.com"<krishna.addepalli at oracle.com>; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10][JDK-8190281] Code cleanup in src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java

 

As told, you overlooked l955,956

Regards
Prasanta

On 12/12/2017 7:37 PM, Krishna Addepalli wrote:

Oops! My bad. Created a new webrev here with the correction: HYPERLINK "http://cr.openjdk.java.net/%7Ekaddepalli/8190281/webrev04/"http://cr.openjdk.java.net/~kaddepalli/8190281/webrev04/

 

From: Prasanta Sadhukhan 
Sent: Tuesday, December 12, 2017 7:05 PM
To: Krishna Addepalli HYPERLINK "mailto:krishna.addepalli at oracle.com"<krishna.addepalli at oracle.com>; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10][JDK-8190281] Code cleanup in src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java

 

You missed using the variable at l933

Regards
Prasanta

On 12/12/2017 5:21 PM, Krishna Addepalli wrote:

Hi Prasanta,

 

Did the change for caching the result of calling "getRowCount()" into a variable, as pointed out by you, and here is the new webrev: HYPERLINK "http://cr.openjdk.java.net/%7Ekaddepalli/8190281/webrev03/"http://cr.openjdk.java.net/~kaddepalli/8190281/webrev03/

 

Thanks,

Krishna

 

From: Prasanta Sadhukhan 
Sent: Monday, December 11, 2017 7:24 PM
To: Krishna Addepalli HYPERLINK "mailto:krishna.addepalli at oracle.com"<krishna.addepalli at oracle.com>; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10][JDK-8190281] Code cleanup in src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java

 

 

 

On 12/11/2017 4:16 PM, Krishna Addepalli wrote:

Hi Prasanta,

 

Yes, you are right, but as I mentioned earlier, that would need to make one variable declaration for caching before trivial reject case, which I wanted to avoid.

As for the body of getRowCount() it is just returning "visibleNodes.size()", which shouldn't be a (performance)problem if called 2 times as I understand.

But, the whole premise of changing getRowCount() <=0  was that it can be overridden and return -ve. Left to present implementation, we would not have needed "less than" check. 
So, if we are changing one case because of the above reason, then we cannot forego the 2nd case's problem, as it can have any implementation.

Regards
Prasanta







 

Thanks,

Krishna

 

From: Prasanta Sadhukhan 
Sent: Monday, December 11, 2017 4:02 PM
To: Krishna Addepalli HYPERLINK "mailto:krishna.addepalli at oracle.com"<krishna.addepalli at oracle.com>; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10][JDK-8190281] Code cleanup in src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java

 

Hi Krishna,

My point was we can call getRowCount() once at first and store the result and use it subsequently. There was no need to call it 2-3 times.

Regards
Prasanta

On 12/11/2017 3:01 PM, Krishna Addepalli wrote:

Hi Prasanta,

 

Thanks for pointing out the "getRowCount()==0" check. Modified it to "getRowCount() <= 0" in the new webrev: HYPERLINK "http://cr.openjdk.java.net/%7Ekaddepalli/8190281/webrev02/"http://cr.openjdk.java.net/~kaddepalli/8190281/webrev02/

 

As for calling the method twice, you are right that we don't need to call it twice, but in the interest of having trivial reject case first, and then start the variable declarations, had to let be there to be called twice. Precisely for the reason you stated, it shouldn't matter if we called it twice.

 

Thanks,

Krishna

 

From: Prasanta Sadhukhan 
Sent: Saturday, December 9, 2017 7:54 PM
To: Krishna Addepalli HYPERLINK "mailto:krishna.addepalli at oracle.com"<krishna.addepalli at oracle.com>; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [10][JDK-8190281] Code cleanup in src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java

 

Hi Krishna,

This seems good to me except one thing. You are checking getRowCount() == 0 but there is a chance of test extending VariableHeightLayoutCache and overriding getRowCount to return -ve also as it is an int. In that case, I guess this function will not return -1 which spec mandates [If there are no rows, -1 is returned] so I guess we should check for <=0. 
Also, there is no need of calling getRowCount() twice as it will not change between 929, 936.

Regards
Prasanta

On 12/7/2017 4:41 PM, Krishna Addepalli wrote:

Hi Sergey,

 

Per our conversation, I have done the following changes:

1.       Found that the .class size increases by 1kb when streams are used, so reverted the changes related to it.

2.       Moved the "++nextIndex" into the conditional, so that there is no logical change.

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

 

Thanks,

Krishna

 

From: Krishna Addepalli 
Sent: Wednesday, December 6, 2017 2:43 PM
To: HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net
Subject: [10][JDK-8190281] Code cleanup in src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java

 

Hi All,

 

Please review the fix for bug:

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

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

 

This bug was created while root causing JDK-8187936, and the following refactoring points have been addressed:

 

1. Line 927: Uninitialized variables, checking for trivial reject case multiple times. 
2. Line 999: Traditional code written to find maximum size of components, which can be done without any local variables and explicit looping by replacing with streams. 
3. Line 1365: Code repetition for differenct conditions, which can be ored together to reduce the repetition. 
4. Line 1482: A large code block gets repeated only because of different values need to be passed in one line. This can be moved to a variable initialization, and the repeating code blocks can be reduced to one. 
5. Line 1505: Variable initialization can be simplified by combining different conditions. 
6. Line 1540: An explicit loop to apply a function over a collection, can be achieved in one line by a forEach construct.  - This is producing some visual artifacts, so ignored.
7. Line 1747: Combine all the trivial reject cases into one condition, and also, a potential bug which increments the "nextIndex" value beyond the length of the containing elements. The increment should happen only if the trivial reject case fails.

 

Thanks,

Krishna

 

 

 

 

 

 

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

From semyon.sadetsky at oracle.com  Tue Dec 19 16:22:38 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Tue, 19 Dec 2017 08:22:38 -0800
Subject: <Swing Dev> [11] Review Request: 6684386 ElementIterator
 javadoc bug
In-Reply-To: <fca8bae2-3781-d596-f4d4-09ed78e1d6f2@oracle.com>
References: <dff2a488-612e-ceec-9bf2-cb66ae09fe23@oracle.com>
 <6da4eafa-5ec4-6679-c8b1-3ca25a27944b@oracle.com>
 <fca8bae2-3781-d596-f4d4-09ed78e1d6f2@oracle.com>
Message-ID: <18d40438-b6b2-089e-e13a-b1152ff88fff@oracle.com>

On 12/18/2017 08:20 PM, Sergey Bylokhov wrote:

> Hi, Semyon.
> On 18/12/2017 17:52, Semyon Sadetsky wrote:
>> Please, surround with <blockquote> the code sample.
>
> Why <blockquote> should be used since an example is not a "quote" but 
> contains code? I guess <pre>{@code} should be enough.
This is just a good practice to separate a code snippet from the rest of 
text in javadoc.
>
>>
>> All references like
>>
>> * ...if {@code next()} is called before...
>>
>> better to replace with
>>
>> * ...if {@link #next()} is called before...
>
> It always confused me when to use @link instead of @code. Currently I 
> use @code everywhere except the place where I write something like
> "Please see {@link java.beans.XMLEncoder}."
> or something like
> "Refer to {@link #setValueContainsLiteralCharacters} for details"
>
> In other words @link is necessary when the description of referred 
> object has some additional information. Otherwise we had to use @link 
> instead of @code everywhere.
I suggest to take care about readers. In this specific case it is hard 
to realize a phrase like

..if next() is called before first() or current() the root will be 
returned..

in the class specification without knowledge what are those next(), 
first() and current().
>
>
>>
>> --Semyon
>>
>> On 12/18/2017 03:28 PM, Sergey Bylokhov wrote:
>>> Hello.
>>> Please review the fix for jdk11.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6684386
>>> Webrev can be found at: 
>>> http://cr.openjdk.java.net/~serb/6684386/webrev.00
>>> Specdiff: 
>>> http://cr.openjdk.java.net/~serb/6684386/specdiff.00/javax/swing/text/ElementIterator.html 
>>>
>>>
>>> Description of the javadoc changes:
>>> ?- <pre> tag is added for the code in the example
>>> ?- the typo in the code was fixed(it.next(")
>>> ?- <ul> tag is added for the list
>>> ?- The rest of the file was updated to use a styles used in the 
>>> previous javadoc related fixes.
>>>
>>
>
>



From semyon.sadetsky at oracle.com  Tue Dec 19 16:32:28 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Tue, 19 Dec 2017 08:32:28 -0800
Subject: <Swing Dev> [10][JDK-8190281] Code cleanup in
 src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java
In-Reply-To: <9490043a-ead7-4278-ab44-6c633ca53a7f@default>
References: <d76a18e3-c363-4159-834f-3ba81aa5a443@default>
 <8ff212fc-7c49-4963-99af-477ac4a0f4e1@default>
 <a7046f27-04f7-ac0d-bec1-fa555a842ec1@oracle.com>
 <e10f0a03-74d4-48da-ac8c-5828147c88ee@default>
 <500d86a0-53dd-645a-eb8b-a74a4511a2d1@oracle.com>
 <d605fbaf-2884-49e4-98fb-6a46e4cd989d@default>
 <133264f1-5e1c-1999-8f9f-a940d8edbe11@oracle.com>
 <6c239b79-9901-4b39-a18f-edbc0f43e013@default>
 <01961a4f-9f7d-ae78-f32e-a2ba7ea9f4c9@oracle.com>
 <02dbfb86-71dd-4813-9624-c6d80e74691e@default>
 <6593bd1e-3f24-3120-37fe-2b2f07288f41@oracle.com>
 <e75fdfb5-2bef-4a62-b895-8054b27c34c2@default>
 <0467651b-d9dd-9e2e-1820-19b4041b53a7@oracle.com>
 <19864cc6-d723-4b5d-902f-4623720d5d71@default>
 <1686f2b4-f23b-7718-22d3-346c58ad7efa@oracle.com>
 <9490043a-ead7-4278-ab44-6c633ca53a7f@default>
Message-ID: <f3997775-605e-5a9d-1093-e150846cddab@oracle.com>

Looks good to me.

--Semyon


On 12/19/2017 12:46 AM, Krishna Addepalli wrote:
>
> Hi Semyon,
>
> I have run the tests under JTree and made sure that the same number of 
> tests passed before and after my changes.
>
> Thank you for pointing out additional places to clean up, I have done 
> some additional changes:
>
> 1.Removed the variables as pointed out.
>
> 2.Changed the traditional for loop into a range based loop.
>
> 3.Initialize the variables at the point of declaration in lines 412, 
> 413, 459,460 and 468.
>
> Here is the updated webrev: 
> http://cr.openjdk.java.net/~kaddepalli/8190281/webrev06/ 
> <http://cr.openjdk.java.net/%7Ekaddepalli/8190281/webrev06/>
>
> Thanks,
>
> Krishna
>
> *From:*Semyon Sadetsky
> *Sent:* Tuesday, December 19, 2017 6:50 AM
> *To:* Krishna Addepalli <krishna.addepalli at oracle.com>; 
> swing-dev at openjdk.java.net
> *Subject:* Re: <Swing Dev> [10][JDK-8190281] Code cleanup in 
> src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java
>
> Hi Krishna,
>
> Which tests did you run to ensure that the functionality was not affected?
>
> Can you also remove variables changedParent (478), newNode(479) and 
> oldRow (646) since they are unused.
>
> --Semyon
>
> On 12/13/2017 12:42 AM, Krishna Addepalli wrote:
>
>     Hi Prasanta,
>
>     Here is the webrev with suggested changes:
>     http://cr.openjdk.java.net/~kaddepalli/8190281/webrev05/
>     <http://cr.openjdk.java.net/%7Ekaddepalli/8190281/webrev05/>
>
>     Thanks,
>
>     Krishna
>
>     *From:*Prasanta Sadhukhan
>     *Sent:* Wednesday, December 13, 2017 10:42 AM
>     *To:* Krishna Addepalli <krishna.addepalli at oracle.com>
>     <mailto:krishna.addepalli at oracle.com>; swing-dev at openjdk.java.net
>     <mailto:swing-dev at openjdk.java.net>
>     *Subject:* Re: <Swing Dev> [10][JDK-8190281] Code cleanup in
>     src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java
>
>     But there is no compulsion that we need to store getRowCount() in
>     "max". You can store in some other variable and then "max" point
>     to that in the loop.
>
>     Regards
>     Prasanta
>
>     On 12/12/2017 9:51 PM, Krishna Addepalli wrote:
>
>         Hi Prasanta,
>
>         The getRowCount() calls l955,956 cannot be removed, since max
>         variable is getting modified in the while loop at l945. There
>         is no guarantee that max will still hold the getRowCount()
>         after the loop exits. So, those calls cannot be removed.
>
>         Thanks,
>
>         Krishna
>
>         *From:*Prasanta Sadhukhan
>         *Sent:* Tuesday, December 12, 2017 8:08 PM
>         *To:* Krishna Addepalli <krishna.addepalli at oracle.com>
>         <mailto:krishna.addepalli at oracle.com>;
>         swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>
>         *Subject:* Re: <Swing Dev> [10][JDK-8190281] Code cleanup in
>         src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java
>
>         As told, you overlooked l955,956
>
>         Regards
>         Prasanta
>
>         On 12/12/2017 7:37 PM, Krishna Addepalli wrote:
>
>             Oops! My bad. Created a new webrev here with the
>             correction:
>             http://cr.openjdk.java.net/~kaddepalli/8190281/webrev04/
>             <http://cr.openjdk.java.net/%7Ekaddepalli/8190281/webrev04/>
>
>             *From:*Prasanta Sadhukhan
>             *Sent:* Tuesday, December 12, 2017 7:05 PM
>             *To:* Krishna Addepalli <krishna.addepalli at oracle.com>
>             <mailto:krishna.addepalli at oracle.com>;
>             swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>
>             *Subject:* Re: <Swing Dev> [10][JDK-8190281] Code cleanup
>             in
>             src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java
>
>             You missed using the variable at l933
>
>             Regards
>             Prasanta
>
>             On 12/12/2017 5:21 PM, Krishna Addepalli wrote:
>
>                 Hi Prasanta,
>
>                 Did the change for caching the result of calling
>                 ?getRowCount()? into a variable, as pointed out by
>                 you, and here is the new webrev:
>                 http://cr.openjdk.java.net/~kaddepalli/8190281/webrev03/
>                 <http://cr.openjdk.java.net/%7Ekaddepalli/8190281/webrev03/>
>
>                 Thanks,
>
>                 Krishna
>
>                 *From:*Prasanta Sadhukhan
>                 *Sent:* Monday, December 11, 2017 7:24 PM
>                 *To:* Krishna Addepalli <krishna.addepalli at oracle.com>
>                 <mailto:krishna.addepalli at oracle.com>;
>                 swing-dev at openjdk.java.net
>                 <mailto:swing-dev at openjdk.java.net>
>                 *Subject:* Re: <Swing Dev> [10][JDK-8190281] Code
>                 cleanup in
>                 src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java
>
>                 On 12/11/2017 4:16 PM, Krishna Addepalli wrote:
>
>                     Hi Prasanta,
>
>                     Yes, you are right, but as I mentioned earlier,
>                     that would need to make one variable declaration
>                     for caching before trivial reject case, which I
>                     wanted to avoid.
>
>                     As for the body of getRowCount() it is just
>                     returning ?visibleNodes.size()?, which shouldn?t
>                     be a (performance)problem if called 2 times as I
>                     understand.
>
>                 But, the whole premise of changing getRowCount() <=0?
>                 was that it can be overridden and return -ve. Left to
>                 present implementation, we would not have needed "less
>                 than" check.
>                 So, if we are changing one case because of the above
>                 reason, then we cannot forego the 2nd case's problem,
>                 as it can have any implementation.
>
>                 Regards
>                 Prasanta
>
>
>
>
>
>                     Thanks,
>
>                     Krishna
>
>                     *From:*Prasanta Sadhukhan
>                     *Sent:* Monday, December 11, 2017 4:02 PM
>                     *To:* Krishna Addepalli
>                     <krishna.addepalli at oracle.com>
>                     <mailto:krishna.addepalli at oracle.com>;
>                     swing-dev at openjdk.java.net
>                     <mailto:swing-dev at openjdk.java.net>
>                     *Subject:* Re: <Swing Dev> [10][JDK-8190281] Code
>                     cleanup in
>                     src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java
>
>                     Hi Krishna,
>
>                     My point was we can call getRowCount() once at
>                     first and store the result and use it
>                     subsequently. There was no need to call it 2-3 times.
>
>                     Regards
>                     Prasanta
>
>                     On 12/11/2017 3:01 PM, Krishna Addepalli wrote:
>
>                         Hi Prasanta,
>
>                         Thanks for pointing out the ?getRowCount()==0?
>                         check. Modified it to ?getRowCount() <= 0? in
>                         the new webrev:
>                         http://cr.openjdk.java.net/~kaddepalli/8190281/webrev02/
>                         <http://cr.openjdk.java.net/%7Ekaddepalli/8190281/webrev02/>
>
>                         As for calling the method twice, you are right
>                         that we don?t need to call it twice, but in
>                         the interest of having trivial reject case
>                         first, and then start the variable
>                         declarations, had to let be there to be called
>                         twice. Precisely for the reason you stated, it
>                         shouldn?t matter if we called it twice.
>
>                         Thanks,
>
>                         Krishna
>
>                         *From:*Prasanta Sadhukhan
>                         *Sent:* Saturday, December 9, 2017 7:54 PM
>                         *To:* Krishna Addepalli
>                         <krishna.addepalli at oracle.com>
>                         <mailto:krishna.addepalli at oracle.com>;
>                         swing-dev at openjdk.java.net
>                         <mailto:swing-dev at openjdk.java.net>
>                         *Subject:* Re: <Swing Dev> [10][JDK-8190281]
>                         Code cleanup in
>                         src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java
>
>                         Hi Krishna,
>
>                         This seems good to me except one thing. You
>                         are checking getRowCount() == 0 but there is a
>                         chance of test extending
>                         VariableHeightLayoutCache and overriding
>                         getRowCount to return -ve also as it is an
>                         int. In that case, I guess this function will
>                         not return -1 which spec mandates [If there
>                         are no rows, -1 is returned] so I guess we
>                         should check for <=0.
>                         Also, there is no need of calling
>                         getRowCount() twice as it will not change
>                         between 929, 936.
>
>                         Regards
>                         Prasanta
>
>                         On 12/7/2017 4:41 PM, Krishna Addepalli wrote:
>
>                             Hi Sergey,
>
>                             Per our conversation, I have done the
>                             following changes:
>
>                             1.Found that the .class size increases by
>                             1kb when streams are used, so reverted the
>                             changes related to it.
>
>                             2.Moved the ?++nextIndex? into the
>                             conditional, so that there is no logical
>                             change.
>
>                             Here is the updated webrev:
>                             http://cr.openjdk.java.net/~kaddepalli/8190281/webrev01/
>                             <http://cr.openjdk.java.net/%7Ekaddepalli/8190281/webrev01/>
>
>                             Thanks,
>
>                             Krishna
>
>                             *From:* Krishna Addepalli
>                             *Sent:* Wednesday, December 6, 2017 2:43 PM
>                             *To:* swing-dev at openjdk.java.net
>                             <mailto:swing-dev at openjdk.java.net>
>                             *Subject:* [10][JDK-8190281] Code cleanup
>                             in
>                             src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java
>
>                             Hi All,
>
>                             Please review the fix for bug:
>
>                             Bug: JDK-8190281
>                             https://bugs.openjdk.java.net/browse/JDK-8190281
>
>                             JDK 10 Webrev:
>                             http://cr.openjdk.java.net/~kaddepalli/8190281/webrev00/
>                             <http://cr.openjdk.java.net/%7Ekaddepalli/8190281/webrev00/>
>
>                             This bug was created while root causing
>                             JDK-8187936, and the following refactoring
>                             points have been addressed:
>
>                             1. Line 927: Uninitialized variables,
>                             checking for trivial reject case multiple
>                             times.
>                             2. Line 999: Traditional code written to
>                             find maximum size of components, which can
>                             be done without any local variables and
>                             explicit looping by replacing with streams.
>                             3. Line 1365: Code repetition for
>                             differenct conditions, which can be ored
>                             together to reduce the repetition.
>                             4. Line 1482: A large code block gets
>                             repeated only because of different values
>                             need to be passed in one line. This can be
>                             moved to a variable initialization, and
>                             the repeating code blocks can be reduced
>                             to one.
>                             5. Line 1505: Variable initialization can
>                             be simplified by combining different
>                             conditions.
>                             6. Line 1540: An explicit loop to apply a
>                             function over a collection, can be
>                             achieved in one line by a forEach
>                             construct.? ? This is producing some
>                             visual artifacts, so ignored.
>                             7. Line 1747: Combine all the trivial
>                             reject cases into one condition, and also,
>                             a potential bug which increments the
>                             "nextIndex" value beyond the length of the
>                             containing elements. The increment should
>                             happen only if the trivial reject case fails.
>
>                             Thanks,
>
>                             Krishna
>

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

From manajit.halder at oracle.com  Mon Dec 25 10:42:06 2017
From: manajit.halder at oracle.com (Manajit Halder)
Date: Mon, 25 Dec 2017 16:12:06 +0530
Subject: <Swing Dev> Swing dev>[10] Review request for JDK-8189253:
 [macos] JPopupMenu is inadvertently shown when using setComponentPopupMenu
In-Reply-To: <4ed5cbcf-c1f7-f615-6404-ebe13c47b8da@oracle.com>
References: <E1445698-445B-4542-98C1-1D82A4A182C9@oracle.com>
 <4ed5cbcf-c1f7-f615-6404-ebe13c47b8da@oracle.com>
Message-ID: <C77A97FC-2163-455F-847D-C590D3B5D522@oracle.com>

Hi Semyon,

Regression is cause by JDK-8080729 <https://bugs.openjdk.java.net/browse/JDK-8080729>. The fix can?t be reversed since it is the choice between addChildWindow or orderWindow. Went through code flow related to the issue but didn?t find any other better place in code to handle this issue. The best way to fix the issue would be to avoid retargeting of events (MOUSE_ENTER and MOUSE_EXIT) between MOUSE_PRESS and MOUSE_RELEASE on the parent window (when the mouse is actually on the child window). Therefore request you to review the webrev.00.

Regards,
Manajit

> On 08-Dec-2017, at 9:55 PM, semyon.sadetsky at oracle.com wrote:
> 
> Hi Manajit,
> 
> Can you provide information which fix caused the regression?
> 
> --Semyon
> 
> On 12/8/17 5:53 AM, Manajit Halder wrote:
>> Hi All,
>> 
>> Kindly review the following Swing fix.
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8189253 <https://bugs.openjdk.java.net/browse/JDK-8189253>
>> Webrev: http://cr.openjdk.java.net/~mhalder/8189253/webrev.00/ <http://cr.openjdk.java.net/%7Emhalder/8189253/webrev.00/>
>> 
>> Cause: 
>> 	Issue was due to retargeting of mouse enter exit events. 
>> 	MOUSE_ENTER and MOUSE_EXIT events were sent on the parent window (JFrame) in between MOUSE_PRESS and MOUSE_RELEASE events on the modeless JDialog.
>> 
>> Fix:
>> 	Retargeting of events is not done in-between MOUSE_PRESS and MOUSE_RELEASE.
>> 
>> Regards,
>> Manajit
>> 
> 

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

From reinhard.pointner at gmail.com  Mon Dec 18 18:56:47 2017
From: reinhard.pointner at gmail.com (Reinhard Pointner)
Date: Mon, 18 Dec 2017 18:56:47 -0000
Subject: <Swing Dev> =?utf-8?b?4oCcU3dpbmctU2hlbGzigJ0gamF2YS5sYW5nLklu?=
	=?utf-8?q?ternalError=3A_Could_not_initialize_COM=3A_HRESULT=3D0x8?=
	=?utf-8?q?0010106?=
Message-ID: <CAFUKpKBuAOeCEtGEScCRdf1s4d5O1oxkuDJf-1nGNbi8FQRHTw@mail.gmail.com>

Dear Java Swing team,

I'm trying to package a Java 9 Swing application for the Microsoft Store to
deploy the app to Windows 10 and Windows 10 S machines.

There does seem to be an issue with COM when and only when running the Java
application inside a APPX container.

Does anybody here have any clue on how to figure this one out?

There's additional information and a test case on stackoverflow:
https://stackoverflow.com/questions/46918448/swing-shell-java-lang-internalerror-could-not-initialize-com-hresult-0x80010

Kind Regards,
Reinhard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20171218/9442f89a/attachment.html>