 elements for instructions on how to disable 
the shortcut is incorrect. In fact, it does not require any special markup.

What about this text?
Some client UI tests devoted to tooltips may fail on macOS platform. 
The tests use Ctrl +F1 key sequence to 
show/hide a tooltip. However, this key combination is reserved by the 
operating system. To run these tests correctly, the default global 
shortcut should be disabled: choose Apple menu > System Preferences, 
click Keyboard, then click Shortcuts; deselect "Turn keyboard access 
on/of" property.

I copied the way Apple uses in its documentation to refer to commands.

On 25/10/2019 11:27, Dmitry Markov wrote:
> Hello,
>
> Could you review the fix for jdk14, please?
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8232880
> webrev: http://cr.openjdk.java.net/~dmarkov/8232880/webrev.00/
>
> Some Client UI tests use the following key sequence to show/hide 
> tooltip message: ?CTRL? + ?F1". However this key combination is 
> reserved by operating system on OS X platform. As a results the tests 
> fail.
> Test documentation should be updated with some notes regarding this.
>
> Thanks,
> Dmitry
>

[1] https://www.w3.org/TR/html52/textlevel-semantics.html#the-kbd-element

-- 
Regards,
Alexey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From erik.joelsson at oracle.com  Fri Oct 25 15:52:54 2019
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 25 Oct 2019 08:52:54 -0700
Subject:   RFR 8232880: Update test documentation
 with additional settings for client UI tooltip tests
In-Reply-To: 
References: <5096E196-8A4F-4A6A-A419-F9FFF7D59A0D@oracle.com>

Message-ID: 

On 2019-10-25 08:42, Alexey Ivanov wrote:
> Hi Dmitry,
>
> Apple uses macOS to refer to its operating system, so should we also 
> use it instead of former OS X?
>
> For HTML version, I would suggest using the following markup 
> Ctrl +F1 for the keyboard shortcut. [1]
>
The HTML is generated from the markup and should not be edited by hand.

/Erik

> I think using 
 elements for instructions on how to disable 
> the shortcut is incorrect. In fact, it does not require any special 
> markup.
>
>
> What about this text?
> Some client UI tests devoted to tooltips may fail on macOS 
> platform. The tests use Ctrl +F1 key 
> sequence to show/hide a tooltip. However, this key combination is 
> reserved by the operating system. To run these tests correctly, the 
> default global shortcut should be disabled: choose Apple menu > 
> System Preferences, click Keyboard, then click Shortcuts; deselect 
> "Turn keyboard access on/of" property.

>
> I copied the way Apple uses in its documentation to refer to commands.
>
> On 25/10/2019 11:27, Dmitry Markov wrote:
>> Hello,
>>
>> Could you review the fix for jdk14, please?
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8232880
>> webrev: http://cr.openjdk.java.net/~dmarkov/8232880/webrev.00/
>>
>> Some Client UI tests use the following key sequence to show/hide 
>> tooltip message: ?CTRL? + ?F1". However this key combination is 
>> reserved by operating system on OS X platform. As a results the tests 
>> fail.
>> Test documentation should be updated with some notes regarding this.
>>
>> Thanks,
>> Dmitry
>>
>
> [1] https://www.w3.org/TR/html52/textlevel-semantics.html#the-kbd-element
>

From alexey.ivanov at oracle.com  Fri Oct 25 15:58:54 2019
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Fri, 25 Oct 2019 16:58:54 +0100
Subject:   RFR 8232880: Update test documentation
 with additional settings for client UI tooltip tests
In-Reply-To: 
References: <5096E196-8A4F-4A6A-A419-F9FFF7D59A0D@oracle.com>

Message-ID: <18fe58a5-003f-a98f-8cab-784f2dd0a9bb@oracle.com>

Got it!
Then I'd just drop the quotes from the key names:
- `?CTRL? + ?F1?`
+ `Ctrl + F1`

On 25/10/2019 16:52, Erik Joelsson wrote:
> The HTML is generated from the markup and should not be edited by hand.
>
> /Erik 
-- 
Regards,
Alexey

From alexey.ivanov at oracle.com  Fri Oct 25 18:01:49 2019
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Fri, 25 Oct 2019 19:01:49 +0100
Subject:  [14] RFR 8232605: [macos] There is no Tooltip
 message displayed when Ctrl+F1 is clicked.
In-Reply-To: <23AE0410-B38C-426C-99AD-4A2C1E9A9CB5@oracle.com>
References: <5BF5F70E-B26E-4AF2-B7DE-FB71FDFB00EB@oracle.com>

 <23AE0410-B38C-426C-99AD-4A2C1E9A9CB5@oracle.com>
Message-ID: 

On 24/10/2019 14:27, Dmitry Markov wrote:
>> On 24 Oct 2019, at 02:36, Sergey Bylokhov > > wrote:
>>
>> On 10/23/19 3:17 am, Dmitry Markov wrote:
>>> I agree the generic documentation should be updated. I have 
>>> openedhttps://bugs.openjdk.java.net/browse/JDK-8232880?to track that.
>>
>> Thanks.
>>
>>> Also I would like to update this particular test, as 
>>> well:http://cr.openjdk.java.net/~dmarkov/8232605/webrev.01/
>>
>> I am not sure it is needed, such system shortcuts will cause issues 
>> in lots of other tests.
>
> I understand your concerns and I will update generic documentation 
> shortly. At the same time I do not see any problems if we duplicate 
> the information from the generic docs in the test. What do you think?

I think it makes sense to duplicate this information as it could prevent 
false failure, and raise the awareness of the required changes to macOS 
settings.

Could you also amend the summary to the list correct key combination?
- 27? * @summary CTRL + 1 does not show tooltip message for menu items
+ 27? * @summary CTRL + F1 does not show tooltip message for menu items

-- 
Regards,
Alexey

From Sergey.Bylokhov at oracle.com  Fri Oct 25 23:55:34 2019
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 25 Oct 2019 16:55:34 -0700
Subject:  RFR 8232880: Update test documentation with
 additional settings for client UI tooltip tests
