Integrated: 8266510: Nimbus JTree default tree cell renderer does not use selected text color

[Tejpal Rebari]

On Mon, 26 Jul 2021 05:46:44 GMT, Tejpal Rebari  wrote:

> Please review the following fix for JDK-18.
> This is revert of the fix for  nimbus jtree renderer properties persist 
> across L(https://bugs.openjdk.java.net/browse/JDK-8249674), This fixed 
> caused nimbus jtree default tree cell renderer to not use the selected text 
> color, which was white originally and changed to black after the fix. 
> Reverted the change to match original behaviour.
> 
> Tested on MacOS , Windows and Linux.

This pull request has now been integrated.

Changeset: ecd44556
Author:Tejpal Rebari 
URL:   
https://git.openjdk.java.net/jdk/commit/ecd445562f8355704a041f9eca0e87dc85a7f44c
Stats: 105 lines in 3 files changed: 0 ins; 100 del; 5 mod

8266510: Nimbus JTree default tree cell renderer does not use selected text 
color

Reviewed-by: psadhukhan, pbansal

-

PR: https://git.openjdk.java.net/jdk/pull/4903

Re: RFR: 8266510: Nimbus JTree default tree cell renderer does not use selected text color

[Tejpal Rebari]

On Mon, 26 Jul 2021 21:03:46 GMT, Sergey Bylokhov  wrote:

> Do we have a new bug to redo the 
> https://bugs.openjdk.java.net/browse/JDK-8249674 again?

Yes, https://bugs.openjdk.java.net/browse/JDK-8271315.

-

PR: https://git.openjdk.java.net/jdk/pull/4903

RFR: 8266510: Nimbus JTree default tree cell renderer does not use selected text color

[Tejpal Rebari]

Please review the following fix for JDK-18.
This is revert of the fix for  nimbus jtree renderer properties persist across 
L(https://bugs.openjdk.java.net/browse/JDK-8249674), This fixed caused nimbus 
jtree default tree cell renderer to not use the selected text color, which was 
white originally and changed to black after the fix. Reverted the change to 
match original behaviour.

Tested on MacOS , Windows and Linux.

-

Commit messages:
 - intial fix

Changes: https://git.openjdk.java.net/jdk/pull/4903/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=4903=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266510
  Stats: 105 lines in 3 files changed: 0 ins; 100 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4903.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4903/head:pull/4903

PR: https://git.openjdk.java.net/jdk/pull/4903

Re: RFR: 8268087: Update documentation of the JPasswordField

[Tejpal Rebari]

On Wed, 2 Jun 2021 01:14:39 GMT, Sergey Bylokhov  wrote:

> Some useful documentation was added to the JPasswordField.

Marked as reviewed by trebari (Committer).

-

PR: https://git.openjdk.java.net/jdk/pull/4296

Integrated: 8049700: Deprecate obsolete classes and methods in javax/swing/plaf/basic

[Tejpal Rebari]

On Wed, 6 Jan 2021 12:43:41 GMT, Tejpal Rebari  wrote:

> Please review the following fix for jdk17.
> In this fix i have deprecated and marked for removal following classes and 
> methods 
>public void intervalAdded(ListDataEvent e)
>public void intervalRemoved(ListDataEvent e)
>protected boolean lt(File a, File b) in BasicDirectoryModel.java
> 
>inner class PropertyChangeHandler, VSBChangeListener, HSBChangeListener, 
>ViewportChangeHandler in BasicScrollPaneUI.java
>inner class MouseInputHandler in BasicMenuItemUI.java
>method BasicToolBarUI.java#createFloatingFrame
> 
> From 8049700 not deprecated the paintText(Graphics g, JComponent c, Rectangle 
> textRect, String text) method in BasicButtonUI  as AquaButtonUI, 
> MetalButtonUI and MetalToggleButtonUI overrides it.
> Similarly not deprecated ChangeHandler of BasicMenuUI as AquaMenuUI and 
> MotifMenuUI uses this class.

This pull request has now been integrated.

Changeset: ebb68d2b
Author:Tejpal Rebari 
URL:   
https://git.openjdk.java.net/jdk/commit/ebb68d2b8652328b80780f6a39c78ff19f24136a
Stats: 38 lines in 4 files changed: 31 ins; 0 del; 7 mod

8049700: Deprecate obsolete classes and methods in javax/swing/plaf/basic

Reviewed-by: psadhukhan, prr, serb, azvegint, iris

-

PR: https://git.openjdk.java.net/jdk/pull/1958

Integrated: 8264950: Set opaque for JTooltip in config file of NimbusLookAndFeel

[Tejpal Rebari]

On Mon, 3 May 2021 08:54:19 GMT, Tejpal Rebari  wrote:

> Set the opaque property for JToolTip in config file (skin.laf) of 
> NimbusLookAndFeel instead of setting up in the SynthToolTipUI.
> This is related to the discussion on PR  
> https://github.com/openjdk/jdk/pull/3167.

This pull request has now been integrated.

Changeset: 30ccd808
Author:Tejpal Rebari 
URL:   
https://git.openjdk.java.net/jdk/commit/30ccd8081b3b82c04203a72c59d12a8c0a24b0c0
Stats: 3 lines in 3 files changed: 0 ins; 1 del; 2 mod

8264950: Set opaque for JTooltip in config file of NimbusLookAndFeel

Reviewed-by: serb, pbansal

-

PR: https://git.openjdk.java.net/jdk/pull/3837

RFR: 8264950: Set opaque for JTooltip in config file of NimbusLookAndFeel

[Tejpal Rebari]

Set the opaque property for JToolTip in config file (skin.laf) of 
NimbusLookAndFeel instead of setting up in the SynthToolTipUI.
This is related to the discussion on PR  
https://github.com/openjdk/jdk/pull/3167.

-

Commit messages:
 - set opaque for JTooltip in config file

Changes: https://git.openjdk.java.net/jdk/pull/3837/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=3837=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8264950
  Stats: 3 lines in 3 files changed: 0 ins; 1 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3837.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3837/head:pull/3837

PR: https://git.openjdk.java.net/jdk/pull/3837

Re: RFR: 8049700: Deprecate obsolete classes and methods in javax/swing/plaf/basic [v9]

[Tejpal Rebari]

> Please review the following fix for jdk17.
> In this fix i have deprecated and marked for removal following classes and 
> methods 
>public void intervalAdded(ListDataEvent e)
>public void intervalRemoved(ListDataEvent e)
>protected boolean lt(File a, File b) in BasicDirectoryModel.java
> 
>inner class PropertyChangeHandler, VSBChangeListener, HSBChangeListener, 
>ViewportChangeHandler in BasicScrollPaneUI.java
>inner class MouseInputHandler in BasicMenuItemUI.java
>method BasicToolBarUI.java#createFloatingFrame
> 
> From 8049700 not deprecated the paintText(Graphics g, JComponent c, Rectangle 
> textRect, String text) method in BasicButtonUI  as AquaButtonUI, 
> MetalButtonUI and MetalToggleButtonUI overrides it.
> Similarly not deprecated ChangeHandler of BasicMenuUI as AquaMenuUI and 
> MotifMenuUI uses this class.

Tejpal Rebari has updated the pull request incrementally with one additional 
commit since the last revision:

  updated according to comments on the CSR

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1958/files
  - new: https://git.openjdk.java.net/jdk/pull/1958/files/88a8c475..8d20e29d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=1958=08
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=1958=07-08

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1958.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1958/head:pull/1958

PR: https://git.openjdk.java.net/jdk/pull/1958

Re: RFR: 8039270: The background color of the button can't be displayed and when pressed the button, the background color can not be changed in accordance with the case described.

[Tejpal Rebari]

On Fri, 16 Apr 2021 09:52:35 GMT, Alexander Zuev  wrote:

> 8039270: The background color of  the button can't be displayed and when 
> pressed the button, the background color can not be changed in accordance 
> with the case described.

Marked as reviewed by trebari (Committer).

-

PR: https://git.openjdk.java.net/jdk/pull/3541

Re: RFR: 8039270: The background color of the button can't be displayed and when pressed the button, the background color can not be changed in accordance with the case described.

[Tejpal Rebari]

On Fri, 16 Apr 2021 09:52:35 GMT, Alexander Zuev  wrote:

> 8039270: The background color of  the button can't be displayed and when 
> pressed the button, the background color can not be changed in accordance 
> with the case described.

Should we also remove the deprecated JApplet from the test ?

-

PR: https://git.openjdk.java.net/jdk/pull/3541

Re: RFR: 8265278: doc build fails after JDK-8262981

[Tejpal Rebari]

On Thu, 15 Apr 2021 13:51:57 GMT, Pankaj Bansal  wrote:

> The doc build fails after the JDK-8262981. The JDK-8262981 adds a new 
> function, but by mistake the param name used in function is different from 
> the param name mentioned in @param tag. This breaks the doc build.
> 
> This change corrects the param name. I have verified that the doc build runs 
> successfully after the changes by running following command. It fails before 
> the current change and passes with the change.
> 
> "make jdk-image docs-jdk"

Marked as reviewed by trebari (Committer).

-

PR: https://git.openjdk.java.net/jdk/pull/3518

Re: RFR: 8049700: Deprecate obsolete classes and methods in javax/swing/plaf/basic [v8]

[Tejpal Rebari]

On Fri, 2 Apr 2021 22:36:04 GMT, Sergey Bylokhov  wrote:

> I think we can file a separate bug to add "for removal" in JDK 19 and then 
> remove them somewhere after JDK 22.

I have filed a separate bug for this : 
https://bugs.openjdk.java.net/browse/JDK-8264743

-

PR: https://git.openjdk.java.net/jdk/pull/1958

Integrated: 8253266 : JList and JTable constructors should clear OPAQUE_SET before calling updateUI

[Tejpal Rebari]

On Wed, 24 Mar 2021 06:17:04 GMT, Tejpal Rebari  wrote:

> Hi All,
> Please review the following fix for jdk17.
> 
> Issue : LookAndFeel.installProperty(list, "opaque", false) is not able to set 
> the opaque property for JList and JTable.
> LookAndFeel.installProperty calls the setUIProperty, and setUIProperty checks 
> for OPAQUE_SET to change the opaque property as requested by the client.
> OPAQUE_SET is always set to true when there is call to setOpaque(boolean).So 
> when the constructor calls setOpaque(true) OPAQUE_SET is set to true and wont 
> allow the setUIProperty to change the opaque property.
> installProperty should work as the opaque property is not set by the client.
> 
> Fix. Fix is to remove the call to the setOpaque() from the constructor of 
> JList and JTable. This will allow the client to change the opaque property 
> calling LookAndFeel.installProperty() when the property is already not set.
> 
> Test : Added a  test  to check the same. Also tested internal tests which all 
> are passing.
> Link is in JBS.

This pull request has now been integrated.

Changeset: 39719da9
Author:Tejpal Rebari 
URL:   https://git.openjdk.java.net/jdk/commit/39719da9
Stats: 161 lines in 7 files changed: 156 ins; 5 del; 0 mod

8253266: JList and JTable constructors should clear OPAQUE_SET before calling 
updateUI

Reviewed-by: psadhukhan, serb

-

PR: https://git.openjdk.java.net/jdk/pull/3167

Re: RFR: 8253266 : JList and JTable constructors should clear OPAQUE_SET before calling updateUI [v3]

[Tejpal Rebari]

On Mon, 5 Apr 2021 08:19:19 GMT, Tejpal Rebari  wrote:

>> src/java.desktop/share/classes/javax/swing/plaf/nimbus/skin.laf line 21581:
>> 
>>> (failed to retrieve contents of file, check the PR for context)
>> Is this newline needed?
>
> No , it automatically got added.Need to remove this.

Done

-

PR: https://git.openjdk.java.net/jdk/pull/3167

Re: RFR: 8253266 : JList and JTable constructors should clear OPAQUE_SET before calling updateUI [v6]

[Tejpal Rebari]

> Hi All,
> Please review the following fix for jdk17.
> 
> Issue : LookAndFeel.installProperty(list, "opaque", false) is not able to set 
> the opaque property for JList and JTable.
> LookAndFeel.installProperty calls the setUIProperty, and setUIProperty checks 
> for OPAQUE_SET to change the opaque property as requested by the client.
> OPAQUE_SET is always set to true when there is call to setOpaque(boolean).So 
> when the constructor calls setOpaque(true) OPAQUE_SET is set to true and wont 
> allow the setUIProperty to change the opaque property.
> installProperty should work as the opaque property is not set by the client.
> 
> Fix. Fix is to remove the call to the setOpaque() from the constructor of 
> JList and JTable. This will allow the client to change the opaque property 
> calling LookAndFeel.installProperty() when the property is already not set.
> 
> Test : Added a  test  to check the same. Also tested internal tests which all 
> are passing.
> Link is in JBS.

Tejpal Rebari has updated the pull request incrementally with one additional 
commit since the last revision:

  set skin.laf as before

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3167/files
  - new: https://git.openjdk.java.net/jdk/pull/3167/files/e3b3e8c6..effda12b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=3167=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=3167=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3167.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3167/head:pull/3167

PR: https://git.openjdk.java.net/jdk/pull/3167

Re: RFR: 8253266 : JList and JTable constructors should clear OPAQUE_SET before calling updateUI [v3]

[Tejpal Rebari]

On Mon, 5 Apr 2021 07:44:59 GMT, Prasanta Sadhukhan  
wrote:

>> Tejpal Rebari has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   Fix for JTree JTooltip and JViewport keeping default opaque value same, 
>> modified the test
>
> src/java.desktop/share/classes/javax/swing/plaf/nimbus/skin.laf line 21581:
> 
>> (failed to retrieve contents of file, check the PR for context)
> Is this newline needed?

No , it automatically got added.Need to remove this.

-

PR: https://git.openjdk.java.net/jdk/pull/3167

Re: RFR: 8253266 : JList and JTable constructors should clear OPAQUE_SET before calling updateUI [v5]

[Tejpal Rebari]

> Hi All,
> Please review the following fix for jdk17.
> 
> Issue : LookAndFeel.installProperty(list, "opaque", false) is not able to set 
> the opaque property for JList and JTable.
> LookAndFeel.installProperty calls the setUIProperty, and setUIProperty checks 
> for OPAQUE_SET to change the opaque property as requested by the client.
> OPAQUE_SET is always set to true when there is call to setOpaque(boolean).So 
> when the constructor calls setOpaque(true) OPAQUE_SET is set to true and wont 
> allow the setUIProperty to change the opaque property.
> installProperty should work as the opaque property is not set by the client.
> 
> Fix. Fix is to remove the call to the setOpaque() from the constructor of 
> JList and JTable. This will allow the client to change the opaque property 
> calling LookAndFeel.installProperty() when the property is already not set.
> 
> Test : Added a  test  to check the same. Also tested internal tests which all 
> are passing.
> Link is in JBS.

Tejpal Rebari has updated the pull request incrementally with one additional 
commit since the last revision:

  set default opaque property for nimbus JToolTip in SynthToolTipUI instead of 
skin.laf

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3167/files
  - new: https://git.openjdk.java.net/jdk/pull/3167/files/953bc3aa..e3b3e8c6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=3167=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=3167=03-04

  Stats: 2 lines in 2 files changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3167.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3167/head:pull/3167

PR: https://git.openjdk.java.net/jdk/pull/3167

Re: RFR: 8253266 : JList and JTable constructors should clear OPAQUE_SET before calling updateUI [v3]

[Tejpal Rebari]

On Mon, 5 Apr 2021 07:08:32 GMT, Prasanta Sadhukhan  
wrote:

>> No, it doesn't work, i have checked.
>> The change needs to be skin.laf file only.
>
> I am not sure where you placed the code. I think it's need to be added after 
> updateStyle() as updateStyle() uninstall the default and install for new 
> style.
> protected void installDefaults(JComponent c) {
> updateStyle(c);
> }

yeah setting the property after updateStyle(c) works fine.
updating the change in the SynthToolTipUI.installDefaults()

-

PR: https://git.openjdk.java.net/jdk/pull/3167

Re: RFR: 8253266 : JList and JTable constructors should clear OPAQUE_SET before calling updateUI [v3]

[Tejpal Rebari]

On Mon, 5 Apr 2021 05:19:06 GMT, Prasanta Sadhukhan  
wrote:

>> Tejpal Rebari has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   Fix for JTree JTooltip and JViewport keeping default opaque value same, 
>> modified the test
>
> src/java.desktop/share/classes/javax/swing/plaf/nimbus/skin.laf line 27251:
> 
>> (failed to retrieve contents of file, check the PR for context)
> In my opinion, instead of changing skin.laf we probably should update 
> SynthToolTipUI.installDefaults() and add 
> `LookAndFeel.installProperty(c, "opaque", Boolean.TRUE);`
> 
> similar to what we do for BasicToolTipUI.installDefaults. Will it not work?

No, it doesn't work, i have checked.
The change needs to be skin.laf file only.

-

PR: https://git.openjdk.java.net/jdk/pull/3167

Re: RFR: 8253266 : JList and JTable constructors should clear OPAQUE_SET before calling updateUI [v3]

[Tejpal Rebari]

On Mon, 5 Apr 2021 05:19:49 GMT, Prasanta Sadhukhan  
wrote:

>> Tejpal Rebari has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   Fix for JTree JTooltip and JViewport keeping default opaque value same, 
>> modified the test
>
> test/jdk/javax/swing/JList/TestOpaqueListTable.java line 24:
> 
>> 22:  */
>> 23: 
>> 24: import javax.swing.*;
> 
> Can you please update this wildcard imports?

Done

-

PR: https://git.openjdk.java.net/jdk/pull/3167

Re: RFR: 8253266 : JList and JTable constructors should clear OPAQUE_SET before calling updateUI [v4]

[Tejpal Rebari]

> Hi All,
> Please review the following fix for jdk17.
> 
> Issue : LookAndFeel.installProperty(list, "opaque", false) is not able to set 
> the opaque property for JList and JTable.
> LookAndFeel.installProperty calls the setUIProperty, and setUIProperty checks 
> for OPAQUE_SET to change the opaque property as requested by the client.
> OPAQUE_SET is always set to true when there is call to setOpaque(boolean).So 
> when the constructor calls setOpaque(true) OPAQUE_SET is set to true and wont 
> allow the setUIProperty to change the opaque property.
> installProperty should work as the opaque property is not set by the client.
> 
> Fix. Fix is to remove the call to the setOpaque() from the constructor of 
> JList and JTable. This will allow the client to change the opaque property 
> calling LookAndFeel.installProperty() when the property is already not set.
> 
> Test : Added a  test  to check the same. Also tested internal tests which all 
> are passing.
> Link is in JBS.

Tejpal Rebari has updated the pull request incrementally with one additional 
commit since the last revision:

  removed wildcard imports

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3167/files
  - new: https://git.openjdk.java.net/jdk/pull/3167/files/67fbef16..953bc3aa

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=3167=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=3167=02-03

  Stats: 9 lines in 1 file changed: 8 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3167.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3167/head:pull/3167

PR: https://git.openjdk.java.net/jdk/pull/3167

Re: RFR: 8253266 : JList and JTable constructors should clear OPAQUE_SET before calling updateUI [v3]

[Tejpal Rebari]

On Mon, 5 Apr 2021 05:20:26 GMT, Prasanta Sadhukhan  
wrote:

>> Tejpal Rebari has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   Fix for JTree JTooltip and JViewport keeping default opaque value same, 
>> modified the test
>
> test/jdk/javax/swing/JList/TestOpaqueListTable.java line 31:
> 
>> 29:  *  @summary setUIProperty should work when opaque property is not set by
>> 30:  *  client
>> 31:  *  @key headful
> 
> Does it need to be headful?

It is better to run this test on headful systems, which has the required 
components installed.
This test checks for all look and feel. I remember making one of the non ui 
test as not headful and it thrown LookAndFeelNot installed exception.
So one of the suggestion was to make it headful, so doing the same here.

-

PR: https://git.openjdk.java.net/jdk/pull/3167

Re: RFR: 8049700: Deprecate obsolete classes and methods in javax/swing/plaf/basic [v8]

[Tejpal Rebari]

On Thu, 1 Apr 2021 23:43:25 GMT, Phil Race  wrote:

>> Marked as reviewed by prr (Reviewer).
>
> The CSR still had forRemoval. I've updated it and generally tidied it, but 
> you may want to check my work.

I have checked the CSR, made minor corrections. 
Overall looks good, thanks for updating it.

-

PR: https://git.openjdk.java.net/jdk/pull/1958

Re: RFR: 8253266 : JList and JTable constructors should clear OPAQUE_SET before calling updateUI [v2]

[Tejpal Rebari]

On Thu, 1 Apr 2021 14:43:36 GMT, Tejpal Rebari  wrote:

>> Please wait for the @prsadhuk approval as well.
>
> I have fixed the issue with JTree, JTooltip and JViewport same way.
> While fixing for JTooltip discovered that default value for JToolTip opaque 
> property for Nimbus LookAndFeel is set to false in the skin.laf file. This 
> value was never taken into account because the setOpaque(true) from the 
> JTooltip was overriding this.
> As we are now removing it from the constructor of JTooptip, NimbusLAF is 
> setting to the false.
> To keep the behaviour same as before i have set it to true for NimbusLAF.
> 
> Also modified the test to check for JTooltip , JTree and JViewport.

Internal testing looks good, link is in JBS

-

PR: https://git.openjdk.java.net/jdk/pull/3167

Re: RFR: 8253266 : JList and JTable constructors should clear OPAQUE_SET before calling updateUI [v2]

[Tejpal Rebari]

On Wed, 31 Mar 2021 20:34:51 GMT, Sergey Bylokhov  wrote:

>> Tejpal Rebari has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   Added default value check for opaque property
>
> Please wait for the @prsadhuk approval as well.

I have fixed the issue with JTree, JTooltip and JViewport same way.
While fixing for JTooltip discovered that default value for JToolTip opaque 
property for Nimbus LookAndFeel is set to false in the skin.laf file. This 
value was never taken into account because the setOpaque(true) from the 
JTooltip was overriding this.
As we are now removing it from the constructor of JTooptip, NimbusLAF is 
setting to the false.
To keep the behaviour same as before i have set it to true for NimbusLAF.

Also modified the test to check for JTooltip , JTree and JViewport.

-

PR: https://git.openjdk.java.net/jdk/pull/3167

Re: RFR: 8253266 : JList and JTable constructors should clear OPAQUE_SET before calling updateUI [v3]

[Tejpal Rebari]

> Hi All,
> Please review the following fix for jdk17.
> 
> Issue : LookAndFeel.installProperty(list, "opaque", false) is not able to set 
> the opaque property for JList and JTable.
> LookAndFeel.installProperty calls the setUIProperty, and setUIProperty checks 
> for OPAQUE_SET to change the opaque property as requested by the client.
> OPAQUE_SET is always set to true when there is call to setOpaque(boolean).So 
> when the constructor calls setOpaque(true) OPAQUE_SET is set to true and wont 
> allow the setUIProperty to change the opaque property.
> installProperty should work as the opaque property is not set by the client.
> 
> Fix. Fix is to remove the call to the setOpaque() from the constructor of 
> JList and JTable. This will allow the client to change the opaque property 
> calling LookAndFeel.installProperty() when the property is already not set.
> 
> Test : Added a  test  to check the same. Also tested internal tests which all 
> are passing.
> Link is in JBS.

Tejpal Rebari has updated the pull request incrementally with one additional 
commit since the last revision:

  Fix for JTree JTooltip and JViewport keeping default opaque value same, 
modified the test

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3167/files
  - new: https://git.openjdk.java.net/jdk/pull/3167/files/eec8b913..67fbef16

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=3167=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=3167=01-02

  Stats: 88 lines in 5 files changed: 63 ins; 11 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3167.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3167/head:pull/3167

PR: https://git.openjdk.java.net/jdk/pull/3167

Re: RFR: 8049700: Deprecate obsolete classes and methods in javax/swing/plaf/basic [v6]

[Tejpal Rebari]

On Wed, 10 Feb 2021 18:04:16 GMT, Phil Race  wrote:

>> Tejpal Rebari has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   removed deprecation from methods of class which is also getting deprecated
>
> Are these methods all expected to be used only by a L rather than an 
> application ?
> If by an application, then forRemoval seems too strong to me.
> If by a L then I think you need to go research what open source L there 
> are out there and see how many of them are affected. Then we can decide about 
> forRemoval.

@prrace any more comments on this ?

-

PR: https://git.openjdk.java.net/jdk/pull/1958

Re: RFR: 8253266 : JList and JTable constructors should clear OPAQUE_SET before calling updateUI [v2]

[Tejpal Rebari]

On Wed, 24 Mar 2021 08:27:40 GMT, Prasanta Sadhukhan  
wrote:

>> Tejpal Rebari has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   Added default value check for opaque property
>
> I am not sure if this is the correct fix, as then we would have to remove 
> setOpaque call for JTree, JToolTip, JRootPane etc where we might face same 
> installProperty issue. 
> Also, if we have to change this, we then need to change "autoScrolls" 
> property too which is set in this 2 component and setUIProperty() can change 
> those too.
> Probably, we need to check if the value to be set is different in 
> setUIProperty and then set it 
> or 
> override setUIProperty per component basis (as it is done for JTable) and 
> then not check for OPAQUE_SET flag for opaque property accordingly.

@prsadhuk  @mrserb is there any more comments on this.

-

PR: https://git.openjdk.java.net/jdk/pull/3167

Re: RFR: 8264328: Broken license in javax/swing/JComboBox/8072767/bug8072767.java

[Tejpal Rebari]

On Sun, 28 Mar 2021 00:21:16 GMT, Sergey Bylokhov  wrote:

> This test has a broken license:
> /*
>  * To change this license header, choose License Headers in Project 
> Properties.
>  * To change this template file, choose Tools | Templates
>  /*
>  * Copyright (c) 2015, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.

Marked as reviewed by trebari (Committer).

-

PR: https://git.openjdk.java.net/jdk/pull/3230

Re: RFR: 8253266 : JList and JTable constructors should clear OPAQUE_SET before calling updateUI [v2]

[Tejpal Rebari]

> Hi All,
> Please review the following fix for jdk17.
> 
> Issue : LookAndFeel.installProperty(list, "opaque", false) is not able to set 
> the opaque property for JList and JTable.
> LookAndFeel.installProperty calls the setUIProperty, and setUIProperty checks 
> for OPAQUE_SET to change the opaque property as requested by the client.
> OPAQUE_SET is always set to true when there is call to setOpaque(boolean).So 
> when the constructor calls setOpaque(true) OPAQUE_SET is set to true and wont 
> allow the setUIProperty to change the opaque property.
> installProperty should work as the opaque property is not set by the client.
> 
> Fix. Fix is to remove the call to the setOpaque() from the constructor of 
> JList and JTable. This will allow the client to change the opaque property 
> calling LookAndFeel.installProperty() when the property is already not set.
> 
> Test : Added a  test  to check the same. Also tested internal tests which all 
> are passing.
> Link is in JBS.

Tejpal Rebari has updated the pull request incrementally with one additional 
commit since the last revision:

  Added default value check for opaque property

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3167/files
  - new: https://git.openjdk.java.net/jdk/pull/3167/files/aafac8f2..eec8b913

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=3167=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=3167=00-01

  Stats: 11 lines in 1 file changed: 11 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3167.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3167/head:pull/3167

PR: https://git.openjdk.java.net/jdk/pull/3167

Re: RFR: 8253266 : JList and JTable constructors should clear OPAQUE_SET before calling updateUI

[Tejpal Rebari]

On Thu, 25 Mar 2021 06:44:10 GMT, Sergey Bylokhov  wrote:

>> Hi All,
>> Please review the following fix for jdk17.
>> 
>> Issue : LookAndFeel.installProperty(list, "opaque", false) is not able to 
>> set the opaque property for JList and JTable.
>> LookAndFeel.installProperty calls the setUIProperty, and setUIProperty 
>> checks for OPAQUE_SET to change the opaque property as requested by the 
>> client.
>> OPAQUE_SET is always set to true when there is call to setOpaque(boolean).So 
>> when the constructor calls setOpaque(true) OPAQUE_SET is set to true and 
>> wont allow the setUIProperty to change the opaque property.
>> installProperty should work as the opaque property is not set by the client.
>> 
>> Fix. Fix is to remove the call to the setOpaque() from the constructor of 
>> JList and JTable. This will allow the client to change the opaque property 
>> calling LookAndFeel.installProperty() when the property is already not set.
>> 
>> Test : Added a  test  to check the same. Also tested internal tests which 
>> all are passing.
>> Link is in JBS.
>
> test/jdk/javax/swing/JList/TestOpaqueListTable.java line 38:
> 
>> 36: 
>> 37: public static void main(String[] args) throws Exception {
>> 38: UIManager.LookAndFeelInfo[] installedLookAndFeels;
> 
> I did not look close to the fix, but you need to check that the default value 
> of the "opaque" property will not be changed. So all default L will set it 
> to true, as before the fix.

Yeah, the default value for "opaque" property will not be changed.
It will be true for All L after the fix as well , I will add  that check to 
the test.

-

PR: https://git.openjdk.java.net/jdk/pull/3167

Re: RFR: 8253266 : JList and JTable constructors should clear OPAQUE_SET before calling updateUI

[Tejpal Rebari]

On Wed, 24 Mar 2021 08:27:40 GMT, Prasanta Sadhukhan  
wrote:

> I am not sure if this is the correct fix, as then we would have to remove 
> setOpaque call for JTree, JToolTip, JRootPane etc where we might face same 
> installProperty issue.

Yes we face the same issue in JTree, JToolTip, and JViewport , 
but many of the components do not  have this problem like JButton JRootPane , 
JCheckbox, JInternalFrame, JMenuItem, JCheckBoxMenuItem, JPopupMenu, JMenu ..etc
We can fix the issue with JTree, JTooltip and JViewport same way.

> Also, if we have to change this, we then need to change "autoScrolls" 
> property too which is set in this 2 component and setUIProperty() can change 
> those too.
> Probably, we need to check if the value to be set is different in 
> setUIProperty and then set it 
> or
> override setUIProperty per component basis (as it is done for JTable) and 
> then not check for OPAQUE_SET flag for opaque property accordingly.

OPAQUE_SET is private variable and can not be accessed in JTable or JTree. 
>From the spec of LookAndFeel.installProperty and setUIProperty it
  * Sets the property with the specified name to the specified value if
 * the property has not already been set by the client program.*
 is clear that once the property is set by the client setUIProperty can not 
change it. And OPAUQE_SET  is  used  for  that
.

Removing the setOpaque() from the constructor of these component will not make 
any initial difference as it is also set to true in BasicListUI, BasicTableUI, 
BasicTreeUI, BasicTooltipUI and BasicViewportUI by calling 
LookAndFeel.installProperty.
The difference which it will make is now by calling 
LookAndFeel.installProperty(c,opaque,false) will clear the opaque property.

-

PR: https://git.openjdk.java.net/jdk/pull/3167

Re: RFR: 8263454: com.apple.laf.AquaFileChooserUI ignores the result of String.trim() [v2]

[Tejpal Rebari]

On Tue, 23 Mar 2021 14:55:58 GMT, Alexander Zvegintsev  
wrote:

>> Looks like the original idea was to set `fallbacktext` on strings containing 
>> only spaces.
>> 
>> I decided to remove the `trim()` call to keep the same behavior and to 
>> allows to set such meaningless space only titles/tooltips(same as on other 
>> platforms, maybe someone want empty label for some reason).
>
> Alexander Zvegintsev has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   allow empty text

Marked as reviewed by trebari (Committer).

-

PR: https://git.openjdk.java.net/jdk/pull/3136

RFR: 8253266 : JList and JTable constructors should clear OPAQUE_SET before calling updateUI

[Tejpal Rebari]

Hi All,
Please review the following fix for jdk17.

Issue : LookAndFeel.installProperty(list, "opaque", false) is not able to set 
the opaque property for JList and JTable.
LookAndFeel.installProperty calls the setUIProperty, and setUIProperty checks 
for OPAQUE_SET to change the opaque property as requested by the client.
OPAQUE_SET is always set to true when there is call to setOpaque(boolean).So 
when the constructor calls setOpaque(true) OPAQUE_SET is set to true and wont 
allow the setUIProperty to change the opaque property.
installProperty should work as the opaque property is not set by the client.

Fix. Fix is to remove the call to the setOpaque() from the constructor of JList 
and JTable. This will allow the client to change the opaque property calling 
LookAndFeel.installProperty() when the property is already not set.

Test : Added a  test  to check the same. Also tested internal tests which all 
are passing.
Link is in JBS.

-

Commit messages:
 - intial changes

Changes: https://git.openjdk.java.net/jdk/pull/3167/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=3167=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8253266
  Stats: 83 lines in 3 files changed: 81 ins; 2 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3167.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3167/head:pull/3167

PR: https://git.openjdk.java.net/jdk/pull/3167

Re: RFR: 8263768: JFormattedTextField.AbstractFormatter.getDocumentFilter()/getNavigationFilter() spec doesn't mention what the default impls return and what does it mean

[Tejpal Rebari]

On Thu, 18 Mar 2021 04:46:03 GMT, Prasanta Sadhukhan  
wrote:

> Default implementation of 
> JFormattedTextField.AbstractFormatter.getDocumentFilter()/getNavigationFilter()
>  returns null but it is not mentioned in the spec.
> It is now explicitly mentioned in the spec by @impNote tag.

Marked as reviewed by trebari (Committer).

-

PR: https://git.openjdk.java.net/jdk/pull/3064

Re: RFR: 8263170: ComboBoxModel documentation refers to a nonexistant type

[Tejpal Rebari]

On Tue, 9 Mar 2021 04:10:38 GMT, Prasanta Sadhukhan  
wrote:

> javadoc of ComboBoxModel incorrectly specifies "extends ListDataModel" but 
> actually it extends ListModel and there is no such interface as 
> ListDataModel. Rectified the anomaly.

Marked as reviewed by trebari (Committer).

-

PR: https://git.openjdk.java.net/jdk/pull/2886

Re: RFR: 8049700: Deprecate obsolete classes and methods in javax/swing/plaf/basic [v6]

[Tejpal Rebari]

On Wed, 10 Feb 2021 18:04:16 GMT, Phil Race  wrote:

>> Tejpal Rebari has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   removed deprecation from methods of class which is also getting deprecated
>
> Are these methods all expected to be used only by a L rather than an 
> application ?
> If by an application, then forRemoval seems too strong to me.
> If by a L then I think you need to go research what open source L there 
> are out there and see how many of them are affected. Then we can decide about 
> forRemoval.

@prrace Please take a look.

-

PR: https://git.openjdk.java.net/jdk/pull/1958

Re: RFR: 8049700: Deprecate obsolete classes and methods in javax/swing/plaf/basic [v8]

[Tejpal Rebari]

> Please review the following fix for jdk17.
> In this fix i have deprecated and marked for removal following classes and 
> methods 
>public void intervalAdded(ListDataEvent e)
>public void intervalRemoved(ListDataEvent e)
>protected boolean lt(File a, File b) in BasicDirectoryModel.java
> 
>inner class PropertyChangeHandler, VSBChangeListener, HSBChangeListener, 
>ViewportChangeHandler in BasicScrollPaneUI.java
>inner class MouseInputHandler in BasicMenuItemUI.java
>method BasicToolBarUI.java#createFloatingFrame
> 
> From 8049700 not deprecated the paintText(Graphics g, JComponent c, Rectangle 
> textRect, String text) method in BasicButtonUI  as AquaButtonUI, 
> MetalButtonUI and MetalToggleButtonUI overrides it.
> Similarly not deprecated ChangeHandler of BasicMenuUI as AquaMenuUI and 
> MotifMenuUI uses this class.

Tejpal Rebari has updated the pull request with a new target base due to a 
merge or a rebase. The incremental webrev excludes the unrelated changes 
brought in by the merge/rebase. The pull request contains eight additional 
commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into 8049700
 - removed forRemoval
 - removed deprecation from methods of class which is also getting deprecated
 - removed jdk version from @deprecated javadoc tag
 - updated documentation
 - Merge remote-tracking branch 'upstream/master' into 8049700
 - minor correction
 - initial fix

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1958/files
  - new: https://git.openjdk.java.net/jdk/pull/1958/files/7dd2b39a..88a8c475

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=1958=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=1958=06-07

  Stats: 69867 lines in 2030 files changed: 41455 ins; 17817 del; 10595 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1958.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1958/head:pull/1958

PR: https://git.openjdk.java.net/jdk/pull/1958

Re: RFR: 8049700: Deprecate obsolete classes and methods in javax/swing/plaf/basic [v6]

[Tejpal Rebari]

On Fri, 19 Feb 2021 15:45:55 GMT, Tejpal Rebari  wrote:

> Are these methods all expected to be used only by a L rather than an 
> application ?
> If by an application, then forRemoval seems too strong to me.
> If by a L then I think you need to go research what open source L there 
> are out there and see how many of them are affected. Then we can decide about 
> forRemoval.

There are open source LAFs which will be affected by removing these.
Like FlatLaf https://www.formdev.com/flatlaf/ uses 
BasicScrollPaneUI$PropertyChangeHandler.
Also i have removed the "forRemoval" for now.

-

PR: https://git.openjdk.java.net/jdk/pull/1958

Re: RFR: 8049700: Deprecate obsolete classes and methods in javax/swing/plaf/basic [v7]

[Tejpal Rebari]

> Please review the following fix for jdk17.
> In this fix i have deprecated and marked for removal following classes and 
> methods 
>public void intervalAdded(ListDataEvent e)
>public void intervalRemoved(ListDataEvent e)
>protected boolean lt(File a, File b) in BasicDirectoryModel.java
> 
>inner class PropertyChangeHandler, VSBChangeListener, HSBChangeListener, 
>ViewportChangeHandler in BasicScrollPaneUI.java
>inner class MouseInputHandler in BasicMenuItemUI.java
>method BasicToolBarUI.java#createFloatingFrame
> 
> From 8049700 not deprecated the paintText(Graphics g, JComponent c, Rectangle 
> textRect, String text) method in BasicButtonUI  as AquaButtonUI, 
> MetalButtonUI and MetalToggleButtonUI overrides it.
> Similarly not deprecated ChangeHandler of BasicMenuUI as AquaMenuUI and 
> MotifMenuUI uses this class.

Tejpal Rebari has updated the pull request incrementally with one additional 
commit since the last revision:

  removed forRemoval

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1958/files
  - new: https://git.openjdk.java.net/jdk/pull/1958/files/7d674c13..7dd2b39a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=1958=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=1958=05-06

  Stats: 9 lines in 4 files changed: 0 ins; 0 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1958.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1958/head:pull/1958

PR: https://git.openjdk.java.net/jdk/pull/1958

Re: RFR: 8049700: Deprecate obsolete classes and methods in javax/swing/plaf/basic [v6]

[Tejpal Rebari]

On Wed, 10 Feb 2021 18:04:16 GMT, Phil Race  wrote:

> Are these methods all expected to be used only by a L rather than an 
> application ?
> If by an application, then forRemoval seems too strong to me.
> If by a L then I think you need to go research what open source L there 
> are out there and see how many of them are affected. Then we can decide about 
> forRemoval.

After the fix i have ran all the automated jtreg and jck (link is in the JBS) 
and not seeing any issues there.
I also ran SwingSet2 with Aqua, Metal, Motif, Nimbus, Windows, Windows Classic, 
and GTK LookAndFeel
 with debug statement in each of the deprecated methods and class, 
and none of the methods and classes are getting called in any of the LAF's.

For now we can remove the "forRemoval".

-

PR: https://git.openjdk.java.net/jdk/pull/1958

Re: RFR: 8260291: The case instruction is not visible in dark mode [v2]

[Tejpal Rebari]

On Mon, 15 Feb 2021 06:36:58 GMT, Pankaj Bansal  wrote:

>> Please review a trivial test only fix.
>> 
>> This is a GTKL specific manual test and create an instruction panel 
>> containing JTextArea. The JTextArea background color is hardcoded as white 
>> color, which is causing issues on dark mode in Ubuntu 20.04 and Ubuntu 20.10 
>> as the text color is also white. The fix is to remove the hardcoded white 
>> color as the JTextArea background color should be set by L and should not 
>> be hardcoded in test.
>
> Pankaj Bansal has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Revert "Add bugID"
>   
>   This reverts commit a84b6098bee8122abd159209a1ff857db716f4b4.

Marked as reviewed by trebari (Committer).

-

PR: https://git.openjdk.java.net/jdk/pull/2564

Re: RFR: 8260291: The case instruction is not visible in dark mode

[Tejpal Rebari]

On Sun, 14 Feb 2021 07:49:39 GMT, Pankaj Bansal  wrote:

> Please review a trivial test only fix.
> 
> This is a GTKL specific manual test and create an instruction panel 
> containing JTextArea. The JTextArea background color is hardcoded as white 
> color, which is causing issues on dark mode in Ubuntu 20.04 and Ubuntu 20.10 
> as the text color is also white. The fix is to remove the hardcoded white 
> color as the JTextArea background color should be set by L and should not 
> be hardcoded in test.

test/jdk/javax/swing/JSpinner/TestJSpinnerPressUnpress.java line 26:

> 24: /*
> 25:  * @test
> 26:  * @bug 8234733 8260291

There is no need to add bug id 8260291 here.
http://openjdk.java.net/jtreg/faq.html#when-should-i-update-the-bug-entry-in-a-test-description

-

PR: https://git.openjdk.java.net/jdk/pull/2564

Re: RFR: 8049700: Deprecate obsolete classes and methods in javax/swing/plaf/basic [v6]

[Tejpal Rebari]

> Please review the following fix for jdk17.
> In this fix i have deprecated and marked for removal following classes and 
> methods 
>public void intervalAdded(ListDataEvent e)
>public void intervalRemoved(ListDataEvent e)
>protected boolean lt(File a, File b) in BasicDirectoryModel.java
> 
>inner class PropertyChangeHandler, VSBChangeListener, HSBChangeListener, 
>ViewportChangeHandler in BasicScrollPaneUI.java
>inner class MouseInputHandler in BasicMenuItemUI.java
>method BasicToolBarUI.java#createFloatingFrame
> 
> From 8049700 not deprecated the paintText(Graphics g, JComponent c, Rectangle 
> textRect, String text) method in BasicButtonUI  as AquaButtonUI, 
> MetalButtonUI and MetalToggleButtonUI overrides it.
> Similarly not deprecated ChangeHandler of BasicMenuUI as AquaMenuUI and 
> MotifMenuUI uses this class.

Tejpal Rebari has updated the pull request incrementally with one additional 
commit since the last revision:

  removed deprecation from methods of class which is also getting deprecated

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1958/files
  - new: https://git.openjdk.java.net/jdk/pull/1958/files/6b989061..7d674c13

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=1958=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=1958=04-05

  Stats: 21 lines in 2 files changed: 0 ins; 21 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1958.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1958/head:pull/1958

PR: https://git.openjdk.java.net/jdk/pull/1958

Re: RFR: 8049700: Deprecate obsolete classes and methods in javax/swing/plaf/basic [v5]

[Tejpal Rebari]

> Please review the following fix for jdk17.
> In this fix i have deprecated and marked for removal following classes and 
> methods 
>public void intervalAdded(ListDataEvent e)
>public void intervalRemoved(ListDataEvent e)
>protected boolean lt(File a, File b) in BasicDirectoryModel.java
> 
>inner class PropertyChangeHandler, VSBChangeListener, HSBChangeListener, 
>ViewportChangeHandler in BasicScrollPaneUI.java
>inner class MouseInputHandler in BasicMenuItemUI.java
>method BasicToolBarUI.java#createFloatingFrame
> 
> From 8049700 not deprecated the paintText(Graphics g, JComponent c, Rectangle 
> textRect, String text) method in BasicButtonUI  as AquaButtonUI, 
> MetalButtonUI and MetalToggleButtonUI overrides it.
> Similarly not deprecated ChangeHandler of BasicMenuUI as AquaMenuUI and 
> MotifMenuUI uses this class.

Tejpal Rebari has updated the pull request incrementally with one additional 
commit since the last revision:

  removed jdk version from @deprecated javadoc tag

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1958/files
  - new: https://git.openjdk.java.net/jdk/pull/1958/files/cf0bc946..6b989061

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=1958=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=1958=03-04

  Stats: 15 lines in 4 files changed: 1 ins; 0 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1958.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1958/head:pull/1958

PR: https://git.openjdk.java.net/jdk/pull/1958

Re: RFR: 8049700: Deprecate obsolete classes and methods in javax/swing/plaf/basic [v4]

[Tejpal Rebari]

On Mon, 1 Feb 2021 08:56:32 GMT, Prasanta Sadhukhan  
wrote:

>> Tejpal Rebari has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   updated documentation
>
> It probably will need CSR

I have created CSR : 
[JDK-8260921](https://bugs.openjdk.java.net/browse/JDK-8260921)
Please take a look.

-

PR: https://git.openjdk.java.net/jdk/pull/1958

Re: RFR: 8049700: Deprecate obsolete classes and methods in javax/swing/plaf/basic [v4]

[Tejpal Rebari]

> Please review the following fix for jdk17.
> In this fix i have deprecated and marked for removal following classes and 
> methods 
>public void intervalAdded(ListDataEvent e)
>public void intervalRemoved(ListDataEvent e)
>protected boolean lt(File a, File b) in BasicDirectoryModel.java
> 
>inner class PropertyChangeHandler, VSBChangeListener, HSBChangeListener, 
>ViewportChangeHandler in BasicScrollPaneUI.java
>inner class MouseInputHandler in BasicMenuItemUI.java
>method BasicToolBarUI.java#createFloatingFrame
> 
> From 8049700 not deprecated the paintText(Graphics g, JComponent c, Rectangle 
> textRect, String text) method in BasicButtonUI  as AquaButtonUI, 
> MetalButtonUI and MetalToggleButtonUI overrides it.
> Similarly not deprecated ChangeHandler of BasicMenuUI as AquaMenuUI and 
> MotifMenuUI uses this class.

Tejpal Rebari has updated the pull request incrementally with one additional 
commit since the last revision:

  updated documentation

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1958/files
  - new: https://git.openjdk.java.net/jdk/pull/1958/files/487c3447..cf0bc946

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=1958=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=1958=02-03

  Stats: 24 lines in 4 files changed: 13 ins; 0 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1958.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1958/head:pull/1958

PR: https://git.openjdk.java.net/jdk/pull/1958

Re: RFR: 8049700: Deprecate obsolete classes and methods in javax/swing/plaf/basic [v4]

[Tejpal Rebari]

On Mon, 25 Jan 2021 12:14:51 GMT, Prasanta Sadhukhan  
wrote:

> > The methods intervalAdded(ListDataEvent e) ,intervalRemoved(ListDataEvent 
> > e) and lt(File a, File b) of 
> > javax/swing/plaf/basic/BasicDirectoryModel.java states that "Obsolete - not 
> > used" ( in the doc).
> > The BasicDirectoryModel uses similar methods like fireIntervalAdded, 
> > fireIntervalRemoved which calls AbstractListModel#fireIntervalAdded.
> > But not sure that these are the alternate methods.Also dont see anything 
> > similar to lt(File a, File b).
> > The method createFloatingFrame in the BasicToolBarUI.java states that it is 
> > "No longer used" and also specifies to use 
> > BasicToolBarUI.createFloatingWindow(JToolBar).
> > The class MouseInputHandler in BasicMenuUI.java and classes 
> > PropertyChangeHandler, VSBChangeListener, HSBChangeListener, 
> > ViewportChangeHandler in BasicScrollPaneUI.java states that(as comments 
> > inside the class)
> > "This class exists only for backward compatibility. All
> > its functionality has been moved into Handler."
> > we can add the above in the doc for these classes.
> 
> OK. Please add these statements in the doc, wherever possible.
I have updated the documentation for some of the classes. Also changed 
copyright year.
> Also, try to run all jtreg/jck tests with these classes/methods removed so 
> that we dont get any surprises once they are removed.
i have ran all the jtreg/jck tests ,the link is in bug description.

-

PR: https://git.openjdk.java.net/jdk/pull/1958

Re: RFR: 8049700: Deprecate obsolete classes and methods in javax/swing/plaf/basic [v3]

[Tejpal Rebari]

> Please review the following fix for jdk17.
> In this fix i have deprecated and marked for removal following classes and 
> methods 
>public void intervalAdded(ListDataEvent e)
>public void intervalRemoved(ListDataEvent e)
>protected boolean lt(File a, File b) in BasicDirectoryModel.java
> 
>inner class PropertyChangeHandler, VSBChangeListener, HSBChangeListener, 
>ViewportChangeHandler in BasicScrollPaneUI.java
>inner class MouseInputHandler in BasicMenuItemUI.java
>method BasicToolBarUI.java#createFloatingFrame
> 
> From 8049700 not deprecated the paintText(Graphics g, JComponent c, Rectangle 
> textRect, String text) method in BasicButtonUI  as AquaButtonUI, 
> MetalButtonUI and MetalToggleButtonUI overrides it.
> Similarly not deprecated ChangeHandler of BasicMenuUI as AquaMenuUI and 
> MotifMenuUI uses this class.

Tejpal Rebari has updated the pull request with a new target base due to a 
merge or a rebase. The incremental webrev excludes the unrelated changes 
brought in by the merge/rebase. The pull request contains three additional 
commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into 8049700
 - minor correction
 - initial fix

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1958/files
  - new: https://git.openjdk.java.net/jdk/pull/1958/files/9bdb67a3..487c3447

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=1958=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=1958=01-02

  Stats: 107189 lines in 2673 files changed: 40250 ins; 39520 del; 27419 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1958.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1958/head:pull/1958

PR: https://git.openjdk.java.net/jdk/pull/1958

Re: RFR: 8197825: [Test] Intermiitent timeout with javax/swing JColorChooser Test

[Tejpal Rebari]

On Mon, 25 Jan 2021 13:24:19 GMT, Prasanta Sadhukhan  
wrote:

> This test was failing in our nightly mach5 testing. Appropriate stability 
> code in form of waitForIdle and delay is added.
> mach5 job running for several iterations on all platforms is ok. Link in JBS.

Marked as reviewed by trebari (Committer).

-

PR: https://git.openjdk.java.net/jdk/pull/2220

Re: RFR: 8049700: Deprecate obsolete classes and methods in javax/swing/plaf/basic [v2]

[Tejpal Rebari]

> Please review the following fix for jdk17.
> In this fix i have deprecated and marked for removal following classes and 
> methods 
>public void intervalAdded(ListDataEvent e)
>public void intervalRemoved(ListDataEvent e)
>protected boolean lt(File a, File b) in BasicDirectoryModel.java
> 
>inner class PropertyChangeHandler, VSBChangeListener, HSBChangeListener, 
>ViewportChangeHandler in BasicScrollPaneUI.java
>inner class MouseInputHandler in BasicMenuItemUI.java
>method BasicToolBarUI.java#createFloatingFrame
> 
> From 8049700 not deprecated the paintText(Graphics g, JComponent c, Rectangle 
> textRect, String text) method in BasicButtonUI  as AquaButtonUI, 
> MetalButtonUI and MetalToggleButtonUI overrides it.
> Similarly not deprecated ChangeHandler of BasicMenuUI as AquaMenuUI and 
> MotifMenuUI uses this class.

Tejpal Rebari has updated the pull request incrementally with one additional 
commit since the last revision:

  minor correction

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1958/files
  - new: https://git.openjdk.java.net/jdk/pull/1958/files/8504fc7c..9bdb67a3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=1958=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=1958=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1958.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1958/head:pull/1958

PR: https://git.openjdk.java.net/jdk/pull/1958

Re: RFR: 8049700: Deprecate obsolete classes and methods in javax/swing/plaf/basic

[Tejpal Rebari]

On Wed, 13 Jan 2021 05:52:49 GMT, Prasanta Sadhukhan  
wrote:

>> Please review the following fix for jdk17.
>> In this fix i have deprecated and marked for removal following classes and 
>> methods 
>>public void intervalAdded(ListDataEvent e)
>>public void intervalRemoved(ListDataEvent e)
>>protected boolean lt(File a, File b) in BasicDirectoryModel.java
>> 
>>inner class PropertyChangeHandler, VSBChangeListener, HSBChangeListener, 
>>ViewportChangeHandler in BasicScrollPaneUI.java
>>inner class MouseInputHandler in BasicMenuItemUI.java
>>method BasicToolBarUI.java#createFloatingFrame
>> 
>> From 8049700 not deprecated the paintText(Graphics g, JComponent c, 
>> Rectangle textRect, String text) method in BasicButtonUI  as AquaButtonUI, 
>> MetalButtonUI and MetalToggleButtonUI overrides it.
>> Similarly not deprecated ChangeHandler of BasicMenuUI as AquaMenuUI and 
>> MotifMenuUI uses this class.
>
> Please elaborate as to why this methods are to be deprecated.
> It will be useful if you give alternate methods to be used in the javadoc in 
> @deprecated tag 
> which are supposed to be called by user once these are removed.

The methods intervalAdded(ListDataEvent e) ,intervalRemoved(ListDataEvent e) 
and  lt(File a, File b) of  javax/swing/plaf/basic/BasicDirectoryModel.java  
states that "Obsolete - not used" ( in the doc).

The BasicDirectoryModel uses similar methods like fireIntervalAdded, 
fireIntervalRemoved which calls AbstractListModel#fireIntervalAdded.
But not sure that these are the  alternate methods.Also dont see anything 
similar to lt(File a, File b).

The method createFloatingFrame in the BasicToolBarUI.java states that it is "No 
longer used" and also specifies to use 
BasicToolBarUI.createFloatingWindow(JToolBar).

The class MouseInputHandler in BasicMenuUI.java and classes 
PropertyChangeHandler, VSBChangeListener, HSBChangeListener, 
ViewportChangeHandler in BasicScrollPaneUI.java states that(as comments inside 
the class)
"This class exists only for backward compatibility. All
its functionality has been moved into Handler."
we can add the above in the doc for these classes.

-

PR: https://git.openjdk.java.net/jdk/pull/1958

Re: [jdk16] RFR: 8258643: [TESTBUG] javax/swing/JComponent/7154030/bug7154030.java failed with "Exception: Failed to hide opaque button"

[Tejpal Rebari]

On Wed, 13 Jan 2021 22:26:47 GMT, Alexander Zuev  wrote:

> Backport from mainline.

Marked as reviewed by trebari (Committer).

-

PR: https://git.openjdk.java.net/jdk16/pull/119

Re: RFR: 8225045: javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java fails on linux-x64 [v2]

[Tejpal Rebari]

On Mon, 11 Jan 2021 04:50:09 GMT, Prasanta Sadhukhan  
wrote:

>> This test was failing on mach5 nightly on ubuntu systems long time back. 
>> Modified the test to add some delays and call robot.waitForIdle() to make it 
>> more stable and the resultant test passes on all mach5 systems including 
>> linux consisting of ubuntu 19.10, 18.04,20.10,20.04 so we can remove the 
>> test from problemlist.
>> mach5 job running for several iterations is posted in JBS.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   Remove unneeded setAutoDelay

Marked as reviewed by trebari (Committer).

-

PR: https://git.openjdk.java.net/jdk/pull/2003

Re: RFR: 8225045: javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java fails on linux-x64 [v2]

[Tejpal Rebari]

On Mon, 11 Jan 2021 04:50:09 GMT, Prasanta Sadhukhan  
wrote:

>> This test was failing on mach5 nightly on ubuntu systems long time back. 
>> Modified the test to add some delays and call robot.waitForIdle() to make it 
>> more stable and the resultant test passes on all mach5 systems including 
>> linux consisting of ubuntu 19.10, 18.04,20.10,20.04 so we can remove the 
>> test from problemlist.
>> mach5 job running for several iterations is posted in JBS.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   Remove unneeded setAutoDelay

test/jdk/javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java line 
220:

> 218: if (!bufferedImagesEqual(imageIconImage, iconImage)) {
> 219: ImageIO.write(imageIconImage, "png", new 
> File("imageicon-fail.png"));
> 220: ImageIO.write(iconImage, "png", new 
> File("iconImage-fail.png"));

Is this for debugging purpose when the test fails ?

-

PR: https://git.openjdk.java.net/jdk/pull/2003

Integrated: 8048109: JToggleButton does not fire actionPerformed under certain conditions

[Tejpal Rebari]

On Mon, 12 Oct 2020 08:01:43 GMT, Tejpal Rebari  wrote:

> Please review the following fix for jdk16.
> 
> Issue : There is a  JToggleButton that will post/take down a JPopupMenu when 
> the button is selected. If the button is selected and the menu is not posted 
> the action listener will post the menu. If the button is selected and the 
> menu is displayed the action listener will take the menu down. The use case 
> is:
> 1 - select button
> 2 - menu posted
> 3 - select button
> 4 - menu taken down
> 
> With MetalLookAndFeel the above use case works fine, but with 
> WindowsLookAndFeel the second button selection does not fire the 
> actionPerformed event,  button needs to be selected third time for the menu 
> to be taken down.
> 
> The issue is that the button must be selected twice after the menu is posted 
> to have the actionPerformed event to fire when using the Windows look and 
> feel.
> 
> Fix : MouseGrabber is not removed while uninstalling the listeners in the 
> BasicPopupMenuUI.
> By removing the mouseGrabber in the uninstallListeners() methods fixes this 
> issue.
> 
> Added a test to test the same in all the LookAndFeels

This pull request has now been integrated.

Changeset: 65ca5c66
Author:Tejpal Rebari 
URL:   https://git.openjdk.java.net/jdk/commit/65ca5c66
Stats: 169 lines in 5 files changed: 165 ins; 0 del; 4 mod

8048109: JToggleButton does not fire actionPerformed under certain conditions

Reviewed-by: serb, psadhukhan, vdyakov

-

PR: https://git.openjdk.java.net/jdk/pull/600

RFR: 8049700: Deprecate obsolete classes and methods in javax/swing/plaf/basic

[Tejpal Rebari]

Please review the following fix for jdk17.
In this fix i have deprecated and marked for removal following classes and 
methods 
   public void intervalAdded(ListDataEvent e)
   public void intervalRemoved(ListDataEvent e)
   protected boolean lt(File a, File b) in BasicDirectoryModel.java

   inner class PropertyChangeHandler, VSBChangeListener, HSBChangeListener, 
   ViewportChangeHandler in BasicScrollPaneUI.java
   inner class MouseInputHandler in BasicMenuItemUI.java
   method BasicToolBarUI.java#createFloatingFrame

>From 8049700 not deprecated the paintText(Graphics g, JComponent c, Rectangle 
>textRect, String text) method in BasicButtonUI  as AquaButtonUI, MetalButtonUI 
>and MetalToggleButtonUI overrides it.
Similarly not deprecated ChangeHandler of BasicMenuUI as AquaMenuUI and 
MotifMenuUI uses this class.

-

Commit messages:
 - initial fix

Changes: https://git.openjdk.java.net/jdk/pull/1958/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=1958=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8049700
  Stats: 38 lines in 4 files changed: 38 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1958.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1958/head:pull/1958

PR: https://git.openjdk.java.net/jdk/pull/1958

Re: RFR: 8048109: JToggleButton does not fire actionPerformed under certain conditions [v4]

[Tejpal Rebari]

On Wed, 23 Dec 2020 23:47:29 GMT, Sergey Bylokhov  wrote:

>> yeah , i have checked in windows and ubuntu native apps and it is matching 
>> native behaviour.
>> The issue is seen in Motif, Nimbus, GTK and windows which sets 
>> consumeEventOnClose to true.
>> It is not seen in Metal And Aqua which doesn't set this variable and the 
>> value from BasicLookAndFeel.java is used which is false.
>
> Can you recheck that using the next usecase:
>  - Create menu in the frame
>  - Add jbutton to the frame exactly in the place where the menu popup is 
> opened
>  - Open menu and click some menu item, will the jbutton be clicked?

Open menu and click some menu item, will the jbutton be clicked?
No, the JButton is not clicked in this use case.

-

PR: https://git.openjdk.java.net/jdk/pull/600

Re: RFR: 8048109: JToggleButton does not fire actionPerformed under certain conditions [v4]

[Tejpal Rebari]

On Fri, 18 Dec 2020 21:43:24 GMT, Sergey Bylokhov  wrote:

>> Before the fix the mouse event that cause the popup to close  was consumed 
>> here as the "PopupMenu.consumeEventOnClose" was true.
>> 
>> After the fix the mouse event that cause the popup to close will not be 
>> consumed here as  "PopupMenu.consumeEventOnClose" is set to false in the fix 
>> for Windows, GTK, Nimbus and Motif LAF.
>
> And does it match the native behavior? I mean different values of 
> "consumeEventOnClose" weren't a bug. It was intentionally set to the 
> appropriate value.

yeah , i have checked in windows and ubuntu native apps and it is matching 
native behaviour.
The issue is seen in Motif, Nimbus, GTK and windows which sets 
consumeEventOnClose to true.
It is not seen in Metal And Aqua which doesn't set this variable and the value 
from BasicLookAndFeel.java is used which is false.

-

PR: https://git.openjdk.java.net/jdk/pull/600

Re: RFR: 8048109: JToggleButton does not fire actionPerformed under certain conditions [v4]

[Tejpal Rebari]

On Fri, 18 Dec 2020 00:18:22 GMT, Sergey Bylokhov  wrote:

>> Tejpal Rebari has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   changed mode of files
>
> src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKLookAndFeel.java
>  line 806:
> 
>> 804: 
>> 805: 
>> 806: "PopupMenu.consumeEventOnClose", Boolean.FALSE,
> 
> This property was added to support some kind of "native" behavior.
> The code from the BasicPopupMenuUI.java:
> 
> // Ask UIManager about should we consume event that closes
> // popup. This made to match native apps behaviour.
> boolean consumeEvent =
> UIManager.getBoolean("PopupMenu.consumeEventOnClose");
> // Consume the event so that normal processing stops.
> if(consumeEvent && !(src instanceof MenuElement)) {
> me.consume();
> }
> So after this fix, the mouse event that causes the popup to close will be not 
> be dispatched to the next component?

Before the fix the mouse event that cause the popup to close  was consumed here 
as the "PopupMenu.consumeEventOnClose" was true.

After the fix the mouse event that cause the popup to close will not be 
consumed here as  "PopupMenu.consumeEventOnClose" is set to false in the fix 
for Windows, GTK, Nimbus and Motif LAF.

-

PR: https://git.openjdk.java.net/jdk/pull/600

Re: RFR: 8258557: Deproblemlist fixed problemlisted test

[Tejpal Rebari]

On Thu, 17 Dec 2020 04:59:43 GMT, Prasanta Sadhukhan  
wrote:

> javax/swing/PopupFactory/8048506/bug8048506.java was failing on windows in 
> nightly mach5 testing but was later fixed in JDK-6847157 but this test was 
> not removed from ProblemList. 
> We can remove this test from problemlist now.
> mach5 job running for several iteration on all platforms is ok. Link in JBS.

Marked as reviewed by trebari (Committer).

-

PR: https://git.openjdk.java.net/jdk/pull/1814

Re: RFR: 8048109: JToggleButton does not fire actionPerformed under certain conditions [v4]

[Tejpal Rebari]

On Wed, 14 Oct 2020 01:52:35 GMT, Sergey Bylokhov  wrote:

>> Tejpal Rebari has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   changed mode of files
>
> Changes requested by serb (Reviewer).

@mrserb please take a look.

-

PR: https://git.openjdk.java.net/jdk/pull/600

Re: RFR: 8258233: Reenable another fixed problemlisted test

[Tejpal Rebari]

On Mon, 14 Dec 2020 12:45:12 GMT, Prasanta Sadhukhan  
wrote:

> javax/swing/JFileChooser/6868611/bug6868611.java was failing in windows in 
> mach5 testing but was fixed in JDK-8198004 later on, but this test was not 
> removed from problemList. We can remove it from problemlist now.
> Tested for several iteration in mach5. Link in JBS.

Marked as reviewed by trebari (Committer).

-

PR: https://git.openjdk.java.net/jdk/pull/1766

Re: RFR: 8048109: JToggleButton does not fire actionPerformed under certain conditions [v4]

[Tejpal Rebari]

On Fri, 11 Dec 2020 10:18:12 GMT, Prasanta Sadhukhan  
wrote:

>> In case of the first attempt to bring down the popup menu the event was 
>> consumed by following code of BasicPopupMenuUI 
>>  boolean consumeEvent =
>> 
>> UIManager.getBoolean("PopupMenu.consumeEventOnClose");
>> // Consume the event so that normal processing stops.
>> if(consumeEvent && !(src instanceof MenuElement)) {
>> me.consume();
>> }
>> The PopupMenu.consumeEventOnClose is true for Windows, Motif, Nimbus, and 
>> GTK LAF and this issue is seen in all these LookAndFeels.
>> For Metal LAF this variable is never set to true so it uses of 
>> BasicLookAndFeel which is set to FALSE
>> This issue is not seen on MetalLAF.
>> 
>> So changed  PopupMenu.consumeEventOnClose to FALSE for Windows, Motif, 
>> Nimbus, and GTK LAF and
>>  it fixes the issue.
>
> Any idea why commenting popup.setInvoker(jtb); line in the test works even 
> without the fix?

In case of commenting popup.setInvoker(jtb); 
the following line of code in BasicPopupMenuUI is never called

boolean consumeEvent =UIManager.getBoolean("PopupMenu.consumeEventOnClose");
// Consume the event so that normal processing stops.
if(consumeEvent && !(src instanceof MenuElement)) {
me.consume();
}

So the event is not consumed here by me.consume() and the the issue is not seen.

-

PR: https://git.openjdk.java.net/jdk/pull/600

Re: RFR: 8048109: JToggleButton does not fire actionPerformed under certain conditions [v4]

[Tejpal Rebari]

On Tue, 1 Dec 2020 02:40:27 GMT, Tejpal Rebari  wrote:

>> Well, the comment was added on Oct 15 and it got hidden on Oct28 because the 
>> ac was not of github author/committer. I think the fix submitter should have 
>> seen the comment lying there for 2 weeks before it got hidden.
>
> I have seen the comment, it is not visible in github but its there in 
> mailing-list.
> 
> "It seems the effect is in WindowsLookAndFeel but you are fixing in Basic 
> L If the cause is in Basic L, then it
> would have affected other L also like Metal,Nimbus, doesn't it? If 
> MouseGrabber not removed is the problem, the I
> guess MouseGrabber.uninstall() is not called. This is called in 
> BasicLookAndFeel#uninitialize() and is overridden in
> WindowsLookAndFeel. Metal does not override this so maybe that's why the 
> issue is not seen in Metal.  Probably the
> right fix is to call this MouseGrabber.uninstall() in 
> Windows:LookAndFeel.uninitialize() same way as is done in
> BasicLookAndFeel.uninitialize()"
> 
> the current fix doesn't looks correct so working on finding the correct fix.

In case of the first attempt to bring down the popup menu the event was 
consumed by following code of BasicPopupMenuUI 
 boolean consumeEvent =
UIManager.getBoolean("PopupMenu.consumeEventOnClose");
// Consume the event so that normal processing stops.
if(consumeEvent && !(src instanceof MenuElement)) {
me.consume();
}
The PopupMenu.consumeEventOnClose is true for Windows, Motif, Nimbus, and GTK 
LAF and this issue is seen in all these LookAndFeels.
For Metal LAF this variable is never set to true so it uses of BasicLookAndFeel 
which is set to FALSE
This issue is not seen on MetalLAF.

So changed  PopupMenu.consumeEventOnClose to FALSE for Windows, Motif, Nimbus, 
and GTK LAF and
 it fixes the issue.

-

PR: https://git.openjdk.java.net/jdk/pull/600

Re: RFR: 8048109: JToggleButton does not fire actionPerformed under certain conditions [v4]

[Tejpal Rebari]

> Please review the following fix for jdk16.
> 
> Issue : There is a  JToggleButton that will post/take down a JPopupMenu when 
> the button is selected. If the button is selected and the menu is not posted 
> the action listener will post the menu. If the button is selected and the 
> menu is displayed the action listener will take the menu down. The use case 
> is:
> 1 - select button
> 2 - menu posted
> 3 - select button
> 4 - menu taken down
> 
> With MetalLookAndFeel the above use case works fine, but with 
> WindowsLookAndFeel the second button selection does not fire the 
> actionPerformed event,  button needs to be selected third time for the menu 
> to be taken down.
> 
> The issue is that the button must be selected twice after the menu is posted 
> to have the actionPerformed event to fire when using the Windows look and 
> feel.
> 
> Fix : MouseGrabber is not removed while uninstalling the listeners in the 
> BasicPopupMenuUI.
> By removing the mouseGrabber in the uninstallListeners() methods fixes this 
> issue.
> 
> Added a test to test the same in all the LookAndFeels

Tejpal Rebari has updated the pull request incrementally with one additional 
commit since the last revision:

  changed mode of files

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/600/files
  - new: https://git.openjdk.java.net/jdk/pull/600/files/036633b4..f07a1729

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=600=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=600=02-03

  Stats: 0 lines in 5 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/600.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/600/head:pull/600

PR: https://git.openjdk.java.net/jdk/pull/600

Re: RFR: 8048109: JToggleButton does not fire actionPerformed under certain conditions [v3]

[Tejpal Rebari]

On Wed, 14 Oct 2020 01:52:12 GMT, Sergey Bylokhov  wrote:

>> Tejpal Rebari has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   reworked fix, also fixed for nimbus,motif,GTK LAF
>
> test/jdk/javax/swing/JPopupMenu/SetInvokerJPopupMenuTest.java line 145:
> 
>> 143: public void setVisible( boolean state ) {
>> 144: if( !state ) {
>> 145: Exception ex = new Exception();
> 
> It is unclear what is the purpose of this method?

This method is needed to reproduce the issue.
If we remove this method then the popup menu never goes off the screen after 
the the first mouse click.

-

PR: https://git.openjdk.java.net/jdk/pull/600

Re: RFR: 8048109: JToggleButton does not fire actionPerformed under certain conditions [v3]

[Tejpal Rebari]

> Please review the following fix for jdk16.
> 
> Issue : There is a  JToggleButton that will post/take down a JPopupMenu when 
> the button is selected. If the button is selected and the menu is not posted 
> the action listener will post the menu. If the button is selected and the 
> menu is displayed the action listener will take the menu down. The use case 
> is:
> 1 - select button
> 2 - menu posted
> 3 - select button
> 4 - menu taken down
> 
> With MetalLookAndFeel the above use case works fine, but with 
> WindowsLookAndFeel the second button selection does not fire the 
> actionPerformed event,  button needs to be selected third time for the menu 
> to be taken down.
> 
> The issue is that the button must be selected twice after the menu is posted 
> to have the actionPerformed event to fire when using the Windows look and 
> feel.
> 
> Fix : MouseGrabber is not removed while uninstalling the listeners in the 
> BasicPopupMenuUI.
> By removing the mouseGrabber in the uninstallListeners() methods fixes this 
> issue.
> 
> Added a test to test the same in all the LookAndFeels

Tejpal Rebari has updated the pull request incrementally with one additional 
commit since the last revision:

  reworked fix, also fixed for nimbus,motif,GTK LAF

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/600/files
  - new: https://git.openjdk.java.net/jdk/pull/600/files/65c08eda..036633b4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=600=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=600=01-02

  Stats: 13 lines in 6 files changed: 0 ins; 8 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/600.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/600/head:pull/600

PR: https://git.openjdk.java.net/jdk/pull/600

Re: RFR: 8048109: JToggleButton does not fire actionPerformed under certain conditions [v2]

[Tejpal Rebari]

On Mon, 30 Nov 2020 17:53:48 GMT, Prasanta Sadhukhan  
wrote:

>>> not wrong but different account but that doesnot make the comment invalid, 
>>> I guess.
>> 
>> But nobody sees it, it is hidden.
>
> Well, the comment was added on Oct 15 and it got hidden on Oct28 because the 
> ac was not of github author/committer. I think the fix submitter should have 
> seen the comment lying there for 2 weeks before it got hidden.

I have seen the comment, it is not visible in github but its there in 
mailing-list.

"It seems the effect is in WindowsLookAndFeel but you are fixing in Basic L 
If the cause is in Basic L, then it
would have affected other L also like Metal,Nimbus, doesn't it? If 
MouseGrabber not removed is the problem, the I
guess MouseGrabber.uninstall() is not called. This is called in 
BasicLookAndFeel#uninitialize() and is overridden in
WindowsLookAndFeel. Metal does not override this so maybe that's why the issue 
is not seen in Metal.  Probably the
right fix is to call this MouseGrabber.uninstall() in 
Windows:LookAndFeel.uninitialize() same way as is done in
BasicLookAndFeel.uninitialize()"

the current fix doesn't looks correct so working on finding the correct fix.

-

PR: https://git.openjdk.java.net/jdk/pull/600

Re: RFR: 8048109: JToggleButton does not fire actionPerformed under certain conditions [v2]

[Tejpal Rebari]

> Please review the following fix for jdk16.
> 
> Issue : There is a  JToggleButton that will post/take down a JPopupMenu when 
> the button is selected. If the button is selected and the menu is not posted 
> the action listener will post the menu. If the button is selected and the 
> menu is displayed the action listener will take the menu down. The use case 
> is:
> 1 - select button
> 2 - menu posted
> 3 - select button
> 4 - menu taken down
> 
> With MetalLookAndFeel the above use case works fine, but with 
> WindowsLookAndFeel the second button selection does not fire the 
> actionPerformed event,  button needs to be selected third time for the menu 
> to be taken down.
> 
> The issue is that the button must be selected twice after the menu is posted 
> to have the actionPerformed event to fire when using the Windows look and 
> feel.
> 
> Fix : MouseGrabber is not removed while uninstalling the listeners in the 
> BasicPopupMenuUI.
> By removing the mouseGrabber in the uninstallListeners() methods fixes this 
> issue.
> 
> Added a test to test the same in all the LookAndFeels

Tejpal Rebari has updated the pull request incrementally with one additional 
commit since the last revision:

  modified the test after suggestions

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/600/files
  - new: https://git.openjdk.java.net/jdk/pull/600/files/a60ffa67..65c08eda

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=600=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=600=00-01

  Stats: 10 lines in 1 file changed: 7 ins; 1 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/600.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/600/head:pull/600

PR: https://git.openjdk.java.net/jdk/pull/600

Re: RFR: 8194126: Regression automated Test '/open/test/jdk/javax/swing/JColorChooser/Test7194184.java' fails

[Tejpal Rebari]

On Fri, 16 Oct 2020 03:31:41 GMT, Prasanta Sadhukhan  
wrote:

> Please review a test fix for an issue where the color is not chosen correctly.
> The issue seems to stem from the fact that keys are not processed properly so 
> the proper color is not chosen.
> Fixed by adding autoDelay during processing of key events and also made EDT 
> change to invokeAndWait from invokeLater.
> Also, move the frame to center of screen and do cleanup at finally block.
> Mach5 job was run for several iteration on all 3 platforms. Link in JBS

Marked as reviewed by trebari (Author).

-

PR: https://git.openjdk.java.net/jdk/pull/692

RFR: 8048109: JToggleButton does not fire actionPerformed under certain conditions

[Tejpal Rebari]

Please review the following fix for jdk16.

Issue : There is a  JToggleButton that will post/take down a JPopupMenu when 
the button is selected. If the button is
selected and the menu is not posted the action listener will post the menu. If 
the button is selected and the menu is
displayed the action listener will take the menu down. The use case is: 1 - 
select button 2 - menu posted
3 - select button
4 - menu taken down

With MetalLookAndFeel the above use case works fine, but with 
WindowsLookAndFeel the second button selection does not
fire the actionPerformed event,  button needs to be selected third time for the 
menu to be taken down.

The issue is that the button must be selected twice after the menu is posted to 
have the actionPerformed event to fire
when using the Windows look and feel.

Fix : MouseGrabber is not removed while uninstalling the listeners in the 
BasicPopupMenuUI.
By removing the mouseGrabber in the uninstallListeners() methods fixes this 
issue.

Added a test to test the same in all the LookAndFeels

-

Commit messages:
 - changed mode of src file
 - changes permission of the test file
 - made intenal classes static and moved them inside main class
 - minor changes
 - Fix for JDK-8048109 and added a test

Changes: https://git.openjdk.java.net/jdk/pull/600/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=600=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8048109
  Stats: 167 lines in 2 files changed: 167 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/600.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/600/head:pull/600

PR: https://git.openjdk.java.net/jdk/pull/600

Re: RFR: 8254112: javax/swing/plaf/basic/BasicComboPopup/JComboBoxPopupLocation/JComboBoxPopupLocation.java fails on windows [v2]

[Tejpal Rebari]

On Wed, 7 Oct 2020 08:54:22 GMT, Prasanta Sadhukhan  
wrote:

>> Please review a test issue where the test was seen to be failing on windows 
>> mach5 system in hidpi mode.
>> I have ran the test locally with different scale factors without reproducing 
>> the issue. Also, mach5 job running this
>> test for several iterations works ok. So, proposing to remove the test from 
>> ProblemList.
>
> Prasanta Sadhukhan has updated the pull request with a new target base due to 
> a merge or a rebase. The pull request now
> contains two commits:
>  - Merge master
>  - 8254112: 
> javax/swing/plaf/basic/BasicComboPopup/JComboBoxPopupLocation/JComboBoxPopupLocation.java
>  fails on windows

Marked as reviewed by trebari (Author).

-

PR: https://git.openjdk.java.net/jdk/pull/535

Integrated: 7151826: [TEST_BUG] [macosx] The test javax/swing/JPopupMenu/4966112/bug4966112.java not for mac

[Tejpal Rebari]

On Wed, 16 Sep 2020 11:45:12 GMT, Tejpal Rebari  wrote:

> The test test/jdk/javax/swing/JPopupMenu/4966112/bug4966112.java fails for 
> Mac OS X
> with the error message Popup was not shown on FileChooser.
> 
> Popup doesn't appear for JFileChooser in MAC OS X platform so
> skipping this test for Mac OS X.

This pull request has now been integrated.

Changeset: 4d9f2073
Author:Tejpal Rebari 
Committer: Jayathirth D V 
URL:   https://git.openjdk.java.net/jdk/commit/4d9f2073
Stats: 31 lines in 2 files changed: 26 ins; 1 del; 4 mod

7151826: [TEST_BUG] [macosx] The test 
javax/swing/JPopupMenu/4966112/bug4966112.java not for mac

Reviewed-by: serb, jdv

-

PR: https://git.openjdk.java.net/jdk/pull/204

Re: RFR: 6441211: Small Error in API at javax.swing.plaf.synth.Region

[Tejpal Rebari]

On Tue, 29 Sep 2020 08:27:43 GMT, Prasanta Sadhukhan  
wrote:

> Fixed a small typo

Marked as reviewed by trebari (Author).

-

PR: https://git.openjdk.java.net/jdk/pull/396

Re: RFR: 7151826: [TEST_BUG] [macosx] The test javax/swing/JPopupMenu/4966112/bug4966112.java not for mac [v4]

[Tejpal Rebari]

> The test test/jdk/javax/swing/JPopupMenu/4966112/bug4966112.java fails for 
> Mac OS X
> with the error message Popup was not shown on FileChooser.
> 
> Popup doesn't appear for JFileChooser in MAC OS X platform so
> skipping this test for Mac OS X.

Tejpal Rebari has updated the pull request incrementally with one additional 
commit since the last revision:

  removed unnecessary code

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/204/files
  - new: https://git.openjdk.java.net/jdk/pull/204/files/9ba6ad42..f7782dc9

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=204=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=204=02-03

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/204.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/204/head:pull/204

PR: https://git.openjdk.java.net/jdk/pull/204

Re: RFR: 7151826: [TEST_BUG] [macosx] The test javax/swing/JPopupMenu/4966112/bug4966112.java not for mac [v3]

[Tejpal Rebari]

On Sat, 26 Sep 2020 06:13:43 GMT, Sergey Bylokhov  wrote:

>> I doubt that if some test will be added later the filechooser under the test 
>> became non-aqua.
>
> It is the Aqua from the beginning till the end or some other L

Ok, in that case we can remove this line

-

PR: https://git.openjdk.java.net/jdk/pull/204

Re: RFR: 7151826: [TEST_BUG] [macosx] The test javax/swing/JPopupMenu/4966112/bug4966112.java not for mac [v3]

[Tejpal Rebari]

On Fri, 25 Sep 2020 21:40:14 GMT, Sergey Bylokhov  wrote:

>> Tejpal Rebari has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   Added check for Aqua LAF instead of Mac OS and minor cleanup
>
> test/jdk/javax/swing/JPopupMenu/4966112/bug4966112.java line 134:
> 
>> 132: closeFrame();
>> 133:
>> 134: isAquaFileChooser = false;
> 
> Why this line at the end of the test is needed?

It is needed if someone adds some other test cases to the end of test.

-

PR: https://git.openjdk.java.net/jdk/pull/204

Re: RFR: 7151826: [TEST_BUG] [macosx] The test javax/swing/JPopupMenu/4966112/bug4966112.java not for mac [v3]

[Tejpal Rebari]

> The test test/jdk/javax/swing/JPopupMenu/4966112/bug4966112.java fails for 
> Mac OS X
> with the error message Popup was not shown on FileChooser.
> 
> Popup doesn't appear for JFileChooser in MAC OS X platform so
> skipping this test for Mac OS X.

Tejpal Rebari has updated the pull request incrementally with one additional 
commit since the last revision:

  Added check for Aqua LAF instead of Mac OS and minor cleanup

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/204/files
  - new: https://git.openjdk.java.net/jdk/pull/204/files/e3da2b2e..9ba6ad42

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=204=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=204=01-02

  Stats: 21 lines in 1 file changed: 16 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/204.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/204/head:pull/204

PR: https://git.openjdk.java.net/jdk/pull/204

Re: RFR: 7151826: [TEST_BUG] [macosx] The test javax/swing/JPopupMenu/4966112/bug4966112.java not for mac [v2]

[Tejpal Rebari]

On Thu, 24 Sep 2020 16:11:11 GMT, Phil Race  wrote:

>> Tejpal Rebari has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   Testing filechooser on aqua at a different place, where context popup works
>
> test/jdk/javax/swing/JPopupMenu/4966112/bug4966112.java line 105:
> 
>> 103: if (System.getProperty("os.name").startsWith("Mac")) {
>> 104: isAquaFileChooser = true;
>> 105: } else {
> 
> nitpick: it depends on the current L, doesn't it ?

Yes it does, this test was testing aqua by default on mac os x. that's why i 
added a check of OS.
But adding a check for LAF sounds better so
I will add (UIManager.getLookAndFeel().getID()).equals("Aqua") check instead of
System.getProperty("os.name").startsWith("Mac")) in the next commit.

> test/jdk/javax/swing/JPopupMenu/4966112/bug4966112.java line 156:
> 
>> 154: Point p = c.getLocationOnScreen();
>> 155: Dimension size = c.getSize();
>> 156: if (isAquaFileChooser){
> 
> nit pick ){ -> ) { - ie add a space.

Will do.

-

PR: https://git.openjdk.java.net/jdk/pull/204

Re: RFR: 7151826: [TEST_BUG] [macosx] The test javax/swing/JPopupMenu/4966112/bug4966112.java not for mac

[Tejpal Rebari]

On Wed, 23 Sep 2020 06:50:52 GMT, Sergey Bylokhov  wrote:

>>> So the popup actually works in that dialog, we just need to test it in a 
>>> different place?
>> 
>> Yes.
>
>> > So the popup actually works in that dialog, we just need to test it in a 
>> > different place?
>> Yes.
> 
> Then it looks like in Aqua, we can test that "different place".

Testing context popup for Filechooser on AquaLAF at the different place where 
the context popup works.
Internal test run link is in JBS, All Green.

-

PR: https://git.openjdk.java.net/jdk/pull/204

Re: RFR: 7151826: [TEST_BUG] [macosx] The test javax/swing/JPopupMenu/4966112/bug4966112.java not for mac [v2]

[Tejpal Rebari]

> The test test/jdk/javax/swing/JPopupMenu/4966112/bug4966112.java fails for 
> Mac OS X
> with the error message Popup was not shown on FileChooser.
> 
> Popup doesn't appear for JFileChooser in MAC OS X platform so
> skipping this test for Mac OS X.

Tejpal Rebari has updated the pull request incrementally with one additional 
commit since the last revision:

  Testing filechooser on aqua at a different place, where context popup works

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/204/files
  - new: https://git.openjdk.java.net/jdk/pull/204/files/415c13a7..e3da2b2e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=204=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=204=00-01

  Stats: 16 lines in 1 file changed: 11 ins; 4 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/204.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/204/head:pull/204

PR: https://git.openjdk.java.net/jdk/pull/204

Re: RFR: 7151826: [TEST_BUG] [macosx] The test javax/swing/JPopupMenu/4966112/bug4966112.java not for mac

[Tejpal Rebari]

On Sat, 19 Sep 2020 02:30:54 GMT, Sergey Bylokhov  wrote:

> So the popup actually works in that dialog, we just need to test it in a 
> different place?

Yes.

-

PR: https://git.openjdk.java.net/jdk/pull/204

Re: RFR: 7151826: [TEST_BUG] [macosx] The test javax/swing/JPopupMenu/4966112/bug4966112.java not for mac

[Tejpal Rebari]

On Wed, 16 Sep 2020 20:29:39 GMT, Sergey Bylokhov  wrote:

>> The test test/jdk/javax/swing/JPopupMenu/4966112/bug4966112.java fails for 
>> Mac OS X
>> with the error message Popup was not shown on FileChooser.
>> 
>> Popup doesn't appear for JFileChooser in MAC OS X platform so
>> skipping this test for Mac OS X.
>
> Why the popup does not show for this component? Why the filechooser on the 
> mac is so specific?

The test creates a JFileChooser and a popup and then click on the middle of the 
JFileChooser.

In case of MAC OS X the context popup doesn't work when clicking on the area 
where files are(the area with the scroll
bar) in the filechooser.

But context popup works when clicking on the other areas of the JFilechooser 
like
1. Upper area where the directory link is given
2. Below area where file format comboBox is there and the close and open 
buttons are there.
3. Context popup doesn't work when clicking on the buttons(close, open) and 
the ComboBoxes

so the test fails because the context popup doesn't work when clicking the 
middle area of JFileChooser in mac os x.

There are two ways to make the test pass, one to omit the mac os x platform for 
JFilechooser part which i did in the PR.
second the click on the other areas of the filechooser when the context popup 
work for mac os x.

-

PR: https://git.openjdk.java.net/jdk/pull/204

RFR: 7151826: [TEST_BUG] [macosx] The test javax/swing/JPopupMenu/4966112/bug4966112.java not for mac

[Tejpal Rebari]

The test test/jdk/javax/swing/JPopupMenu/4966112/bug4966112.java fails for Mac 
OS X
with the error message Popup was not shown on FileChooser.

Popup doesn't appear for JFileChooser in MAC OS X platform so
skipping this test for Mac OS X.

-

Commit messages:
 - Skip JFileChooser test for Mac OS

Changes: https://git.openjdk.java.net/jdk/pull/204/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=204=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-7151826
  Stats: 5 lines in 2 files changed: 4 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/204.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/204/head:pull/204

PR: https://git.openjdk.java.net/jdk/pull/204

Re: RFR: 8251122: doclint html5 errors in java.desktop/share/classes/javax/swing/plaf/nimbus/doc-files/properties.html

[Tejpal Rebari]

Hi Alexey,
Thanks for the review.
I will modify the copyright year as per your suggestion before pushing.

Regards
Tejpal

> On 31-Aug-2020, at 4:26 PM, Alexey Ivanov  wrote:
> 
> Hi Tejpal,
> 
> *DesktopProperties.html*
> 
>8  Copyright (c) 2005, 2019, 2020, Oracle and/or its affiliates. All 
> rights reserved.
> The copyright consists of two years: the first one is when the file was 
> added, the second one is when the file was modified.
> 
> It should like this:
>8  Copyright (c) 2005, 2020, Oracle and/or its affiliates. All rights 
> reserved.
> 
> The same comment applies to *properties.html* and *componentProperties.html* 
> files in the webrev. I don't mind if you make this change before pushing 
> without creating an additional webrev.
> 
> 
> Other that, it looks fine to me.
> 
> Regards,
> Alexey
> 
> On 31/08/2020 06:05, Tejpal Rebari wrote:
>> Hi Alexey,
>> I have added  inside the  and  doclint is not throwing any 
>> error.
>> Also Modified the copyright year and made some small syntax related changes.
>> 
>> Please take a look
>> Updated webrev : http://cr.openjdk.java.net/~trebari/swing/8251122/webrev03/
>> 
>> 
>>> On 27-Aug-2020, at 2:15 PM, Tejpal Rebari >> <mailto:tejpal.reb...@oracle.com>> wrote:
>>> 
>>> Hi Alexey,
>>> Thanks for the review
>>> 
>>>> On 21-Aug-2020, at 1:04 AM, Alexey Ivanov >>> <mailto:alexey.iva...@oracle.com>> wrote:
>>>> 
>>>> Hi Tejpal,
>>>> 
>>>> Looks good overall, however, I have a couple of comments.
>>>> 
>>>> I suggest using the  elements for setting width of table columns. Add 
>>>> the following three lines before  in *properties.html*:
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> Dropping "padding:2px;" style makes the table look consistent with other 
>>>> tables above: there's no additional padding between table border and its 
>>>> cells.
>>>> 
>>>> Removing all other style attributes ("border-collapse: separate; 
>>>> border-spacing: 2px;") does not change rendering. The table looks exactly 
>>>> as the table above which does not have any additional style specifiers.
>>>> 
>>>> I guess we should strive for consistent look of all the tables on the 
>>>> page. Shall we drop the additional attributes then?
>>> 
>>> Yeah, I have dropped the style attributes to make the table  consistent.
>>> Updated webrev : http://cr.openjdk.java.net/~trebari/swing/8251122/webrev01/
>>> 
>>> Also there was one new error in java/awt/doc-files/DesktopProperties.html 
>>> due to the fix of 8251124.
>>> So I have removed an empty  tag.
>>> Also verified that no accessibility doclint errors were thrown.
>>> 
>>>> The same comments apply to the following JInternalFrame, 
>>>> JInternalFrameTitlePane, JProgressBar…
>>>> 
>>>> If required, I'd rather add these style declarations inside 

Re: RFR: 8251122: doclint html5 errors in java.desktop/share/classes/javax/swing/plaf/nimbus/doc-files/properties.html

[Tejpal Rebari]

Hi Alexey,
I have added  inside the  and  doclint is not throwing any error.
Also Modified the copyright year and made some small syntax related changes.

Please take a look
Updated webrev : http://cr.openjdk.java.net/~trebari/swing/8251122/webrev03/ 
<http://cr.openjdk.java.net/~trebari/swing/8251122/webrev03/>


> On 27-Aug-2020, at 2:15 PM, Tejpal Rebari  wrote:
> 
> Hi Alexey,
> Thanks for the review
> 
>> On 21-Aug-2020, at 1:04 AM, Alexey Ivanov > <mailto:alexey.iva...@oracle.com>> wrote:
>> 
>> Hi Tejpal,
>> 
>> Looks good overall, however, I have a couple of comments.
>> 
>> I suggest using the  elements for setting width of table columns. Add 
>> the following three lines before  in *properties.html*:
>> 
>> 
>> 
>> 
>> 
>> Dropping "padding:2px;" style makes the table look consistent with other 
>> tables above: there's no additional padding between table border and its 
>> cells.
>> 
>> Removing all other style attributes ("border-collapse: separate; 
>> border-spacing: 2px;") does not change rendering. The table looks exactly as 
>> the table above which does not have any additional style specifiers.
>> 
>> I guess we should strive for consistent look of all the tables on the page. 
>> Shall we drop the additional attributes then?
> 
> Yeah, I have dropped the style attributes to make the table  consistent.
> Updated webrev : http://cr.openjdk.java.net/~trebari/swing/8251122/webrev01/ 
> <http://cr.openjdk.java.net/~trebari/swing/8251122/webrev01/>
> 
> Also there was one new error in java/awt/doc-files/DesktopProperties.html due 
> to the fix of 8251124.
> So I have removed an empty  tag.
> Also verified that no accessibility doclint errors were thrown.
> 
>> The same comments apply to the following JInternalFrame, 
>> JInternalFrameTitlePane, JProgressBar…
>> 
>> If required, I'd rather add these style declarations inside 

Re: RFR: 8251122: doclint html5 errors in java.desktop/share/classes/javax/swing/plaf/nimbus/doc-files/properties.html

[Tejpal Rebari]

Hi Alexey,
Thanks for the review

> On 21-Aug-2020, at 1:04 AM, Alexey Ivanov  wrote:
> 
> Hi Tejpal,
> 
> Looks good overall, however, I have a couple of comments.
> 
> I suggest using the  elements for setting width of table columns. Add 
> the following three lines before  in *properties.html*:
> 
> 
> 
> 
> 
> Dropping "padding:2px;" style makes the table look consistent with other 
> tables above: there's no additional padding between table border and its 
> cells.
> 
> Removing all other style attributes ("border-collapse: separate; 
> border-spacing: 2px;") does not change rendering. The table looks exactly as 
> the table above which does not have any additional style specifiers.
> 
> I guess we should strive for consistent look of all the tables on the page. 
> Shall we drop the additional attributes then?

Yeah, I have dropped the style attributes to make the table  consistent.
Updated webrev : http://cr.openjdk.java.net/~trebari/swing/8251122/webrev01/ 


Also there was one new error in java/awt/doc-files/DesktopProperties.html due 
to the fix of 8251124.
So I have removed an empty  tag.
Also verified that no accessibility doclint errors were thrown.

> The same comments apply to the following JInternalFrame, 
> JInternalFrameTitlePane, JProgressBar…
> 
> If required, I'd rather add these style declarations inside 

RFR: 8251122: doclint html5 errors in java.desktop/share/classes/javax/swing/plaf/nimbus/doc-files/properties.html

[Tejpal Rebari]

Hi All,
Please review the following fix for jdk16.

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

Webrev : http://cr.openjdk.java.net/~trebari/swing/8251122/webrev00/ 


Issue : doclint html5 errors in 
java.desktop/share/classes/javax/swing/plaf/nimbus/doc-files/properties.html
Doclint identified that some of the swing classes were still using attributes 
which is not supported in html5.

Fix :  Doclint identified that the html attributes like width, bgcolor , 
cellspacing, cellpadding were still in use in swing classes.
Used CSS properties for these attributes, like style=“width” for width, 
background-color for bgcolor etc.

Verified that the doclint doesn’t throw any error after the fix.

Regards
Tejpal

Re: RFR: 8251125: doclint errors about missing references in Swing javadoc

[Tejpal Rebari]

Hi Prasanta,

> On 13-Aug-2020, at 6:52 PM, Prasanta Sadhukhan 
>  wrote:
> 
> 
> On 13-Aug-20 6:46 PM, Tejpal Rebari wrote:
>> Hi Prasanta,
>> Thanks for the review.
>> 
>>> On 13-Aug-2020, at 6:36 PM, Prasanta Sadhukhan 
>>>  wrote:
>>> 
>>> Looks ok to me with one request to not break package-info l110-111 lines 
>>> and make it into 1 line
>> Does it mean 80chars per line doesn’t apply to the documentation part of the 
>> file.
>> I have seen that there are other lines in the same file that doesn’t follow 
>> 80 chars per line.
> 
> It should. What I mean is dont break abruptly, break at 80chars.
Ok, I have updated the webrev.
 http://cr.openjdk.java.net/~trebari/swing/8251125/webrev01/ 
<http://cr.openjdk.java.net/~trebari/swing/8251125/webrev01/>

Regards
Tejpal


> Regards
> 
> Prasanta
> 
>> Regards
>> Tejpal
>> 
>>> Regards
>>> 
>>> Prasanta
>>> 
>>> On 13-Aug-20 6:12 PM, Tejpal Rebari wrote:
>>>> Hi All,
>>>> Please review the following fix for jdk16.
>>>> 
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8251125
>>>> Webrev : http://cr.openjdk.java.net/~trebari/swing/8251125/webrev00/
>>>> 
>>>> Issue : Doclint errors about missing references in Swing javadoc.
>>>> Doclint identified that some of the swing classes are missing reference.
>>>> 
>>>> Fix : Added complete path name where the reference was missing.
>>>> Verified that the doclint doesn’t throw any error after the fix.
>>>> 
>>>> 
>>>> Thanks
>>>> Tejpal

Re: RFR: 8251125: doclint errors about missing references in Swing javadoc

[Tejpal Rebari]

Hi Prasanta,
Thanks for the review.

> On 13-Aug-2020, at 6:36 PM, Prasanta Sadhukhan 
>  wrote:
> 
> Looks ok to me with one request to not break package-info l110-111 lines and 
> make it into 1 line
Does it mean 80chars per line doesn’t apply to the documentation part of the 
file.
I have seen that there are other lines in the same file that doesn’t follow 80 
chars per line.

Regards
Tejpal

> 
> Regards
> 
> Prasanta
> 
> On 13-Aug-20 6:12 PM, Tejpal Rebari wrote:
>> Hi All,
>> Please review the following fix for jdk16.
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8251125
>> Webrev : http://cr.openjdk.java.net/~trebari/swing/8251125/webrev00/
>> 
>> Issue : Doclint errors about missing references in Swing javadoc.
>> Doclint identified that some of the swing classes are missing reference.
>> 
>> Fix : Added complete path name where the reference was missing.
>> Verified that the doclint doesn’t throw any error after the fix.
>> 
>> 
>> Thanks
>> Tejpal

RFR: 8251125: doclint errors about missing references in Swing javadoc

[Tejpal Rebari]

Hi All,
Please review the following fix for jdk16.

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

Webrev : http://cr.openjdk.java.net/~trebari/swing/8251125/webrev00/ 


Issue : Doclint errors about missing references in Swing javadoc.
Doclint identified that some of the swing classes are missing reference.

Fix : Added complete path name where the reference was missing.
Verified that the doclint doesn’t throw any error after the fix.


Thanks
Tejpal

Re: RFR: 8249674: Redo: Nimbus JTree renderer properties persist across L changes

[Tejpal Rebari]

Gentle Reminder.

> On 04-Aug-2020, at 11:46 AM, Tejpal Rebari  wrote:
> 
> Hi Phil,
> I have updated the path of the test.
> Updated webrev : http://cr.openjdk.java.net/~trebari/swing/8249674/webrev02/ 
> <http://cr.openjdk.java.net/~trebari/swing/8249674/webrev02/>
> 
> Thanks
> Tejpal
> 
>> On 01-Aug-2020, at 9:41 PM, Philip Race > <mailto:philip.r...@oracle.com>> wrote:
>> 
>> We've been trying to get away from using bug ids in path names or the names
>> of the tests themselves.
>> 
>> -phil
>> 
>> On 7/29/20, 4:53 AM, Prasanta Sadhukhan wrote:
>>> 
>>> 
>>> On 29-Jul-20 1:25 PM, Tejpal Rebari wrote:
>>>> Hi Prasanta,
>>>> 
>>>>> On 27-Jul-2020, at 2:21 PM, Prasanta Sadhukhan 
>>>>> mailto:prasanta.sadhuk...@oracle.com>> 
>>>>> wrote:
>>>>> 
>>>>> Fix looks ok to me. But I think the test is more appropriate if it is 
>>>>> placed in javax/swing/plaf/nimbus directory. Also, the test can be 
>>>>> enhanced a bit to not fail at the first attempt as we are testing 8 
>>>>> different properties, so I think it will be good if you will store the 
>>>>> results in a string for each property that fails, and finally at the end 
>>>>> throw failure with stored string.
>>>> I was bit confused about where the test should be placed because it also 
>>>> checks for other LAFs.
>>>> But for other LAF test was passing earlier also so keeping the test in 
>>>> javax/swing/plaf/nimbus.
>>>> 
>>> We normally place the test in the area where the fix is being made.
>>>> 
>>>> Made changes in the test to throw failure with stored string.
>>>> 
>>>> Updated webrev : 
>>>> http://cr.openjdk.java.net/~trebari/swing/8249674/webrev01/ 
>>>> <http://cr.openjdk.java.net/%7Etrebari/swing/8249674/webrev01/>Looks ok 
>>>> but please use "," instead of "/t" 
>>> and replace "/t" with ":" if "failedkeys" is null. No need of another 
>>> webrev for me.
>>> Regards
>>> Prasanta
>>>> 
>>>> Thanks
>>>> Tejpal
>>>> 
>>>> 
>>>>> 
>>>>> Regards
>>>>> Prasanta
>>>>> On 24-Jul-20 2:36 PM, Tejpal Rebari wrote:
>>>>>> Hi All,
>>>>>> Please review the following fix for jdk16.
>>>>>> 
>>>>>> Bug :  https://bugs.openjdk.java.net/browse/JDK-8249674 
>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8249674>
>>>>>> Webrev : http://cr.openjdk.java.net/~trebari/swing/8249674/webrev00/ 
>>>>>> <http://cr.openjdk.java.net/%7Etrebari/swing/8249674/webrev00/>
>>>>>> 
>>>>>> This is a modified fix for 
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8041701 
>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8041701> 
>>>>>> which caused some internal test to fail.
>>>>>> 
>>>>>> Issue : UI properties “Tree.leafIcon”, “Tree.closedIcon”, 
>>>>>> “Tree.openIcon”,
>>>>>>  “Tree.selectionForeground” ..etc are supposed to be instances of 
>>>>>> UIResource 
>>>>>> if they are defined by LAF. 
>>>>>> 
>>>>>> In Nimbus LAF all the above properties are defined , but none of them 
>>>>>> implement 
>>>>>> UIResource, this causes them to persists when LAF is changed. 
>>>>>> This leaves artefacts when switching from nimbus to other LAFs.
>>>>>> 
>>>>>> Fix :  Fix is to make use of UIResource for the above mentioned 
>>>>>> uiProperties.
>>>>>> Making NimbuIcon implements the UIResource was working fine earlier 
>>>>>> so keeping the change same.
>>>>>> 
>>>>>> The second part of the earlier fix "class DerivedColor extends Color 
>>>>>> implements UIResource"
>>>>>> caused the internal test failure,
>>>>>> 
>>>>>> So changed this fix to keep the DerivedColor class same and for the 
>>>>>> uiProperties 
>>>>>> Tree.selectionForeground” ..etc  use the UIResource
>>>>>> class that is inside the DerivedColor. These changes were made in 
>>>>>> skin.laf file.
>>>>>> 
>>>>>> Testing : Tested on all three platform, and all internal tests.Link is 
>>>>>> in JBS.
>>>>>> In test also added the part which was the reason of revert of earlier 
>>>>>> fix.
>>>>>> The test fails with the fix of 8041701 and passes with the current fix.
>>>>>> 
>>>>>> 
>>>>>> Regards
>>>>>> Tejpal
>>>> 
> 

Re: RFR: 8249674: Redo: Nimbus JTree renderer properties persist across L changes

[Tejpal Rebari]

Hi Phil,
I have updated the path of the test.
Updated webrev : http://cr.openjdk.java.net/~trebari/swing/8249674/webrev02/ 
<http://cr.openjdk.java.net/~trebari/swing/8249674/webrev02/>

Thanks
Tejpal

> On 01-Aug-2020, at 9:41 PM, Philip Race  wrote:
> 
> We've been trying to get away from using bug ids in path names or the names
> of the tests themselves.
> 
> -phil
> 
> On 7/29/20, 4:53 AM, Prasanta Sadhukhan wrote:
>> 
>> 
>> On 29-Jul-20 1:25 PM, Tejpal Rebari wrote:
>>> Hi Prasanta,
>>> 
>>>> On 27-Jul-2020, at 2:21 PM, Prasanta Sadhukhan 
>>>> mailto:prasanta.sadhuk...@oracle.com>> 
>>>> wrote:
>>>> 
>>>> Fix looks ok to me. But I think the test is more appropriate if it is 
>>>> placed in javax/swing/plaf/nimbus directory. Also, the test can be 
>>>> enhanced a bit to not fail at the first attempt as we are testing 8 
>>>> different properties, so I think it will be good if you will store the 
>>>> results in a string for each property that fails, and finally at the end 
>>>> throw failure with stored string.
>>> I was bit confused about where the test should be placed because it also 
>>> checks for other LAFs.
>>> But for other LAF test was passing earlier also so keeping the test in 
>>> javax/swing/plaf/nimbus.
>>> 
>> We normally place the test in the area where the fix is being made.
>>> 
>>> Made changes in the test to throw failure with stored string.
>>> 
>>> Updated webrev : 
>>> http://cr.openjdk.java.net/~trebari/swing/8249674/webrev01/ 
>>> <http://cr.openjdk.java.net/%7Etrebari/swing/8249674/webrev01/>Looks ok but 
>>> please use "," instead of "/t" 
>> and replace "/t" with ":" if "failedkeys" is null. No need of another webrev 
>> for me.
>> Regards
>> Prasanta
>>> 
>>> Thanks
>>> Tejpal
>>> 
>>> 
>>>> 
>>>> Regards
>>>> Prasanta
>>>> On 24-Jul-20 2:36 PM, Tejpal Rebari wrote:
>>>>> Hi All,
>>>>> Please review the following fix for jdk16.
>>>>> 
>>>>> Bug :  https://bugs.openjdk.java.net/browse/JDK-8249674 
>>>>> <https://bugs.openjdk.java.net/browse/JDK-8249674>
>>>>> Webrev : http://cr.openjdk.java.net/~trebari/swing/8249674/webrev00/ 
>>>>> <http://cr.openjdk.java.net/%7Etrebari/swing/8249674/webrev00/>
>>>>> 
>>>>> This is a modified fix for 
>>>>> https://bugs.openjdk.java.net/browse/JDK-8041701 
>>>>> <https://bugs.openjdk.java.net/browse/JDK-8041701> 
>>>>> which caused some internal test to fail.
>>>>> 
>>>>> Issue : UI properties “Tree.leafIcon”, “Tree.closedIcon”, “Tree.openIcon”,
>>>>>  “Tree.selectionForeground” ..etc are supposed to be instances of 
>>>>> UIResource 
>>>>> if they are defined by LAF. 
>>>>> 
>>>>> In Nimbus LAF all the above properties are defined , but none of them 
>>>>> implement 
>>>>> UIResource, this causes them to persists when LAF is changed. 
>>>>> This leaves artefacts when switching from nimbus to other LAFs.
>>>>> 
>>>>> Fix :  Fix is to make use of UIResource for the above mentioned 
>>>>> uiProperties.
>>>>> Making NimbuIcon implements the UIResource was working fine earlier 
>>>>> so keeping the change same.
>>>>> 
>>>>> The second part of the earlier fix "class DerivedColor extends Color 
>>>>> implements UIResource"
>>>>> caused the internal test failure,
>>>>> 
>>>>> So changed this fix to keep the DerivedColor class same and for the 
>>>>> uiProperties 
>>>>> Tree.selectionForeground” ..etc  use the UIResource
>>>>> class that is inside the DerivedColor. These changes were made in 
>>>>> skin.laf file.
>>>>> 
>>>>> Testing : Tested on all three platform, and all internal tests.Link is in 
>>>>> JBS.
>>>>> In test also added the part which was the reason of revert of earlier fix.
>>>>> The test fails with the fix of 8041701 and passes with the current fix.
>>>>> 
>>>>> 
>>>>> Regards
>>>>> Tejpal
>>> 

Re: RFR: 8249674: Redo: Nimbus JTree renderer properties persist across L changes

[Tejpal Rebari]

Hi Prasanta,

> On 27-Jul-2020, at 2:21 PM, Prasanta Sadhukhan 
>  wrote:
> 
> Fix looks ok to me. But I think the test is more appropriate if it is placed 
> in javax/swing/plaf/nimbus directory. Also, the test can be enhanced a bit to 
> not fail at the first attempt as we are testing 8 different properties, so I 
> think it will be good if you will store the results in a string for each 
> property that fails, and finally at the end throw failure with stored string.
> 
I was bit confused about where the test should be placed because it also checks 
for other LAFs.
But for other LAF test was passing earlier also so keeping the test in 
javax/swing/plaf/nimbus.

Made changes in the test to throw failure with stored string.

Updated webrev : http://cr.openjdk.java.net/~trebari/swing/8249674/webrev01/ 
<http://cr.openjdk.java.net/~trebari/swing/8249674/webrev01/>

Thanks
Tejpal


> Regards
> Prasanta
> On 24-Jul-20 2:36 PM, Tejpal Rebari wrote:
>> Hi All,
>> Please review the following fix for jdk16.
>> 
>> Bug :  https://bugs.openjdk.java.net/browse/JDK-8249674 
>> <https://bugs.openjdk.java.net/browse/JDK-8249674>
>> Webrev : http://cr.openjdk.java.net/~trebari/swing/8249674/webrev00/ 
>> <http://cr.openjdk.java.net/~trebari/swing/8249674/webrev00/>
>> 
>> This is a modified fix for https://bugs.openjdk.java.net/browse/JDK-8041701 
>> <https://bugs.openjdk.java.net/browse/JDK-8041701> 
>> which caused some internal test to fail.
>> 
>> Issue : UI properties “Tree.leafIcon”, “Tree.closedIcon”, “Tree.openIcon”,
>>  “Tree.selectionForeground” ..etc are supposed to be instances of UIResource 
>> if they are defined by LAF. 
>> 
>> In Nimbus LAF all the above properties are defined , but none of them 
>> implement 
>> UIResource, this causes them to persists when LAF is changed. 
>> This leaves artefacts when switching from nimbus to other LAFs.
>> 
>> Fix :  Fix is to make use of UIResource for the above mentioned uiProperties.
>> Making NimbuIcon implements the UIResource was working fine earlier 
>> so keeping the change same.
>> 
>> The second part of the earlier fix "class DerivedColor extends Color 
>> implements UIResource"
>> caused the internal test failure,
>> 
>> So changed this fix to keep the DerivedColor class same and for the 
>> uiProperties 
>> Tree.selectionForeground” ..etc  use the UIResource
>> class that is inside the DerivedColor. These changes were made in skin.laf 
>> file.
>> 
>> Testing : Tested on all three platform, and all internal tests.Link is in 
>> JBS.
>> In test also added the part which was the reason of revert of earlier fix.
>> The test fails with the fix of 8041701 and passes with the current fix.
>> 
>> 
>> Regards
>> Tejpal

RFR: 8249674: Redo: Nimbus JTree renderer properties persist across L changes

[Tejpal Rebari]

Hi All,
Please review the following fix for jdk16.

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

Webrev : http://cr.openjdk.java.net/~trebari/swing/8249674/webrev00/ 


This is a modified fix for https://bugs.openjdk.java.net/browse/JDK-8041701 
 
which caused some internal test to fail.

Issue : UI properties “Tree.leafIcon”, “Tree.closedIcon”, “Tree.openIcon”,
 “Tree.selectionForeground” ..etc are supposed to be instances of UIResource 
if they are defined by LAF. 

In Nimbus LAF all the above properties are defined , but none of them implement 
UIResource, this causes them to persists when LAF is changed. 
This leaves artefacts when switching from nimbus to other LAFs.

Fix :  Fix is to make use of UIResource for the above mentioned uiProperties.
Making NimbuIcon implements the UIResource was working fine earlier 
so keeping the change same.

The second part of the earlier fix "class DerivedColor extends Color implements 
UIResource"
caused the internal test failure,

So changed this fix to keep the DerivedColor class same and for the 
uiProperties 
Tree.selectionForeground” ..etc  use the UIResource
class that is inside the DerivedColor. These changes were made in skin.laf file.

Testing : Tested on all three platform, and all internal tests.Link is in JBS.
In test also added the part which was the reason of revert of earlier fix.
The test fails with the fix of 8041701 and passes with the current fix.


Regards
Tejpal

Re: RFR: Nimbus L Fix for 8041701 is causing some Nimbus tests to fail

[Tejpal Rebari]

> On 17-Jul-2020, at 8:59 PM, Philip Race  wrote:
> 
> Sound fine except do NOT re-open 8041701 - please file a new bug.

Ok, sure I will file a new bug.
Can somebody please push this change, as I don’t have commit rights.

Thanks
Tejpal
> 
> -phil.
> 
> On 7/17/20, 6:16 AM, Tejpal Rebari wrote:
>> 
>> Hi All,
>> 
>> Please review the following fix for jdk16.
>> 
>> Bug : https://bugs.openjdk.java.net/browse/JDK-8249619 
>> <https://bugs.openjdk.java.net/browse/JDK-8249619>
>> Webrev : http://cr.openjdk.java.net/~trebari/swing/8249619/webrev00/ 
>> <http://cr.openjdk.java.net/%7Etrebari/swing/8249619/webrev00/>
>> 
>> This change is revert of fix for JDK-8041701 
>> <https://bugs.openjdk.java.net/browse/JDK-8041701> .
>> The fix for JDK-8041701 <https://bugs.openjdk.java.net/browse/JDK-8041701> 
>> caused some internal NimbusLAF test to fail so need to reverted.
>> JDK-8041701 <https://bugs.openjdk.java.net/browse/JDK-8041701> will be 
>> reopened and re-worked for a proper fix.
>> 
>> Thanks
>> Tejpal

RFR: Nimbus L Fix for 8041701 is causing some Nimbus tests to fail

[Tejpal Rebari]

Hi All,

Please review the following fix for jdk16.

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

Webrev : http://cr.openjdk.java.net/~trebari/swing/8249619/webrev00/ 


This change is revert of fix for JDK-8041701 
 .
The fix for JDK-8041701  
caused some internal NimbusLAF test to fail so need to reverted.
JDK-8041701  will be reopened 
and re-worked for a proper fix.

Thanks
Tejpal

Re: RFR: 8041701 Nimbus JTree renderer properties persist across L changes

[Tejpal Rebari]

Hi Sergey,
Thanks for the review.

> On 11-Jul-2020, at 11:41 AM, Sergey Bylokhov  
> wrote:
> 
> Hi, Tejpal.
> 
> The fix looks fine, could you please update the test to check that all 
> installed L work the same way.
I have updated the test to check for all installed LAF.
Updated webrev : http://cr.openjdk.java.net/~trebari/swing/8041701/webrev01/ 


Tested on all there platform. 
Mach5 link is in JBS.

Regards
Tejpal

RFR: 8041701 Nimbus JTree renderer properties persist across L changes

[Tejpal Rebari]

Hi All,
Please review the following fix for jdk16.

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

Webrev : http://cr.openjdk.java.net/~trebari/swing/8041701/webrev00/ 


Issue : UI properties “Tree.leafIcon”, “Tree.closedIcon”, “Tree.openIcon”,
 “Tree.selectionForeground” ..etc are supposed to be instances of UIResource 
if they are defined by LAF. 

In Nimbus LAF all the above properties are defined , but none of them implement 
UIResource, this causes them to persists when LAF is changed.

Fix : Fix is to make NimbusLookAndFeel classes instance of UIResource,
which uses above mentioned UI Properties.

Test : Added an automated test.
Tested on all the three platforms. Mach5 link is in JBS.


Regards
Tejpal