In-Reply-To: <5096E196-8A4F-4A6A-A419-F9FFF7D59A0D@oracle.com>
References: <5096E196-8A4F-4A6A-A419-F9FFF7D59A0D@oracle.com>
Message-ID: <8f9d6d2e-4002-df17-119f-4f52127393bc@oracle.com>

Hi, Dmitry.

I suggest to make this block more generic, and describe the  "### Client UI - Tests".
It would be useful to mention that the tests in this category use different key combinations,
which might be registered as a system shortcuts, and it could cause a test failure. It is suggested
to disable these shortcuts:
  - macOS config location.....
  - Linux config location.....
  - On window some other application may have global shortcuts....

As an example of such issue you can provide CTRL+F1 which is used....

On 10/25/19 3:27 am, Dmitry Markov wrote:
> Hello,
> 
> Could you review the fix for jdk14, please?
> 
> 	bug: https://bugs.openjdk.java.net/browse/JDK-8232880 
> 	webrev: http://cr.openjdk.java.net/~dmarkov/8232880/webrev.00/ 
> 
> Some Client UI tests use the following key sequence to show/hide tooltip message: ?CTRL? + ?F1". However this key combination is reserved by operating system on OS X platform. As a results the tests fail.
> Test documentation should be updated with some notes regarding this.
> 
> Thanks,
> Dmitry
> 

-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Sat Oct 26 00:51:28 2019
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 25 Oct 2019 17:51:28 -0700
Subject:  Box.Filler focusability
In-Reply-To: <13D6476D-FB53-4C3A-BA9E-51A308B17408@cbfiddle.com>
References: <46AE5D7A-36C5-46B3-9AFC-470CA20E74E8@cbfiddle.com>

 <856a2285-eb87-b9af-c728-e55e483509d1@oracle.com>
 <13D6476D-FB53-4C3A-BA9E-51A308B17408@cbfiddle.com>
Message-ID: <6629cdc6-8107-e338-7504-8de6fe2c946f@oracle.com>

On 10/2/19 7:49 am, Alan Snyder wrote:
> HI Sergey,
> 
> I?m happy to create a new bug report, but I?m not sure what it should say.

I guess you need to describe the problem/bug which you are faced in your code if such exists.

> 
> Could you explain why the existing report is insufficient?
> 
>    Alan
> 
> 
> 
>> On Oct 1, 2019, at 12:40 PM, Sergey Bylokhov  wrote:
>>
>> Hi, Alan.
>>
>> I do not see a reason why it should be focusable by default, but not sure we can change it.
>> It will be necessary to check the history of the related code. I suggest to create a new bug to track it.
>>
>> On 8/13/19 7:12 am, Alan Snyder wrote:
>>> I ask only because I don?t want to file a bug report that will be rejected immediately...
>>>> On Aug 9, 2019, at 11:01 AM, Alan Snyder  wrote:
>>>>
>>>> I find that Box.Filler instances are focusable by default. That seems wrong. Am I missing something?
>>>>
>>
>>
>> -- 
>> Best regards, Sergey.
>>
> 

-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Sat Oct 26 00:49:47 2019
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 25 Oct 2019 17:49:47 -0700
Subject:  adding a component to a container that it is
 already a member of (specifically a JLayeredPane container)
In-Reply-To: <60F9BD06-93AA-4C25-AEB2-DB16EE3355CC@cbfiddle.com>
References: <60F9BD06-93AA-4C25-AEB2-DB16EE3355CC@cbfiddle.com>
Message-ID: 

On 10/3/19 12:16 pm, Alan Snyder wrote:
> If this case is truly not supported, then the documentation should be improved to make it clear that this case is not supported.
> 
> Which direction should be taken? Fix the code or the documentation?

It is always better to document long-standing behavior instead fix it,
but for this particular bug, I guess it depends on the possible change in the fix.

-- 
Best regards, Sergey.

From dmitry.markov at oracle.com  Mon Oct 28 17:23:50 2019
From: dmitry.markov at oracle.com (Dmitry Markov)
Date: Mon, 28 Oct 2019 17:23:50 +0000
Subject:  RFR 8232880: Update test documentation with
 additional settings for client UI tooltip tests
In-Reply-To: <8f9d6d2e-4002-df17-119f-4f52127393bc@oracle.com>
References: <5096E196-8A4F-4A6A-A419-F9FFF7D59A0D@oracle.com>
 <8f9d6d2e-4002-df17-119f-4f52127393bc@oracle.com>
Message-ID: <1439841D-22B8-49A9-9385-235EC9B81C72@oracle.com>

Hi Alexey, Erik, Sergey,
Thank you for your feedback. I have updated the fix based on your suggestions: http://cr.openjdk.java.net/~dmarkov/8232880/webrev.01/ 
Can you take a look, please?

Thanks,
Dmitry

> On 26 Oct 2019, at 00:55, Sergey Bylokhov  wrote:
> 
> Hi, Dmitry.
> 
> I suggest to make this block more generic, and describe the  "### Client UI - Tests".
> It would be useful to mention that the tests in this category use different key combinations,
> which might be registered as a system shortcuts, and it could cause a test failure. It is suggested
> to disable these shortcuts:
> - macOS config location.....
> - Linux config location.....
> - On window some other application may have global shortcuts....
> 
> As an example of such issue you can provide CTRL+F1 which is used....
> 
> 
> On 10/25/19 3:27 am, Dmitry Markov wrote:
>> Hello,
>> Could you review the fix for jdk14, please?
>> 	bug: https://bugs.openjdk.java.net/browse/JDK-8232880 
>> 	webrev: http://cr.openjdk.java.net/~dmarkov/8232880/webrev.00/ 
>> Some Client UI tests use the following key sequence to show/hide tooltip message: ?CTRL? + ?F1". However this key combination is reserved by operating system on OS X platform. As a results the tests fail.
>> Test documentation should be updated with some notes regarding this.
>> Thanks,
>> Dmitry
> 
> 
> -- 
> Best regards, Sergey.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From philip.race at oracle.com  Mon Oct 28 17:49:10 2019
From: philip.race at oracle.com (Phil Race)
Date: Mon, 28 Oct 2019 10:49:10 -0700
Subject:  [14] RFR JDK-8231084:Large performance regression
 in SwingMark TextArea in 14-b13
In-Reply-To: <068f8bdd-d95e-b895-46e4-c392c17b8335@oracle.com>
References: <068f8bdd-d95e-b895-46e4-c392c17b8335@oracle.com>
Message-ID: <0f063bf1-4acf-fa66-7b16-d2d547ffb3b0@oracle.com>

Can we just problem list the tests rather than deleting them ?
Won't they be uiseful for the new version of the fix ?
Perhaps the JEditorLayoutPaneTest.java won't be needed if
it was only to confirm the first regression was resolved, but I am not sure.

-phil.

On 10/23/19 4:07 PM, Prasanta Sadhukhan wrote:
> Hi All,
>
> Please review a rollback of the bug fix which caused large performance 
> regression for TextArea.
>
> JDK-8226513 removes the zero component size check to layout the root 
> view when text component is updated by resetting the 
> rootViewNeedsLayout flag, but it caused textarea performance 
> regression as rootview initialization is triggered multiple times.
>
> JDK-8226513 was a regression of JDK-8160246, which was again 
> regression of JDK-8130892, which in turn was a regression of JDK-8001470
> where view's preferred size is set only when text component's height 
> or width is 0. This check is modified in subsequent fixes which caused 
> more regressions.
>
> Proposed fix for performance regression is to roll back to original 
> issue and figure out why negative insets are obtained for 
> JEditorPane.getPreferredSize()
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8231084
>
> webrev: http://cr.openjdk.java.net/~psadhukhan/8231084/webrev.0/
>
> Changeset of 8001470 : 
> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/ff8622450b29
>
> A new bug JDK-8232917 has been created to investigate a fix for the 
> original issue JDK-8001470.
>
> Regards
> Prasanta
>
>

From prasanta.sadhukhan at oracle.com  Tue Oct 29 05:22:47 2019
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Tue, 29 Oct 2019 10:52:47 +0530
Subject:  [14] RFR JDK-8231084:Large performance regression
 in SwingMark TextArea in 14-b13
In-Reply-To: <0f063bf1-4acf-fa66-7b16-d2d547ffb3b0@oracle.com>
References: <068f8bdd-d95e-b895-46e4-c392c17b8335@oracle.com>
 <0f063bf1-4acf-fa66-7b16-d2d547ffb3b0@oracle.com>
Message-ID: 

We probably could keep bug8001470.java testcase but would like to take a 
relook at the test during fix of the original issue. The original issue 
was JDK-8001470was identified as generic but the testcase fails only in 
linux even after the removal of fix. Other testcases was for the 
regressions and since we are rolling those back, my take is not to keep 
them.

Regards
Prasanta
On 28-Oct-19 11:19 PM, Phil Race wrote:
> Can we just problem list the tests rather than deleting them ?
> Won't they be uiseful for the new version of the fix ?
> Perhaps the JEditorLayoutPaneTest.java won't be needed if
> it was only to confirm the first regression was resolved, but I am not 
> sure.
>
> -phil.
>
>
> On 10/23/19 4:07 PM, Prasanta Sadhukhan wrote:
>> Hi All,
>>
>> Please review a rollback of the bug fix which caused large 
>> performance regression for TextArea.
>>
>> JDK-8226513 removes the zero component size check to layout the root 
>> view when text component is updated by resetting the 
>> rootViewNeedsLayout flag, but it caused textarea performance 
>> regression as rootview initialization is triggered multiple times.
>>
>> JDK-8226513 was a regression of JDK-8160246, which was again 
>> regression of JDK-8130892, which in turn was a regression of JDK-8001470
>> where view's preferred size is set only when text component's height 
>> or width is 0. This check is modified in subsequent fixes which 
>> caused more regressions.
>>
>> Proposed fix for performance regression is to roll back to original 
>> issue and figure out why negative insets are obtained for 
>> JEditorPane.getPreferredSize()
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8231084
>>
>> webrev: http://cr.openjdk.java.net/~psadhukhan/8231084/webrev.0/
>>
>> Changeset of 8001470 : 
>> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/ff8622450b29
>>
>> A new bug JDK-8232917 has been created to investigate a fix for the 
>> original issue JDK-8001470.
>>
>> Regards
>> Prasanta
>>
>>
>

From philip.race at oracle.com  Tue Oct 29 18:03:34 2019
From: philip.race at oracle.com (Phil Race)
Date: Tue, 29 Oct 2019 11:03:34 -0700
Subject:  [14] RFR JDK-8231084:Large performance regression
 in SwingMark TextArea in 14-b13
In-Reply-To: 
References: <068f8bdd-d95e-b895-46e4-c392c17b8335@oracle.com>
 <0f063bf1-4acf-fa66-7b16-d2d547ffb3b0@oracle.com>

Message-ID: 

Ok then, keep just the one on the problem list.

-phil.

On 10/28/19 10:22 PM, Prasanta Sadhukhan wrote:
> We probably could keep bug8001470.java testcase but would like to take 
> a relook at the test during fix of the original issue. The original 
> issue was JDK-8001470was identified as generic but the testcase fails 
> only in linux even after the removal of fix. Other testcases was for 
> the regressions and since we are rolling those back, my take is not to 
> keep them.
>
> Regards
> Prasanta
> On 28-Oct-19 11:19 PM, Phil Race wrote:
>> Can we just problem list the tests rather than deleting them ?
>> Won't they be uiseful for the new version of the fix ?
>> Perhaps the JEditorLayoutPaneTest.java won't be needed if
>> it was only to confirm the first regression was resolved, but I am 
>> not sure.
>>
>> -phil.
>>
>>
>> On 10/23/19 4:07 PM, Prasanta Sadhukhan wrote:
>>> Hi All,
>>>
>>> Please review a rollback of the bug fix which caused large 
>>> performance regression for TextArea.
>>>
>>> JDK-8226513 removes the zero component size check to layout the root 
>>> view when text component is updated by resetting the 
>>> rootViewNeedsLayout flag, but it caused textarea performance 
>>> regression as rootview initialization is triggered multiple times.
>>>
>>> JDK-8226513 was a regression of JDK-8160246, which was again 
>>> regression of JDK-8130892, which in turn was a regression of 
>>> JDK-8001470
>>> where view's preferred size is set only when text component's height 
>>> or width is 0. This check is modified in subsequent fixes which 
>>> caused more regressions.
>>>
>>> Proposed fix for performance regression is to roll back to original 
>>> issue and figure out why negative insets are obtained for 
>>> JEditorPane.getPreferredSize()
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8231084
>>>
>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8231084/webrev.0/
>>>
>>> Changeset of 8001470 : 
>>> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/ff8622450b29
>>>
>>> A new bug JDK-8232917 has been created to investigate a fix for the 
>>> original issue JDK-8001470.
>>>
>>> Regards
>>> Prasanta
>>>
>>>
>>

From alexey.ivanov at oracle.com  Tue Oct 29 19:29:57 2019
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Tue, 29 Oct 2019 19:29:57 +0000
Subject:  RFR 8232880: Update test documentation with
 additional settings for client UI tooltip tests
In-Reply-To: <1439841D-22B8-49A9-9385-235EC9B81C72@oracle.com>
References: <5096E196-8A4F-4A6A-A419-F9FFF7D59A0D@oracle.com>
 <8f9d6d2e-4002-df17-119f-4f52127393bc@oracle.com>
 <1439841D-22B8-49A9-9385-235EC9B81C72@oracle.com>
Message-ID: <8a01b08a-051a-d808-7882-d9edad825fed@oracle.com>

Hi Dmitry,

Shall we drop hyphen in the header: ?Client UI Tests??

I think there should be no definite article in this sentence: ?use -the- 
key sequences?.

??Turn off Windowss key hotkeys??, there's an extra ?s? in Windows.

?Note: restart is required to make the settings take effect.?
Just to confirm: is signing out and signing in not enough?

I'd use backticks for gpedit markup: ?Type `gpedit` in the Search??

Does it make sense to move the example into macOS section? Then the 
steps to disable the shortcut can be reduced to the required option 
only. The steps themselves should not be listed as code, i.e. no backticks.

(For my understanding, "Turn keyboard access on or off" turns off only 
one specific shortcut, i.e. Ctrl+F1?)

Regards,
Alexey

On 28/10/2019 17:23, Dmitry Markov wrote:
> Hi Alexey, Erik, Sergey,
> Thank you for your feedback. I have updated the fix based on your 
> suggestions: http://cr.openjdk.java.net/~dmarkov/8232880/webrev.01/
> Can you take a look, please?
>
> Thanks,
> Dmitry
>
>> On 26 Oct 2019, at 00:55, Sergey Bylokhov > > wrote:
>>
>> Hi, Dmitry.
>>
>> I suggest to make this block more generic, and describe the ?"### 
>> Client UI - Tests".
>> It would be useful to mention that the tests in this category use 
>> different key combinations,
>> which might be registered as a system shortcuts, and it could cause a 
>> test failure. It is suggested
>> to disable these shortcuts:
>> - macOS config location.....
>> - Linux config location.....
>> - On window some other application may have global shortcuts....
>>
>> As an example of such issue you can provide CTRL+F1 which is used....
>>
>>
>> On 10/25/19 3:27 am, Dmitry Markov wrote:
>>> Hello,
>>> Could you review the fix for jdk14, please?
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8232880 
>>> 
>>> webrev: http://cr.openjdk.java.net/~dmarkov/8232880/webrev.00/ 
>>> 
>>> Some Client UI tests use the following key sequence to show/hide 
>>> tooltip message: ?CTRL? + ?F1". However this key combination is 
>>> reserved by operating system on OS X platform. As a results the 
>>> tests fail.
>>> Test documentation should be updated with some notes regarding this.
>>> Thanks,
>>> Dmitry
>>
>>
>> -- 
>> Best regards, Sergey.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From Sergey.Bylokhov at oracle.com  Wed Oct 30 00:33:43 2019
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 29 Oct 2019 17:33:43 -0700
Subject:  [14] RFR JDK-8231084:Large performance regression
 in SwingMark TextArea in 14-b13
In-Reply-To: 
References: <068f8bdd-d95e-b895-46e4-c392c17b8335@oracle.com>
 <0f063bf1-4acf-fa66-7b16-d2d547ffb3b0@oracle.com>

Message-ID: <236f7fe0-eb17-01bc-f75d-d56f019bebae@oracle.com>

I suggest to attach these tests to the new CR just as
an additional verification step for the future fix.

On 10/29/19 11:03 am, Phil Race wrote:
> Ok then, keep just the one on the problem list.
> 
> -phil.
> 
> On 10/28/19 10:22 PM, Prasanta Sadhukhan wrote:
>> We probably could keep bug8001470.java testcase but would like to take a relook at the test during fix of the original issue. The original issue was JDK-8001470was identified as generic but the testcase fails only in linux even after the removal of fix. Other testcases was for the regressions and since we are rolling those back, my take is not to keep them.
>>
>> Regards
>> Prasanta
>> On 28-Oct-19 11:19 PM, Phil Race wrote:
>>> Can we just problem list the tests rather than deleting them ?
>>> Won't they be uiseful for the new version of the fix ?
>>> Perhaps the JEditorLayoutPaneTest.java won't be needed if
>>> it was only to confirm the first regression was resolved, but I am not sure.
>>>
>>> -phil.
>>>
>>>
>>> On 10/23/19 4:07 PM, Prasanta Sadhukhan wrote:
>>>> Hi All,
>>>>
>>>> Please review a rollback of the bug fix which caused large performance regression for TextArea.
>>>>
>>>> JDK-8226513 removes the zero component size check to layout the root view when text component is updated by resetting the rootViewNeedsLayout flag, but it caused textarea performance regression as rootview initialization is triggered multiple times.
>>>>
>>>> JDK-8226513 was a regression of JDK-8160246, which was again regression of JDK-8130892, which in turn was a regression of JDK-8001470
>>>> where view's preferred size is set only when text component's height or width is 0. This check is modified in subsequent fixes which caused more regressions.
>>>>
>>>> Proposed fix for performance regression is to roll back to original issue and figure out why negative insets are obtained for JEditorPane.getPreferredSize()
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8231084
>>>>
>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8231084/webrev.0/
>>>>
>>>> Changeset of 8001470 : http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/ff8622450b29
>>>>
>>>> A new bug JDK-8232917 has been created to investigate a fix for the original issue JDK-8001470.
>>>>
>>>> Regards
>>>> Prasanta
>>>>
>>>>
>>>
> 

-- 
Best regards, Sergey.

From prasanta.sadhukhan at oracle.com  Wed Oct 30 06:49:26 2019
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Wed, 30 Oct 2019 12:19:26 +0530
Subject:  [14] RFR JDK-8231084:Large performance regression
 in SwingMark TextArea in 14-b13
In-Reply-To: <236f7fe0-eb17-01bc-f75d-d56f019bebae@oracle.com>
References: <068f8bdd-d95e-b895-46e4-c392c17b8335@oracle.com>
 <0f063bf1-4acf-fa66-7b16-d2d547ffb3b0@oracle.com>

 <236f7fe0-eb17-01bc-f75d-d56f019bebae@oracle.com>
Message-ID: 

http://cr.openjdk.java.net/~psadhukhan/8231084/webrev.1/ problemlisting 
the original testcase to be fixed in new CR JDK-8233177 
 (clone of 8001470).

Regards
Prasanta
On 30-Oct-19 6:03 AM, Sergey Bylokhov wrote:
> I suggest to attach these tests to the new CR just as
> an additional verification step for the future fix.
>
> On 10/29/19 11:03 am, Phil Race wrote:
>> Ok then, keep just the one on the problem list.
>>
>> -phil.
>>
>> On 10/28/19 10:22 PM, Prasanta Sadhukhan wrote:
>>> We probably could keep bug8001470.java testcase but would like to 
>>> take a relook at the test during fix of the original issue. The 
>>> original issue was JDK-8001470was identified as generic but the 
>>> testcase fails only in linux even after the removal of fix. Other 
>>> testcases was for the regressions and since we are rolling those 
>>> back, my take is not to keep them.
>>>
>>> Regards
>>> Prasanta
>>> On 28-Oct-19 11:19 PM, Phil Race wrote:
>>>> Can we just problem list the tests rather than deleting them ?
>>>> Won't they be uiseful for the new version of the fix ?
>>>> Perhaps the JEditorLayoutPaneTest.java won't be needed if
>>>> it was only to confirm the first regression was resolved, but I am 
>>>> not sure.
>>>>
>>>> -phil.
>>>>
>>>>
>>>> On 10/23/19 4:07 PM, Prasanta Sadhukhan wrote:
>>>>> Hi All,
>>>>>
>>>>> Please review a rollback of the bug fix which caused large 
>>>>> performance regression for TextArea.
>>>>>
>>>>> JDK-8226513 removes the zero component size check to layout the 
>>>>> root view when text component is updated by resetting the 
>>>>> rootViewNeedsLayout flag, but it caused textarea performance 
>>>>> regression as rootview initialization is triggered multiple times.
>>>>>
>>>>> JDK-8226513 was a regression of JDK-8160246, which was again 
>>>>> regression of JDK-8130892, which in turn was a regression of 
>>>>> JDK-8001470
>>>>> where view's preferred size is set only when text component's 
>>>>> height or width is 0. This check is modified in subsequent fixes 
>>>>> which caused more regressions.
>>>>>
>>>>> Proposed fix for performance regression is to roll back to 
>>>>> original issue and figure out why negative insets are obtained for 
>>>>> JEditorPane.getPreferredSize()
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8231084
>>>>>
>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8231084/webrev.0/
>>>>>
>>>>> Changeset of 8001470 : 
>>>>> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/ff8622450b29
>>>>>
>>>>> A new bug JDK-8232917 has been created to investigate a fix for 
>>>>> the original issue JDK-8001470.
>>>>>
>>>>> Regards
>>>>> Prasanta
>>>>>
>>>>>
>>>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From Sergey.Bylokhov at oracle.com  Wed Oct 30 21:54:46 2019
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 30 Oct 2019 14:54:46 -0700
Subject:  [14] RFR : JDK-4949105 : Access Bridge lacks html
 tags parsing
In-Reply-To: <015bd550-93bd-415f-962a-bf132f206ad6@default>
References: <015bd550-93bd-415f-962a-bf132f206ad6@default>
Message-ID: <726ef686-e261-f526-4b09-0003432346c1@oracle.com>

Hi, Ambarish.

I have checked behavior change, and it looks like it has some
unexpected issues.

If the text of some component like JLabel sets
the text to HTML and then to the simple text, then HTML based
a11y name will be used instead of simple text.

Note that you should not use "printStackTrace" I guess the old
behavior should be used if some errors occur.

On 9/24/19 9:45 am, Ambarish Rapte wrote:
> Hi All,
> 
> Please review this accessibility fix,
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-4949105
> 
> Webrev: http://cr.openjdk.java.net/~arapte/a11y/4949105/webrev.00/
> 
> Issue:
> 
> When a Swing component is created with html text. The same html text is shared as AccessibleName with screen reader application.
> 
> If screen reader fails to parse the html string correctly, then it may read the text different from the text displayed for the component.
> 
> Fix:
> 
> The same parsed html string for the component should be shared to screen reader as AccessibleName.
> 
> No existing Swing component tests fail due to this change.
> 
> Regards,
> 
> Ambarish
> 

-- 
Best regards, Sergey.

From tejpal.rebari at oracle.com  Thu Oct 31 08:24:51 2019
From: tejpal.rebari at oracle.com (Tejpal Rebari)
Date: Thu, 31 Oct 2019 13:54:51 +0530
Subject:  [14] RFR JDK-7020860 - BasicTreeUI contains
 getters/setters with unclear spec
Message-ID: 

Hi All,
Please review the following fix for JDK 14.

Bug : 	https://bugs.openjdk.java.net/browse/JDK-7020860 
Webrev :  http://cr.openjdk.java.net/~trebari/swing/7020860/webrev0/ 

Issue : Class javax.swing.plaf.basic.BasicTreeUI contains some getters/setters that are not consistent and 
and have specification that says nothing about how they should be used and how do they behave in BasicTreeUI.

Fix : This bug was already sent for review by semyon http://cr.openjdk.java.net/~ssadetsky/7020860/webrev.00/ .
I have made the following changes to the above webrev : 
	* @param newValue the new value of the {@code editable}> property
	changed to ?>>
	* @param newValue the new value of the {@code editable} property

And 
		* Returns whether the root node of the drawn tree component is displayable.

		changed to ?>>

		* Returns whether the root node of the drawn tree component should be displayed.

Regards
Tejpal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From prasanta.sadhukhan at oracle.com  Thu Oct 31 08:28:43 2019
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Thu, 31 Oct 2019 13:58:43 +0530
Subject:  [14] RFR JDK-8190763 - Class cast exception on
 (CompoundEdit) UndoableEditEvent.getEdit()
In-Reply-To: <5F67C52F-6287-47F6-A4F5-FA4D3EE28FB2@oracle.com>
References: <5F67C52F-6287-47F6-A4F5-FA4D3EE28FB2@oracle.com>
Message-ID: <3b14da46-7b21-4152-19c9-45c19018d4ce@oracle.com>

Hi tejpal,

Can you add a testcase to the fix? I guess one is there in the JBS itself.

Regards
Prasanta
On 24-Oct-19 10:31 AM, Tejpal Rebari wrote:
> Hi All,
> Please review the following fix for jdk14.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8190763
> Webrev: http://cr.openjdk.java.net/~trebari/swing/8190763/webrev0/
>
> Issue?:?This issue is a regression of 
> https://bugs.openjdk.java.net/browse/JDK-8030702.
> When UndoableEditEvent.getEdit() is casted to CompoundEdit, it throws 
> class cast exception.
>
> Fix :??In JDK-8030702 
> ? a new class 
> DefaultDocumentEventUndoableWrapper was introduced.
> UndoableEditEvent.getEdit() returns an object of 
> DefaultDocumentEventUndoableWrapper and when it is casted to 
> CompoundEdit it throws class cast exception because
> it doesn?t inherit CompoundEdit.
> Before the fix of JDK-8030702 
> ? , 
> UndoableEditEvent.getEdit() ?used to return an object of 
> DefaultDocumentEvent which inherits CompoundEdit so the class cast 
> exception was not thrown.
> The solution is to make DefaultDocumentEventUndoableWrapper a subclass 
> of DefaultDocumentEvent.
>
> Testing : I have tested it on Mac, Windows and Ubuntu.
>
> Regards
> Tejpal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From dmitry.markov at oracle.com  Thu Oct 31 10:56:07 2019
From: dmitry.markov at oracle.com (Dmitry Markov)
Date: Thu, 31 Oct 2019 10:56:07 +0000
Subject:  RFR 8232880: Update test documentation with
 additional settings for client UI tooltip tests
In-Reply-To: <8a01b08a-051a-d808-7882-d9edad825fed@oracle.com>
References: <5096E196-8A4F-4A6A-A419-F9FFF7D59A0D@oracle.com>
 <8f9d6d2e-4002-df17-119f-4f52127393bc@oracle.com>
 <1439841D-22B8-49A9-9385-235EC9B81C72@oracle.com>
 <8a01b08a-051a-d808-7882-d9edad825fed@oracle.com>
Message-ID: 

Hi Alexey,

I have updated the fix based on your recommendation. The new version is located at: http://cr.openjdk.java.net/~dmarkov/8232880/webrev.02/ 
Also please find my answers inline.

Thanks,
Dmitry

> On 29 Oct 2019, at 19:29, Alexey Ivanov  wrote:
> 
> Hi Dmitry,
> 
> Shall we drop hyphen in the header: ?Client UI Tests??
> 
> I think there should be no definite article in this sentence: ?use -the- key sequences?.
> 
> ??Turn off Windowss key hotkeys??, there's an extra ?s? in Windows.
> 
> ?Note: restart is required to make the settings take effect.?
> Just to confirm: is signing out and signing in not enough?
According to Microsoft site: restart is required but I guess signing out/in should work too. Unfortunately I do not have Windows on hand to check it out. 

> 
> I'd use backticks for gpedit markup: ?Type `gpedit` in the Search??
> 
> 
> Does it make sense to move the example into macOS section? Then the steps to disable the shortcut can be reduced to the required option only. The steps themselves should not be listed as code, i.e. no backticks.
> 
> (For my understanding, "Turn keyboard access on or off" turns off only one specific shortcut, i.e. Ctrl+F1?)
Yes, that?s right. I have added clarification to the doc.

> 
> 
> Regards,
> Alexey
> 
> On 28/10/2019 17:23, Dmitry Markov wrote:
>> Hi Alexey, Erik, Sergey,
>> Thank you for your feedback. I have updated the fix based on your suggestions: http://cr.openjdk.java.net/~dmarkov/8232880/webrev.01/ 
>> Can you take a look, please?
>> 
>> Thanks,
>> Dmitry
>> 
>>> On 26 Oct 2019, at 00:55, Sergey Bylokhov > wrote:
>>> 
>>> Hi, Dmitry.
>>> 
>>> I suggest to make this block more generic, and describe the  "### Client UI - Tests".
>>> It would be useful to mention that the tests in this category use different key combinations,
>>> which might be registered as a system shortcuts, and it could cause a test failure. It is suggested
>>> to disable these shortcuts:
>>> - macOS config location.....
>>> - Linux config location.....
>>> - On window some other application may have global shortcuts....
>>> 
>>> As an example of such issue you can provide CTRL+F1 which is used....
>>> 
>>> 
>>> On 10/25/19 3:27 am, Dmitry Markov wrote:
>>>> Hello,
>>>> Could you review the fix for jdk14, please?
>>>> 	bug: https://bugs.openjdk.java.net/browse/JDK-8232880  >
>>>> 	webrev: http://cr.openjdk.java.net/~dmarkov/8232880/webrev.00/  >
>>>> Some Client UI tests use the following key sequence to show/hide tooltip message: ?CTRL? + ?F1". However this key combination is reserved by operating system on OS X platform. As a results the tests fail.
>>>> Test documentation should be updated with some notes regarding this.
>>>> Thanks,
>>>> Dmitry
>>> 
>>> 
>>> -- 
>>> Best regards, Sergey.
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From ambarish.rapte at oracle.com  Thu Oct 31 11:57:59 2019
From: ambarish.rapte at oracle.com (Ambarish Rapte)
Date: Thu, 31 Oct 2019 04:57:59 -0700 (PDT)
Subject:  [14] RFR : JDK-4949105 : Access Bridge lacks html
 tags parsing
In-Reply-To: <726ef686-e261-f526-4b09-0003432346c1@oracle.com>
References: <015bd550-93bd-415f-962a-bf132f206ad6@default>
 <726ef686-e261-f526-4b09-0003432346c1@oracle.com>
Message-ID: 

Hi Sergey,
Thanks for the review,
Here is the updated webrev: http://cr.openjdk.java.net/~arapte/a11y/4949105/webrev.01/

Fixed both the review comments:
1.  AccessibleContext.ACCESSIBLE_NAME_PROPERTY shall be set only if the text is html string, otherwise it is set to null which is existing behavior.
2.  Removed printStackTrace() call.  In case of exception  AccessibleContext.ACCESSIBLE_NAME_PROPERTY  shall be set to null which is existing behavior.
3.  Added a test for setText() scenario.

Regards,
Ambarish

-----Original Message-----
From: Sergey Bylokhov 
Sent: Thursday, October 31, 2019 3:25 AM
To: Ambarish Rapte ; swing-dev at openjdk.java.net
Subject: Re:  [14] RFR : JDK-4949105 : Access Bridge lacks html tags parsing

Hi, Ambarish.

I have checked behavior change, and it looks like it has some unexpected issues.

If the text of some component like JLabel sets the text to HTML and then to the simple text, then HTML based a11y name will be used instead of simple text.

Note that you should not use "printStackTrace" I guess the old behavior should be used if some errors occur.

On 9/24/19 9:45 am, Ambarish Rapte wrote:
> Hi All,
> 
> Please review this accessibility fix,
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-4949105
> 
> Webrev: http://cr.openjdk.java.net/~arapte/a11y/4949105/webrev.00/
> 
> Issue:
> 
> When a Swing component is created with html text. The same html text is shared as AccessibleName with screen reader application.
> 
> If screen reader fails to parse the html string correctly, then it may read the text different from the text displayed for the component.
> 
> Fix:
> 
> The same parsed html string for the component should be shared to screen reader as AccessibleName.
> 
> No existing Swing component tests fail due to this change.
> 
> Regards,
> 
> Ambarish
> 

--
Best regards, Sergey.

From pankaj.b.bansal at oracle.com  Thu Oct 31 12:59:51 2019
From: pankaj.b.bansal at oracle.com (Pankaj Bansal)
Date: Thu, 31 Oct 2019 05:59:51 -0700 (PDT)
Subject:  [14] RFR JDK-8230235 - Rendering HTML with empty
 img attribute and documentBaseKey cause Exception
In-Reply-To: <95fde072-6311-9793-8b8e-bc55bb1e03a0@oracle.com>
References: <8089f79a-94f1-4818-8fef-a678b1b6e974@default>
 <638c1045-e8f4-bc7a-8acb-2a388bb45fd1@oracle.com>
 <95fde072-6311-9793-8b8e-bc55bb1e03a0@oracle.com>
Message-ID: <80b79824-124b-4d5d-87ff-edb829c1d871@default>

Hi Sergey/Alexey

Webrev: http://cr.openjdk.java.net/~pbansal/8230235/webrev01/

<< I guess that the problem is that the "image" is accessed w/o synchronization on "this" like in other places, but it will be necessary to add one null check before usage of "image".
I have updated the code to access image with synchronization. But that does not solve the issue. So I have kept the null check also. I tried to add the null check before calling getWidth, calling getWidth still makes the image null. So the check before calling getHeight is still required.

< [14] RFR JDK-8230235 - Rendering HTML with empty img attribute and documentBaseKey cause Exception

Hi Pankaj,

I'd like to confirm:

793???????????????? int width = image.getWidth(imageObserver);
794???????????????? if (image != null) {

the image is not null at line 793, and as the side effect of calling image.getWidth(imageObserver), image is set to null, right?
This requires a comment, doesn't it? Otherwise the condition in if looks always true. Is it possible that image becomes null before getWidth() is called?

Can we implement this differently?
I guess we'll also get NPE if src attribute of  tag is not an image.

I agree with Sergey, try-catch are not necessary in this case: you declared that main throws Exception. Any exception indicates the test failed.

Since JLabel is a Swing component, you should create its instance on EDT. SwingUtilities.invokeAndWait would do the job.

Regards,
Alexey

On 10/10/2019 21:35, Sergey Bylokhov wrote:
> Hi, Pankaj.
> I guess that the problem is that the "image" is accessed w/o 
> synchronization on "this"
> like in other places, but it will be necessary to add one null check 
> before usage of "image".
> Also, it is not necessary to have a try/catch block in the test, just 
> call the problematic method
>
> On 10/10/19 11:01 am, Pankaj Bansal wrote:
>> Hi All,
>>
>> Please review the following fix for jdk14.
>>
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8230235
>>
>> Webrev: http://cr.openjdk.java.net/~pbansal/8230235/webrev00/
>>
>> Issue:
>>
>> Rendering HTML with empty img attribute and documentBaseKey set 
>> causes NPE
>>
>> Fix:
>>
>> The issues is introduced after
>> https://bugs.openjdk.java.net/browse/JDK-8218674.
>>
>> When the documentBaseKey is set, but img tag is not set, the image 
>> URL may not be complete and may not point to actual image. In 
>> ImageView class, when getWidth(ImageObserver) is called from the 
>> updateImageSize, it checks if image source is null and adds the 
>> ImageObserver (ImageView.ImageHandler) on the Image and sets the 
>> ImageView image as null. When getHeight is called, as image is set to 
>> null, it results in NPE.
>>
>> We should verify that image is not null.
>>
>> Testing:
>>
>> I have tested it on Window, Linux and Mac.
>>
>>
>> Regards,
>> Pankaj Bansal
>>
>
>

From alexey.ivanov at oracle.com  Thu Oct 31 16:27:23 2019
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Thu, 31 Oct 2019 16:27:23 +0000
Subject:  RFR 8232880: Update test documentation with
 additional settings for client UI tooltip tests
In-Reply-To: 
References: <5096E196-8A4F-4A6A-A419-F9FFF7D59A0D@oracle.com>
 <8f9d6d2e-4002-df17-119f-4f52127393bc@oracle.com>
 <1439841D-22B8-49A9-9385-235EC9B81C72@oracle.com>
 <8a01b08a-051a-d808-7882-d9edad825fed@oracle.com>

Message-ID: <3776f84b-b845-3233-47da-021aba45ff84@oracle.com>

Hi Dmitry,

437 ?by the operating system. ?

I'd modify the following text a bit:
To run the test correctly, the default global key shortcut should be 
disabled. Follow the steps above, and then deselect "Turn keyboard 
access on or off" property which is responsible for `CTRL + F1` combination.

Does it sound clearer?
I'd not use backticks on the "Turn keyboard access on or off" because 
it's not something user is typing, nor is it a piece of code. Is the 
word ?property? correct? Does ?shortcut? or ?option? fit better?

I'd recommend adding quotes around the option to look for:
448 in the right-side pane look for "Turn off Windows key hotkeys" and 
double click on it;

Consider adding an empty line before this line
450 Note: restart is required to make the settings take effect.
to make it a separate paragraph in HTML.

Regards,
Alexey

On 31/10/2019 10:56, Dmitry Markov wrote:
> Hi Alexey,
>
> I have updated the fix based on your recommendation. The new version 
> is located at: http://cr.openjdk.java.net/~dmarkov/8232880/webrev.02/
> Also please find my answers inline.
>
> Thanks,
> Dmitry
>
>> On 29 Oct 2019, at 19:29, Alexey Ivanov > > wrote:
>>
>> Hi Dmitry,
>>
>> Shall we drop hyphen in the header: ?Client UI Tests??
>>
>> I think there should be no definite article in this sentence: ?use 
>> -the- key sequences?.
>>
>> ??Turn off Windowss key hotkeys??, there's an extra ?s? in Windows.
>>
>> ?Note: restart is required to make the settings take effect.?
>> Just to confirm: is signing out and signing in not enough?
> According to Microsoft site: restart is required but I guess signing 
> out/in should work too. Unfortunately I do not have Windows on hand to 
> check it out.
>
>>
>> I'd use backticks for gpedit markup: ?Type `gpedit` in the Search??
>>
>>
>> Does it make sense to move the example into macOS section? Then the 
>> steps to disable the shortcut can be reduced to the required option 
>> only. The steps themselves should not be listed as code, i.e. no 
>> backticks.
>>
>> (For my understanding, "Turn keyboard access on or off" turns off 
>> only one specific shortcut, i.e. Ctrl+F1?)
> Yes, that?s right. I have added clarification to the doc.
>
>>
>>
>> Regards,
>> Alexey

From Sergey.Bylokhov at oracle.com  Thu Oct 31 19:53:13 2019
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 31 Oct 2019 12:53:13 -0700
Subject:  [14] RFR JDK-8230235 - Rendering HTML with empty
 img attribute and documentBaseKey cause Exception
In-Reply-To: <80b79824-124b-4d5d-87ff-edb829c1d871@default>
References: <8089f79a-94f1-4818-8fef-a678b1b6e974@default>
 <638c1045-e8f4-bc7a-8acb-2a388bb45fd1@oracle.com>
 <95fde072-6311-9793-8b8e-bc55bb1e03a0@oracle.com>
 <80b79824-124b-4d5d-87ff-edb829c1d871@default>
Message-ID: 

On 10/31/19 5:59 am, Pankaj Bansal wrote:
> << I guess that the problem is that the "image" is accessed w/o synchronization on "this" like in other places, but it will be necessary to add one null check before usage of "image".
> I have updated the code to access image with synchronization. But that does not solve the issue. So I have kept the null check also. I tried to add the null check before calling getWidth, calling getWidth still makes the image null. So the check before calling getHeight is still required.

You need to read the image to the local var under synchronization and then get W/H from the local image variable.
I guess in this case both W/H will be 0 since error is occured?

-- 
Best regards, Sergey.

From hoffmann at mountainminds.com  Thu Oct 31 18:56:51 2019
From: hoffmann at mountainminds.com (Marc Hoffmann)
Date: Thu, 31 Oct 2019 19:56:51 +0100
Subject:  Fixing compiler warnings in src/demo/share/jfc
Message-ID: <94A76E1D-D348-4729-BDDD-CADC947AC6F7@mountainminds.com>

Dear Swing maintainers,

I was referred to this mailing list from build-dev. I would like to fix the compiler warnings caused by the Swing demo code. Please find original posting below.

As I learned that attachments might be stripped please find my patches also in this gist: https://gist.github.com/marchof/59923f8e2ebab0768ed76ffb5315a2c7

Best regards,
-marc

MOTIVATION

As a developer of the JaCoCo code coverage library I do lots of JDK builds. JDK
builds are simple, fast and produce minimal log output. Nice! What annoys me
though are plenty of compiler warnings at the end of the build caused by the
example code in src/demo/share/jfc

FIX

I propose a series of 3 patches (based on each other) which fixes all compiler
warnings for the demos:

patch1.txt - Fix compiler warnings in demos: raw types
patch2.txt - Fix compiler warnings in demos: deprecated APIs
patch3.txt - Fix compiler warnings in demos: deprecated Applet APIs

While patch 1 & 2 do not change functionality patch 3 actually removes the
Applet versions of some of the demos. The java main versions of the same demos
are still intact.

The patches are based on changeset 56699:70e6b0d8db13.

They have been tested from this clone: 
https://github.com/marchof/jdk/tree/fix-compiler-warnings-in-demos

RESULT

All compiler warnings on demo code during JDK build are removed

TESTING

I haven't found any automated tests so I manually launched all the demos. From
what I can say they are still functional.

SCOPE

I applied minimal changes to remove compiler warnings only. There are many more
cleanup opportunities in the demo code. Also there is (dead?) code in
src/demo/share/java2d which has similar issues. Both are not on scope of these
patches.

NEXT STEPS

I?m have no experience with OpenJDK patches. If you?re interested in getting these warnings fixed please
let me know how I can submit these patches properly.

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch1.txt
URL: 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch2.txt
URL: 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch3.txt
URL: 
-------------- next part --------------