From psadhukhan at openjdk.java.net Thu Apr 1 07:38:32 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Thu, 1 Apr 2021 07:38:32 GMT Subject: Integrated: 8263496: MetalHighContrastTheme.getControlHighlight cleanup In-Reply-To: References: Message-ID: On Tue, 23 Mar 2021 10:26:42 GMT, Prasanta Sadhukhan wrote: > SonarCloud reports the potential issue with MetalHighContrastTheme.getControlHighlight where `controlHighlight ` field is not used and the getControlHighlight() uses secondary field. > public ColorUIResource getControlHighlight() { > // This was super.getSecondary3(); > return secondary2; > } > Removed the unused field. This pull request has now been integrated. Changeset: 0696fd0e Author: Prasanta Sadhukhan URL: https://git.openjdk.java.net/jdk/commit/0696fd0e Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod 8263496: MetalHighContrastTheme.getControlHighlight cleanup Reviewed-by: azvegint ------------- PR: https://git.openjdk.java.net/jdk/pull/3149 From psadhukhan at openjdk.java.net Thu Apr 1 11:30:20 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Thu, 1 Apr 2021 11:30:20 GMT Subject: RFR: 8264218: Public method javax.swing.JMenu.setComponentOrientation() has no spec In-Reply-To: References: Message-ID: On Sat, 27 Mar 2021 01:20:45 GMT, Sergey Bylokhov wrote: >> A public overriding method JMenu.setComponentOrientation(java.awt.ComponentOrientation) >> has no spec. >> Added spec for the method. > > Looks like the JavaDoc bug, the spec was there in jdk7: > https://docs.oracle.com/javase/7/docs/api/javax/swing/JMenu.html#setComponentOrientation(java.awt.ComponentOrientation) I could not see the spec in the last 14 years openjdk history of this file. Shouldn't we need to add the spec even if it's javadoc bug? Instead of blindly copying JComponent setComponentOrientation spec as was done in jdk7 in above link, I have added a concise javadoc (same as is seen in JScrollPane#setComponentOrientation) ------------- PR: https://git.openjdk.java.net/jdk/pull/3213 From psadhukhan at openjdk.java.net Thu Apr 1 11:30:33 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Thu, 1 Apr 2021 11:30:33 GMT Subject: RFR: 8263907: Specification of CellRendererPane::paintComponent(..Rectangle) should clearly mention which method it delegates the call to In-Reply-To: References: Message-ID: On Tue, 23 Mar 2021 06:10:32 GMT, Prasanta Sadhukhan wrote: > Specification for method > javax/swing/CellRendererPane.html#paintComponent(java.awt.Graphics,java.awt.Component,java.awt.Container,java.awt.Rectangle) > is not perfectly clear which method the call is delegated to. > > Updated spec to clarify. Any reviewers? ------------- PR: https://git.openjdk.java.net/jdk/pull/3146 From pbansal at openjdk.java.net Thu Apr 1 12:12:40 2021 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Thu, 1 Apr 2021 12:12:40 GMT Subject: RFR: 8262981: Create implementation for NSAccessibilitySlider protocol [v3] In-Reply-To: References: Message-ID: > Create implementation of NSAccessibilitySlider protocol https://developer.apple.com/documentation/appkit/nsaccessibilityslider > > The implementation has the function performIncrement and performDecrement to increase/decrease the value of slider using the VoiceOver. To implement this functionality, I could think of following two ways. I have chosen the first one here though it is more intrusive. > 1. Make the AccessibleJSlider class implement the AccessibleAction interface. This makes AccessibleJSlider consistent with the AccessibleJSpinner class. It is more clear and the logic to increase/decrease Slider value can be changed easily. But this changes AccessibleJSlider class and will need a CSR. > 2. Get the current Accessible Value from the component and just increment/decrement it in SliderAccessibility.m class itself and then set the current accessible value fro there only. This will not need any changes in AccessibleJSlider class, but this does not look correct way and I have not used this. > > The changes can be easily tested by using a JSlider example, like the following example. VO should announce the correct the slider values. To change the slider values, use ctrl+opt+shift+down key to start interacting with the slider, then use ctrl+opt+up/down arrow keys to increment/decrement slider values. > > import javax.swing.JFrame; > import javax.swing.JSlider; > > public class JSliderDemo{ > public static void main(String[] args) throws Exception { > JFrame jframe = new JFrame("JSlider Demo"); > jframe.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); > jframe.add(new JSlider()); > > jframe.setLocationRelativeTo(null); > jframe.pack(); > jframe.setVisible(true); > } > } Pankaj Bansal has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: - Merge branch 'master' into JDK-8262981 - increase initial capacity for rolesMap - Remove whitespaces - remove SpinboxAccessibility.m changes - Code cleanup - cleanup - 8262981: Create implementation for NSAccessibilitySlider protocol ------------- Changes: https://git.openjdk.java.net/jdk/pull/2874/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2874&range=02 Stats: 75 lines in 4 files changed: 68 ins; 1 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/2874.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2874/head:pull/2874 PR: https://git.openjdk.java.net/jdk/pull/2874 From psadhukhan at openjdk.java.net Thu Apr 1 12:26:35 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Thu, 1 Apr 2021 12:26:35 GMT Subject: =?utf-8?q?RFR=3A_8264398=3A_BevelBorderUIResource?= =?utf-8?q?=E2=80=8B=28int=2C_Color=2C_Color=29_spec_should_mention_that_t?= =?utf-8?q?he_passed_colors_are_for_highlightInner_and_shadowOuter_props?= Message-ID: The current spec for javax/swing/plaf/BorderUIResource.BevelBorderUIResource.html(int,java.awt.Color,java.awt.Color) does not clearly specify the usage of color for hightlight and shadow as there are outer/inner hightlight and outer/inner shadow. Updated spec to clarify the same. ------------- Commit messages: - 8264398: BevelBorderUIResource?(int, Color, Color) spec should mention that the passed colors are for highlightInner and shadowOuter props Changes: https://git.openjdk.java.net/jdk/pull/3305/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3305&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264398 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3305.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3305/head:pull/3305 PR: https://git.openjdk.java.net/jdk/pull/3305 From aivanov at openjdk.java.net Thu Apr 1 12:38:20 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Thu, 1 Apr 2021 12:38:20 GMT Subject: RFR: 8264218: Public method javax.swing.JMenu.setComponentOrientation() has no spec In-Reply-To: References: Message-ID: <6lhKE_kHeA5SRB92zvKOWsD1flARHhcpcnVJsxLBX3M=.88085c8e-89bc-475c-b18e-23041f5592e7@github.com> On Thu, 1 Apr 2021 11:26:55 GMT, Prasanta Sadhukhan wrote: >> Looks like the JavaDoc bug, the spec was there in jdk7: >> https://docs.oracle.com/javase/7/docs/api/javax/swing/JMenu.html#setComponentOrientation(java.awt.ComponentOrientation) > > I could not see the spec in the last 14 years openjdk history of this file. Shouldn't we need to add the spec even if it's javadoc bug? > Instead of blindly copying JComponent setComponentOrientation spec as was done in jdk7 in above link, I have added a concise javadoc (same as is seen in JScrollPane#setComponentOrientation) The method is also present in the Java 8: https://docs.oracle.com/javase/8/docs/api/javax/swing/JMenu.html#setComponentOrientation-java.awt.ComponentOrientation- ------------- PR: https://git.openjdk.java.net/jdk/pull/3213 From psadhukhan at openjdk.java.net Thu Apr 1 12:52:38 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Thu, 1 Apr 2021 12:52:38 GMT Subject: RFR: 8264218: Public method javax.swing.JMenu.setComponentOrientation() has no spec In-Reply-To: <6lhKE_kHeA5SRB92zvKOWsD1flARHhcpcnVJsxLBX3M=.88085c8e-89bc-475c-b18e-23041f5592e7@github.com> References: <6lhKE_kHeA5SRB92zvKOWsD1flARHhcpcnVJsxLBX3M=.88085c8e-89bc-475c-b18e-23041f5592e7@github.com> Message-ID: On Thu, 1 Apr 2021 12:35:21 GMT, Alexey Ivanov wrote: >> I could not see the spec in the last 14 years openjdk history of this file. Shouldn't we need to add the spec even if it's javadoc bug? >> Instead of blindly copying JComponent setComponentOrientation spec as was done in jdk7 in above link, I have added a concise javadoc (same as is seen in JScrollPane#setComponentOrientation) > > The method is also present in the Java 8: > https://docs.oracle.com/javase/8/docs/api/javax/swing/JMenu.html#setComponentOrientation-java.awt.ComponentOrientation- I guess openjdk shows file history from 7u23 onwards IIRC so not sure why it is showing "Initial load" and not who/what removed it. Maybe the spec wordings actually was not there but some javadoc trickery was adding the javadoc comment in to the spec document seeing it's overidden from JComponent.... I am not sure what needs to be done here... ------------- PR: https://git.openjdk.java.net/jdk/pull/3213 From github.com+741251+turbanoff at openjdk.java.net Thu Apr 1 12:52:39 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Thu, 1 Apr 2021 12:52:39 GMT Subject: RFR: 8264428: Cleanup usages of StringBuffer in java.desktop In-Reply-To: <27yKI-MoNpdtE7_qYEHLNj-tmphsEvwwT7NunRjEY5c=.d585ed9c-b74c-4b82-8c24-fca05d944f58@github.com> References: <2y9jvm8hnBRZQIO4qwAY-C07aSQM1QIzIT6SWAj7c70=.bda3ef0d-a445-40b0-b155-3920d072cb89@github.com> <27yKI-MoNpdtE7_qYEHLNj-tmphsEvwwT7NunRjEY5c=.d585ed9c-b74c-4b82-8c24-fca05d944f58@github.com> Message-ID: On Wed, 31 Mar 2021 21:12:37 GMT, Sergey Bylokhov wrote: >> Submitted: https://bugs.openjdk.java.net/browse/JDK-8264428, please rename PR to "8264428: Replace uses of StringBuffer with StringBuilder in java.desktop". > > Looks like this change goes beyond of simple replacement of StringBuffer with StringBuilder. Please update the description of the bug and PR description. I've updated PR description, but I don't have rights to update JIRA. ------------- PR: https://git.openjdk.java.net/jdk/pull/3251 From aivanov at openjdk.java.net Thu Apr 1 12:52:39 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Thu, 1 Apr 2021 12:52:39 GMT Subject: RFR: 8264218: Public method javax.swing.JMenu.setComponentOrientation() has no spec In-Reply-To: References: Message-ID: On Fri, 26 Mar 2021 11:30:35 GMT, Prasanta Sadhukhan wrote: > A public overriding method JMenu.setComponentOrientation(java.awt.ComponentOrientation) > has no spec. > Added spec for the method. src/java.desktop/share/classes/javax/swing/JMenu.java line 1269: > 1267: * > 1268: * @see java.awt.ComponentOrientation > 1269: */ Shall it just use `{@inheritDoc}`? The javadoc generated in 7 and 8 does exactly this. However, the new text explicitly mentions that this method changes not only orientation of this component but also of the associated popup menu. I do not think the description of the parameter has to list all the values of `ComponentOrientation`, these are the only publicly available values any way. If a value is added in the future, the javadoc will become incorrect. ------------- PR: https://git.openjdk.java.net/jdk/pull/3213 From kcr at openjdk.java.net Thu Apr 1 12:52:38 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 1 Apr 2021 12:52:38 GMT Subject: RFR: 8264218: Public method javax.swing.JMenu.setComponentOrientation() has no spec In-Reply-To: References: <6lhKE_kHeA5SRB92zvKOWsD1flARHhcpcnVJsxLBX3M=.88085c8e-89bc-475c-b18e-23041f5592e7@github.com> Message-ID: On Thu, 1 Apr 2021 12:41:14 GMT, Prasanta Sadhukhan wrote: >> The method is also present in the Java 8: >> https://docs.oracle.com/javase/8/docs/api/javax/swing/JMenu.html#setComponentOrientation-java.awt.ComponentOrientation- > > I guess openjdk shows file history from 7u23 onwards IIRC so not sure why it is showing "Initial load" and not who/what removed it. Maybe the spec wordings actually was not there but some javadoc trickery was adding the javadoc comment in to the spec document seeing it's overidden from JComponent.... > I am not sure what needs to be done here... The `javadoc` tool (or the standard doclet) used to automatically copy the description from the superclass, and it seems that it no longer does. Perhaps @jonathan-gibbons could comment on this change? @prsadhuk You could always add `@inheritDoc` like this: /** * {@inheritDoc} */ ------------- PR: https://git.openjdk.java.net/jdk/pull/3213 From psadhukhan at openjdk.java.net Thu Apr 1 12:52:40 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Thu, 1 Apr 2021 12:52:40 GMT Subject: RFR: 8264218: Public method javax.swing.JMenu.setComponentOrientation() has no spec In-Reply-To: References: Message-ID: On Thu, 1 Apr 2021 12:42:19 GMT, Alexey Ivanov wrote: >> A public overriding method JMenu.setComponentOrientation(java.awt.ComponentOrientation) >> has no spec. >> Added spec for the method. > > src/java.desktop/share/classes/javax/swing/JMenu.java line 1269: > >> 1267: * >> 1268: * @see java.awt.ComponentOrientation >> 1269: */ > > Shall it just use `{@inheritDoc}`? > The javadoc generated in 7 and 8 does exactly this. > > However, the new text explicitly mentions that this method changes not only orientation of this component but also of the associated popup menu. > > I do not think the description of the parameter has to list all the values of `ComponentOrientation`, these are the only publicly available values any way. If a value is added in the future, the javadoc will become incorrect. It is done similarly in JScrollPane which I used here...maybe there also it's an oversight then.. I will update to use @inheritdoc in this spec ... ------------- PR: https://git.openjdk.java.net/jdk/pull/3213 From psadhukhan at openjdk.java.net Thu Apr 1 12:55:42 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Thu, 1 Apr 2021 12:55:42 GMT Subject: RFR: 8264218: Public method javax.swing.JMenu.setComponentOrientation() has no spec [v2] In-Reply-To: References: Message-ID: > A public overriding method JMenu.setComponentOrientation(java.awt.ComponentOrientation) > has no spec. > Added spec for the method. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Add @inheritDoc ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3213/files - new: https://git.openjdk.java.net/jdk/pull/3213/files/41eddf23..e2f1d259 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3213&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3213&range=00-01 Stats: 10 lines in 1 file changed: 0 ins; 9 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3213.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3213/head:pull/3213 PR: https://git.openjdk.java.net/jdk/pull/3213 From aivanov at openjdk.java.net Thu Apr 1 13:03:32 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Thu, 1 Apr 2021 13:03:32 GMT Subject: RFR: 8264218: Public method javax.swing.JMenu.setComponentOrientation() has no spec [v2] In-Reply-To: References: Message-ID: On Thu, 1 Apr 2021 12:49:06 GMT, Prasanta Sadhukhan wrote: >> src/java.desktop/share/classes/javax/swing/JMenu.java line 1269: >> >>> 1267: * >>> 1268: * @see java.awt.ComponentOrientation >>> 1269: */ >> >> Shall it just use `{@inheritDoc}`? >> The javadoc generated in 7 and 8 does exactly this. >> >> However, the new text explicitly mentions that this method changes not only orientation of this component but also of the associated popup menu. >> >> I do not think the description of the parameter has to list all the values of `ComponentOrientation`, these are the only publicly available values any way. If a value is added in the future, the javadoc will become incorrect. > > It is done similarly in JScrollPane which I used here...maybe there also it's an oversight then.. > I will update to use @inheritdoc in this spec ... Yes, I see? Yet I think listing values of `ComponentOrientation` is redundant. However, looking at JScrollPane, its javadoc specifies why it's overridden: _Sets the orientation for the vertical and horizontal scrollbars_. In the case of `JMenu`, it also changes the orientation of *popup menu* inside JMenu. Taking into account this additional detail, your initial text could have been better. ------------- PR: https://git.openjdk.java.net/jdk/pull/3213 From pbansal at openjdk.java.net Thu Apr 1 14:10:20 2021 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Thu, 1 Apr 2021 14:10:20 GMT Subject: RFR: 8262981: Create implementation for NSAccessibilitySlider protocol In-Reply-To: References: <3kHCT6j_xnm9mbA2jeP35p9rY4nxOD61PInSB9mglT8=.71c3b9df-0cc3-40f7-b339-15b382e36b6f@github.com> <4SZRIR695DBooSWt-1aatGx-CKPy6EwuRpXS29A8wro=.4ba37fe2-6017-482f-83c4-33d7a11fc320@github.com> <60QaQ3ISOvoR5RMWU1hTSCsiBHfy7xU2QjvLzrGaSvA=.c02ab62e-5176-4015-a16c-849a71088452@github.com> Message-ID: <_0Cgp4vsNo49z6YCKsdAawn-Dufn7opDEUAzlFIjkQA=.4d9097da-86f2-4671-967d-6c9fa65d3ede@github.com> On Wed, 31 Mar 2021 19:56:24 GMT, Sergey Bylokhov wrote: > Ok, please file a similar bug for the windows platform. I have created the bug for windows here https://bugs.openjdk.java.net/browse/JDK-8264598. I have also created the CSR for the current issue. ------------- PR: https://git.openjdk.java.net/jdk/pull/2874 From jjg at openjdk.java.net Thu Apr 1 14:13:13 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Thu, 1 Apr 2021 14:13:13 GMT Subject: RFR: 8264218: Public method javax.swing.JMenu.setComponentOrientation() has no spec In-Reply-To: References: <6lhKE_kHeA5SRB92zvKOWsD1flARHhcpcnVJsxLBX3M=.88085c8e-89bc-475c-b18e-23041f5592e7@github.com> Message-ID: <57KgcbXzUmc5FzqD-mvUsyUe662nCpJ70NJ0JUZp4kE=.d193e739-7541-486c-b002-16bdd23fed53@github.com> On Thu, 1 Apr 2021 12:45:52 GMT, Kevin Rushforth wrote: >> I guess openjdk shows file history from 7u23 onwards IIRC so not sure why it is showing "Initial load" and not who/what removed it. Maybe the spec wordings actually was not there but some javadoc trickery was adding the javadoc comment in to the spec document seeing it's overidden from JComponent.... >> I am not sure what needs to be done here... > > @prsadhuk You could always add `@inheritDoc` like this: > > /** > * {@inheritDoc} > */ Starting in JDK 10, the default behavior of the standard doclet was changed so that if a method is just being overridden for implementation reasons, and there is no change in the public spec or signature, then the method will not be listed in the main part of the summary table and corresponding details section.? Instead, it will just be listed along with other inherited methods at the end of the summary section, in a list which is renamed from "Methods inherited from ..." to "Methods declared in ..." To be clear, this behavior only applies when there is nothing new to document about the overriding method. "No change in spec" means either no doc comment or a comment that is just `/** ***@***.***Doc} */`. "No change in signature" covers publicly visibly changes like covariant return, change in modifiers, change in throws list, etc. You can change the behavior on a per-instance behavior by providing additional changes in the doc comment. javadoc still supports the old style of doc generation with a command-line option, but for JDK docs, the default is the new behavior I described. -- Jon On 4/1/21 5:43 AM, Kevin Rushforth wrote: > > The |javadoc| tool (or the standard doclet) used to automatically copy > the description from the superclass, and it seems that it no longer > does. Perhaps @jonathan-gibbons > > could comment on this change? > > ? > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > , > or unsubscribe > . > ------------- PR: https://git.openjdk.java.net/jdk/pull/3213 From trebari at openjdk.java.net Thu Apr 1 14:37:48 2021 From: trebari at openjdk.java.net (Tejpal Rebari) Date: Thu, 1 Apr 2021 14:37:48 GMT Subject: RFR: 8253266 : JList and JTable constructors should clear OPAQUE_SET before calling updateUI [v3] In-Reply-To: <0xQaEjHSESc7X1yaj1XWaOXBSyQDQgD1Jd6bkJbBGGw=.30558ebd-a585-4204-a501-b23d41249573@github.com> References: <0xQaEjHSESc7X1yaj1XWaOXBSyQDQgD1Jd6bkJbBGGw=.30558ebd-a585-4204-a501-b23d41249573@github.com> Message-ID: > 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&pr=3167&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3167&range=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 From trebari at openjdk.java.net Thu Apr 1 14:46:35 2021 From: trebari at openjdk.java.net (Tejpal Rebari) Date: Thu, 1 Apr 2021 14:46:35 GMT Subject: RFR: 8253266 : JList and JTable constructors should clear OPAQUE_SET before calling updateUI [v2] In-Reply-To: References: <0xQaEjHSESc7X1yaj1XWaOXBSyQDQgD1Jd6bkJbBGGw=.30558ebd-a585-4204-a501-b23d41249573@github.com> Message-ID: 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 From shade at openjdk.java.net Thu Apr 1 14:55:24 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 1 Apr 2021 14:55:24 GMT Subject: RFR: 8264428: Cleanup usages of StringBuffer in java.desktop In-Reply-To: References: <2y9jvm8hnBRZQIO4qwAY-C07aSQM1QIzIT6SWAj7c70=.bda3ef0d-a445-40b0-b155-3920d072cb89@github.com> <27yKI-MoNpdtE7_qYEHLNj-tmphsEvwwT7NunRjEY5c=.d585ed9c-b74c-4b82-8c24-fca05d944f58@github.com> Message-ID: <7xA0-f_B9XNpEBl0l9tpBx8Q_jAbS2cKIKFKu01OSVE=.71194289-36fe-4768-b753-7c298d7ee349@github.com> On Thu, 1 Apr 2021 12:48:52 GMT, Andrey Turbanov wrote: >> Looks like this change goes beyond of simple replacement of StringBuffer with StringBuilder. Please update the description of the bug and PR description. > > I've updated PR description, but I don't have rights to update JIRA. I updated the bug synopsis in JIRA. ------------- PR: https://git.openjdk.java.net/jdk/pull/3251 From psadhukhan at openjdk.java.net Thu Apr 1 15:28:22 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Thu, 1 Apr 2021 15:28:22 GMT Subject: RFR: 8264218: Public method javax.swing.JMenu.setComponentOrientation() has no spec In-Reply-To: <57KgcbXzUmc5FzqD-mvUsyUe662nCpJ70NJ0JUZp4kE=.d193e739-7541-486c-b002-16bdd23fed53@github.com> References: <6lhKE_kHeA5SRB92zvKOWsD1flARHhcpcnVJsxLBX3M=.88085c8e-89bc-475c-b18e-23041f5592e7@github.com> <57KgcbXzUmc5FzqD-mvUsyUe662nCpJ70NJ0JUZp4kE=.d193e739-7541-486c-b002-16bdd23fed53@github.com> Message-ID: On Thu, 1 Apr 2021 14:10:08 GMT, Jonathan Gibbons wrote: >> @prsadhuk You could always add `@inheritDoc` like this: >> >> /** >> * {@inheritDoc} >> */ > > Starting in JDK 10, the default behavior of the standard doclet was > changed so that if a method is just being overridden for implementation > reasons, and there is no change in the public spec or signature, then > the method will not be listed in the main part of the summary table and > corresponding details section.? Instead, it will just be listed along > with other inherited methods at the end of the summary section, in a > list which is renamed from "Methods inherited from ..." to "Methods > declared in ..." > > To be clear, this behavior only applies when there is nothing new to > document about the overriding method. > > "No change in spec" means either no doc comment or a comment that is > just `/** {@inheritDoc} */` or its whitespace equivalent. > > "No change in signature" covers publicly visibly changes like covariant > return, change in modifiers, change in throws list, etc. > > You can change the behavior on a per-instance behavior by providing > additional changes in the doc comment. > > javadoc still supports the old style of doc generation with a > command-line option, but for JDK docs, the default is the new behavior I > described. > > -- Jon > > On 4/1/21 5:43 AM, Kevin Rushforth wrote: >> >> The |javadoc| tool (or the standard doclet) used to automatically copy >> the description from the superclass, and it seems that it no longer >> does. Perhaps @jonathan-gibbons >> >> could comment on this change? >> >> ? >> You are receiving this because you were mentioned. >> Reply to this email directly, view it on GitHub >> , >> or unsubscribe >> . >> > > Starting in JDK 10, the default behavior of the standard doclet was changed so that if a method is just being overridden for implementation reasons, and there is no change in the public spec or signature, then the method will not be listed in the main part of the summary table and corresponding details section. Instead, it will just be listed along with other inherited methods at the end of the summary section, in a list which is renamed from "Methods inherited from ..." to "Methods declared in ..." To be clear, this behavior only applies when there is nothing new to document about the overriding method. "No change in spec" means either no doc comment or a comment that is just `/** {@inheritdoc} */` or its whitespace equivalent. "No change in signature" covers publicly visibly changes like covariant return, change in modifiers, change in throws list, etc. You can change the behavior on a per-instance behavior by providing additional changes in the doc comment. javadoc still suppor ts the old style of doc generation with a command-line option, but for JDK docs, the default is the new behavior I described. > [?](#) > -- Jon > On 4/1/21 5:43 AM, Kevin Rushforth wrote: The |javadoc| tool (or the standard doclet) used to automatically copy the description from the superclass, and it seems that it no longer does. Perhaps @jonathan-gibbons <[https://urldefense.com/v3/__https://github.com/jonathan-gibbons__;!!GqivPVa7Brio!Nt46yROIsMrLvPBMvzgGTeSnhOvHtuHlNczVmgAJ-wPR9Lk254rhfVFX79WhAtjxN8g4zw$](https://urldefense.com/v3/__https://github.com/jonathan-gibbons__;!!GqivPVa7Brio!Nt46yROIsMrLvPBMvzgGTeSnhOvHtuHlNczVmgAJ-wPR9Lk254rhfVFX79WhAtjxN8g4zw%24)> could comment on this change? ? You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <[https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/3213*issuecomment-811880830__;Iw!!GqivPVa7Brio!Nt46yROIsMrLvPBMvzgGTeSnhOvHtuHlNczVmgAJ-wPR9Lk254rhfVFX79WhAtiQlz8B-g$](https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/3213*issuecomment-811880830__;Iw!!GqivPVa7Brio!Nt46yROIsMrLvPBMvzgGTeSnhOvHtuHlNczVmgAJ -wPR9Lk254rhfVFX79WhAtiQlz8B-g%24)>, or unsubscribe <[https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AOUXBRUGHOZZ4X3NOBWRX63TGRS55ANCNFSM4Z3HDOJA__;!!GqivPVa7Brio!Nt46yROIsMrLvPBMvzgGTeSnhOvHtuHlNczVmgAJ-wPR9Lk254rhfVFX79WhAtg5YRT3Kw$](https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AOUXBRUGHOZZ4X3NOBWRX63TGRS55ANCNFSM4Z3HDOJA__;!!GqivPVa7Brio!Nt46yROIsMrLvPBMvzgGTeSnhOvHtuHlNczVmgAJ-wPR9Lk254rhfVFX79WhAtg5YRT3Kw%24)>. So, are you saying that even if we provide @inheritDoc, it will not be listed if there is no change in spec compared to super class? ------------- PR: https://git.openjdk.java.net/jdk/pull/3213 From jjg at openjdk.java.net Thu Apr 1 15:32:14 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Thu, 1 Apr 2021 15:32:14 GMT Subject: RFR: 8264218: Public method javax.swing.JMenu.setComponentOrientation() has no spec In-Reply-To: References: <6lhKE_kHeA5SRB92zvKOWsD1flARHhcpcnVJsxLBX3M=.88085c8e-89bc-475c-b18e-23041f5592e7@github.com> <57KgcbXzUmc5FzqD-mvUsyUe662nCpJ70NJ0JUZp4kE=.d193e739-7541-486c-b002-16bdd23fed53@github.com> Message-ID: On Thu, 1 Apr 2021 15:25:44 GMT, Prasanta Sadhukhan wrote: >> Starting in JDK 10, the default behavior of the standard doclet was >> changed so that if a method is just being overridden for implementation >> reasons, and there is no change in the public spec or signature, then >> the method will not be listed in the main part of the summary table and >> corresponding details section.? Instead, it will just be listed along >> with other inherited methods at the end of the summary section, in a >> list which is renamed from "Methods inherited from ..." to "Methods >> declared in ..." >> >> To be clear, this behavior only applies when there is nothing new to >> document about the overriding method. >> >> "No change in spec" means either no doc comment or a comment that is >> just `/** {@inheritDoc} */` or its whitespace equivalent. >> >> "No change in signature" covers publicly visibly changes like covariant >> return, change in modifiers, change in throws list, etc. >> >> You can change the behavior on a per-instance behavior by providing >> additional changes in the doc comment. >> >> javadoc still supports the old style of doc generation with a >> command-line option, but for JDK docs, the default is the new behavior I >> described. >> >> -- Jon >> >> On 4/1/21 5:43 AM, Kevin Rushforth wrote: >>> >>> The |javadoc| tool (or the standard doclet) used to automatically copy >>> the description from the superclass, and it seems that it no longer >>> does. Perhaps @jonathan-gibbons >>> >>> could comment on this change? >>> >>> ? >>> You are receiving this because you were mentioned. >>> Reply to this email directly, view it on GitHub >>> , >>> or unsubscribe >>> . >>> > >> >> Starting in JDK 10, the default behavior of the standard doclet was changed so that if a method is just being overridden for implementation reasons, and there is no change in the public spec or signature, then the method will not be listed in the main part of the summary table and corresponding details section. Instead, it will just be listed along with other inherited methods at the end of the summary section, in a list which is renamed from "Methods inherited from ..." to "Methods declared in ..." To be clear, this behavior only applies when there is nothing new to document about the overriding method. "No change in spec" means either no doc comment or a comment that is just `/** {@inheritdoc} */` or its whitespace equivalent. "No change in signature" covers publicly visibly changes like covariant return, change in modifiers, change in throws list, etc. You can change the behavior on a per-instance behavior by providing additional changes in the doc comment. javadoc still suppo rts the old style of doc generation with a command-line option, but for JDK docs, the default is the new behavior I described. >> [?](#) >> -- Jon >> On 4/1/21 5:43 AM, Kevin Rushforth wrote: The |javadoc| tool (or the standard doclet) used to automatically copy the description from the superclass, and it seems that it no longer does. Perhaps @jonathan-gibbons <[https://urldefense.com/v3/__https://github.com/jonathan-gibbons__;!!GqivPVa7Brio!Nt46yROIsMrLvPBMvzgGTeSnhOvHtuHlNczVmgAJ-wPR9Lk254rhfVFX79WhAtjxN8g4zw$](https://urldefense.com/v3/__https://github.com/jonathan-gibbons__;!!GqivPVa7Brio!Nt46yROIsMrLvPBMvzgGTeSnhOvHtuHlNczVmgAJ-wPR9Lk254rhfVFX79WhAtjxN8g4zw%24)> could comment on this change? ? You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <[https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/3213*issuecomment-811880830__;Iw!!GqivPVa7Brio!Nt46yROIsMrLvPBMvzgGTeSnhOvHtuHlNczVmgAJ-wPR9Lk254rhfVFX79WhAtiQlz8B-g$](https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/3213*issuecomment-811880830__;Iw!!GqivPVa7Brio!Nt46yROIsMrLvPBMvzgGTeSnhOvHtuHlNczVmgA J-wPR9Lk254rhfVFX79WhAtiQlz8B-g%24)>, or unsubscribe <[https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AOUXBRUGHOZZ4X3NOBWRX63TGRS55ANCNFSM4Z3HDOJA__;!!GqivPVa7Brio!Nt46yROIsMrLvPBMvzgGTeSnhOvHtuHlNczVmgAJ-wPR9Lk254rhfVFX79WhAtg5YRT3Kw$](https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AOUXBRUGHOZZ4X3NOBWRX63TGRS55ANCNFSM4Z3HDOJA__;!!GqivPVa7Brio!Nt46yROIsMrLvPBMvzgGTeSnhOvHtuHlNczVmgAJ-wPR9Lk254rhfVFX79WhAtg5YRT3Kw%24)>. > > So, are you saying that even if we provide @inheritDoc, it will not be listed if there is no change in spec compared to super class? On 4/1/21 8:26 AM, Prasanta Sadhukhan wrote: > > So, are you saying that even if we provide @inheritdoc > , > it will not be listed if there is no change in spec compared to super > class? > Yes. ------------- PR: https://git.openjdk.java.net/jdk/pull/3213 From psadhukhan at openjdk.java.net Thu Apr 1 15:48:53 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Thu, 1 Apr 2021 15:48:53 GMT Subject: RFR: 8264218: Public method javax.swing.JMenu.setComponentOrientation() has no spec [v3] In-Reply-To: References: Message-ID: <9DD5xnz2i68lQz4ADKDBj-qF1z0v7E3uAqiExKJ6p_M=.4055695c-5e32-4bbc-b301-cf5ba0c2b7b5@github.com> > A public overriding method JMenu.setComponentOrientation(java.awt.ComponentOrientation) > has no spec. > Added spec for the method. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: javadoc change ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3213/files - new: https://git.openjdk.java.net/jdk/pull/3213/files/e2f1d259..f8d2da21 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3213&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3213&range=01-02 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3213.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3213/head:pull/3213 PR: https://git.openjdk.java.net/jdk/pull/3213 From serb at openjdk.java.net Thu Apr 1 15:56:20 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Thu, 1 Apr 2021 15:56:20 GMT Subject: RFR: 8264218: Public method javax.swing.JMenu.setComponentOrientation() has no spec In-Reply-To: References: <6lhKE_kHeA5SRB92zvKOWsD1flARHhcpcnVJsxLBX3M=.88085c8e-89bc-475c-b18e-23041f5592e7@github.com> <57KgcbXzUmc5FzqD-mvUsyUe662nCpJ70NJ0JUZp4kE=.d193e739-7541-486c-b002-16bdd23fed53@github.com> Message-ID: On Thu, 1 Apr 2021 15:29:34 GMT, Jonathan Gibbons wrote: >>> >>> Starting in JDK 10, the default behavior of the standard doclet was changed so that if a method is just being overridden for implementation reasons, and there is no change in the public spec or signature, then the method will not be listed in the main part of the summary table and corresponding details section. Instead, it will just be listed along with other inherited methods at the end of the summary section, in a list which is renamed from "Methods inherited from ..." to "Methods declared in ..." To be clear, this behavior only applies when there is nothing new to document about the overriding method. "No change in spec" means either no doc comment or a comment that is just `/** {@inheritdoc} */` or its whitespace equivalent. "No change in signature" covers publicly visibly changes like covariant return, change in modifiers, change in throws list, etc. You can change the behavior on a per-instance behavior by providing additional changes in the doc comment. javadoc still supp orts the old style of doc generation with a command-line option, but for JDK docs, the default is the new behavior I described. >>> [?](#) >>> -- Jon >>> On 4/1/21 5:43 AM, Kevin Rushforth wrote: The |javadoc| tool (or the standard doclet) used to automatically copy the description from the superclass, and it seems that it no longer does. Perhaps @jonathan-gibbons <[https://urldefense.com/v3/__https://github.com/jonathan-gibbons__;!!GqivPVa7Brio!Nt46yROIsMrLvPBMvzgGTeSnhOvHtuHlNczVmgAJ-wPR9Lk254rhfVFX79WhAtjxN8g4zw$](https://urldefense.com/v3/__https://github.com/jonathan-gibbons__;!!GqivPVa7Brio!Nt46yROIsMrLvPBMvzgGTeSnhOvHtuHlNczVmgAJ-wPR9Lk254rhfVFX79WhAtjxN8g4zw%24)> could comment on this change? ? You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <[https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/3213*issuecomment-811880830__;Iw!!GqivPVa7Brio!Nt46yROIsMrLvPBMvzgGTeSnhOvHtuHlNczVmgAJ-wPR9Lk254rhfVFX79WhAtiQlz8B-g$](https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/3213*issuecomment-811880830__;Iw!!GqivPVa7Brio!Nt46yROIsMrLvPBMvzgGTeSnhOvHtuHlNczVmg AJ-wPR9Lk254rhfVFX79WhAtiQlz8B-g%24)>, or unsubscribe <[https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AOUXBRUGHOZZ4X3NOBWRX63TGRS55ANCNFSM4Z3HDOJA__;!!GqivPVa7Brio!Nt46yROIsMrLvPBMvzgGTeSnhOvHtuHlNczVmgAJ-wPR9Lk254rhfVFX79WhAtg5YRT3Kw$](https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AOUXBRUGHOZZ4X3NOBWRX63TGRS55ANCNFSM4Z3HDOJA__;!!GqivPVa7Brio!Nt46yROIsMrLvPBMvzgGTeSnhOvHtuHlNczVmgAJ-wPR9Lk254rhfVFX79WhAtg5YRT3Kw%24)>. >> >> So, are you saying that even if we provide @inheritDoc, it will not be listed if there is no change in spec compared to super class? > > On 4/1/21 8:26 AM, Prasanta Sadhukhan wrote: >> >> So, are you saying that even if we provide @inheritdoc >> , >> it will not be listed if there is no change in spec compared to super >> class? >> > > Yes. The method was overridden to change the implementation without changing of specification. This is exactly the case that was changed in the JavaDoc tool in jdk10. For this case, the JavaDoc tool decided to skip spec generation, it is a feature. So this is not a bug in the Swing, probably it is a bug in the JavaDoc tool, maybe not a bug at all. ------------- PR: https://git.openjdk.java.net/jdk/pull/3213 From aivanov at openjdk.java.net Thu Apr 1 15:56:22 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Thu, 1 Apr 2021 15:56:22 GMT Subject: RFR: 8264218: Public method javax.swing.JMenu.setComponentOrientation() has no spec [v3] In-Reply-To: <9DD5xnz2i68lQz4ADKDBj-qF1z0v7E3uAqiExKJ6p_M=.4055695c-5e32-4bbc-b301-cf5ba0c2b7b5@github.com> References: <9DD5xnz2i68lQz4ADKDBj-qF1z0v7E3uAqiExKJ6p_M=.4055695c-5e32-4bbc-b301-cf5ba0c2b7b5@github.com> Message-ID: <8jVFn8yKKp2MYxELI-hea-_Tsv6UJ3zrn6QRE2YbBns=.5016e20e-eed8-465d-9039-5784ada787fe@github.com> On Thu, 1 Apr 2021 15:48:53 GMT, Prasanta Sadhukhan wrote: >> A public overriding method JMenu.setComponentOrientation(java.awt.ComponentOrientation) >> has no spec. >> Added spec for the method. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > javadoc change src/java.desktop/share/classes/javax/swing/JMenu.java line 1259: > 1257: > 1258: /** > 1259: * Sets the orientation for this menu and the associated popup component Suggestion: * Sets the orientation for this menu and the associated popup menu I think *popup component* isn't specific enough. Maybe ?and *its* associated?? is even better? src/java.desktop/share/classes/javax/swing/JMenu.java line 1260: > 1258: /** > 1259: * Sets the orientation for this menu and the associated popup component > 1260: * determined by the ComponentOrientation argument. Suggestion: * determined by the {@code ComponentOrientation} argument. The new code should use javadoc syntax. src/java.desktop/share/classes/javax/swing/JMenu.java line 1265: > 1263: * the popup menu component contained within it. > 1264: */ > 1265: public void setComponentOrientation(ComponentOrientation o) { For consistency, I suggest using the same wording here as in the introduction sentence. ------------- PR: https://git.openjdk.java.net/jdk/pull/3213 From psadhukhan at openjdk.java.net Thu Apr 1 16:12:41 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Thu, 1 Apr 2021 16:12:41 GMT Subject: RFR: 8264218: Public method javax.swing.JMenu.setComponentOrientation() has no spec [v4] In-Reply-To: References: Message-ID: > A public overriding method JMenu.setComponentOrientation(java.awt.ComponentOrientation) > has no spec. > Added spec for the method. Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision: - javadoc change - javadoc change ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3213/files - new: https://git.openjdk.java.net/jdk/pull/3213/files/f8d2da21..8a4645b2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3213&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3213&range=02-03 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/3213.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3213/head:pull/3213 PR: https://git.openjdk.java.net/jdk/pull/3213 From aivanov at openjdk.java.net Thu Apr 1 16:12:41 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Thu, 1 Apr 2021 16:12:41 GMT Subject: RFR: 8264218: Public method javax.swing.JMenu.setComponentOrientation() has no spec In-Reply-To: References: <6lhKE_kHeA5SRB92zvKOWsD1flARHhcpcnVJsxLBX3M=.88085c8e-89bc-475c-b18e-23041f5592e7@github.com> <57KgcbXzUmc5FzqD-mvUsyUe662nCpJ70NJ0JUZp4kE=.d193e739-7541-486c-b002-16bdd23fed53@github.com> Message-ID: On Thu, 1 Apr 2021 15:52:49 GMT, Sergey Bylokhov wrote: > The method was overridden to change the implementation without changing of specification. This might have been overlooked. The overridden method changes the behaviour. I'm for documenting the updated behaviour. > This is exactly the case that was changed in the JavaDoc tool in jdk10. For this case, the JavaDoc tool decided to skip spec generation, it is a feature. So this is not a bug in the Swing, probably it is a bug in the JavaDoc tool, maybe not a bug at all. It looks as the intentional change in the javadoc tool. ------------- PR: https://git.openjdk.java.net/jdk/pull/3213 From psadhukhan at openjdk.java.net Thu Apr 1 16:12:42 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Thu, 1 Apr 2021 16:12:42 GMT Subject: RFR: 8264218: Public method javax.swing.JMenu.setComponentOrientation() has no spec [v3] In-Reply-To: <8jVFn8yKKp2MYxELI-hea-_Tsv6UJ3zrn6QRE2YbBns=.5016e20e-eed8-465d-9039-5784ada787fe@github.com> References: <9DD5xnz2i68lQz4ADKDBj-qF1z0v7E3uAqiExKJ6p_M=.4055695c-5e32-4bbc-b301-cf5ba0c2b7b5@github.com> <8jVFn8yKKp2MYxELI-hea-_Tsv6UJ3zrn6QRE2YbBns=.5016e20e-eed8-465d-9039-5784ada787fe@github.com> Message-ID: On Thu, 1 Apr 2021 15:50:28 GMT, Alexey Ivanov wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: >> >> javadoc change > > src/java.desktop/share/classes/javax/swing/JMenu.java line 1260: > >> 1258: /** >> 1259: * Sets the orientation for this menu and the associated popup component >> 1260: * determined by the ComponentOrientation argument. > > Suggestion: > > * determined by the {@code ComponentOrientation} argument. > The new code should use javadoc syntax. I did not change it as then we may need to change `applyComponentOrientation` which uses the same syntax. It will look odd having different syntax in same file. ------------- PR: https://git.openjdk.java.net/jdk/pull/3213 From aivanov at openjdk.java.net Thu Apr 1 16:12:43 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Thu, 1 Apr 2021 16:12:43 GMT Subject: RFR: 8264218: Public method javax.swing.JMenu.setComponentOrientation() has no spec [v4] In-Reply-To: References: Message-ID: <4emEw4AI_7bX2FWZtE5G0ms59PD3RNy4-K0sfgfmkNw=.035b854d-d77c-4f6e-b031-3b48a4cd4ad0@github.com> On Thu, 1 Apr 2021 16:08:48 GMT, Prasanta Sadhukhan wrote: >> A public overriding method JMenu.setComponentOrientation(java.awt.ComponentOrientation) >> has no spec. >> Added spec for the method. > > Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision: > > - javadoc change > - javadoc change src/java.desktop/share/classes/javax/swing/JMenu.java line 1263: > 1261: * > 1262: * @param o the new orientation for this menu and > 1263: * its associated popup menu contained within it. I'd rather remove ?contained within it?. ------------- PR: https://git.openjdk.java.net/jdk/pull/3213 From psadhukhan at openjdk.java.net Thu Apr 1 16:19:48 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Thu, 1 Apr 2021 16:19:48 GMT Subject: RFR: 8264218: Public method javax.swing.JMenu.setComponentOrientation() has no spec [v5] In-Reply-To: References: Message-ID: <22JyhhEtdDzZ3uaobbNwCbA7rrcNYYX2Mb6G_zYBkqM=.451f59da-c2b8-4020-b4a6-ed00605305ce@github.com> > A public overriding method JMenu.setComponentOrientation(java.awt.ComponentOrientation) > has no spec. > Added spec for the method. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: javadoc change ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3213/files - new: https://git.openjdk.java.net/jdk/pull/3213/files/8a4645b2..cb5bac80 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3213&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3213&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3213.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3213/head:pull/3213 PR: https://git.openjdk.java.net/jdk/pull/3213 From aivanov at openjdk.java.net Thu Apr 1 16:19:51 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Thu, 1 Apr 2021 16:19:51 GMT Subject: RFR: 8264218: Public method javax.swing.JMenu.setComponentOrientation() has no spec [v5] In-Reply-To: <22JyhhEtdDzZ3uaobbNwCbA7rrcNYYX2Mb6G_zYBkqM=.451f59da-c2b8-4020-b4a6-ed00605305ce@github.com> References: <22JyhhEtdDzZ3uaobbNwCbA7rrcNYYX2Mb6G_zYBkqM=.451f59da-c2b8-4020-b4a6-ed00605305ce@github.com> Message-ID: On Thu, 1 Apr 2021 16:16:07 GMT, Prasanta Sadhukhan wrote: >> A public overriding method JMenu.setComponentOrientation(java.awt.ComponentOrientation) >> has no spec. >> Added spec for the method. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > javadoc change Marked as reviewed by aivanov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3213 From serb at openjdk.java.net Thu Apr 1 17:03:21 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Thu, 1 Apr 2021 17:03:21 GMT Subject: RFR: 8264218: Public method javax.swing.JMenu.setComponentOrientation() has no spec [v5] In-Reply-To: References: <22JyhhEtdDzZ3uaobbNwCbA7rrcNYYX2Mb6G_zYBkqM=.451f59da-c2b8-4020-b4a6-ed00605305ce@github.com> Message-ID: <5cYHAAOWHyRD7vQ4p1k5o1zhYW32uxsCaVVMjILVFpo=.15bb8636-458b-41ad-bdf6-19d105c6bea1@github.com> On Thu, 1 Apr 2021 16:14:14 GMT, Alexey Ivanov wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: >> >> javadoc change > > Marked as reviewed by aivanov (Reviewer). > This might have been overlooked. The overridden method changes the behaviour. I'm for documenting the updated behaviour. It does not, the spec of the parent is still applicable to this method since the "associated popup menu" is actually a part of the JMenu. And we have other similar methods as well like JTextComponent#setComponentOrientation. Note that even JMenu#applyComponentOrientation says nothing about "associated popup menu" but instead uses "getMenuComponents" - this is why that method is overridden. > It looks as the intentional change in the javadoc tool. It is still under deiscussion in JDK-8264217 ------------- PR: https://git.openjdk.java.net/jdk/pull/3213 From serb at openjdk.java.net Thu Apr 1 17:19:23 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Thu, 1 Apr 2021 17:19:23 GMT Subject: RFR: 8263907: Specification of CellRendererPane::paintComponent(..Rectangle) should clearly mention which method it delegates the call to In-Reply-To: References: Message-ID: <7WGGElNmSFM3KnzrWjW2j3YlcLSmp766DrWhJmod_Pk=.d68fc4af-c256-47cd-8f03-8e87c0d8ed12@github.com> On Tue, 23 Mar 2021 06:10:32 GMT, Prasanta Sadhukhan wrote: > Specification for method > javax/swing/CellRendererPane.html#paintComponent(java.awt.Graphics,java.awt.Component,java.awt.Container,java.awt.Rectangle) > is not perfectly clear which method the call is delegated to. > > Updated spec to clarify. src/java.desktop/share/classes/javax/swing/CellRendererPane.java line 204: > 202: /** > 203: * Calls this.paintComponent(g, c, p, x, y, w, h) with the input parameter > 204: * {@code Rectangle} x,y,width,height fields. Probably the simple "Calls paintComponent(g, c, p, r.x, r.y, r.width, r.height)" will work? ------------- PR: https://git.openjdk.java.net/jdk/pull/3146 From prr at openjdk.java.net Thu Apr 1 23:36:24 2021 From: prr at openjdk.java.net (Phil Race) Date: Thu, 1 Apr 2021 23:36:24 GMT Subject: RFR: 8049700: Deprecate obsolete classes and methods in javax/swing/plaf/basic [v8] In-Reply-To: <2qYuQ3q4_mqTbzdGse7HOVNhEjfHt8JddLX8S9Xx_v4=.569c94da-ab0a-497c-a8ba-2e3d34e192af@github.com> References: <2qYuQ3q4_mqTbzdGse7HOVNhEjfHt8JddLX8S9Xx_v4=.569c94da-ab0a-497c-a8ba-2e3d34e192af@github.com> Message-ID: On Thu, 4 Mar 2021 05:50:18 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. > > 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 Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1958 From prr at openjdk.java.net Thu Apr 1 23:46:29 2021 From: prr at openjdk.java.net (Phil Race) Date: Thu, 1 Apr 2021 23:46:29 GMT Subject: RFR: 8049700: Deprecate obsolete classes and methods in javax/swing/plaf/basic [v8] In-Reply-To: References: <2qYuQ3q4_mqTbzdGse7HOVNhEjfHt8JddLX8S9Xx_v4=.569c94da-ab0a-497c-a8ba-2e3d34e192af@github.com> Message-ID: On Thu, 1 Apr 2021 23:33:28 GMT, Phil Race wrote: >> 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 > > 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. ------------- PR: https://git.openjdk.java.net/jdk/pull/1958 From trebari at openjdk.java.net Fri Apr 2 05:04:27 2021 From: trebari at openjdk.java.net (Tejpal Rebari) Date: Fri, 2 Apr 2021 05:04:27 GMT Subject: RFR: 8253266 : JList and JTable constructors should clear OPAQUE_SET before calling updateUI [v2] In-Reply-To: References: <0xQaEjHSESc7X1yaj1XWaOXBSyQDQgD1Jd6bkJbBGGw=.30558ebd-a585-4204-a501-b23d41249573@github.com> Message-ID: 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 From trebari at openjdk.java.net Fri Apr 2 05:37:30 2021 From: trebari at openjdk.java.net (Tejpal Rebari) Date: Fri, 2 Apr 2021 05:37:30 GMT Subject: RFR: 8049700: Deprecate obsolete classes and methods in javax/swing/plaf/basic [v8] In-Reply-To: References: <2qYuQ3q4_mqTbzdGse7HOVNhEjfHt8JddLX8S9Xx_v4=.569c94da-ab0a-497c-a8ba-2e3d34e192af@github.com> Message-ID: 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 From serb at openjdk.java.net Fri Apr 2 06:14:29 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Fri, 2 Apr 2021 06:14:29 GMT Subject: RFR: 8264526: javax/swing/text/html/parser/Parser/8078268/bug8078268.java timeout In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 16:23:23 GMT, Jie Fu wrote: > Hi all, > > I'd like to fix the timeout of javax/swing/text/html/parser/Parser/8078268/bug8078268.java. > It seems to take about 6~7 seconds to run on some of our testing platforms. > But the timeout of the test is hard-coded as 5 seconds. > > The fix just increases the timeout from 5 seconds to 10 seconds. > > Thanks. > Best regards, > Jie Marked as reviewed by serb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3287 From jiefu at openjdk.java.net Fri Apr 2 06:17:19 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Fri, 2 Apr 2021 06:17:19 GMT Subject: RFR: 8264526: javax/swing/text/html/parser/Parser/8078268/bug8078268.java timeout In-Reply-To: References: Message-ID: <7a6FiNehVFt9bRXUKy9rvB8ZlvdO0ojfxLpc3ft99vs=.d4dc3e78-0f84-470a-9d6f-0e7114b65ef3@github.com> On Fri, 2 Apr 2021 06:11:00 GMT, Sergey Bylokhov wrote: >> Hi all, >> >> I'd like to fix the timeout of javax/swing/text/html/parser/Parser/8078268/bug8078268.java. >> It seems to take about 6~7 seconds to run on some of our testing platforms. >> But the timeout of the test is hard-coded as 5 seconds. >> >> The fix just increases the timeout from 5 seconds to 10 seconds. >> >> Thanks. >> Best regards, >> Jie > > Marked as reviewed by serb (Reviewer). Thanks @mrserb for your review. ------------- PR: https://git.openjdk.java.net/jdk/pull/3287 From jiefu at openjdk.java.net Fri Apr 2 08:28:40 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Fri, 2 Apr 2021 08:28:40 GMT Subject: Integrated: 8264526: javax/swing/text/html/parser/Parser/8078268/bug8078268.java timeout In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 16:23:23 GMT, Jie Fu wrote: > Hi all, > > I'd like to fix the timeout of javax/swing/text/html/parser/Parser/8078268/bug8078268.java. > It seems to take about 6~7 seconds to run on some of our testing platforms. > But the timeout of the test is hard-coded as 5 seconds. > > The fix just increases the timeout from 5 seconds to 10 seconds. > > Thanks. > Best regards, > Jie This pull request has now been integrated. Changeset: da643cdb Author: Jie Fu URL: https://git.openjdk.java.net/jdk/commit/da643cdb Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod 8264526: javax/swing/text/html/parser/Parser/8078268/bug8078268.java timeout Reviewed-by: serb ------------- PR: https://git.openjdk.java.net/jdk/pull/3287 From dcubed at openjdk.java.net Fri Apr 2 18:50:39 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 2 Apr 2021 18:50:39 GMT Subject: RFR: 8264658: ProblemList javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java on linux-x64 Message-ID: A trivial fix to ProblemList javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java on linux-x64 ------------- Depends on: https://git.openjdk.java.net/jdk/pull/3329 Commit messages: - 8264658: ProblemList javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java on linux-x64 Changes: https://git.openjdk.java.net/jdk/pull/3330/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3330&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264658 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3330.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3330/head:pull/3330 PR: https://git.openjdk.java.net/jdk/pull/3330 From dcubed at openjdk.java.net Fri Apr 2 18:55:57 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 2 Apr 2021 18:55:57 GMT Subject: RFR: 8264658: ProblemList javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java on linux-x64 [v2] In-Reply-To: References: Message-ID: > A trivial fix to ProblemList javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java on linux-x64 Daniel D. Daugherty 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. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3330/files - new: https://git.openjdk.java.net/jdk/pull/3330/files/08d28602..08d28602 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3330&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3330&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3330.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3330/head:pull/3330 PR: https://git.openjdk.java.net/jdk/pull/3330 From dcubed at openjdk.java.net Fri Apr 2 19:03:43 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 2 Apr 2021 19:03:43 GMT Subject: RFR: 8264658: ProblemList javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java on linux-x64 [v3] In-Reply-To: References: Message-ID: > A trivial fix to ProblemList javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java on linux-x64 Daniel D. Daugherty 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 branch 'master' into JDK-8264658 - 8264658: ProblemList javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java on linux-x64 - 8264657: ProblemList java/awt/Focus/FrameMinimizeTest/FrameMinimizeTest.java on linux-x64 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3330/files - new: https://git.openjdk.java.net/jdk/pull/3330/files/08d28602..36454a93 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3330&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3330&range=01-02 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3330.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3330/head:pull/3330 PR: https://git.openjdk.java.net/jdk/pull/3330 From pbansal at openjdk.java.net Fri Apr 2 19:11:22 2021 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Fri, 2 Apr 2021 19:11:22 GMT Subject: RFR: 8264658: ProblemList javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java on linux-x64 [v3] In-Reply-To: References: Message-ID: <-PMGRTMYPqahkJ8FXjDdwZwyjy261iNv2zjj5gWim4s=.6092a50e-47d9-41f0-af11-ddc3957c13f4@github.com> On Fri, 2 Apr 2021 19:03:43 GMT, Daniel D. Daugherty wrote: >> A trivial fix to ProblemList javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java on linux-x64 > > Daniel D. Daugherty 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 branch 'master' into JDK-8264658 > - 8264658: ProblemList javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java on linux-x64 > - 8264657: ProblemList java/awt/Focus/FrameMinimizeTest/FrameMinimizeTest.java on linux-x64 Marked as reviewed by pbansal (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3330 From dcubed at openjdk.java.net Fri Apr 2 19:19:34 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 2 Apr 2021 19:19:34 GMT Subject: RFR: 8264658: ProblemList javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java on linux-x64 [v3] In-Reply-To: <-PMGRTMYPqahkJ8FXjDdwZwyjy261iNv2zjj5gWim4s=.6092a50e-47d9-41f0-af11-ddc3957c13f4@github.com> References: <-PMGRTMYPqahkJ8FXjDdwZwyjy261iNv2zjj5gWim4s=.6092a50e-47d9-41f0-af11-ddc3957c13f4@github.com> Message-ID: On Fri, 2 Apr 2021 19:07:57 GMT, Pankaj Bansal wrote: >> Daniel D. Daugherty 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 branch 'master' into JDK-8264658 >> - 8264658: ProblemList javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java on linux-x64 >> - 8264657: ProblemList java/awt/Focus/FrameMinimizeTest/FrameMinimizeTest.java on linux-x64 > > Marked as reviewed by pbansal (Reviewer). @pankaj-bansal - Thanks for the fast review. ------------- PR: https://git.openjdk.java.net/jdk/pull/3330 From dcubed at openjdk.java.net Fri Apr 2 19:19:35 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 2 Apr 2021 19:19:35 GMT Subject: Integrated: 8264658: ProblemList javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java on linux-x64 In-Reply-To: References: Message-ID: On Fri, 2 Apr 2021 18:42:26 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java on linux-x64 This pull request has now been integrated. Changeset: 4133dede Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/4133dede Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8264658: ProblemList javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java on linux-x64 Reviewed-by: pbansal ------------- PR: https://git.openjdk.java.net/jdk/pull/3330 From serb at openjdk.java.net Fri Apr 2 21:22:30 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Fri, 2 Apr 2021 21:22:30 GMT Subject: RFR: 8253266 : JList and JTable constructors should clear OPAQUE_SET before calling updateUI [v3] In-Reply-To: References: <0xQaEjHSESc7X1yaj1XWaOXBSyQDQgD1Jd6bkJbBGGw=.30558ebd-a585-4204-a501-b23d41249573@github.com> Message-ID: On Thu, 1 Apr 2021 14:37:48 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. > > 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 Marked as reviewed by serb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3167 From aivanov at openjdk.java.net Fri Apr 2 21:27:28 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Fri, 2 Apr 2021 21:27:28 GMT Subject: RFR: 8182043: Access to Windows Large Icons In-Reply-To: References: Message-ID: On Mon, 8 Mar 2021 13:22:07 GMT, Alexander Zuev wrote: > Fix updated after first round of review. src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java line 260: > 258: > 259: /** > 260: * Icon for a file, directory, or folder as it would be displayed in *Returns an icon* for a file? src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java line 276: > 274: * > 275: * @param f a File object > 276: * @param size width and height of the icon in pixels Pixels could be ambiguous now. Usually, Swing deals with user's space. That is 16?16 icon should actually be 32?32 if the scale factor of the current display is 200%. Yes, this issue is somewhat irrelevant because the method returns multi-resolution icon. However, the terminology used must be unambiguous and clear; for consistency with other Swing API, it should be in terms of user's space coordinates, *virtual pixels*. ------------- PR: https://git.openjdk.java.net/jdk/pull/2875 From serb at openjdk.java.net Fri Apr 2 22:38:38 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Fri, 2 Apr 2021 22:38:38 GMT Subject: RFR: 8049700: Deprecate obsolete classes and methods in javax/swing/plaf/basic [v8] In-Reply-To: <2qYuQ3q4_mqTbzdGse7HOVNhEjfHt8JddLX8S9Xx_v4=.569c94da-ab0a-497c-a8ba-2e3d34e192af@github.com> References: <2qYuQ3q4_mqTbzdGse7HOVNhEjfHt8JddLX8S9Xx_v4=.569c94da-ab0a-497c-a8ba-2e3d34e192af@github.com> Message-ID: On Thu, 4 Mar 2021 05:50:18 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. > > 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 Marked as reviewed by serb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1958 From serb at openjdk.java.net Fri Apr 2 22:38:43 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Fri, 2 Apr 2021 22:38:43 GMT Subject: RFR: 8049700: Deprecate obsolete classes and methods in javax/swing/plaf/basic [v8] In-Reply-To: References: <2qYuQ3q4_mqTbzdGse7HOVNhEjfHt8JddLX8S9Xx_v4=.569c94da-ab0a-497c-a8ba-2e3d34e192af@github.com> Message-ID: On Fri, 2 Apr 2021 22:34:59 GMT, Sergey Bylokhov wrote: >> 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 > > Marked as reviewed by serb (Reviewer). I think we can file a separate bug to add "for removal" in JDK 19 and then remove them somewhere after JDK 22. ------------- PR: https://git.openjdk.java.net/jdk/pull/1958 From github.com+76791+alblue at openjdk.java.net Sat Apr 3 22:11:53 2021 From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt) Date: Sat, 3 Apr 2021 22:11:53 GMT Subject: RFR: 8264680: Use the blessed modifier order in java.desktop Message-ID: 8264680: Use the blessed modifier order in java.desktop ------------- Commit messages: - 8264680: Use the blessed modifier order in java.desktop Changes: https://git.openjdk.java.net/jdk/pull/3337/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3337&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264680 Stats: 14 lines in 11 files changed: 0 ins; 1 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/3337.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3337/head:pull/3337 PR: https://git.openjdk.java.net/jdk/pull/3337 From github.com+76791+alblue at openjdk.java.net Sat Apr 3 22:28:54 2021 From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt) Date: Sat, 3 Apr 2021 22:28:54 GMT Subject: RFR: 8264680: Use the blessed modifier order in java.desktop [v2] In-Reply-To: References: Message-ID: <7tWzZRpM_-C5E35SuC4CkciMAmF7oLYeoXrXLEB0XEo=.138dfad3-dc19-4283-9804-0365c9dddba3@github.com> > 8264680: Use the blessed modifier order in java.desktop Alex Blewitt has updated the pull request incrementally with one additional commit since the last revision: Additionally remove detritus from PNGImageDecoder.java ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3337/files - new: https://git.openjdk.java.net/jdk/pull/3337/files/1fb0fe1b..7bb8d9dd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3337&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3337&range=00-01 Stats: 120 lines in 1 file changed: 0 ins; 113 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/3337.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3337/head:pull/3337 PR: https://git.openjdk.java.net/jdk/pull/3337 From serb at openjdk.java.net Sun Apr 4 08:01:31 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Sun, 4 Apr 2021 08:01:31 GMT Subject: RFR: 8264680: Use the blessed modifier order in java.desktop [v2] In-Reply-To: <7tWzZRpM_-C5E35SuC4CkciMAmF7oLYeoXrXLEB0XEo=.138dfad3-dc19-4283-9804-0365c9dddba3@github.com> References: <7tWzZRpM_-C5E35SuC4CkciMAmF7oLYeoXrXLEB0XEo=.138dfad3-dc19-4283-9804-0365c9dddba3@github.com> Message-ID: <-SCBgCyxuS50ZA6JNjGNqPNTf1Xpfe7cA1f7ui_vrJI=.8fe36cc5-7f24-4198-9723-f05021b73617@github.com> On Sat, 3 Apr 2021 22:28:54 GMT, Alex Blewitt wrote: >> 8264680: Use the blessed modifier order in java.desktop > > Alex Blewitt has updated the pull request incrementally with one additional commit since the last revision: > > Additionally remove detritus from PNGImageDecoder.java Marked as reviewed by serb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3337 From kizune at openjdk.java.net Sun Apr 4 08:12:07 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Sun, 4 Apr 2021 08:12:07 GMT Subject: RFR: 8264680: Use the blessed modifier order in java.desktop [v2] In-Reply-To: <7tWzZRpM_-C5E35SuC4CkciMAmF7oLYeoXrXLEB0XEo=.138dfad3-dc19-4283-9804-0365c9dddba3@github.com> References: <7tWzZRpM_-C5E35SuC4CkciMAmF7oLYeoXrXLEB0XEo=.138dfad3-dc19-4283-9804-0365c9dddba3@github.com> Message-ID: On Sat, 3 Apr 2021 22:28:54 GMT, Alex Blewitt wrote: >> 8264680: Use the blessed modifier order in java.desktop > > Alex Blewitt has updated the pull request incrementally with one additional commit since the last revision: > > Additionally remove detritus from PNGImageDecoder.java Marked as reviewed by kizune (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3337 From psadhukhan at openjdk.java.net Mon Apr 5 05:07:04 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Mon, 5 Apr 2021 05:07:04 GMT Subject: RFR: 8263907: Specification of CellRendererPane::paintComponent(..Rectangle) should clearly mention which method it delegates the call to In-Reply-To: <7WGGElNmSFM3KnzrWjW2j3YlcLSmp766DrWhJmod_Pk=.d68fc4af-c256-47cd-8f03-8e87c0d8ed12@github.com> References: <7WGGElNmSFM3KnzrWjW2j3YlcLSmp766DrWhJmod_Pk=.d68fc4af-c256-47cd-8f03-8e87c0d8ed12@github.com> Message-ID: On Thu, 1 Apr 2021 17:16:45 GMT, Sergey Bylokhov wrote: >> Specification for method >> javax/swing/CellRendererPane.html#paintComponent(java.awt.Graphics,java.awt.Component,java.awt.Container,java.awt.Rectangle) >> is not perfectly clear which method the call is delegated to. >> >> Updated spec to clarify. > > src/java.desktop/share/classes/javax/swing/CellRendererPane.java line 204: > >> 202: /** >> 203: * Calls this.paintComponent(g, c, p, x, y, w, h) with the input parameter >> 204: * {@code Rectangle} x,y,width,height fields. > > Probably the simple "Calls paintComponent(g, c, p, r.x, r.y, r.width, r.height)" will work? Then the question might arise what is r.x, r.y....I guess my wordings makes it more clearer with pointer to input paramter. ------------- PR: https://git.openjdk.java.net/jdk/pull/3146 From psadhukhan at openjdk.java.net Mon Apr 5 05:25:58 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Mon, 5 Apr 2021 05:25:58 GMT Subject: RFR: 8253266 : JList and JTable constructors should clear OPAQUE_SET before calling updateUI [v3] In-Reply-To: References: <0xQaEjHSESc7X1yaj1XWaOXBSyQDQgD1Jd6bkJbBGGw=.30558ebd-a585-4204-a501-b23d41249573@github.com> Message-ID: On Thu, 1 Apr 2021 14:37:48 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. > > 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? test/jdk/javax/swing/JList/TestOpaqueListTable.java line 24: > 22: */ > 23: > 24: import javax.swing.*; Can you please update this wildcard imports? 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? ------------- PR: https://git.openjdk.java.net/jdk/pull/3167 From trebari at openjdk.java.net Mon Apr 5 05:43:45 2021 From: trebari at openjdk.java.net (Tejpal Rebari) Date: Mon, 5 Apr 2021 05:43:45 GMT Subject: RFR: 8253266 : JList and JTable constructors should clear OPAQUE_SET before calling updateUI [v3] In-Reply-To: References: <0xQaEjHSESc7X1yaj1XWaOXBSyQDQgD1Jd6bkJbBGGw=.30558ebd-a585-4204-a501-b23d41249573@github.com> Message-ID: 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 From trebari at openjdk.java.net Mon Apr 5 05:51:17 2021 From: trebari at openjdk.java.net (Tejpal Rebari) Date: Mon, 5 Apr 2021 05:51:17 GMT Subject: RFR: 8253266 : JList and JTable constructors should clear OPAQUE_SET before calling updateUI [v4] In-Reply-To: <0xQaEjHSESc7X1yaj1XWaOXBSyQDQgD1Jd6bkJbBGGw=.30558ebd-a585-4204-a501-b23d41249573@github.com> References: <0xQaEjHSESc7X1yaj1XWaOXBSyQDQgD1Jd6bkJbBGGw=.30558ebd-a585-4204-a501-b23d41249573@github.com> Message-ID: > 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&pr=3167&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3167&range=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 From trebari at openjdk.java.net Mon Apr 5 05:51:18 2021 From: trebari at openjdk.java.net (Tejpal Rebari) Date: Mon, 5 Apr 2021 05:51:18 GMT Subject: RFR: 8253266 : JList and JTable constructors should clear OPAQUE_SET before calling updateUI [v3] In-Reply-To: References: <0xQaEjHSESc7X1yaj1XWaOXBSyQDQgD1Jd6bkJbBGGw=.30558ebd-a585-4204-a501-b23d41249573@github.com> Message-ID: 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 From trebari at openjdk.java.net Mon Apr 5 06:52:30 2021 From: trebari at openjdk.java.net (Tejpal Rebari) Date: Mon, 5 Apr 2021 06:52:30 GMT Subject: RFR: 8253266 : JList and JTable constructors should clear OPAQUE_SET before calling updateUI [v3] In-Reply-To: References: <0xQaEjHSESc7X1yaj1XWaOXBSyQDQgD1Jd6bkJbBGGw=.30558ebd-a585-4204-a501-b23d41249573@github.com> Message-ID: 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 From psadhukhan at openjdk.java.net Mon Apr 5 07:11:29 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Mon, 5 Apr 2021 07:11:29 GMT Subject: RFR: 8253266 : JList and JTable constructors should clear OPAQUE_SET before calling updateUI [v3] In-Reply-To: References: <0xQaEjHSESc7X1yaj1XWaOXBSyQDQgD1Jd6bkJbBGGw=.30558ebd-a585-4204-a501-b23d41249573@github.com> Message-ID: On Mon, 5 Apr 2021 06:34:17 GMT, Tejpal Rebari wrote: >> 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. 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); } ------------- PR: https://git.openjdk.java.net/jdk/pull/3167 From trebari at openjdk.java.net Mon Apr 5 07:36:35 2021 From: trebari at openjdk.java.net (Tejpal Rebari) Date: Mon, 5 Apr 2021 07:36:35 GMT Subject: RFR: 8253266 : JList and JTable constructors should clear OPAQUE_SET before calling updateUI [v3] In-Reply-To: References: <0xQaEjHSESc7X1yaj1XWaOXBSyQDQgD1Jd6bkJbBGGw=.30558ebd-a585-4204-a501-b23d41249573@github.com> Message-ID: 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 From trebari at openjdk.java.net Mon Apr 5 07:39:45 2021 From: trebari at openjdk.java.net (Tejpal Rebari) Date: Mon, 5 Apr 2021 07:39:45 GMT Subject: RFR: 8253266 : JList and JTable constructors should clear OPAQUE_SET before calling updateUI [v5] In-Reply-To: <0xQaEjHSESc7X1yaj1XWaOXBSyQDQgD1Jd6bkJbBGGw=.30558ebd-a585-4204-a501-b23d41249573@github.com> References: <0xQaEjHSESc7X1yaj1XWaOXBSyQDQgD1Jd6bkJbBGGw=.30558ebd-a585-4204-a501-b23d41249573@github.com> Message-ID: > 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&pr=3167&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3167&range=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 From psadhukhan at openjdk.java.net Mon Apr 5 07:48:43 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Mon, 5 Apr 2021 07:48:43 GMT Subject: RFR: 8253266 : JList and JTable constructors should clear OPAQUE_SET before calling updateUI [v3] In-Reply-To: References: <0xQaEjHSESc7X1yaj1XWaOXBSyQDQgD1Jd6bkJbBGGw=.30558ebd-a585-4204-a501-b23d41249573@github.com> Message-ID: <2xvFoK4MDm8aTCgJItVNSjaquHUwsu3wlaQl9BvYzZ4=.eed6c4de-4fa8-49fe-bc7c-c121febe9ef8@github.com> On Thu, 1 Apr 2021 14:37:48 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. > > 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? ------------- PR: https://git.openjdk.java.net/jdk/pull/3167 From serb at openjdk.java.net Mon Apr 5 07:53:30 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Mon, 5 Apr 2021 07:53:30 GMT Subject: RFR: 8253266 : JList and JTable constructors should clear OPAQUE_SET before calling updateUI [v3] In-Reply-To: References: <0xQaEjHSESc7X1yaj1XWaOXBSyQDQgD1Jd6bkJbBGGw=.30558ebd-a585-4204-a501-b23d41249573@github.com> Message-ID: On Mon, 5 Apr 2021 07:33:16 GMT, Tejpal Rebari wrote: >> 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() What is the difference from setting it via "skin.laf"? The "skin.laf" is converted to the NimbusDefaults during the build and these defaults are used by the NimbusLookAndFeel. ------------- PR: https://git.openjdk.java.net/jdk/pull/3167 From psadhukhan at openjdk.java.net Mon Apr 5 07:58:46 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Mon, 5 Apr 2021 07:58:46 GMT Subject: RFR: 8253266 : JList and JTable constructors should clear OPAQUE_SET before calling updateUI [v3] In-Reply-To: References: <0xQaEjHSESc7X1yaj1XWaOXBSyQDQgD1Jd6bkJbBGGw=.30558ebd-a585-4204-a501-b23d41249573@github.com> Message-ID: On Mon, 5 Apr 2021 07:50:25 GMT, Sergey Bylokhov wrote: >> yeah setting the property after updateStyle(c) works fine. >> updating the change in the SynthToolTipUI.installDefaults() > > What is the difference from setting it via "skin.laf"? The "skin.laf" is converted to the NimbusDefaults during the build and these defaults are used by the NimbusLookAndFeel. I personally feel setting in code will be easier to maintain going forward than to go through property file settings. ------------- PR: https://git.openjdk.java.net/jdk/pull/3167 From trebari at openjdk.java.net Mon Apr 5 08:22:44 2021 From: trebari at openjdk.java.net (Tejpal Rebari) Date: Mon, 5 Apr 2021 08:22:44 GMT Subject: RFR: 8253266 : JList and JTable constructors should clear OPAQUE_SET before calling updateUI [v3] In-Reply-To: <2xvFoK4MDm8aTCgJItVNSjaquHUwsu3wlaQl9BvYzZ4=.eed6c4de-4fa8-49fe-bc7c-c121febe9ef8@github.com> References: <0xQaEjHSESc7X1yaj1XWaOXBSyQDQgD1Jd6bkJbBGGw=.30558ebd-a585-4204-a501-b23d41249573@github.com> <2xvFoK4MDm8aTCgJItVNSjaquHUwsu3wlaQl9BvYzZ4=.eed6c4de-4fa8-49fe-bc7c-c121febe9ef8@github.com> Message-ID: 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 From trebari at openjdk.java.net Mon Apr 5 08:47:15 2021 From: trebari at openjdk.java.net (Tejpal Rebari) Date: Mon, 5 Apr 2021 08:47:15 GMT Subject: RFR: 8253266 : JList and JTable constructors should clear OPAQUE_SET before calling updateUI [v6] In-Reply-To: <0xQaEjHSESc7X1yaj1XWaOXBSyQDQgD1Jd6bkJbBGGw=.30558ebd-a585-4204-a501-b23d41249573@github.com> References: <0xQaEjHSESc7X1yaj1XWaOXBSyQDQgD1Jd6bkJbBGGw=.30558ebd-a585-4204-a501-b23d41249573@github.com> Message-ID: > 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&pr=3167&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3167&range=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 From psadhukhan at openjdk.java.net Mon Apr 5 08:47:16 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Mon, 5 Apr 2021 08:47:16 GMT Subject: RFR: 8253266 : JList and JTable constructors should clear OPAQUE_SET before calling updateUI [v6] In-Reply-To: References: <0xQaEjHSESc7X1yaj1XWaOXBSyQDQgD1Jd6bkJbBGGw=.30558ebd-a585-4204-a501-b23d41249573@github.com> Message-ID: <-IbIyTJdyaQ8Pccwx-9zUqgHgy6pIHdzddfFyNi0wFU=.d70d7664-18c6-475f-bedc-abd965d37a36@github.com> On Mon, 5 Apr 2021 08:44:37 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. > > Tejpal Rebari has updated the pull request incrementally with one additional commit since the last revision: > > set skin.laf as before Marked as reviewed by psadhukhan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3167 From trebari at openjdk.java.net Mon Apr 5 08:47:16 2021 From: trebari at openjdk.java.net (Tejpal Rebari) Date: Mon, 5 Apr 2021 08:47:16 GMT Subject: RFR: 8253266 : JList and JTable constructors should clear OPAQUE_SET before calling updateUI [v3] In-Reply-To: References: <0xQaEjHSESc7X1yaj1XWaOXBSyQDQgD1Jd6bkJbBGGw=.30558ebd-a585-4204-a501-b23d41249573@github.com> <2xvFoK4MDm8aTCgJItVNSjaquHUwsu3wlaQl9BvYzZ4=.eed6c4de-4fa8-49fe-bc7c-c121febe9ef8@github.com> Message-ID: 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 From psadhukhan at openjdk.java.net Mon Apr 5 11:10:13 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Mon, 5 Apr 2021 11:10:13 GMT Subject: =?utf-8?q?RFR=3A_8264398=3A_BevelBorderUIResource?= =?utf-8?q?=E2=80=8B=28int=2C_Color=2C_Color=29_spec_should_mention_that_t?= =?utf-8?q?he_passed_colors_are_for_highlightInner_and_shadowOuter_props_?= =?utf-8?q?=5Bv2=5D?= In-Reply-To: References: Message-ID: > The current spec for javax/swing/plaf/BorderUIResource.BevelBorderUIResource.html(int,java.awt.Color,java.awt.Color) does not clearly specify the usage of color for hightlight and shadow as there are outer/inner hightlight and outer/inner shadow. > Updated spec to clarify the same. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Fix javadoc ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3305/files - new: https://git.openjdk.java.net/jdk/pull/3305/files/ea847758..cb0b25c3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3305&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3305&range=00-01 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/3305.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3305/head:pull/3305 PR: https://git.openjdk.java.net/jdk/pull/3305 From dbessono at openjdk.java.net Mon Apr 5 11:26:47 2021 From: dbessono at openjdk.java.net (Dmitry Bessonov) Date: Mon, 5 Apr 2021 11:26:47 GMT Subject: =?utf-8?q?RFR=3A_8264398=3A_BevelBorderUIResource?= =?utf-8?q?=E2=80=8B=28int=2C_Color=2C_Color=29_spec_should_mention_that_t?= =?utf-8?q?he_passed_colors_are_for_highlightInner_and_shadowOuter_props?= In-Reply-To: References: Message-ID: On Thu, 1 Apr 2021 12:20:54 GMT, Prasanta Sadhukhan wrote: > The current spec for javax/swing/plaf/BorderUIResource.BevelBorderUIResource.html(int,java.awt.Color,java.awt.Color) does not clearly specify the usage of color for hightlight and shadow as there are outer/inner hightlight and outer/inner shadow. > Updated spec to clarify the same. Is there a normative definition somewhere in the spec of what "derived color" is for this domain? ------------- PR: https://git.openjdk.java.net/jdk/pull/3305 From psadhukhan at openjdk.java.net Mon Apr 5 11:26:48 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Mon, 5 Apr 2021 11:26:48 GMT Subject: =?utf-8?q?RFR=3A_8264398=3A_BevelBorderUIResource?= =?utf-8?q?=E2=80=8B=28int=2C_Color=2C_Color=29_spec_should_mention_that_t?= =?utf-8?q?he_passed_colors_are_for_highlightInner_and_shadowOuter_props?= In-Reply-To: References: Message-ID: On Mon, 5 Apr 2021 11:10:40 GMT, Dmitry Bessonov wrote: >> The current spec for javax/swing/plaf/BorderUIResource.BevelBorderUIResource.html(int,java.awt.Color,java.awt.Color) does not clearly specify the usage of color for hightlight and shadow as there are outer/inner hightlight and outer/inner shadow. >> Updated spec to clarify the same. > > Is there a normative definition somewhere in the spec of what "derived color" is for this domain? As per https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/border/BevelBorder.java#L151 and https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/border/BevelBorder.java#L183 `derived ` is used to obtain the darker or brighter version of the same color, which is being done here for this highlight and shadow color too. ------------- PR: https://git.openjdk.java.net/jdk/pull/3305 From trebari at openjdk.java.net Mon Apr 5 14:21:54 2021 From: trebari at openjdk.java.net (Tejpal Rebari) Date: Mon, 5 Apr 2021 14:21:54 GMT Subject: Integrated: 8253266 : JList and JTable constructors should clear OPAQUE_SET before calling updateUI In-Reply-To: <0xQaEjHSESc7X1yaj1XWaOXBSyQDQgD1Jd6bkJbBGGw=.30558ebd-a585-4204-a501-b23d41249573@github.com> References: <0xQaEjHSESc7X1yaj1XWaOXBSyQDQgD1Jd6bkJbBGGw=.30558ebd-a585-4204-a501-b23d41249573@github.com> Message-ID: <1SqCa7bB1FD83Q8rgiGlaDSRFmHUWbBOVoOG7cDM8jM=.3edea5c6-8e62-46a1-a893-fb29d9d6f973@github.com> 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 From serb at openjdk.java.net Mon Apr 5 17:48:17 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Mon, 5 Apr 2021 17:48:17 GMT Subject: RFR: 8253266 : JList and JTable constructors should clear OPAQUE_SET before calling updateUI [v3] In-Reply-To: References: <0xQaEjHSESc7X1yaj1XWaOXBSyQDQgD1Jd6bkJbBGGw=.30558ebd-a585-4204-a501-b23d41249573@github.com> Message-ID: On Mon, 5 Apr 2021 07:55:11 GMT, Prasanta Sadhukhan wrote: >> What is the difference from setting it via "skin.laf"? The "skin.laf" is converted to the NimbusDefaults during the build and these defaults are used by the NimbusLookAndFeel. > > I personally feel setting in code will be easier to maintain going forward than to go through property file settings. Then why we need this file at all? Now we will set the false value in the config, and true at runtime, what is the profit? ------------- PR: https://git.openjdk.java.net/jdk/pull/3167 From pbansal at openjdk.java.net Mon Apr 5 18:50:25 2021 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Mon, 5 Apr 2021 18:50:25 GMT Subject: RFR: 8262981: Create implementation for NSAccessibilitySlider protocol In-Reply-To: References: <3kHCT6j_xnm9mbA2jeP35p9rY4nxOD61PInSB9mglT8=.71c3b9df-0cc3-40f7-b339-15b382e36b6f@github.com> <4SZRIR695DBooSWt-1aatGx-CKPy6EwuRpXS29A8wro=.4ba37fe2-6017-482f-83c4-33d7a11fc320@github.com> <60QaQ3ISOvoR5RMWU1hTSCsiBHfy7xU2QjvLzrGaSvA=.c02ab62e-5176-4015-a16c-849a71088452@github.com> Message-ID: <3CKaFVyC5vtiHzByCzX4XXPMk798bLVvO00p1t8Pl4g=.9426b24b-1725-40dc-8957-dd13f26701c8@github.com> On Wed, 31 Mar 2021 19:56:24 GMT, Sergey Bylokhov wrote: >>> > It looks like the Dialog must have handled the keys as there are no special keys mentioned for JAWS to interact with the component like the VO >>> >>> Did you check this list of hotkeys? >>> https://www.freedomscientific.com/training/jaws/hotkeys >>> https://freedomscientific.github.io/VFO-standards-support/aria.html >>> Something like: >>> RIGHT ARROW and UP ARROW increase the value of the slider. >>> LEFT ARROW and DOWN ARROW decrease the value of the slider. >>> HOME and END move to the minimum and maximum values of the slider. >>> PAGE UP and PAGE DOWN increment or decrement the slider by a given amount. >>> >>> ======================= >>> My main point is that if we will change some shared code we should care about both supported platforms. >> >> I tried the hot keys with the both native dialog ("Display Settings" with a "Brightness" Slider ) and java applications. >> Both Java and native dialog are themselves handling the RIGHT ARROW, UP ARROW, LEFT ARROW, DOWN ARROW, HOME and END buttons for JSlider and user can change slider value using these keys without JAWS also. but they are not handling the PAGE UP and PAGE DOWN button. >> PAGE UP and PAGE DOWN button don't work with JAWS either, meaning JAWS is not able to handle the keys and is not able to change component values for both native dialogs and Java application. Also, I am not able to find any component in Swing, where JAWS can change the component values using any hot key. Please correct me if I am wrong in this and JAWS can actually manipulate some component. Also, in the old implementation for MacOS , the VO can not change the Spinner/Slider values and we are adding this functionality now only. >> In addition to this, the functionality we are adding in slider can be used with JAWS also if we decide to provide the support for the same later. Currently, I do not see JAWS being able to change any component value in swing, so it will not be able to change Slider value too. > > Ok, please file a similar bug for the windows platform. @mrserb @azuev-java Any other comments on this? Can you please look at the CSR also? ------------- PR: https://git.openjdk.java.net/jdk/pull/2874 From trebari at openjdk.java.net Tue Apr 6 04:47:18 2021 From: trebari at openjdk.java.net (Tejpal Rebari) Date: Tue, 6 Apr 2021 04:47:18 GMT Subject: RFR: 8049700: Deprecate obsolete classes and methods in javax/swing/plaf/basic [v8] In-Reply-To: References: <2qYuQ3q4_mqTbzdGse7HOVNhEjfHt8JddLX8S9Xx_v4=.569c94da-ab0a-497c-a8ba-2e3d34e192af@github.com> Message-ID: 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 From psadhukhan at openjdk.java.net Tue Apr 6 11:15:21 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Tue, 6 Apr 2021 11:15:21 GMT Subject: =?utf-8?q?RFR=3A_8264398=3A_BevelBorderUIResource?= =?utf-8?q?=E2=80=8B=28int=2C_Color=2C_Color=29_spec_should_mention_that_t?= =?utf-8?q?he_passed_colors_are_for_highlightInner_and_shadowOuter_props?= In-Reply-To: References: Message-ID: On Mon, 5 Apr 2021 11:23:36 GMT, Prasanta Sadhukhan wrote: >> Is there a normative definition somewhere in the spec of what "derived color" is for this domain? > > As per https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/border/BevelBorder.java#L151 > and https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/border/BevelBorder.java#L183 > `derived ` is used to obtain the darker or brighter version of the same color, which is being done here for this highlight and shadow color too. any comments on the spec wording? ------------- PR: https://git.openjdk.java.net/jdk/pull/3305 From psadhukhan at openjdk.java.net Tue Apr 6 11:15:26 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Tue, 6 Apr 2021 11:15:26 GMT Subject: RFR: 8263907: Specification of CellRendererPane::paintComponent(..Rectangle) should clearly mention which method it delegates the call to In-Reply-To: References: <7WGGElNmSFM3KnzrWjW2j3YlcLSmp766DrWhJmod_Pk=.d68fc4af-c256-47cd-8f03-8e87c0d8ed12@github.com> Message-ID: On Mon, 5 Apr 2021 05:03:38 GMT, Prasanta Sadhukhan wrote: >> src/java.desktop/share/classes/javax/swing/CellRendererPane.java line 204: >> >>> 202: /** >>> 203: * Calls this.paintComponent(g, c, p, x, y, w, h) with the input parameter >>> 204: * {@code Rectangle} x,y,width,height fields. >> >> Probably the simple "Calls paintComponent(g, c, p, r.x, r.y, r.width, r.height)" will work? > > Then the question might arise what is r.x, r.y....I guess my wordings makes it more clearer with pointer to input paramter. Can this please be approved if there's no more comments? ------------- PR: https://git.openjdk.java.net/jdk/pull/3146 From dbessono at openjdk.java.net Tue Apr 6 12:18:25 2021 From: dbessono at openjdk.java.net (Dmitry Bessonov) Date: Tue, 6 Apr 2021 12:18:25 GMT Subject: =?utf-8?q?RFR=3A_8264398=3A_BevelBorderUIResource?= =?utf-8?q?=E2=80=8B=28int=2C_Color=2C_Color=29_spec_should_mention_that_t?= =?utf-8?q?he_passed_colors_are_for_highlightInner_and_shadowOuter_props?= In-Reply-To: References: Message-ID: On Tue, 6 Apr 2021 11:12:27 GMT, Prasanta Sadhukhan wrote: >> As per https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/border/BevelBorder.java#L151 >> and https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/border/BevelBorder.java#L183 >> `derived ` is used to obtain the darker or brighter version of the same color, which is being done here for this highlight and shadow color too. > > any comments on the spec wording? Does 'derived' in javax.swing domain mean the color would be different, or 'equal color' also qualifies as 'derived' javax.swing? ------------- PR: https://git.openjdk.java.net/jdk/pull/3305 From psadhukhan at openjdk.java.net Tue Apr 6 12:34:25 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Tue, 6 Apr 2021 12:34:25 GMT Subject: =?utf-8?q?RFR=3A_8264398=3A_BevelBorderUIResource?= =?utf-8?q?=E2=80=8B=28int=2C_Color=2C_Color=29_spec_should_mention_that_t?= =?utf-8?q?he_passed_colors_are_for_highlightInner_and_shadowOuter_props?= In-Reply-To: References: Message-ID: On Tue, 6 Apr 2021 12:15:20 GMT, Dmitry Bessonov wrote: >> any comments on the spec wording? > > Does 'derived' in javax.swing domain mean the color would be different, or 'equal color' also qualifies as 'derived' javax.swing? In this context and BevelBorder context, 'derived' is used for brighter/darker version of the same color and as per Color.brighter method https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/java/awt/Color.java#L636 it can return the same color on case-to-case basis. ------------- PR: https://git.openjdk.java.net/jdk/pull/3305 From azvegint at openjdk.java.net Tue Apr 6 14:02:39 2021 From: azvegint at openjdk.java.net (Alexander Zvegintsev) Date: Tue, 6 Apr 2021 14:02:39 GMT Subject: RFR: 8049700: Deprecate obsolete classes and methods in javax/swing/plaf/basic [v8] In-Reply-To: <2qYuQ3q4_mqTbzdGse7HOVNhEjfHt8JddLX8S9Xx_v4=.569c94da-ab0a-497c-a8ba-2e3d34e192af@github.com> References: <2qYuQ3q4_mqTbzdGse7HOVNhEjfHt8JddLX8S9Xx_v4=.569c94da-ab0a-497c-a8ba-2e3d34e192af@github.com> Message-ID: On Thu, 4 Mar 2021 05:50:18 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. > > 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 Marked as reviewed by azvegint (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1958 From azvegint at openjdk.java.net Tue Apr 6 14:19:28 2021 From: azvegint at openjdk.java.net (Alexander Zvegintsev) Date: Tue, 6 Apr 2021 14:19:28 GMT Subject: RFR: 8264680: Use the blessed modifier order in java.desktop [v2] In-Reply-To: <7tWzZRpM_-C5E35SuC4CkciMAmF7oLYeoXrXLEB0XEo=.138dfad3-dc19-4283-9804-0365c9dddba3@github.com> References: <7tWzZRpM_-C5E35SuC4CkciMAmF7oLYeoXrXLEB0XEo=.138dfad3-dc19-4283-9804-0365c9dddba3@github.com> Message-ID: On Sat, 3 Apr 2021 22:28:54 GMT, Alex Blewitt wrote: >> 8264680: Use the blessed modifier order in java.desktop > > Alex Blewitt has updated the pull request incrementally with one additional commit since the last revision: > > Additionally remove detritus from PNGImageDecoder.java Marked as reviewed by azvegint (Reviewer). src/java.desktop/share/classes/sun/awt/image/PNGImageDecoder.java line 2: > 1: /* > 2: * Copyright (c) 1999, 2021, Oracle and/or its affiliates. All rights reserved. Copyright year in other files might be updated as well. ------------- PR: https://git.openjdk.java.net/jdk/pull/3337 From azvegint at openjdk.java.net Tue Apr 6 16:04:33 2021 From: azvegint at openjdk.java.net (Alexander Zvegintsev) Date: Tue, 6 Apr 2021 16:04:33 GMT Subject: RFR: 8264428: Cleanup usages of StringBuffer in java.desktop [v2] In-Reply-To: References: <2y9jvm8hnBRZQIO4qwAY-C07aSQM1QIzIT6SWAj7c70=.bda3ef0d-a445-40b0-b155-3920d072cb89@github.com> Message-ID: On Tue, 30 Mar 2021 19:05:37 GMT, Andrey Turbanov wrote: >> There are few possible cleanups in java.desktop related to legacy StringBuffer usages: >> 1. In few places StringBuffer can be replaced with plain String concatenation. >> 2. StringBuffer can be replaced with StringBuilder. StringBuilder has better performance as it is not thread-safe. >> 3. There are few places where result of string concatenation is passed to StringBuffer.append method. Using separate `.append` calls is more clear. >> 4. In few places primitives are unnecessary converted to String before `.append` call. They can be replaced with specialized methods (like `.append(int)` calls. > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > [PATCH] Replace uses of StringBuffer with StringBuilder in java.desktop src/java.desktop/windows/classes/sun/java2d/d3d/D3DContext.java line 139: > 137: @Override > 138: public String toString() { > 139: StringBuilder buf = new StringBuilder(super.toString()); Looks like this is the only file where copyright year is not updated. ------------- PR: https://git.openjdk.java.net/jdk/pull/3251 From aivanov at openjdk.java.net Tue Apr 6 20:26:27 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Tue, 6 Apr 2021 20:26:27 GMT Subject: RFR: 8263907: Specification of CellRendererPane::paintComponent(..Rectangle) should clearly mention which method it delegates the call to In-Reply-To: References: <7WGGElNmSFM3KnzrWjW2j3YlcLSmp766DrWhJmod_Pk=.d68fc4af-c256-47cd-8f03-8e87c0d8ed12@github.com> Message-ID: On Tue, 6 Apr 2021 11:11:56 GMT, Prasanta Sadhukhan wrote: >> Then the question might arise what is r.x, r.y....I guess my wordings makes it more clearer with pointer to input paramter. > > Can this please be approved if there's no more comments? > Probably the simple "Calls paintComponent(g, c, p, r.x, r.y, r.width, r.height)" will work? ?where `{@code r}` is the passed in rectangle. I'd add spaces after commas: x, y, width, height. ------------- PR: https://git.openjdk.java.net/jdk/pull/3146 From serb at openjdk.java.net Wed Apr 7 01:32:41 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Wed, 7 Apr 2021 01:32:41 GMT Subject: RFR: 8253266 : JList and JTable constructors should clear OPAQUE_SET before calling updateUI [v3] In-Reply-To: References: <0xQaEjHSESc7X1yaj1XWaOXBSyQDQgD1Jd6bkJbBGGw=.30558ebd-a585-4204-a501-b23d41249573@github.com> Message-ID: On Mon, 5 Apr 2021 17:45:33 GMT, Sergey Bylokhov wrote: >> I personally feel setting in code will be easier to maintain going forward than to go through property file settings. > > Then why we need this file at all? Now we will set the false value in the config, and true at runtime, what is the profit? I think we should set it in the config file since this is the place where all other properties are stored. ------------- PR: https://git.openjdk.java.net/jdk/pull/3167 From psadhukhan at openjdk.java.net Wed Apr 7 03:21:13 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Wed, 7 Apr 2021 03:21:13 GMT Subject: RFR: 8263907: Specification of CellRendererPane::paintComponent(..Rectangle) should clearly mention which method it delegates the call to [v2] In-Reply-To: References: Message-ID: > Specification for method > javax/swing/CellRendererPane.html#paintComponent(java.awt.Graphics,java.awt.Component,java.awt.Container,java.awt.Rectangle) > is not perfectly clear which method the call is delegated to. > > Updated spec to clarify. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: javadoc change ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3146/files - new: https://git.openjdk.java.net/jdk/pull/3146/files/961b47bc..c74fbd1b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3146&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3146&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3146.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3146/head:pull/3146 PR: https://git.openjdk.java.net/jdk/pull/3146 From psadhukhan at openjdk.java.net Wed Apr 7 03:21:13 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Wed, 7 Apr 2021 03:21:13 GMT Subject: RFR: 8263907: Specification of CellRendererPane::paintComponent(..Rectangle) should clearly mention which method it delegates the call to [v2] In-Reply-To: References: <7WGGElNmSFM3KnzrWjW2j3YlcLSmp766DrWhJmod_Pk=.d68fc4af-c256-47cd-8f03-8e87c0d8ed12@github.com> Message-ID: On Tue, 6 Apr 2021 20:22:36 GMT, Alexey Ivanov wrote: >> Can this please be approved if there's no more comments? > >> Probably the simple "Calls paintComponent(g, c, p, r.x, r.y, r.width, r.height)" will work? > > ?where `{@code r}` is the passed in rectangle. > > I'd add spaces after commas: x, y, width, height. OK. done ------------- PR: https://git.openjdk.java.net/jdk/pull/3146 From psadhukhan at openjdk.java.net Wed Apr 7 03:22:38 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Wed, 7 Apr 2021 03:22:38 GMT Subject: RFR: 8253266 : JList and JTable constructors should clear OPAQUE_SET before calling updateUI [v3] In-Reply-To: References: <0xQaEjHSESc7X1yaj1XWaOXBSyQDQgD1Jd6bkJbBGGw=.30558ebd-a585-4204-a501-b23d41249573@github.com> Message-ID: On Wed, 7 Apr 2021 01:29:22 GMT, Sergey Bylokhov wrote: >> Then why we need this file at all? Now we will set the false value in the config, and true at runtime, what is the profit? > > I think we should set it in the config file since this is the place where all other properties are stored. Before this fix, I see it was set in property file and then overridden in JToolTip. Current fix does the same, set in property file and then overridden in SynthToolTipUI. But I don't have objection if it is only controlled by property file. ------------- PR: https://git.openjdk.java.net/jdk/pull/3167 From psadhukhan at openjdk.java.net Wed Apr 7 03:35:30 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Wed, 7 Apr 2021 03:35:30 GMT Subject: RFR: 8264218: Public method javax.swing.JMenu.setComponentOrientation() has no spec [v5] In-Reply-To: <5cYHAAOWHyRD7vQ4p1k5o1zhYW32uxsCaVVMjILVFpo=.15bb8636-458b-41ad-bdf6-19d105c6bea1@github.com> References: <22JyhhEtdDzZ3uaobbNwCbA7rrcNYYX2Mb6G_zYBkqM=.451f59da-c2b8-4020-b4a6-ed00605305ce@github.com> <5cYHAAOWHyRD7vQ4p1k5o1zhYW32uxsCaVVMjILVFpo=.15bb8636-458b-41ad-bdf6-19d105c6bea1@github.com> Message-ID: <4zXvrDVbNGJT_xrWG6aDsodCfYCdQxNdNp6AEcg4dqI=.ef4a5c05-0ba0-49a5-9076-40e48ab01ccd@github.com> On Thu, 1 Apr 2021 17:00:15 GMT, Sergey Bylokhov wrote: >> Marked as reviewed by aivanov (Reviewer). > >> This might have been overlooked. The overridden method changes the behaviour. I'm for documenting the updated behaviour. > > It does not, the spec of the parent is still applicable to this method since the "associated popup menu" is actually a part of the JMenu. And we have other similar methods as well like JTextComponent#setComponentOrientation. > Note that even JMenu#applyComponentOrientation says nothing about "associated popup menu" but instead uses "getMenuComponents" - this is why that method is overridden. > > > >> It looks as the intentional change in the javadoc tool. > > It is still under deiscussion in JDK-8264217 @jonathan-gibbons I dont see any update in JDK-8264217. Is this then considered to be a javadoc bug? If yes, can I close this as dup of JDK-8264217? I see we have 3 options 1. Close this as dup of javadoc bug JDK-8264217? 2. Use {@code inheritDoc} to retain the spec of the super class method but it seems to not showing the spec if there is no change in spec wording compared to super class method. Can it be rectified in javadoc? 3. Use the spec wording as it is currently which will then be shown in spec as it is different from super class method. Please let me know which option to pursue. ------------- PR: https://git.openjdk.java.net/jdk/pull/3213 From github.com+76791+alblue at openjdk.java.net Wed Apr 7 06:18:37 2021 From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt) Date: Wed, 7 Apr 2021 06:18:37 GMT Subject: Integrated: 8264680: Use the blessed modifier order in java.desktop In-Reply-To: References: Message-ID: On Sat, 3 Apr 2021 22:03:44 GMT, Alex Blewitt wrote: > 8264680: Use the blessed modifier order in java.desktop This pull request has now been integrated. Changeset: 92fad1b4 Author: Alex Blewitt Committer: Sergey Bylokhov URL: https://git.openjdk.java.net/jdk/commit/92fad1b4 Stats: 132 lines in 11 files changed: 0 ins; 114 del; 18 mod 8264680: Use the blessed modifier order in java.desktop Reviewed-by: serb, kizune, azvegint ------------- PR: https://git.openjdk.java.net/jdk/pull/3337 From github.com+741251+turbanoff at openjdk.java.net Wed Apr 7 06:39:51 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Wed, 7 Apr 2021 06:39:51 GMT Subject: RFR: 8264428: Cleanup usages of StringBuffer in java.desktop [v3] In-Reply-To: References: <2y9jvm8hnBRZQIO4qwAY-C07aSQM1QIzIT6SWAj7c70=.bda3ef0d-a445-40b0-b155-3920d072cb89@github.com> Message-ID: <3cbmasQ5AlXcT2qoxYxlAUP_gtPwPsiA6bCT7qkOclw=.d33c2593-591c-420e-8375-4524475f4927@github.com> On Tue, 30 Mar 2021 15:46:56 GMT, Alexander Zvegintsev wrote: >> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: >> >> [PATCH] Replace uses of StringBuffer with StringBuilder in java.desktop >> >> fix copyright year > > src/java.desktop/windows/classes/sun/java2d/d3d/D3DContext.java line 139: > >> 137: @Override >> 138: public String toString() { >> 139: StringBuilder buf = new StringBuilder(super.toString()); > > Looks like this is the only file where copyright year is not updated. Thanks. Fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/3251 From github.com+741251+turbanoff at openjdk.java.net Wed Apr 7 06:39:48 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Wed, 7 Apr 2021 06:39:48 GMT Subject: RFR: 8264428: Cleanup usages of StringBuffer in java.desktop [v3] In-Reply-To: <2y9jvm8hnBRZQIO4qwAY-C07aSQM1QIzIT6SWAj7c70=.bda3ef0d-a445-40b0-b155-3920d072cb89@github.com> References: <2y9jvm8hnBRZQIO4qwAY-C07aSQM1QIzIT6SWAj7c70=.bda3ef0d-a445-40b0-b155-3920d072cb89@github.com> Message-ID: <8GAS4aHM0frtXpSG96f9tJczhTFPFPV_b9gWhFUJ8FY=.caacc6fa-6b9d-42f0-834b-ad1b210834be@github.com> > There are few possible cleanups in java.desktop related to legacy StringBuffer usages: > 1. In few places StringBuffer can be replaced with plain String concatenation. > 2. StringBuffer can be replaced with StringBuilder. StringBuilder has better performance as it is not thread-safe. > 3. There are few places where result of string concatenation is passed to StringBuffer.append method. Using separate `.append` calls is more clear. > 4. In few places primitives are unnecessary converted to String before `.append` call. They can be replaced with specialized methods (like `.append(int)` calls. Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: [PATCH] Replace uses of StringBuffer with StringBuilder in java.desktop fix copyright year ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3251/files - new: https://git.openjdk.java.net/jdk/pull/3251/files/80bff1db..963dc56e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3251&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3251&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3251.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3251/head:pull/3251 PR: https://git.openjdk.java.net/jdk/pull/3251 From azvegint at openjdk.java.net Wed Apr 7 11:01:36 2021 From: azvegint at openjdk.java.net (Alexander Zvegintsev) Date: Wed, 7 Apr 2021 11:01:36 GMT Subject: RFR: 8264428: Cleanup usages of StringBuffer in java.desktop [v3] In-Reply-To: <8GAS4aHM0frtXpSG96f9tJczhTFPFPV_b9gWhFUJ8FY=.caacc6fa-6b9d-42f0-834b-ad1b210834be@github.com> References: <2y9jvm8hnBRZQIO4qwAY-C07aSQM1QIzIT6SWAj7c70=.bda3ef0d-a445-40b0-b155-3920d072cb89@github.com> <8GAS4aHM0frtXpSG96f9tJczhTFPFPV_b9gWhFUJ8FY=.caacc6fa-6b9d-42f0-834b-ad1b210834be@github.com> Message-ID: <3G3a1TvBD_pa6-QmuKRm6HKbMDNCkCvjEyA1SqkOd3s=.478017e6-57ad-4823-ac39-8324f7a2ef5a@github.com> On Wed, 7 Apr 2021 06:39:48 GMT, Andrey Turbanov wrote: >> There are few possible cleanups in java.desktop related to legacy StringBuffer usages: >> 1. In few places StringBuffer can be replaced with plain String concatenation. >> 2. StringBuffer can be replaced with StringBuilder. StringBuilder has better performance as it is not thread-safe. >> 3. There are few places where result of string concatenation is passed to StringBuffer.append method. Using separate `.append` calls is more clear. >> 4. In few places primitives are unnecessary converted to String before `.append` call. They can be replaced with specialized methods (like `.append(int)` calls. > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > [PATCH] Replace uses of StringBuffer with StringBuilder in java.desktop > > fix copyright year Marked as reviewed by azvegint (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3251 From aivanov at openjdk.java.net Wed Apr 7 11:05:33 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Wed, 7 Apr 2021 11:05:33 GMT Subject: RFR: 8263907: Specification of CellRendererPane::paintComponent(..Rectangle) should clearly mention which method it delegates the call to [v2] In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 03:21:13 GMT, Prasanta Sadhukhan wrote: >> Specification for method >> javax/swing/CellRendererPane.html#paintComponent(java.awt.Graphics,java.awt.Component,java.awt.Container,java.awt.Rectangle) >> is not perfectly clear which method the call is delegated to. >> >> Updated spec to clarify. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > javadoc change Marked as reviewed by aivanov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3146 From aivanov at openjdk.java.net Wed Apr 7 15:30:40 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Wed, 7 Apr 2021 15:30:40 GMT Subject: RFR: 8264428: Cleanup usages of StringBuffer in java.desktop [v3] In-Reply-To: <8GAS4aHM0frtXpSG96f9tJczhTFPFPV_b9gWhFUJ8FY=.caacc6fa-6b9d-42f0-834b-ad1b210834be@github.com> References: <2y9jvm8hnBRZQIO4qwAY-C07aSQM1QIzIT6SWAj7c70=.bda3ef0d-a445-40b0-b155-3920d072cb89@github.com> <8GAS4aHM0frtXpSG96f9tJczhTFPFPV_b9gWhFUJ8FY=.caacc6fa-6b9d-42f0-834b-ad1b210834be@github.com> Message-ID: On Wed, 7 Apr 2021 06:39:48 GMT, Andrey Turbanov wrote: >> There are few possible cleanups in java.desktop related to legacy StringBuffer usages: >> 1. In few places StringBuffer can be replaced with plain String concatenation. >> 2. StringBuffer can be replaced with StringBuilder. StringBuilder has better performance as it is not thread-safe. >> 3. There are few places where result of string concatenation is passed to StringBuffer.append method. Using separate `.append` calls is more clear. >> 4. In few places primitives are unnecessary converted to String before `.append` call. They can be replaced with specialized methods (like `.append(int)` calls. > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > [PATCH] Replace uses of StringBuffer with StringBuilder in java.desktop > > fix copyright year Marked as reviewed by aivanov (Reviewer). src/java.desktop/unix/classes/sun/awt/X11/XCreateWindowParams.java line 88: > 86: while (eIter.hasNext()) { > 87: Map.Entry entry = eIter.next(); > 88: buf.append(entry.getKey()).append(": ").append(entry.getValue()).append("\n"); Would it be clearer if each append was on its own line? Suggestion: buf.append(entry.getKey()) .append(": ") .append(entry.getValue()) .append("\n"); ------------- PR: https://git.openjdk.java.net/jdk/pull/3251 From serb at openjdk.java.net Wed Apr 7 19:18:37 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Wed, 7 Apr 2021 19:18:37 GMT Subject: RFR: 8263907: Specification of CellRendererPane::paintComponent(..Rectangle) should clearly mention which method it delegates the call to [v2] In-Reply-To: References: Message-ID: <3d3Ee-hpjCaIOsw_a9z4G1Vi3IPwkVR2MKNGQBv3TgY=.6966500b-bb6d-4371-a002-4d03c0c2baa0@github.com> On Wed, 7 Apr 2021 03:21:13 GMT, Prasanta Sadhukhan wrote: >> Specification for method >> javax/swing/CellRendererPane.html#paintComponent(java.awt.Graphics,java.awt.Component,java.awt.Container,java.awt.Rectangle) >> is not perfectly clear which method the call is delegated to. >> >> Updated spec to clarify. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > javadoc change Marked as reviewed by serb (Reviewer). src/java.desktop/share/classes/javax/swing/CellRendererPane.java line 203: > 201: > 202: /** > 203: * Calls this.paintComponent(g, c, p, r.x, r.y, r.w, r.h) where BTW the Rectangle does not have "w" and "h" fields ------------- PR: https://git.openjdk.java.net/jdk/pull/3146 From serb at openjdk.java.net Wed Apr 7 20:09:28 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Wed, 7 Apr 2021 20:09:28 GMT Subject: RFR: 8264218: Public method javax.swing.JMenu.setComponentOrientation() has no spec [v5] In-Reply-To: <4zXvrDVbNGJT_xrWG6aDsodCfYCdQxNdNp6AEcg4dqI=.ef4a5c05-0ba0-49a5-9076-40e48ab01ccd@github.com> References: <22JyhhEtdDzZ3uaobbNwCbA7rrcNYYX2Mb6G_zYBkqM=.451f59da-c2b8-4020-b4a6-ed00605305ce@github.com> <5cYHAAOWHyRD7vQ4p1k5o1zhYW32uxsCaVVMjILVFpo=.15bb8636-458b-41ad-bdf6-19d105c6bea1@github.com> <4zXvrDVbNGJT_xrWG6aDsodCfYCdQxNdNp6AEcg4dqI=.ef4a5c05-0ba0-49a5-9076-40e48ab01ccd@github.com> Message-ID: <18zG-1Vc7bu1SFOuPkiojVtzmVWNHxnri0upEp4iI1o=.725325ac-3266-4263-b9e5-4d4c2198b77f@github.com> On Wed, 7 Apr 2021 03:32:35 GMT, Prasanta Sadhukhan wrote: > I dont see any update in JDK-8264217. Is this then considered to be a javadoc bug? It does not matter is it a JavaDoc bug or feature. If it is a bug it will be fixed and spec will be returned for the current method. If it is an intentional feature to skip the identical comments in the subclasses then the spec in the current method will be intentionally skipped. ------------- PR: https://git.openjdk.java.net/jdk/pull/3213 From serb at openjdk.java.net Wed Apr 7 20:10:36 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Wed, 7 Apr 2021 20:10:36 GMT Subject: RFR: 8262981: Create implementation for NSAccessibilitySlider protocol In-Reply-To: <3CKaFVyC5vtiHzByCzX4XXPMk798bLVvO00p1t8Pl4g=.9426b24b-1725-40dc-8957-dd13f26701c8@github.com> References: <3kHCT6j_xnm9mbA2jeP35p9rY4nxOD61PInSB9mglT8=.71c3b9df-0cc3-40f7-b339-15b382e36b6f@github.com> <4SZRIR695DBooSWt-1aatGx-CKPy6EwuRpXS29A8wro=.4ba37fe2-6017-482f-83c4-33d7a11fc320@github.com> <60QaQ3ISOvoR5RMWU1hTSCsiBHfy7xU2QjvLzrGaSvA=.c02ab62e-5176-4015-a16c-849a71088452@github.com> <3CKaFVyC5vtiHzByCzX4XXPMk798bLVvO00p1t8Pl4g=.9426b24b-1725-40dc-8957-dd13f26701c8@github.com> Message-ID: On Mon, 5 Apr 2021 18:47:25 GMT, Pankaj Bansal wrote: >> Ok, please file a similar bug for the windows platform. > > @mrserb @azuev-java Any other comments on this? Can you please look at the CSR also? I have no additional comments. ------------- PR: https://git.openjdk.java.net/jdk/pull/2874 From aivanov at openjdk.java.net Wed Apr 7 20:37:36 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Wed, 7 Apr 2021 20:37:36 GMT Subject: RFR: 8264218: Public method javax.swing.JMenu.setComponentOrientation() has no spec [v5] In-Reply-To: <18zG-1Vc7bu1SFOuPkiojVtzmVWNHxnri0upEp4iI1o=.725325ac-3266-4263-b9e5-4d4c2198b77f@github.com> References: <22JyhhEtdDzZ3uaobbNwCbA7rrcNYYX2Mb6G_zYBkqM=.451f59da-c2b8-4020-b4a6-ed00605305ce@github.com> <5cYHAAOWHyRD7vQ4p1k5o1zhYW32uxsCaVVMjILVFpo=.15bb8636-458b-41ad-bdf6-19d105c6bea1@github.com> <4zXvrDVbNGJT_xrWG6aDsodCfYCdQxNdNp6AEcg4dqI=.ef4a5c05-0ba0-49a5-9076-40e48ab01ccd@github.com> <18zG-1Vc7bu1SFOuPkiojVtzmVWNHxnri0upEp4iI1o=.725325ac-3266-4263-b9e5-4d4c2198b77f@github.com> Message-ID: On Wed, 7 Apr 2021 20:06:46 GMT, Sergey Bylokhov wrote: > > I dont see any update in JDK-8264217. Is this then considered to be a javadoc bug? > > It does not matter is it a JavaDoc bug or feature. If it is a bug it will be fixed and spec will be returned for the current method. If it is an intentional feature to skip the identical comments in the subclasses then the spec in the current method will be intentionally skipped. Then this bug is not an issue, right? Unless we want to document that `JMenu.setComponentOrientation` _also sets_ the orientation to _`popupMenu`_, which doesn't change the orientation of menu items the `popupMenu` contains. However, it aligns with the specification: use `applyComponentOrientation` to change the orientation of the components contained within. ------------- PR: https://git.openjdk.java.net/jdk/pull/3213 From jjg at openjdk.java.net Thu Apr 8 00:18:37 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Thu, 8 Apr 2021 00:18:37 GMT Subject: RFR: 8264218: Public method javax.swing.JMenu.setComponentOrientation() has no spec [v5] In-Reply-To: References: <22JyhhEtdDzZ3uaobbNwCbA7rrcNYYX2Mb6G_zYBkqM=.451f59da-c2b8-4020-b4a6-ed00605305ce@github.com> <5cYHAAOWHyRD7vQ4p1k5o1zhYW32uxsCaVVMjILVFpo=.15bb8636-458b-41ad-bdf6-19d105c6bea1@github.com> <4zXvrDVbNGJT_xrWG6aDsodCfYCdQxNdNp6AEcg4dqI=.ef4a5c05-0ba0-49a5-9076-40e48ab01ccd@github.com> <18zG-1Vc7bu1SFOuPkiojVtzmVWNHxnri0upEp4iI1o=.725325ac-3266-4263-b9e5-4d4c2198b77f@github.com> Message-ID: <7CyTK5xhBNteEsN_T0jFdY6WU--ijSRqMG1Vw4Dd3aU=.2fcdb272-e03f-4ef7-9abd-8651b9fe45c6@github.com> On Wed, 7 Apr 2021 20:34:22 GMT, Alexey Ivanov wrote: >>> I dont see any update in JDK-8264217. Is this then considered to be a javadoc bug? >> >> It does not matter is it a JavaDoc bug or feature. If it is a bug it will be fixed and spec will be returned for the current method. If it is an intentional feature to skip the identical comments in the subclasses then the spec in the current method will be intentionally skipped. > >> > I dont see any update in JDK-8264217. Is this then considered to be a javadoc bug? >> >> It does not matter is it a JavaDoc bug or feature. If it is a bug it will be fixed and spec will be returned for the current method. If it is an intentional feature to skip the identical comments in the subclasses then the spec in the current method will be intentionally skipped. > > Then this bug is not an issue, right? > > Unless we want to document that `JMenu.setComponentOrientation` _also sets_ the orientation to _`popupMenu`_, which doesn't change the orientation of menu items the `popupMenu` contains. However, it aligns with the specification: use `applyComponentOrientation` to change the orientation of the components contained within. The behavior is not a javadoc bug. If a method is overridden with no specified change in behavior, the method will be documented in the "Methods Declared In ..." list at the end of the main summary table. -- Jon On 4/7/21 1:07 PM, Sergey Bylokhov wrote: > > I dont see any update in JDK-8264217. Is this then considered to > be a javadoc bug? > > It does not matter is it a JavaDoc bug or feature. If it is a bug it > will be fixed and spec will be returned for the current method. If it > is an intentional feature to skip the identical comments in the > subclasses then the spec in the current method will be intentionally > skipped. > > ? > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > , > or unsubscribe > . > ------------- PR: https://git.openjdk.java.net/jdk/pull/3213 From serb at openjdk.java.net Thu Apr 8 00:42:16 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Thu, 8 Apr 2021 00:42:16 GMT Subject: RFR: 8264218: Public method javax.swing.JMenu.setComponentOrientation() has no spec [v5] In-Reply-To: <7CyTK5xhBNteEsN_T0jFdY6WU--ijSRqMG1Vw4Dd3aU=.2fcdb272-e03f-4ef7-9abd-8651b9fe45c6@github.com> References: <22JyhhEtdDzZ3uaobbNwCbA7rrcNYYX2Mb6G_zYBkqM=.451f59da-c2b8-4020-b4a6-ed00605305ce@github.com> <5cYHAAOWHyRD7vQ4p1k5o1zhYW32uxsCaVVMjILVFpo=.15bb8636-458b-41ad-bdf6-19d105c6bea1@github.com> <4zXvrDVbNGJT_xrWG6aDsodCfYCdQxNdNp6AEcg4dqI=.ef4a5c05-0ba0-49a5-9076-40e48ab01ccd@github.com> <18zG-1Vc7bu1SFOuPkiojVtzmVWNHxnri0upEp4iI1o=.725325ac-3266-4263-b9e5-4d4c2198b77f@github.com> <7CyTK5xhBNteEsN_T0jFdY6WU--ijSRqMG1Vw4Dd3aU=.2fcdb272-e03f-4ef7-9abd-8651b9fe45c6@github.com> Message-ID: On Thu, 8 Apr 2021 00:16:29 GMT, Jonathan Gibbons wrote: > The behavior is not a javadoc bug. If a method is overridden with no specified change in behavior, the method will be documented in the "Methods Declared In ..." list at the end of the main summary table. If it is not a bug it is necessary to update the javadoc spec: https://docs.oracle.com/en/java/javase/16/docs/specs/javadoc/doc-comment-spec.html It currently states that in such use-case the spec should be copied, and it also states that "{@inheritDoc}" must force the doc to be copied as well. Anyway this issue can be closed as not a bug. ------------- PR: https://git.openjdk.java.net/jdk/pull/3213 From serb at openjdk.java.net Thu Apr 8 01:00:08 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Thu, 8 Apr 2021 01:00:08 GMT Subject: =?utf-8?q?RFR=3A_8264398=3A_BevelBorderUIResource?= =?utf-8?q?=E2=80=8B=28int=2C_Color=2C_Color=29_spec_should_mention_that_t?= =?utf-8?q?he_passed_colors_are_for_highlightInner_and_shadowOuter_props?= In-Reply-To: References: Message-ID: On Tue, 6 Apr 2021 12:31:00 GMT, Prasanta Sadhukhan wrote: >> Does 'derived' in javax.swing domain mean the color would be different, or 'equal color' also qualifies as 'derived' javax.swing? > > In this context and BevelBorder context, 'derived' is used for brighter/darker version of the same color and as per Color.brighter method https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/java/awt/Color.java#L636 > it can return the same color on case-to-case basis. Please update the title of the bug/PR, since the change now in another class. ------------- PR: https://git.openjdk.java.net/jdk/pull/3305 From serb at openjdk.java.net Thu Apr 8 01:03:55 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Thu, 8 Apr 2021 01:03:55 GMT Subject: =?utf-8?q?RFR=3A_8264398=3A_BevelBorderUIResource?= =?utf-8?q?=E2=80=8B=28int=2C_Color=2C_Color=29_spec_should_mention_that_t?= =?utf-8?q?he_passed_colors_are_for_highlightInner_and_shadowOuter_props?= In-Reply-To: References: Message-ID: On Thu, 8 Apr 2021 00:56:34 GMT, Sergey Bylokhov wrote: >> In this context and BevelBorder context, 'derived' is used for brighter/darker version of the same color and as per Color.brighter method https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/java/awt/Color.java#L636 >> it can return the same color on case-to-case basis. > > Please update the title of the bug/PR, since the change now in another class. BevelBorder vs BevelBorderUIResource. The BevelBorderUIResource is a UIResource version of BevelBorder and its spec is just a copy. ------------- PR: https://git.openjdk.java.net/jdk/pull/3305 From psadhukhan at openjdk.java.net Thu Apr 8 04:14:16 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Thu, 8 Apr 2021 04:14:16 GMT Subject: RFR: 8263907: Specification of CellRendererPane::paintComponent(..Rectangle) should clearly mention which method it delegates the call to [v3] In-Reply-To: References: Message-ID: > Specification for method > javax/swing/CellRendererPane.html#paintComponent(java.awt.Graphics,java.awt.Component,java.awt.Container,java.awt.Rectangle) > is not perfectly clear which method the call is delegated to. > > Updated spec to clarify. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: javadoc change ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3146/files - new: https://git.openjdk.java.net/jdk/pull/3146/files/c74fbd1b..92749f76 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3146&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3146&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3146.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3146/head:pull/3146 PR: https://git.openjdk.java.net/jdk/pull/3146 From psadhukhan at openjdk.java.net Thu Apr 8 04:26:17 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Thu, 8 Apr 2021 04:26:17 GMT Subject: =?utf-8?q?RFR=3A_8264398=3A_BevelBorderUIResource?= =?utf-8?q?=E2=80=8B=28int=2C_Color=2C_Color=29_spec_should_mention_that_t?= =?utf-8?q?he_passed_colors_are_for_highlightInner_and_shadowOuter_props?= In-Reply-To: References: Message-ID: <-kQPmDHx0QmDkdTuYhiRUjMaMtrVKWNXweYo5-mhJhQ=.9940313e-5e84-40d7-96ae-89417ddcc804@github.com> On Thu, 8 Apr 2021 01:00:37 GMT, Sergey Bylokhov wrote: >> Please update the title of the bug/PR, since the change now in another class. > > BevelBorder vs BevelBorderUIResource. The BevelBorderUIResource is a UIResource version of BevelBorder and its spec is just a copy. Not sure I understand...The change is still in BevelorderUIResource(int, Color, Color) method so what should be changed in PR title? ------------- PR: https://git.openjdk.java.net/jdk/pull/3305 From serb at openjdk.java.net Thu Apr 8 04:33:23 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Thu, 8 Apr 2021 04:33:23 GMT Subject: =?utf-8?q?RFR=3A_8264398=3A_BevelBorderUIResource?= =?utf-8?q?=E2=80=8B=28int=2C_Color=2C_Color=29_spec_should_mention_that_t?= =?utf-8?q?he_passed_colors_are_for_highlightInner_and_shadowOuter_props?= In-Reply-To: <-kQPmDHx0QmDkdTuYhiRUjMaMtrVKWNXweYo5-mhJhQ=.9940313e-5e84-40d7-96ae-89417ddcc804@github.com> References: <-kQPmDHx0QmDkdTuYhiRUjMaMtrVKWNXweYo5-mhJhQ=.9940313e-5e84-40d7-96ae-89417ddcc804@github.com> Message-ID: On Thu, 8 Apr 2021 04:20:16 GMT, Prasanta Sadhukhan wrote: > Not sure I understand...The change is still in BevelorderUIResource(int, Color, Color) method so what should be changed in PR title? It should be Bevelorder as well, the class from where the spec is copied to the BevelorderUIResource. ------------- PR: https://git.openjdk.java.net/jdk/pull/3305 From psadhukhan at openjdk.java.net Thu Apr 8 04:34:23 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Thu, 8 Apr 2021 04:34:23 GMT Subject: RFR: 8264218: Public method javax.swing.JMenu.setComponentOrientation() has no spec [v5] In-Reply-To: References: <22JyhhEtdDzZ3uaobbNwCbA7rrcNYYX2Mb6G_zYBkqM=.451f59da-c2b8-4020-b4a6-ed00605305ce@github.com> <5cYHAAOWHyRD7vQ4p1k5o1zhYW32uxsCaVVMjILVFpo=.15bb8636-458b-41ad-bdf6-19d105c6bea1@github.com> <4zXvrDVbNGJT_xrWG6aDsodCfYCdQxNdNp6AEcg4dqI=.ef4a5c05-0ba0-49a5-9076-40e48ab01ccd@github.com> <18zG-1Vc7bu1SFOuPkiojVtzmVWNHxnri0upEp4iI1o=.725325ac-3266-4263-b9e5-4d4c2198b77f@github.com> <7CyTK5xhBNteEsN_T0jFdY6WU--ijSRqMG1Vw4Dd3aU=.2fcdb272-e03f-4ef7-9abd-8651b9fe45c6@github.com> Message-ID: On Thu, 8 Apr 2021 00:37:57 GMT, Sergey Bylokhov wrote: >> The behavior is not a javadoc bug. >> >> If a method is overridden with no specified change in behavior, the >> method will be documented in the "Methods Declared In ..." list at the >> end of the main summary table. >> >> -- Jon >> >> On 4/7/21 1:07 PM, Sergey Bylokhov wrote: >>> >>> I dont see any update in JDK-8264217. Is this then considered to >>> be a javadoc bug? >>> >>> It does not matter is it a JavaDoc bug or feature. If it is a bug it >>> will be fixed and spec will be returned for the current method. If it >>> is an intentional feature to skip the identical comments in the >>> subclasses then the spec in the current method will be intentionally >>> skipped. >>> >>> ? >>> You are receiving this because you were mentioned. >>> Reply to this email directly, view it on GitHub >>> , >>> or unsubscribe >>> . >>> > >> The behavior is not a javadoc bug. If a method is overridden with no specified change in behavior, the method will be documented in the "Methods Declared In ..." list at the end of the main summary table. > > If it is not a bug it is necessary to update the javadoc spec: > https://docs.oracle.com/en/java/javase/16/docs/specs/javadoc/doc-comment-spec.html > It currently states that in such use-case the spec should be copied, and it also states that "{@inheritDoc}" must force the doc to be copied as well. > > Anyway this issue can be closed as not a bug. I think we should at least use {@inheritDoc} so that if and when javadoc tool is changed, then we would have the possibility of method spec being visible? In many places, we use {@inheritDoc} [ex. https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/synth/SynthToolTipUI.java#L68] for same usecase!!! ------------- PR: https://git.openjdk.java.net/jdk/pull/3213 From psadhukhan at openjdk.java.net Thu Apr 8 04:40:04 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Thu, 8 Apr 2021 04:40:04 GMT Subject: =?utf-8?q?RFR=3A_8264398=3A_BevelBorderUIResource?= =?utf-8?q?=E2=80=8B=28int=2C_Color=2C_Color=29_spec_should_mention_that_t?= =?utf-8?q?he_passed_colors_are_for_highlightInner_and_shadowOuter_props?= In-Reply-To: References: <-kQPmDHx0QmDkdTuYhiRUjMaMtrVKWNXweYo5-mhJhQ=.9940313e-5e84-40d7-96ae-89417ddcc804@github.com> Message-ID: On Thu, 8 Apr 2021 04:27:02 GMT, Sergey Bylokhov wrote: >> Not sure I understand...The change is still in BevelorderUIResource(int, Color, Color) method so what should be changed in PR title? > >> Not sure I understand...The change is still in BevelorderUIResource(int, Color, Color) method so what should be changed in PR title? > > It should be Bevelorder as well, the class from where the spec is copied to the BevelorderUIResource. I don't think the spec is coped from BevelBorder...Yes, the spec is inspired by how BevelBorder treates the shadow/highlight color!! You want same spec to be copied to BevelBorder(int, Color, Color) constrcutor too? ------------- PR: https://git.openjdk.java.net/jdk/pull/3305 From psadhukhan at openjdk.java.net Thu Apr 8 04:49:39 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Thu, 8 Apr 2021 04:49:39 GMT Subject: Integrated: 8263907: Specification of CellRendererPane::paintComponent(..Rectangle) should clearly mention which method it delegates the call to In-Reply-To: References: Message-ID: On Tue, 23 Mar 2021 06:10:32 GMT, Prasanta Sadhukhan wrote: > Specification for method > javax/swing/CellRendererPane.html#paintComponent(java.awt.Graphics,java.awt.Component,java.awt.Container,java.awt.Rectangle) > is not perfectly clear which method the call is delegated to. > > Updated spec to clarify. This pull request has now been integrated. Changeset: 016db40c Author: Prasanta Sadhukhan URL: https://git.openjdk.java.net/jdk/commit/016db40c Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod 8263907: Specification of CellRendererPane::paintComponent(..Rectangle) should clearly mention which method it delegates the call to Reviewed-by: aivanov, serb ------------- PR: https://git.openjdk.java.net/jdk/pull/3146 From serb at openjdk.java.net Thu Apr 8 04:49:55 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Thu, 8 Apr 2021 04:49:55 GMT Subject: =?utf-8?q?RFR=3A_8264398=3A_BevelBorderUIResource?= =?utf-8?q?=E2=80=8B=28int=2C_Color=2C_Color=29_spec_should_mention_that_t?= =?utf-8?q?he_passed_colors_are_for_highlightInner_and_shadowOuter_props?= In-Reply-To: References: <-kQPmDHx0QmDkdTuYhiRUjMaMtrVKWNXweYo5-mhJhQ=.9940313e-5e84-40d7-96ae-89417ddcc804@github.com> Message-ID: <4Bnk6MvlBG_db2u1rZIZK9SeevV7K5iUhY8h8Rr58RY=.1d6337ae-b705-4f0a-8384-b049e202fd48@github.com> On Thu, 8 Apr 2021 04:31:12 GMT, Prasanta Sadhukhan wrote: > I don't think the spec is coped from BevelBorder...Yes, the spec is inspired by how BevelBorder treates the shadow/highlight color! The BevelBorderUIResource is just a tagged wrapper on top of the BevelBorder, it does not provide any additional functionality. > You want same spec to be copied to BevelBorder(int, Color, Color) constrcutor too? Yes, this constructor is called from the BevelBorderUIResource, and it will be strange if the subclass will have a better spec than the parent. ------------- PR: https://git.openjdk.java.net/jdk/pull/3305 From psadhukhan at openjdk.java.net Thu Apr 8 04:58:14 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Thu, 8 Apr 2021 04:58:14 GMT Subject: =?utf-8?q?RFR=3A_8264398=3A_BevelBorderUIResource?= =?utf-8?q?=E2=80=8B=28int=2C_Color=2C_Color=29_spec_should_mention_that_t?= =?utf-8?q?he_passed_colors_are_for_highlightInner_and_shadowOuter_props_?= =?utf-8?q?=5Bv3=5D?= In-Reply-To: References: Message-ID: > The current spec for javax/swing/plaf/BorderUIResource.BevelBorderUIResource.html(int,java.awt.Color,java.awt.Color) does not clearly specify the usage of color for hightlight and shadow as there are outer/inner hightlight and outer/inner shadow. > Updated spec to clarify the same. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: javadoc change in BevelBorder constructor ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3305/files - new: https://git.openjdk.java.net/jdk/pull/3305/files/cb0b25c3..f5d6be5d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3305&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3305&range=01-02 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3305.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3305/head:pull/3305 PR: https://git.openjdk.java.net/jdk/pull/3305 From serb at openjdk.java.net Thu Apr 8 05:05:11 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Thu, 8 Apr 2021 05:05:11 GMT Subject: RFR: 8264218: Public method javax.swing.JMenu.setComponentOrientation() has no spec [v5] In-Reply-To: References: <22JyhhEtdDzZ3uaobbNwCbA7rrcNYYX2Mb6G_zYBkqM=.451f59da-c2b8-4020-b4a6-ed00605305ce@github.com> <5cYHAAOWHyRD7vQ4p1k5o1zhYW32uxsCaVVMjILVFpo=.15bb8636-458b-41ad-bdf6-19d105c6bea1@github.com> <4zXvrDVbNGJT_xrWG6aDsodCfYCdQxNdNp6AEcg4dqI=.ef4a5c05-0ba0-49a5-9076-40e48ab01ccd@github.com> <18zG-1Vc7bu1SFOuPkiojVtzmVWNHxnri0upEp4iI1o=.725325ac-3266-4263-b9e5-4d4c2198b77f@github.com> <7CyTK5xhBNteEsN_T0jFdY6WU--ijSRqMG1Vw4Dd3aU=.2fcdb272-e03f-4ef7-9abd-8651b9fe45c6@github.com> Message-ID: On Thu, 8 Apr 2021 04:27:16 GMT, Prasanta Sadhukhan wrote: >>> The behavior is not a javadoc bug. If a method is overridden with no specified change in behavior, the method will be documented in the "Methods Declared In ..." list at the end of the main summary table. >> >> If it is not a bug it is necessary to update the javadoc spec: >> https://docs.oracle.com/en/java/javase/16/docs/specs/javadoc/doc-comment-spec.html >> It currently states that in such use-case the spec should be copied, and it also states that "{@inheritDoc}" must force the doc to be copied as well. >> >> Anyway this issue can be closed as not a bug. > > I think we should at least use {@inheritDoc} so that if and when javadoc tool is changed, then we would have the possibility of method spec being visible? > In many places, we use {@inheritDoc} [ex. https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/synth/SynthToolTipUI.java#L68] for same usecase!!! > In many places, we use {@inheritdoc} [ex. https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/synth/SynthToolTipUI.java#L68] for same usecase!!! All of them are in the SynthXX classes and were added as part of moving that classes to the javax package by the JDK-6827653 in jdk7. The spec of the parent class was used in the CCC since the new functionality of these methods was not specified and was hidden. So you are right, it looks like the same use case as we discussed here, and if in this case the javadoc was hidden intentionally then I assume it was hidden there as well. Lets wait how the JDK-8264217 will be resolved. ------------- PR: https://git.openjdk.java.net/jdk/pull/3213 From kizune at openjdk.java.net Thu Apr 8 10:10:27 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Thu, 8 Apr 2021 10:10:27 GMT Subject: RFR: 8262981: Create implementation for NSAccessibilitySlider protocol [v3] In-Reply-To: References: Message-ID: On Thu, 1 Apr 2021 12:12:40 GMT, Pankaj Bansal wrote: >> Create implementation of NSAccessibilitySlider protocol https://developer.apple.com/documentation/appkit/nsaccessibilityslider >> >> The implementation has the function performIncrement and performDecrement to increase/decrease the value of slider using the VoiceOver. To implement this functionality, I could think of following two ways. I have chosen the first one here though it is more intrusive. >> 1. Make the AccessibleJSlider class implement the AccessibleAction interface. This makes AccessibleJSlider consistent with the AccessibleJSpinner class. It is more clear and the logic to increase/decrease Slider value can be changed easily. But this changes AccessibleJSlider class and will need a CSR. >> 2. Get the current Accessible Value from the component and just increment/decrement it in SliderAccessibility.m class itself and then set the current accessible value fro there only. This will not need any changes in AccessibleJSlider class, but this does not look correct way and I have not used this. >> >> The changes can be easily tested by using a JSlider example, like the following example. VO should announce the correct the slider values. To change the slider values, use ctrl+opt+shift+down key to start interacting with the slider, then use ctrl+opt+up/down arrow keys to increment/decrement slider values. >> >> import javax.swing.JFrame; >> import javax.swing.JSlider; >> >> public class JSliderDemo{ >> public static void main(String[] args) throws Exception { >> JFrame jframe = new JFrame("JSlider Demo"); >> jframe.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); >> jframe.add(new JSlider()); >> >> jframe.setLocationRelativeTo(null); >> jframe.pack(); >> jframe.setVisible(true); >> } >> } > > Pankaj Bansal has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: > > - Merge branch 'master' into JDK-8262981 > - increase initial capacity for rolesMap > - Remove whitespaces > - remove SpinboxAccessibility.m changes > - Code cleanup > - cleanup > - 8262981: Create implementation for NSAccessibilitySlider protocol Marked as reviewed by kizune (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2874 From github.com+741251+turbanoff at openjdk.java.net Thu Apr 8 14:43:50 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Thu, 8 Apr 2021 14:43:50 GMT Subject: RFR: 8264428: Cleanup usages of StringBuffer in java.desktop [v4] In-Reply-To: <2y9jvm8hnBRZQIO4qwAY-C07aSQM1QIzIT6SWAj7c70=.bda3ef0d-a445-40b0-b155-3920d072cb89@github.com> References: <2y9jvm8hnBRZQIO4qwAY-C07aSQM1QIzIT6SWAj7c70=.bda3ef0d-a445-40b0-b155-3920d072cb89@github.com> Message-ID: > There are few possible cleanups in java.desktop related to legacy StringBuffer usages: > 1. In few places StringBuffer can be replaced with plain String concatenation. > 2. StringBuffer can be replaced with StringBuilder. StringBuilder has better performance as it is not thread-safe. > 3. There are few places where result of string concatenation is passed to StringBuffer.append method. Using separate `.append` calls is more clear. > 4. In few places primitives are unnecessary converted to String before `.append` call. They can be replaced with specialized methods (like `.append(int)` calls. Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: 8264484: Replace uses of StringBuffer with StringBuilder in jdk.hotspot.agent place each 'append' call on its own line ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3251/files - new: https://git.openjdk.java.net/jdk/pull/3251/files/963dc56e..d083f953 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3251&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3251&range=02-03 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3251.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3251/head:pull/3251 PR: https://git.openjdk.java.net/jdk/pull/3251 From github.com+741251+turbanoff at openjdk.java.net Thu Apr 8 14:43:52 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Thu, 8 Apr 2021 14:43:52 GMT Subject: RFR: 8264428: Cleanup usages of StringBuffer in java.desktop [v3] In-Reply-To: References: <2y9jvm8hnBRZQIO4qwAY-C07aSQM1QIzIT6SWAj7c70=.bda3ef0d-a445-40b0-b155-3920d072cb89@github.com> <8GAS4aHM0frtXpSG96f9tJczhTFPFPV_b9gWhFUJ8FY=.caacc6fa-6b9d-42f0-834b-ad1b210834be@github.com> Message-ID: On Wed, 7 Apr 2021 15:21:40 GMT, Alexey Ivanov wrote: >> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: >> >> [PATCH] Replace uses of StringBuffer with StringBuilder in java.desktop >> >> fix copyright year > > src/java.desktop/unix/classes/sun/awt/X11/XCreateWindowParams.java line 88: > >> 86: while (eIter.hasNext()) { >> 87: Map.Entry entry = eIter.next(); >> 88: buf.append(entry.getKey()).append(": ").append(entry.getValue()).append("\n"); > > Would it be clearer if each append was on its own line? > Suggestion: > > buf.append(entry.getKey()) > .append(": ") > .append(entry.getValue()) > .append("\n"); done ------------- PR: https://git.openjdk.java.net/jdk/pull/3251 From aivanov at openjdk.java.net Thu Apr 8 14:51:07 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Thu, 8 Apr 2021 14:51:07 GMT Subject: RFR: 8264428: Cleanup usages of StringBuffer in java.desktop [v4] In-Reply-To: References: <2y9jvm8hnBRZQIO4qwAY-C07aSQM1QIzIT6SWAj7c70=.bda3ef0d-a445-40b0-b155-3920d072cb89@github.com> Message-ID: On Thu, 8 Apr 2021 14:43:50 GMT, Andrey Turbanov wrote: >> There are few possible cleanups in java.desktop related to legacy StringBuffer usages: >> 1. In few places StringBuffer can be replaced with plain String concatenation. >> 2. StringBuffer can be replaced with StringBuilder. StringBuilder has better performance as it is not thread-safe. >> 3. There are few places where result of string concatenation is passed to StringBuffer.append method. Using separate `.append` calls is more clear. >> 4. In few places primitives are unnecessary converted to String before `.append` call. They can be replaced with specialized methods (like `.append(int)` calls. > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8264484: Replace uses of StringBuffer with StringBuilder in jdk.hotspot.agent > > place each 'append' call on its own line Marked as reviewed by aivanov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3251 From azvegint at openjdk.java.net Thu Apr 8 15:26:18 2021 From: azvegint at openjdk.java.net (Alexander Zvegintsev) Date: Thu, 8 Apr 2021 15:26:18 GMT Subject: RFR: 8264428: Cleanup usages of StringBuffer in java.desktop [v4] In-Reply-To: References: <2y9jvm8hnBRZQIO4qwAY-C07aSQM1QIzIT6SWAj7c70=.bda3ef0d-a445-40b0-b155-3920d072cb89@github.com> Message-ID: On Thu, 8 Apr 2021 14:43:50 GMT, Andrey Turbanov wrote: >> There are few possible cleanups in java.desktop related to legacy StringBuffer usages: >> 1. In few places StringBuffer can be replaced with plain String concatenation. >> 2. StringBuffer can be replaced with StringBuilder. StringBuilder has better performance as it is not thread-safe. >> 3. There are few places where result of string concatenation is passed to StringBuffer.append method. Using separate `.append` calls is more clear. >> 4. In few places primitives are unnecessary converted to String before `.append` call. They can be replaced with specialized methods (like `.append(int)` calls. > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8264484: Replace uses of StringBuffer with StringBuilder in jdk.hotspot.agent > > place each 'append' call on its own line Marked as reviewed by azvegint (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3251 From github.com+741251+turbanoff at openjdk.java.net Thu Apr 8 21:27:14 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Thu, 8 Apr 2021 21:27:14 GMT Subject: Integrated: 8264428: Cleanup usages of StringBuffer in java.desktop In-Reply-To: <2y9jvm8hnBRZQIO4qwAY-C07aSQM1QIzIT6SWAj7c70=.bda3ef0d-a445-40b0-b155-3920d072cb89@github.com> References: <2y9jvm8hnBRZQIO4qwAY-C07aSQM1QIzIT6SWAj7c70=.bda3ef0d-a445-40b0-b155-3920d072cb89@github.com> Message-ID: On Mon, 29 Mar 2021 20:50:14 GMT, Andrey Turbanov wrote: > There are few possible cleanups in java.desktop related to legacy StringBuffer usages: > 1. In few places StringBuffer can be replaced with plain String concatenation. > 2. StringBuffer can be replaced with StringBuilder. StringBuilder has better performance as it is not thread-safe. > 3. There are few places where result of string concatenation is passed to StringBuffer.append method. Using separate `.append` calls is more clear. > 4. In few places primitives are unnecessary converted to String before `.append` call. They can be replaced with specialized methods (like `.append(int)` calls. This pull request has now been integrated. Changeset: 8a235807 Author: Andrey Turbanov Committer: Alexander Zvegintsev URL: https://git.openjdk.java.net/jdk/commit/8a235807 Stats: 48 lines in 11 files changed: 3 ins; 8 del; 37 mod 8264428: Cleanup usages of StringBuffer in java.desktop Reviewed-by: azvegint, aivanov ------------- PR: https://git.openjdk.java.net/jdk/pull/3251 From serb at openjdk.java.net Fri Apr 9 00:48:15 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Fri, 9 Apr 2021 00:48:15 GMT Subject: =?utf-8?q?RFR=3A_8264398=3A_BevelBorderUIResource?= =?utf-8?b?4oCLKGludCwgQ29sb3IsIENvbG9yKSBhbmQgQmV2ZWxCb2RlcihpbnQsIENv?= =?utf-8?q?lor=2C_Color=29_spec_should_clarify_about_usage_of_highlight_an?= =?utf-8?q?d_shadow_color_=5Bv3=5D?= In-Reply-To: References: Message-ID: <6YG2cHxAKmifaFkMFlBB-y0-HnflxTdNK4lNIyt7UEY=.c06c3d93-94d2-44d4-a435-a80a27940b93@github.com> On Thu, 8 Apr 2021 04:58:14 GMT, Prasanta Sadhukhan wrote: >> The current spec for javax/swing/plaf/BorderUIResource.BevelBorderUIResource.html(int,java.awt.Color,java.awt.Color) does not clearly specify the usage of color for hightlight and shadow as there are outer/inner hightlight and outer/inner shadow. >> Updated spec to clarify the same. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > javadoc change in BevelBorder constructor src/java.desktop/share/classes/javax/swing/border/BevelBorder.java line 89: > 87: * Creates a bevel border with the specified type, highlight and > 88: * shadow colors. > 89: * highlightOuterColor and highlightInnerColor will be derived from I think we should use just a brief text for "highlightOuterColor"/etc like in the other parts of class "the outer shadow"/"the inner shadow"/"the inner highlight" etc. Since in this particular case the highlightOuterColor is not a parameter nor a field. And please update the copyright dates. ------------- PR: https://git.openjdk.java.net/jdk/pull/3305 From psadhukhan at openjdk.java.net Fri Apr 9 03:15:39 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Fri, 9 Apr 2021 03:15:39 GMT Subject: =?utf-8?q?RFR=3A_8264398=3A_BevelBorderUIResource?= =?utf-8?b?4oCLKGludCwgQ29sb3IsIENvbG9yKSBhbmQgQmV2ZWxCb2RlcihpbnQsIENv?= =?utf-8?q?lor=2C_Color=29_spec_should_clarify_about_usage_of_highlight_an?= =?utf-8?q?d_shadow_color_=5Bv4=5D?= In-Reply-To: References: Message-ID: > The current spec for javax/swing/plaf/BorderUIResource.BevelBorderUIResource.html(int,java.awt.Color,java.awt.Color) does not clearly specify the usage of color for hightlight and shadow as there are outer/inner hightlight and outer/inner shadow. > Updated spec to clarify the same. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: javadoc change ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3305/files - new: https://git.openjdk.java.net/jdk/pull/3305/files/f5d6be5d..7605c189 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3305&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3305&range=02-03 Stats: 20 lines in 2 files changed: 12 ins; 0 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/3305.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3305/head:pull/3305 PR: https://git.openjdk.java.net/jdk/pull/3305 From psadhukhan at openjdk.java.net Fri Apr 9 03:20:43 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Fri, 9 Apr 2021 03:20:43 GMT Subject: =?utf-8?q?RFR=3A_8264398=3A_BevelBorderUIResource?= =?utf-8?b?4oCLKGludCwgQ29sb3IsIENvbG9yKSBhbmQgQmV2ZWxCb2RlcihpbnQsIENv?= =?utf-8?q?lor=2C_Color=29_spec_should_clarify_about_usage_of_highlight_an?= =?utf-8?q?d_shadow_color_=5Bv5=5D?= In-Reply-To: References: Message-ID: > The current spec for javax/swing/plaf/BorderUIResource.BevelBorderUIResource.html(int,java.awt.Color,java.awt.Color) does not clearly specify the usage of color for hightlight and shadow as there are outer/inner hightlight and outer/inner shadow. > Updated spec to clarify the same. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: javadoc change ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3305/files - new: https://git.openjdk.java.net/jdk/pull/3305/files/7605c189..4e650b0f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3305&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3305&range=03-04 Stats: 16 lines in 2 files changed: 0 ins; 8 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/3305.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3305/head:pull/3305 PR: https://git.openjdk.java.net/jdk/pull/3305 From psadhukhan at openjdk.java.net Sat Apr 10 02:59:19 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Sat, 10 Apr 2021 02:59:19 GMT Subject: =?utf-8?q?RFR=3A_8264398=3A_BevelBorderUIResource?= =?utf-8?b?4oCLKGludCwgQ29sb3IsIENvbG9yKSBhbmQgQmV2ZWxCb2RlcihpbnQsIENv?= =?utf-8?q?lor=2C_Color=29_spec_should_clarify_about_usage_of_highlight_an?= =?utf-8?q?d_shadow_color_=5Bv3=5D?= In-Reply-To: <6YG2cHxAKmifaFkMFlBB-y0-HnflxTdNK4lNIyt7UEY=.c06c3d93-94d2-44d4-a435-a80a27940b93@github.com> References: <6YG2cHxAKmifaFkMFlBB-y0-HnflxTdNK4lNIyt7UEY=.c06c3d93-94d2-44d4-a435-a80a27940b93@github.com> Message-ID: <-6iYzJZBB56EK9wQ9DIq8DbIfM24kVf8yORGuPU0EEY=.aec67340-8dd2-4966-82d6-f571c126f5d5@github.com> On Fri, 9 Apr 2021 00:44:54 GMT, Sergey Bylokhov wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: >> >> javadoc change in BevelBorder constructor > > src/java.desktop/share/classes/javax/swing/border/BevelBorder.java line 89: > >> 87: * Creates a bevel border with the specified type, highlight and >> 88: * shadow colors. >> 89: * highlightOuterColor and highlightInnerColor will be derived from > > I think we should use just a brief text for "highlightOuterColor"/etc like in the other parts of class "the outer shadow"/"the inner shadow"/"the inner highlight" etc. Since in this particular case the highlightOuterColor is not a parameter nor a field. > And please update the copyright dates. I guess I have done what is being asked. Are there any other comments? If not, can this PR and CSR be approved please? ------------- PR: https://git.openjdk.java.net/jdk/pull/3305 From dbessono at openjdk.java.net Sat Apr 10 11:26:27 2021 From: dbessono at openjdk.java.net (Dmitry Bessonov) Date: Sat, 10 Apr 2021 11:26:27 GMT Subject: =?utf-8?q?RFR=3A_8264398=3A_BevelBorderUIResource?= =?utf-8?b?4oCLKGludCwgQ29sb3IsIENvbG9yKSBhbmQgQmV2ZWxCb2RlcihpbnQsIENv?= =?utf-8?q?lor=2C_Color=29_spec_should_clarify_about_usage_of_highlight_an?= =?utf-8?q?d_shadow_color_=5Bv3=5D?= In-Reply-To: <-6iYzJZBB56EK9wQ9DIq8DbIfM24kVf8yORGuPU0EEY=.aec67340-8dd2-4966-82d6-f571c126f5d5@github.com> References: <6YG2cHxAKmifaFkMFlBB-y0-HnflxTdNK4lNIyt7UEY=.c06c3d93-94d2-44d4-a435-a80a27940b93@github.com> <-6iYzJZBB56EK9wQ9DIq8DbIfM24kVf8yORGuPU0EEY=.aec67340-8dd2-4966-82d6-f571c126f5d5@github.com> Message-ID: On Sat, 10 Apr 2021 02:56:07 GMT, Prasanta Sadhukhan wrote: >> src/java.desktop/share/classes/javax/swing/border/BevelBorder.java line 89: >> >>> 87: * Creates a bevel border with the specified type, highlight and >>> 88: * shadow colors. >>> 89: * highlightOuterColor and highlightInnerColor will be derived from >> >> I think we should use just a brief text for "highlightOuterColor"/etc like in the other parts of class "the outer shadow"/"the inner shadow"/"the inner highlight" etc. Since in this particular case the highlightOuterColor is not a parameter nor a field. >> And please update the copyright dates. > > I guess I have done what is being asked. Are there any other comments? If not, can this PR and CSR be approved please? So as per the updated version of the specification - what could be checked is that the resulting inner/outer/highlight/shadow colors should be either: - equal to the passed - ::brighter() than the passed - darker() than the passed ? ------------- PR: https://git.openjdk.java.net/jdk/pull/3305 From psadhukhan at openjdk.java.net Sat Apr 10 11:43:30 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Sat, 10 Apr 2021 11:43:30 GMT Subject: =?utf-8?q?RFR=3A_8264398=3A_BevelBorderUIResource?= =?utf-8?b?4oCLKGludCwgQ29sb3IsIENvbG9yKSBhbmQgQmV2ZWxCb2RlcihpbnQsIENv?= =?utf-8?q?lor=2C_Color=29_spec_should_clarify_about_usage_of_highlight_an?= =?utf-8?q?d_shadow_color_=5Bv3=5D?= In-Reply-To: References: <6YG2cHxAKmifaFkMFlBB-y0-HnflxTdNK4lNIyt7UEY=.c06c3d93-94d2-44d4-a435-a80a27940b93@github.com> <-6iYzJZBB56EK9wQ9DIq8DbIfM24kVf8yORGuPU0EEY=.aec67340-8dd2-4966-82d6-f571c126f5d5@github.com> Message-ID: On Sat, 10 Apr 2021 11:23:42 GMT, Dmitry Bessonov wrote: >> I guess I have done what is being asked. Are there any other comments? If not, can this PR and CSR be approved please? > > So as per the updated version of the specification - what could be checked is that the resulting inner/outer/highlight/shadow colors should be either: > - equal to the passed > - ::brighter() than the passed > - darker() than the passed > ? Yes, the passed highlight and shadow color to the constructor would be equal to getHighlightInnerColor(), getShadowOuterColor but again this is for our jdk implementation. As told in the JBS, these are implementation details which should hold true if JDK's BevelBorder class is in use but some other JDK can override the class and can give its own implementation as the class is not 'final'. ------------- PR: https://git.openjdk.java.net/jdk/pull/3305 From serb at openjdk.java.net Sat Apr 10 20:34:32 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Sat, 10 Apr 2021 20:34:32 GMT Subject: =?utf-8?q?RFR=3A_8264398=3A_BevelBorderUIResource?= =?utf-8?b?4oCLKGludCwgQ29sb3IsIENvbG9yKSBhbmQgQmV2ZWxCb2RlcihpbnQsIENv?= =?utf-8?q?lor=2C_Color=29_spec_should_clarify_about_usage_of_highlight_an?= =?utf-8?q?d_shadow_color_=5Bv5=5D?= In-Reply-To: References: Message-ID: On Fri, 9 Apr 2021 03:20:43 GMT, Prasanta Sadhukhan wrote: >> The current spec for javax/swing/plaf/BorderUIResource.BevelBorderUIResource.html(int,java.awt.Color,java.awt.Color) does not clearly specify the usage of color for hightlight and shadow as there are outer/inner hightlight and outer/inner shadow. >> Updated spec to clarify the same. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > javadoc change src/java.desktop/share/classes/javax/swing/border/BevelBorder.java line 94: > 92: * bevel outer shadow color > 93: * and bevel inner shadow color > 94: * will be derived from specified shadow color. It mostly looks fine, but probably we may reformat it better than 55 chars per line. ------------- PR: https://git.openjdk.java.net/jdk/pull/3305 From psadhukhan at openjdk.java.net Mon Apr 12 04:18:22 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Mon, 12 Apr 2021 04:18:22 GMT Subject: =?utf-8?q?RFR=3A_8264398=3A_BevelBorderUIResource?= =?utf-8?b?4oCLKGludCwgQ29sb3IsIENvbG9yKSBhbmQgQmV2ZWxCb2RlcihpbnQsIENv?= =?utf-8?q?lor=2C_Color=29_spec_should_clarify_about_usage_of_highlight_an?= =?utf-8?q?d_shadow_color_=5Bv6=5D?= In-Reply-To: References: Message-ID: > The current spec for javax/swing/plaf/BorderUIResource.BevelBorderUIResource.html(int,java.awt.Color,java.awt.Color) does not clearly specify the usage of color for hightlight and shadow as there are outer/inner hightlight and outer/inner shadow. > Updated spec to clarify the same. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Formatting ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3305/files - new: https://git.openjdk.java.net/jdk/pull/3305/files/4e650b0f..f0d98111 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3305&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3305&range=04-05 Stats: 10 lines in 2 files changed: 0 ins; 4 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/3305.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3305/head:pull/3305 PR: https://git.openjdk.java.net/jdk/pull/3305 From psadhukhan at openjdk.java.net Mon Apr 12 04:18:23 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Mon, 12 Apr 2021 04:18:23 GMT Subject: =?utf-8?q?RFR=3A_8264398=3A_BevelBorderUIResource?= =?utf-8?b?4oCLKGludCwgQ29sb3IsIENvbG9yKSBhbmQgQmV2ZWxCb2RlcihpbnQsIENv?= =?utf-8?q?lor=2C_Color=29_spec_should_clarify_about_usage_of_highlight_an?= =?utf-8?q?d_shadow_color_=5Bv5=5D?= In-Reply-To: References: Message-ID: On Sat, 10 Apr 2021 20:30:53 GMT, Sergey Bylokhov wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: >> >> javadoc change > > src/java.desktop/share/classes/javax/swing/border/BevelBorder.java line 94: > >> 92: * bevel outer shadow color >> 93: * and bevel inner shadow color >> 94: * will be derived from specified shadow color. > > It mostly looks fine, but probably we may reformat it better than 55 chars per line. Done ------------- PR: https://git.openjdk.java.net/jdk/pull/3305 From serb at openjdk.java.net Mon Apr 12 20:55:07 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Mon, 12 Apr 2021 20:55:07 GMT Subject: =?utf-8?q?RFR=3A_8264398=3A_BevelBorderUIResource?= =?utf-8?b?4oCLKGludCwgQ29sb3IsIENvbG9yKSBhbmQgQmV2ZWxCb2RlcihpbnQsIENv?= =?utf-8?q?lor=2C_Color=29_spec_should_clarify_about_usage_of_highlight_an?= =?utf-8?q?d_shadow_color_=5Bv6=5D?= In-Reply-To: References: Message-ID: On Mon, 12 Apr 2021 04:18:22 GMT, Prasanta Sadhukhan wrote: >> The current spec for javax/swing/plaf/BorderUIResource.BevelBorderUIResource.html(int,java.awt.Color,java.awt.Color) does not clearly specify the usage of color for hightlight and shadow as there are outer/inner hightlight and outer/inner shadow. >> Updated spec to clarify the same. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Formatting Marked as reviewed by serb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3305 From psadhukhan at openjdk.java.net Tue Apr 13 09:25:01 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Tue, 13 Apr 2021 09:25:01 GMT Subject: =?utf-8?q?RFR=3A_8264398=3A_BevelBorderUIResource?= =?utf-8?b?4oCLKGludCwgQ29sb3IsIENvbG9yKSBhbmQgQmV2ZWxCb2RlcihpbnQsIENv?= =?utf-8?q?lor=2C_Color=29_spec_should_clarify_about_usage_of_highlight_an?= =?utf-8?q?d_shadow_color_=5Bv6=5D?= In-Reply-To: References: Message-ID: On Mon, 12 Apr 2021 04:18:22 GMT, Prasanta Sadhukhan wrote: >> The current spec for javax/swing/plaf/BorderUIResource.BevelBorderUIResource.html(int,java.awt.Color,java.awt.Color) does not clearly specify the usage of color for hightlight and shadow as there are outer/inner hightlight and outer/inner shadow. >> Updated spec to clarify the same. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Formatting Please have a look at the CSR too https://bugs.openjdk.java.net/browse/JDK-8264706 ------------- PR: https://git.openjdk.java.net/jdk/pull/3305 From azvegint at openjdk.java.net Tue Apr 13 19:37:07 2021 From: azvegint at openjdk.java.net (Alexander Zvegintsev) Date: Tue, 13 Apr 2021 19:37:07 GMT Subject: RFR: 8075915: The eight controls without black backgrounds with WinLAF & GTK LAF & Nimbus LAF Message-ID: This manual test was written for Metal L&F, so now it is set explicitly. Test is also refactored to use JFrame instead of Applet. The test is not in `ProblemList.txt`. It still fails on JDK 1.5 (after removing all syntactic sugar). ------------- Commit messages: - trailing whitespaces fix - instructions update - initial Changes: https://git.openjdk.java.net/jdk/pull/3474/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3474&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8075915 Stats: 187 lines in 2 files changed: 77 ins; 63 del; 47 mod Patch: https://git.openjdk.java.net/jdk/pull/3474.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3474/head:pull/3474 PR: https://git.openjdk.java.net/jdk/pull/3474 From aivanov at openjdk.java.net Tue Apr 13 20:18:04 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Tue, 13 Apr 2021 20:18:04 GMT Subject: RFR: 8075915: The eight controls without black backgrounds with WinLAF & GTK LAF & Nimbus LAF In-Reply-To: References: Message-ID: <6flLPl9TSAkaz_fvhskHTB3CNAullFhUdoETrmHZkL8=.2b11ee12-a38e-461c-a17f-2409906544ce@github.com> On Tue, 13 Apr 2021 19:24:43 GMT, Alexander Zvegintsev wrote: > This manual test was written for Metal L&F, so now it is set explicitly. > Test is also refactored to use JFrame instead of Applet. > > The test is not in `ProblemList.txt`. > It still fails on JDK 1.5 (after removing all syntactic sugar). test/jdk/javax/swing/JCheckBox/4449413/bug4449413.java line 87: > 85: if (timeoutHappened || failed) { > 86: throw new RuntimeException("Test failed!"); > 87: } Shall the test dispose of the frame if it times out? ------------- PR: https://git.openjdk.java.net/jdk/pull/3474 From azvegint at openjdk.java.net Wed Apr 14 00:33:22 2021 From: azvegint at openjdk.java.net (Alexander Zvegintsev) Date: Wed, 14 Apr 2021 00:33:22 GMT Subject: RFR: 8075915: The eight controls without black backgrounds with WinLAF & GTK LAF & Nimbus LAF [v2] In-Reply-To: References: Message-ID: <-TbqVkPOTJ4vbQEpsY6eyMF4vGO9tMTVP79NNQQoyDo=.c0f38b30-922b-4f65-971c-c062948c5cc0@github.com> > This manual test was written for Metal L&F, so now it is set explicitly. > Test is also refactored to use JFrame instead of Applet. > > The test is not in `ProblemList.txt`. > It still fails on JDK 1.5 (after removing all syntactic sugar). Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: Tuned for standalone mode. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3474/files - new: https://git.openjdk.java.net/jdk/pull/3474/files/4a8b55a1..6c7457d3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3474&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3474&range=00-01 Stats: 22 lines in 1 file changed: 19 ins; 2 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3474.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3474/head:pull/3474 PR: https://git.openjdk.java.net/jdk/pull/3474 From azvegint at openjdk.java.net Wed Apr 14 00:33:23 2021 From: azvegint at openjdk.java.net (Alexander Zvegintsev) Date: Wed, 14 Apr 2021 00:33:23 GMT Subject: RFR: 8075915: The eight controls without black backgrounds with WinLAF & GTK LAF & Nimbus LAF [v2] In-Reply-To: <6flLPl9TSAkaz_fvhskHTB3CNAullFhUdoETrmHZkL8=.2b11ee12-a38e-461c-a17f-2409906544ce@github.com> References: <6flLPl9TSAkaz_fvhskHTB3CNAullFhUdoETrmHZkL8=.2b11ee12-a38e-461c-a17f-2409906544ce@github.com> Message-ID: On Tue, 13 Apr 2021 20:14:46 GMT, Alexey Ivanov wrote: >> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: >> >> Tuned for standalone mode. > > test/jdk/javax/swing/JCheckBox/4449413/bug4449413.java line 87: > >> 85: if (timeoutHappened || failed) { >> 86: throw new RuntimeException("Test failed!"); >> 87: } > > Shall the test dispose of the frame if it times out? Actually `jtreg` handles it. But I've updated the test to support standalone mode. ------------- PR: https://git.openjdk.java.net/jdk/pull/3474 From psadhukhan at openjdk.java.net Wed Apr 14 06:48:06 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Wed, 14 Apr 2021 06:48:06 GMT Subject: RFR: 8075915: The eight controls without black backgrounds with WinLAF & GTK LAF & Nimbus LAF [v2] In-Reply-To: <-TbqVkPOTJ4vbQEpsY6eyMF4vGO9tMTVP79NNQQoyDo=.c0f38b30-922b-4f65-971c-c062948c5cc0@github.com> References: <-TbqVkPOTJ4vbQEpsY6eyMF4vGO9tMTVP79NNQQoyDo=.c0f38b30-922b-4f65-971c-c062948c5cc0@github.com> Message-ID: On Wed, 14 Apr 2021 00:33:22 GMT, Alexander Zvegintsev wrote: >> This manual test was written for Metal L&F, so now it is set explicitly. >> Test is also refactored to use JFrame instead of Applet. >> >> The test is not in `ProblemList.txt`. >> It still fails on JDK 1.5 (after removing all syntactic sugar). > > Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: > > Tuned for standalone mode. ![image](https://user-images.githubusercontent.com/43534309/114665616-e1ec4380-9d1a-11eb-851f-937ca72d9c4f.png) I see RadioButton and RBMenuItem check mark is not visible...so probably there is still a product bug somewhere...I guess we need to fix that as well when we fix this test.. ------------- PR: https://git.openjdk.java.net/jdk/pull/3474 From psadhukhan at openjdk.java.net Wed Apr 14 12:19:14 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Wed, 14 Apr 2021 12:19:14 GMT Subject: RFR: 8263970: Manual test javax/swing/JTextField/JapaneseReadingAttributes/JapaneseReadingAttributes.java failed Message-ID: Modified test instruction to point that IME option is supposed to be "Full width Katakana" for the test to pass which by default was picking up "Half width Alphanumeric" english style input IME option. ------------- Commit messages: - 8263970: Manual test javax/swing/JTextField/JapaneseReadingAttributes/JapaneseReadingAttributes.java failed Changes: https://git.openjdk.java.net/jdk/pull/3489/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3489&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263970 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3489.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3489/head:pull/3489 PR: https://git.openjdk.java.net/jdk/pull/3489 From azvegint at openjdk.java.net Wed Apr 14 12:34:18 2021 From: azvegint at openjdk.java.net (Alexander Zvegintsev) Date: Wed, 14 Apr 2021 12:34:18 GMT Subject: RFR: 8075915: The eight controls without black backgrounds with WinLAF & GTK LAF & Nimbus LAF [v2] In-Reply-To: References: <-TbqVkPOTJ4vbQEpsY6eyMF4vGO9tMTVP79NNQQoyDo=.c0f38b30-922b-4f65-971c-c062948c5cc0@github.com> Message-ID: On Wed, 14 Apr 2021 06:45:16 GMT, Prasanta Sadhukhan wrote: > I see RadioButton and RBMenuItem check mark is not visible...so probably there is still a product bug somewhere...I guess we need to fix that as well when we fix this test.. Actually it is clearly visible. You can click on it to see the difference between checked/unchecked state. Probably you are referring to a circle shape of "check mark", but that is correct shape. Here is a comparison of JDK17 vs JDK5 (all components are in selected state). JDK17 ![image](https://user-images.githubusercontent.com/77687766/114709437-3dc3c600-9d35-11eb-8d99-955ab72f9fb4.png) JDK5 ![image](https://user-images.githubusercontent.com/77687766/114709449-41efe380-9d35-11eb-96a3-e025ddc17528.png) JDK17 ![image](https://user-images.githubusercontent.com/77687766/114709471-4a481e80-9d35-11eb-9bb2-9281d6c7a4c4.png) JDK5 ![image](https://user-images.githubusercontent.com/77687766/114709483-4f0cd280-9d35-11eb-9602-1104277581f7.png) JDK5 clearly failed this test. ------------- PR: https://git.openjdk.java.net/jdk/pull/3474 From psadhukhan at openjdk.java.net Wed Apr 14 12:46:07 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Wed, 14 Apr 2021 12:46:07 GMT Subject: RFR: 8075915: The eight controls without black backgrounds with WinLAF & GTK LAF & Nimbus LAF [v2] In-Reply-To: <-TbqVkPOTJ4vbQEpsY6eyMF4vGO9tMTVP79NNQQoyDo=.c0f38b30-922b-4f65-971c-c062948c5cc0@github.com> References: <-TbqVkPOTJ4vbQEpsY6eyMF4vGO9tMTVP79NNQQoyDo=.c0f38b30-922b-4f65-971c-c062948c5cc0@github.com> Message-ID: On Wed, 14 Apr 2021 00:33:22 GMT, Alexander Zvegintsev wrote: >> This manual test was written for Metal L&F, so now it is set explicitly. >> Test is also refactored to use JFrame instead of Applet. >> >> The test is not in `ProblemList.txt`. >> It still fails on JDK 1.5 (after removing all syntactic sugar). > > Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: > > Tuned for standalone mode. I am referring to check mark only, not the shape...I could see the white visible selected checkmark(circular) for RadioButton when "Ocean Theme" is not selected but when "Ocean Theme" is selected, black checkmark over black background is not visible. Also, the original bug 4449413 does not talk about Metal. It seems the issue is seen only in Metal but that should not prevent us from running in all L&Fs. ------------- PR: https://git.openjdk.java.net/jdk/pull/3474 From azvegint at openjdk.java.net Wed Apr 14 12:51:19 2021 From: azvegint at openjdk.java.net (Alexander Zvegintsev) Date: Wed, 14 Apr 2021 12:51:19 GMT Subject: RFR: 8263970: Manual test javax/swing/JTextField/JapaneseReadingAttributes/JapaneseReadingAttributes.java failed In-Reply-To: References: Message-ID: On Wed, 14 Apr 2021 12:12:59 GMT, Prasanta Sadhukhan wrote: > Modified test instruction to point that IME option is supposed to be "Full width Katakana" for the test to pass which by default was picking up "Half width Alphanumeric" english style input IME option. Marked as reviewed by azvegint (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3489 From psadhukhan at openjdk.java.net Wed Apr 14 13:14:10 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Wed, 14 Apr 2021 13:14:10 GMT Subject: Integrated: 8263970: Manual test javax/swing/JTextField/JapaneseReadingAttributes/JapaneseReadingAttributes.java failed In-Reply-To: References: Message-ID: <7yw8yDEO5o-HDi10GE0IK0VUNq23-67MB9qVc-M-9T8=.6e269fb6-a7cc-4b71-aa6e-383b42c7316f@github.com> On Wed, 14 Apr 2021 12:12:59 GMT, Prasanta Sadhukhan wrote: > Modified test instruction to point that IME option is supposed to be "Full width Katakana" for the test to pass which by default was picking up "Half width Alphanumeric" english style input IME option. This pull request has now been integrated. Changeset: 75b039a4 Author: Prasanta Sadhukhan URL: https://git.openjdk.java.net/jdk/commit/75b039a4 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8263970: Manual test javax/swing/JTextField/JapaneseReadingAttributes/JapaneseReadingAttributes.java failed Reviewed-by: azvegint ------------- PR: https://git.openjdk.java.net/jdk/pull/3489 From azvegint at openjdk.java.net Wed Apr 14 20:43:53 2021 From: azvegint at openjdk.java.net (Alexander Zvegintsev) Date: Wed, 14 Apr 2021 20:43:53 GMT Subject: RFR: 8075915: The eight controls without black backgrounds with WinLAF & GTK LAF & Nimbus LAF [v3] In-Reply-To: References: Message-ID: > This manual test was written for Metal L&F, so now it is set explicitly. > Test is also refactored to use JFrame instead of Applet. > > The test is not in `ProblemList.txt`. > It still fails on JDK 1.5 (after removing all syntactic sugar). Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: allow to run it with different L&F ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3474/files - new: https://git.openjdk.java.net/jdk/pull/3474/files/6c7457d3..f804ee19 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3474&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3474&range=01-02 Stats: 30 lines in 1 file changed: 15 ins; 3 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/3474.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3474/head:pull/3474 PR: https://git.openjdk.java.net/jdk/pull/3474 From azvegint at openjdk.java.net Wed Apr 14 20:43:53 2021 From: azvegint at openjdk.java.net (Alexander Zvegintsev) Date: Wed, 14 Apr 2021 20:43:53 GMT Subject: RFR: 8075915: The eight controls without black backgrounds with WinLAF & GTK LAF & Nimbus LAF [v2] In-Reply-To: References: <-TbqVkPOTJ4vbQEpsY6eyMF4vGO9tMTVP79NNQQoyDo=.c0f38b30-922b-4f65-971c-c062948c5cc0@github.com> Message-ID: On Wed, 14 Apr 2021 12:43:38 GMT, Prasanta Sadhukhan wrote: > I am referring to check mark only, not the shape...I could see the white visible selected checkmark(circular) for RadioButton when "Ocean Theme" is not selected but when "Ocean Theme" is selected, black checkmark over black background is not visible. > This black check mark does have a light colored halo around which helps to see it. Here is an example of radio button usage in group: ![image](https://user-images.githubusercontent.com/77687766/114772901-083fcc80-9d77-11eb-8f15-a3218aedc6fe.png) I definitely can see which one is selected. So I do not see issue here. > Also, the original bug 4449413 does not talk about Metal. It seems the issue is seen only in Metal but that should not prevent us from running in all L&Fs. Updated to allow it to run with other L&Fs. Please see below screenshots with other L&Fs applied. Some of them controversial, but I prefer to file a new bugs for them if any. ![image](https://user-images.githubusercontent.com/77687766/114774723-227aaa00-9d79-11eb-8714-61f718460f02.png) ![image](https://user-images.githubusercontent.com/77687766/114775115-9d43c500-9d79-11eb-8f2b-a4df86849f0c.png) ![image](https://user-images.githubusercontent.com/77687766/114775187-b2205880-9d79-11eb-99e3-c2e7a7f5b892.png) ![image](https://user-images.githubusercontent.com/77687766/114775242-c2383800-9d79-11eb-9427-b650e317806e.png) ![image](https://user-images.githubusercontent.com/77687766/114775276-cc5a3680-9d79-11eb-8ef4-f99122f4174f.png) (Labels for disabled text is not visible, but MotifLookAndFeel is marked for removal, so probably it is not worth to fix it.) ------------- PR: https://git.openjdk.java.net/jdk/pull/3474 From psadhukhan at openjdk.java.net Thu Apr 15 09:55:34 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Thu, 15 Apr 2021 09:55:34 GMT Subject: RFR: 8075915: The eight controls without black backgrounds with WinLAF & GTK LAF & Nimbus LAF [v3] In-Reply-To: References: Message-ID: On Wed, 14 Apr 2021 20:43:53 GMT, Alexander Zvegintsev wrote: >> This manual test was written for Metal L&F, so now it is set explicitly. >> Test is also refactored to use JFrame instead of Applet. >> >> The test is not in `ProblemList.txt`. >> It still fails on JDK 1.5 (after removing all syntactic sugar). > > Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: > > allow to run it with different L&F test/jdk/javax/swing/JCheckBox/4449413/bug4449413.java line 191: > 189: }; > 190: > 191: b.setOpaque(true); Any reason why this setOpaque was added? I am of the opinion that it should get controlled either by LookAndFeel.installProperty or by component's constructor. ------------- PR: https://git.openjdk.java.net/jdk/pull/3474 From pbansal at openjdk.java.net Thu Apr 15 11:49:37 2021 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Thu, 15 Apr 2021 11:49:37 GMT Subject: Integrated: 8262981: Create implementation for NSAccessibilitySlider protocol In-Reply-To: References: Message-ID: On Mon, 8 Mar 2021 12:51:56 GMT, Pankaj Bansal wrote: > Create implementation of NSAccessibilitySlider protocol https://developer.apple.com/documentation/appkit/nsaccessibilityslider > > The implementation has the function performIncrement and performDecrement to increase/decrease the value of slider using the VoiceOver. To implement this functionality, I could think of following two ways. I have chosen the first one here though it is more intrusive. > 1. Make the AccessibleJSlider class implement the AccessibleAction interface. This makes AccessibleJSlider consistent with the AccessibleJSpinner class. It is more clear and the logic to increase/decrease Slider value can be changed easily. But this changes AccessibleJSlider class and will need a CSR. > 2. Get the current Accessible Value from the component and just increment/decrement it in SliderAccessibility.m class itself and then set the current accessible value fro there only. This will not need any changes in AccessibleJSlider class, but this does not look correct way and I have not used this. > > The changes can be easily tested by using a JSlider example, like the following example. VO should announce the correct the slider values. To change the slider values, use ctrl+opt+shift+down key to start interacting with the slider, then use ctrl+opt+up/down arrow keys to increment/decrement slider values. > > import javax.swing.JFrame; > import javax.swing.JSlider; > > public class JSliderDemo{ > public static void main(String[] args) throws Exception { > JFrame jframe = new JFrame("JSlider Demo"); > jframe.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); > jframe.add(new JSlider()); > > jframe.setLocationRelativeTo(null); > jframe.pack(); > jframe.setVisible(true); > } > } This pull request has now been integrated. Changeset: 9d669c91 Author: Pankaj Bansal URL: https://git.openjdk.java.net/jdk/commit/9d669c91 Stats: 75 lines in 4 files changed: 68 ins; 1 del; 6 mod 8262981: Create implementation for NSAccessibilitySlider protocol Reviewed-by: kizune ------------- PR: https://git.openjdk.java.net/jdk/pull/2874 From azvegint at openjdk.java.net Thu Apr 15 13:21:35 2021 From: azvegint at openjdk.java.net (Alexander Zvegintsev) Date: Thu, 15 Apr 2021 13:21:35 GMT Subject: RFR: 8075915: The eight controls without black backgrounds with WinLAF & GTK LAF & Nimbus LAF [v3] In-Reply-To: References: Message-ID: On Thu, 15 Apr 2021 09:39:12 GMT, Prasanta Sadhukhan wrote: >> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: >> >> allow to run it with different L&F > > test/jdk/javax/swing/JCheckBox/4449413/bug4449413.java line 191: > >> 189: }; >> 190: >> 191: b.setOpaque(true); > > Any reason why this setOpaque was added? I am of the opinion that it should get controlled either by LookAndFeel.installProperty or by component's constructor. The reason is in `JComponent#setBackground()` [javadoc](https://docs.oracle.com/en/java/javase/15/docs/api/java.desktop/javax/swing/JComponent.html#setBackground(java.awt.Color)) > Sets the background color of this component. The background color is used only if the component is opaque, and only by subclasses of JComponent or ComponentUI implementations. Direct subclasses of JComponent must override paintComponent to honor this property. > > It is up to the look and feel to honor this property, some may choose to ignore it. ------------- PR: https://git.openjdk.java.net/jdk/pull/3474 From pbansal at openjdk.java.net Thu Apr 15 13:58:55 2021 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Thu, 15 Apr 2021 13:58:55 GMT Subject: RFR: 8265278: doc build fails after JDK-8262981 Message-ID: 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" ------------- Commit messages: - Fix the param name Changes: https://git.openjdk.java.net/jdk/pull/3518/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3518&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265278 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/3518.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3518/head:pull/3518 PR: https://git.openjdk.java.net/jdk/pull/3518 From trebari at openjdk.java.net Thu Apr 15 14:04:35 2021 From: trebari at openjdk.java.net (Tejpal Rebari) Date: Thu, 15 Apr 2021 14:04:35 GMT Subject: RFR: 8265278: doc build fails after JDK-8262981 In-Reply-To: References: Message-ID: 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 From jdv at openjdk.java.net Thu Apr 15 14:04:34 2021 From: jdv at openjdk.java.net (Jayathirth D V) Date: Thu, 15 Apr 2021 14:04:34 GMT Subject: RFR: 8265278: doc build fails after JDK-8262981 In-Reply-To: References: Message-ID: 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 jdv (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3518 From pbansal at openjdk.java.net Thu Apr 15 14:07:39 2021 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Thu, 15 Apr 2021 14:07:39 GMT Subject: Integrated: 8265278: doc build fails after JDK-8262981 In-Reply-To: References: Message-ID: <8VaWTcrPlhDeUutSAH0eZBc6IzukwDJMI2xSYoXMJNY=.98468343-199e-41e5-b2b6-50334260a5a2@github.com> 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" This pull request has now been integrated. Changeset: 6b907155 Author: Pankaj Bansal URL: https://git.openjdk.java.net/jdk/commit/6b907155 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod 8265278: doc build fails after JDK-8262981 Reviewed-by: jdv, trebari ------------- PR: https://git.openjdk.java.net/jdk/pull/3518 From psadhukhan at openjdk.java.net Thu Apr 15 15:28:54 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Thu, 15 Apr 2021 15:28:54 GMT Subject: RFR: 8075915: The eight controls without black backgrounds with WinLAF & GTK LAF & Nimbus LAF [v3] In-Reply-To: References: Message-ID: On Wed, 14 Apr 2021 20:43:53 GMT, Alexander Zvegintsev wrote: >> This manual test was written for Metal L&F, so now it is set explicitly. >> Test is also refactored to use JFrame instead of Applet. >> >> The test is not in `ProblemList.txt`. >> It still fails on JDK 1.5 (after removing all syntactic sugar). > > Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: > > allow to run it with different L&F Marked as reviewed by psadhukhan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3474 From azvegint at openjdk.java.net Thu Apr 15 22:25:05 2021 From: azvegint at openjdk.java.net (Alexander Zvegintsev) Date: Thu, 15 Apr 2021 22:25:05 GMT Subject: RFR: 8075915: The eight controls without black backgrounds with WinLAF & GTK LAF & Nimbus LAF [v4] In-Reply-To: References: Message-ID: > This manual test was written for Metal L&F, so now it is set explicitly. > Test is also refactored to use JFrame instead of Applet. > > The test is not in `ProblemList.txt`. > It still fails on JDK 1.5 (after removing all syntactic sugar). Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: trailing whitespace ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3474/files - new: https://git.openjdk.java.net/jdk/pull/3474/files/f804ee19..86c154a2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3474&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3474&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3474.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3474/head:pull/3474 PR: https://git.openjdk.java.net/jdk/pull/3474 From psadhukhan at openjdk.java.net Fri Apr 16 06:59:54 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Fri, 16 Apr 2021 06:59:54 GMT Subject: RFR: 8199079: Test javax/swing/UIDefaults/6302464/bug6302464.java is unstable Message-ID: This test was marked as unstable in CI run in samevm mode but later on was found passing in now-default othervm mode but was problemlisted only on macos by JDK-8254976. It is found that this test started failing in macos due to JDK-8220150: [macos] macos10.14 Mojave returns anti-aliased glyphs instead of aliased B&W glyphs which turns Antialias hint even if it is set to off from macosx10.14 onwards. So, this test started failing when it tries to test Antialias OFF hint. Proposed fix is to check for macosx 10.14 and greater version and bail out from this subtest. @prrace Can you please take a look? ------------- Commit messages: - 8199079: Test javax/swing/UIDefaults/6302464/bug6302464.java is unstable Changes: https://git.openjdk.java.net/jdk/pull/3537/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3537&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8199079 Stats: 26 lines in 2 files changed: 18 ins; 1 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/3537.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3537/head:pull/3537 PR: https://git.openjdk.java.net/jdk/pull/3537 From kizune at openjdk.java.net Fri Apr 16 10:02:06 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Fri, 16 Apr 2021 10:02:06 GMT Subject: 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. Message-ID: 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. ------------- Commit messages: - 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. Changes: https://git.openjdk.java.net/jdk/pull/3541/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3541&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8039270 Stats: 184 lines in 2 files changed: 184 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3541.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3541/head:pull/3541 PR: https://git.openjdk.java.net/jdk/pull/3541 From trebari at openjdk.java.net Fri Apr 16 10:16:36 2021 From: trebari at openjdk.java.net (Tejpal Rebari) Date: Fri, 16 Apr 2021 10:16:36 GMT Subject: 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. In-Reply-To: References: Message-ID: 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 From kizune at openjdk.java.net Fri Apr 16 10:30:41 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Fri, 16 Apr 2021 10:30:41 GMT Subject: 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. In-Reply-To: References: Message-ID: On Fri, 16 Apr 2021 10:13:37 GMT, Tejpal Rebari wrote: > Should we also remove the deprecated JApplet from the test ? Once we decide how to properly deal with all the applet-based tests they will be converted into application-type tests but for now it is outside of the scope of this fix. ------------- PR: https://git.openjdk.java.net/jdk/pull/3541 From kizune at openjdk.java.net Fri Apr 16 10:46:36 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Fri, 16 Apr 2021 10:46:36 GMT Subject: RFR: 8075915: The eight controls without black backgrounds with WinLAF & GTK LAF & Nimbus LAF [v4] In-Reply-To: References: Message-ID: On Thu, 15 Apr 2021 22:25:05 GMT, Alexander Zvegintsev wrote: >> This manual test was written for Metal L&F, so now it is set explicitly. >> Test is also refactored to use JFrame instead of Applet. >> >> The test is not in `ProblemList.txt`. >> It still fails on JDK 1.5 (after removing all syntactic sugar). > > Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: > > trailing whitespace Marked as reviewed by kizune (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3474 From aivanov at openjdk.java.net Fri Apr 16 11:20:37 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Fri, 16 Apr 2021 11:20:37 GMT Subject: RFR: 8075915: The eight controls without black backgrounds with WinLAF & GTK LAF & Nimbus LAF [v4] In-Reply-To: References: Message-ID: <_DC49wCYV6yjBFCvO1w5a7iZRa_FZ7jpRKXVZHIyt2o=.484e9b56-69cb-4118-9c47-4cf33b7d62ac@github.com> On Thu, 15 Apr 2021 22:25:05 GMT, Alexander Zvegintsev wrote: >> This manual test was written for Metal L&F, so now it is set explicitly. >> Test is also refactored to use JFrame instead of Applet. >> >> The test is not in `ProblemList.txt`. >> It still fails on JDK 1.5 (after removing all syntactic sugar). > > Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: > > trailing whitespace Changes requested by aivanov (Reviewer). test/jdk/javax/swing/JCheckBox/4449413/bug4449413.java line 96: > 94: if (instance != null) { > 95: instance.dispose(); > 96: } This should be wrapped into `invokeAndWait`. ------------- PR: https://git.openjdk.java.net/jdk/pull/3474 From azvegint at openjdk.java.net Fri Apr 16 13:54:06 2021 From: azvegint at openjdk.java.net (Alexander Zvegintsev) Date: Fri, 16 Apr 2021 13:54:06 GMT Subject: RFR: 8075915: The eight controls without black backgrounds with WinLAF & GTK LAF & Nimbus LAF [v4] In-Reply-To: <_DC49wCYV6yjBFCvO1w5a7iZRa_FZ7jpRKXVZHIyt2o=.484e9b56-69cb-4118-9c47-4cf33b7d62ac@github.com> References: <_DC49wCYV6yjBFCvO1w5a7iZRa_FZ7jpRKXVZHIyt2o=.484e9b56-69cb-4118-9c47-4cf33b7d62ac@github.com> Message-ID: On Fri, 16 Apr 2021 11:17:05 GMT, Alexey Ivanov wrote: >> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: >> >> trailing whitespace > > test/jdk/javax/swing/JCheckBox/4449413/bug4449413.java line 96: > >> 94: if (instance != null) { >> 95: instance.dispose(); >> 96: } > > This should be wrapped into `invokeAndWait`. Sure, fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/3474 From azvegint at openjdk.java.net Fri Apr 16 13:54:05 2021 From: azvegint at openjdk.java.net (Alexander Zvegintsev) Date: Fri, 16 Apr 2021 13:54:05 GMT Subject: RFR: 8075915: The eight controls without black backgrounds with WinLAF & GTK LAF & Nimbus LAF [v5] In-Reply-To: References: Message-ID: <5dV2BZx1AKcaxLcM1uYmi2rIID4NpgQLHm3u78GaIUY=.cf1f9abe-9076-43b7-b4ee-accc06587187@github.com> > This manual test was written for Metal L&F, so now it is set explicitly. > Test is also refactored to use JFrame instead of Applet. > > The test is not in `ProblemList.txt`. > It still fails on JDK 1.5 (after removing all syntactic sugar). Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: text block replaced with string literal. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3474/files - new: https://git.openjdk.java.net/jdk/pull/3474/files/86c154a2..e46bd17a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3474&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3474&range=03-04 Stats: 6 lines in 1 file changed: 3 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/3474.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3474/head:pull/3474 PR: https://git.openjdk.java.net/jdk/pull/3474 From azvegint at openjdk.java.net Fri Apr 16 14:14:11 2021 From: azvegint at openjdk.java.net (Alexander Zvegintsev) Date: Fri, 16 Apr 2021 14:14:11 GMT Subject: RFR: 8075915: The eight controls without black backgrounds with WinLAF & GTK LAF & Nimbus LAF [v6] In-Reply-To: References: Message-ID: > This manual test was written for Metal L&F, so now it is set explicitly. > Test is also refactored to use JFrame instead of Applet. > > The test is not in `ProblemList.txt`. > It still fails on JDK 1.5 (after removing all syntactic sugar). Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: text block replaced with string literal. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3474/files - new: https://git.openjdk.java.net/jdk/pull/3474/files/e46bd17a..ad54c65f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3474&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3474&range=04-05 Stats: 16 lines in 1 file changed: 2 ins; 5 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/3474.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3474/head:pull/3474 PR: https://git.openjdk.java.net/jdk/pull/3474 From azvegint at openjdk.java.net Fri Apr 16 14:14:12 2021 From: azvegint at openjdk.java.net (Alexander Zvegintsev) Date: Fri, 16 Apr 2021 14:14:12 GMT Subject: RFR: 8075915: The eight controls without black backgrounds with WinLAF & GTK LAF & Nimbus LAF [v5] In-Reply-To: <5dV2BZx1AKcaxLcM1uYmi2rIID4NpgQLHm3u78GaIUY=.cf1f9abe-9076-43b7-b4ee-accc06587187@github.com> References: <5dV2BZx1AKcaxLcM1uYmi2rIID4NpgQLHm3u78GaIUY=.cf1f9abe-9076-43b7-b4ee-accc06587187@github.com> Message-ID: On Fri, 16 Apr 2021 13:54:05 GMT, Alexander Zvegintsev wrote: >> This manual test was written for Metal L&F, so now it is set explicitly. >> Test is also refactored to use JFrame instead of Applet. >> >> The test is not in `ProblemList.txt`. >> It still fails on JDK 1.5 (after removing all syntactic sugar). > > Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: > > text block replaced with string literal. I've also replaced text blocks with string literals to ease backporting. ------------- PR: https://git.openjdk.java.net/jdk/pull/3474 From aivanov at openjdk.java.net Fri Apr 16 14:24:36 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Fri, 16 Apr 2021 14:24:36 GMT Subject: RFR: 8075915: The eight controls without black backgrounds with WinLAF & GTK LAF & Nimbus LAF [v6] In-Reply-To: References: Message-ID: <2FUiOkOqsgorMrUaRl-7nulUam2Ms2bAMrK0JBREOLg=.54962d76-c5f9-4d6c-a2f6-30cc82817c7a@github.com> On Fri, 16 Apr 2021 14:14:11 GMT, Alexander Zvegintsev wrote: >> This manual test was written for Metal L&F, so now it is set explicitly. >> Test is also refactored to use JFrame instead of Applet. >> >> The test is not in `ProblemList.txt`. >> It still fails on JDK 1.5 (after removing all syntactic sugar). > > Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: > > text block replaced with string literal. Marked as reviewed by aivanov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3474 From azvegint at openjdk.java.net Fri Apr 16 14:31:36 2021 From: azvegint at openjdk.java.net (Alexander Zvegintsev) Date: Fri, 16 Apr 2021 14:31:36 GMT Subject: 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. In-Reply-To: References: Message-ID: 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 azvegint (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3541 From azvegint at openjdk.java.net Fri Apr 16 14:35:39 2021 From: azvegint at openjdk.java.net (Alexander Zvegintsev) Date: Fri, 16 Apr 2021 14:35:39 GMT Subject: Integrated: 8075915: The eight controls without black backgrounds with WinLAF & GTK LAF & Nimbus LAF In-Reply-To: References: Message-ID: <-0R7CJArqQFC36sZHY5dR9e8C8hdgQPTqLUNQTn2AaA=.cb6234a4-78a7-434d-9af5-31da7fdb1b54@github.com> On Tue, 13 Apr 2021 19:24:43 GMT, Alexander Zvegintsev wrote: > This manual test was written for Metal L&F, so now it is set explicitly. > Test is also refactored to use JFrame instead of Applet. > > The test is not in `ProblemList.txt`. > It still fails on JDK 1.5 (after removing all syntactic sugar). This pull request has now been integrated. Changeset: 6946d91d Author: Alexander Zvegintsev URL: https://git.openjdk.java.net/jdk/commit/6946d91d Stats: 222 lines in 2 files changed: 116 ins; 73 del; 33 mod 8075915: The eight controls without black backgrounds with WinLAF & GTK LAF & Nimbus LAF Reviewed-by: psadhukhan, kizune, aivanov ------------- PR: https://git.openjdk.java.net/jdk/pull/3474 From trebari at openjdk.java.net Fri Apr 16 14:35:40 2021 From: trebari at openjdk.java.net (Tejpal Rebari) Date: Fri, 16 Apr 2021 14:35:40 GMT Subject: 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. In-Reply-To: References: Message-ID: 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 From kizune at openjdk.java.net Fri Apr 16 19:33:37 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Fri, 16 Apr 2021 19:33:37 GMT Subject: Integrated: 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. In-Reply-To: References: Message-ID: 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. This pull request has now been integrated. Changeset: 74d03abb Author: Alexander Zuev URL: https://git.openjdk.java.net/jdk/commit/74d03abb Stats: 184 lines in 2 files changed: 184 ins; 0 del; 0 mod 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. Reviewed-by: azvegint, trebari ------------- PR: https://git.openjdk.java.net/jdk/pull/3541 From psadhukhan at openjdk.java.net Tue Apr 20 03:39:03 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Tue, 20 Apr 2021 03:39:03 GMT Subject: RFR: 8199079: Test javax/swing/UIDefaults/6302464/bug6302464.java is unstable In-Reply-To: References: Message-ID: On Fri, 16 Apr 2021 06:53:21 GMT, Prasanta Sadhukhan wrote: > This test was marked as unstable in CI run in samevm mode but later on was found passing in now-default othervm mode but was problemlisted only on macos by JDK-8254976. > It is found that this test started failing in macos due to JDK-8220150: [macos] macos10.14 Mojave returns anti-aliased glyphs instead of aliased B&W glyphs > which turns Antialias hint even if it is set to off from macosx10.14 onwards. > So, this test started failing when it tries to test Antialias OFF hint. > > Proposed fix is to check for macosx 10.14 and greater version and bail out from this subtest. > > @prrace Can you please take a look? Any reviewers please? ------------- PR: https://git.openjdk.java.net/jdk/pull/3537 From prr at openjdk.java.net Tue Apr 20 23:19:05 2021 From: prr at openjdk.java.net (Phil Race) Date: Tue, 20 Apr 2021 23:19:05 GMT Subject: RFR: 8199079: Test javax/swing/UIDefaults/6302464/bug6302464.java is unstable In-Reply-To: References: Message-ID: On Fri, 16 Apr 2021 06:53:21 GMT, Prasanta Sadhukhan wrote: > This test was marked as unstable in CI run in samevm mode but later on was found passing in now-default othervm mode but was problemlisted only on macos by JDK-8254976. > It is found that this test started failing in macos due to JDK-8220150: [macos] macos10.14 Mojave returns anti-aliased glyphs instead of aliased B&W glyphs > which turns Antialias hint even if it is set to off from macosx10.14 onwards. > So, this test started failing when it tries to test Antialias OFF hint. > > Proposed fix is to check for macosx 10.14 and greater version and bail out from this subtest. > > @prrace Can you please take a look? test/jdk/javax/swing/UIDefaults/6302464/bug6302464.java line 138: > 136: } > 137: if (!isMacOSX14) { > 138: HashSet colorsAAOff = getAntialiasedColors(VALUE_TEXT_ANTIALIAS_OFF, 100); what happens on macOS 11 ? ------------- PR: https://git.openjdk.java.net/jdk/pull/3537 From psadhukhan at openjdk.java.net Wed Apr 21 03:59:04 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Wed, 21 Apr 2021 03:59:04 GMT Subject: RFR: 8199079: Test javax/swing/UIDefaults/6302464/bug6302464.java is unstable In-Reply-To: References: Message-ID: On Tue, 20 Apr 2021 23:16:29 GMT, Phil Race wrote: >> This test was marked as unstable in CI run in samevm mode but later on was found passing in now-default othervm mode but was problemlisted only on macos by JDK-8254976. >> It is found that this test started failing in macos due to JDK-8220150: [macos] macos10.14 Mojave returns anti-aliased glyphs instead of aliased B&W glyphs >> which turns Antialias hint even if it is set to off from macosx10.14 onwards. >> So, this test started failing when it tries to test Antialias OFF hint. >> >> Proposed fix is to check for macosx 10.14 and greater version and bail out from this subtest. >> >> @prrace Can you please take a look? > > test/jdk/javax/swing/UIDefaults/6302464/bug6302464.java line 138: > >> 136: } >> 137: if (!isMacOSX14) { >> 138: HashSet colorsAAOff = getAntialiasedColors(VALUE_TEXT_ANTIALIAS_OFF, 100); > > what happens on macOS 11 ? it also works in macos11 ------------- PR: https://git.openjdk.java.net/jdk/pull/3537 From prr at openjdk.java.net Wed Apr 21 05:13:04 2021 From: prr at openjdk.java.net (Phil Race) Date: Wed, 21 Apr 2021 05:13:04 GMT Subject: RFR: 8199079: Test javax/swing/UIDefaults/6302464/bug6302464.java is unstable In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 03:55:50 GMT, Prasanta Sadhukhan wrote: >> test/jdk/javax/swing/UIDefaults/6302464/bug6302464.java line 138: >> >>> 136: } >>> 137: if (!isMacOSX14) { >>> 138: HashSet colorsAAOff = getAntialiasedColors(VALUE_TEXT_ANTIALIAS_OFF, 100); >> >> what happens on macOS 11 ? > > it also works in macos11 So on macOS 11 we enter this block since isMacOSX14 is false and the test passes ? ------------- PR: https://git.openjdk.java.net/jdk/pull/3537 From psadhukhan at openjdk.java.net Wed Apr 21 05:13:04 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Wed, 21 Apr 2021 05:13:04 GMT Subject: RFR: 8199079: Test javax/swing/UIDefaults/6302464/bug6302464.java is unstable In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 05:07:38 GMT, Phil Race wrote: >> it also works in macos11 > > So on macOS 11 we enter this block since isMacOSX14 is false and the test passes ? No, it still fails in macosx11 without this modification. macos11, System .getProperty returns 10.16 so it satisfies this macosx >=10.14 condition and it bails out from this subtest. ------------- PR: https://git.openjdk.java.net/jdk/pull/3537 From prr at openjdk.java.net Wed Apr 21 05:21:01 2021 From: prr at openjdk.java.net (Phil Race) Date: Wed, 21 Apr 2021 05:21:01 GMT Subject: RFR: 8199079: Test javax/swing/UIDefaults/6302464/bug6302464.java is unstable In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 05:09:48 GMT, Prasanta Sadhukhan wrote: >> So on macOS 11 we enter this block since isMacOSX14 is false and the test passes ? > > No, it still fails in macosx11 without this modification. macos11, System .getProperty returns 10.16 so it satisfies this macosx >=10.14 condition and it bails out from this subtest. Are you sure you are up to date ? There was a fix so that it returns 11 My build on my machine : ~/jdk.git/build/macosx-x86_64-server-release/jdk/bin/jshell | Welcome to JShell -- Version 17-internal | For an introduction type: /help intro jshell> System.getProperty("os.version") $1 ==> "11.2.3" ------------- PR: https://git.openjdk.java.net/jdk/pull/3537 From psadhukhan at openjdk.java.net Wed Apr 21 11:23:02 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Wed, 21 Apr 2021 11:23:02 GMT Subject: RFR: 8199079: Test javax/swing/UIDefaults/6302464/bug6302464.java is unstable [v2] In-Reply-To: References: Message-ID: > This test was marked as unstable in CI run in samevm mode but later on was found passing in now-default othervm mode but was problemlisted only on macos by JDK-8254976. > It is found that this test started failing in macos due to JDK-8220150: [macos] macos10.14 Mojave returns anti-aliased glyphs instead of aliased B&W glyphs > which turns Antialias hint even if it is set to off from macosx10.14 onwards. > So, this test started failing when it tries to test Antialias OFF hint. > > Proposed fix is to check for macosx 10.14 and greater version and bail out from this subtest. > > @prrace Can you please take a look? Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: BigSur fix ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3537/files - new: https://git.openjdk.java.net/jdk/pull/3537/files/7bfef241..b0188638 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3537&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3537&range=00-01 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3537.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3537/head:pull/3537 PR: https://git.openjdk.java.net/jdk/pull/3537 From psadhukhan at openjdk.java.net Wed Apr 21 11:23:02 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Wed, 21 Apr 2021 11:23:02 GMT Subject: RFR: 8199079: Test javax/swing/UIDefaults/6302464/bug6302464.java is unstable [v2] In-Reply-To: References: Message-ID: <2-odhF5-blEsGHZ6VV3ZmHWFxyUo3K_FD7C7k-T5WGU=.b398f733-6222-4d3e-b965-9a2c1e220ac1@github.com> On Wed, 21 Apr 2021 05:18:06 GMT, Phil Race wrote: >> No, it still fails in macosx11 without this modification. macos11, System .getProperty returns 10.16 so it satisfies this macosx >=10.14 condition and it bails out from this subtest. > > Are you sure you are up to date ? There was a fix so that it returns 11 > > My build on my machine : > ~/jdk.git/build/macosx-x86_64-server-release/jdk/bin/jshell > | Welcome to JShell -- Version 17-internal > | For an introduction type: /help intro > > jshell> System.getProperty("os.version") > $1 ==> "11.2.3" Yes, the repo was a bit outdated on BigSur system. I have updated the fix to check BigSur OS too. ------------- PR: https://git.openjdk.java.net/jdk/pull/3537 From prr at openjdk.java.net Wed Apr 21 14:13:34 2021 From: prr at openjdk.java.net (Phil Race) Date: Wed, 21 Apr 2021 14:13:34 GMT Subject: RFR: 8199079: Test javax/swing/UIDefaults/6302464/bug6302464.java is unstable [v2] In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 11:23:02 GMT, Prasanta Sadhukhan wrote: >> This test was marked as unstable in CI run in samevm mode but later on was found passing in now-default othervm mode but was problemlisted only on macos by JDK-8254976. >> It is found that this test started failing in macos due to JDK-8220150: [macos] macos10.14 Mojave returns anti-aliased glyphs instead of aliased B&W glyphs >> which turns Antialias hint even if it is set to off from macosx10.14 onwards. >> So, this test started failing when it tries to test Antialias OFF hint. >> >> Proposed fix is to check for macosx 10.14 and greater version and bail out from this subtest. >> >> @prrace Can you please take a look? > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > BigSur fix Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3537 From prr at openjdk.java.net Wed Apr 21 14:16:41 2021 From: prr at openjdk.java.net (Phil Race) Date: Wed, 21 Apr 2021 14:16:41 GMT Subject: RFR: 8199079: Test javax/swing/UIDefaults/6302464/bug6302464.java is unstable [v2] In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 11:23:02 GMT, Prasanta Sadhukhan wrote: >> This test was marked as unstable in CI run in samevm mode but later on was found passing in now-default othervm mode but was problemlisted only on macos by JDK-8254976. >> It is found that this test started failing in macos due to JDK-8220150: [macos] macos10.14 Mojave returns anti-aliased glyphs instead of aliased B&W glyphs >> which turns Antialias hint even if it is set to off from macosx10.14 onwards. >> So, this test started failing when it tries to test Antialias OFF hint. >> >> Proposed fix is to check for macosx 10.14 and greater version and bail out from this subtest. >> >> @prrace Can you please take a look? > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > BigSur fix I guess this will work - until Apple come out with 12.0 when it will break again. I'd have preferred to see you convert the first part of the string - up to before any 2nd decimal pt into a float and then just do a comparison. Not sure if the jtreg OSUtils have something to help. ------------- PR: https://git.openjdk.java.net/jdk/pull/3537 From psadhukhan at openjdk.java.net Wed Apr 21 14:38:37 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Wed, 21 Apr 2021 14:38:37 GMT Subject: RFR: 8199079: Test javax/swing/UIDefaults/6302464/bug6302464.java is unstable [v2] In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 14:13:47 GMT, Phil Race wrote: > > > I guess this will work - until Apple come out with 12.0 when it will break again. > I'd have preferred to see you convert the first part of the string - up to before any 2nd decimal pt > into a float and then just do a comparison. > Not sure if the jtreg OSUtils have something to help. Yes, could have. Next time for sure...We will have time till 12.0 to work on it...BTW, I could not find OSUtils in our repo.. ------------- PR: https://git.openjdk.java.net/jdk/pull/3537 From psadhukhan at openjdk.java.net Wed Apr 21 14:38:38 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Wed, 21 Apr 2021 14:38:38 GMT Subject: Integrated: 8199079: Test javax/swing/UIDefaults/6302464/bug6302464.java is unstable In-Reply-To: References: Message-ID: On Fri, 16 Apr 2021 06:53:21 GMT, Prasanta Sadhukhan wrote: > This test was marked as unstable in CI run in samevm mode but later on was found passing in now-default othervm mode but was problemlisted only on macos by JDK-8254976. > It is found that this test started failing in macos due to JDK-8220150: [macos] macos10.14 Mojave returns anti-aliased glyphs instead of aliased B&W glyphs > which turns Antialias hint even if it is set to off from macosx10.14 onwards. > So, this test started failing when it tries to test Antialias OFF hint. > > Proposed fix is to check for macosx 10.14 and greater version and bail out from this subtest. > > @prrace Can you please take a look? This pull request has now been integrated. Changeset: 41fc7ddd Author: Prasanta Sadhukhan URL: https://git.openjdk.java.net/jdk/commit/41fc7ddd Stats: 29 lines in 2 files changed: 21 ins; 1 del; 7 mod 8199079: Test javax/swing/UIDefaults/6302464/bug6302464.java is unstable Reviewed-by: prr ------------- PR: https://git.openjdk.java.net/jdk/pull/3537 From kizune at openjdk.java.net Wed Apr 21 16:22:50 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Wed, 21 Apr 2021 16:22:50 GMT Subject: RFR: 8171381: [TEST_BUG] [macos] javax/swing/JPopupMenu/7156657/bug7156657.java fails on OS X Message-ID: <4bbWXhcUEX52kHgDS5PTdoIHqn-OEm8Y6FUAB-80_Ao=.6f5885fa-e8b6-448f-bf84-8ed1fb9a4d44@github.com> Replaces usage of SunToolkit.realSync() with Robot.waitForIdle() ------------- Commit messages: - 8171381: [TEST_BUG] [macos] javax/swing/JPopupMenu/7156657/bug7156657.java fails on OS X Changes: https://git.openjdk.java.net/jdk/pull/3606/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3606&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8171381 Stats: 8 lines in 1 file changed: 0 ins; 4 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/3606.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3606/head:pull/3606 PR: https://git.openjdk.java.net/jdk/pull/3606 From serb at openjdk.java.net Wed Apr 21 19:46:31 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Wed, 21 Apr 2021 19:46:31 GMT Subject: RFR: 8171381: [TEST_BUG] [macos] javax/swing/JPopupMenu/7156657/bug7156657.java fails on OS X In-Reply-To: <4bbWXhcUEX52kHgDS5PTdoIHqn-OEm8Y6FUAB-80_Ao=.6f5885fa-e8b6-448f-bf84-8ed1fb9a4d44@github.com> References: <4bbWXhcUEX52kHgDS5PTdoIHqn-OEm8Y6FUAB-80_Ao=.6f5885fa-e8b6-448f-bf84-8ed1fb9a4d44@github.com> Message-ID: On Wed, 21 Apr 2021 16:15:50 GMT, Alexander Zuev wrote: > Replaces usage of SunToolkit.realSync() with Robot.waitForIdle() The Robot.waitForIdle() is implemented via SunToolkit.realSync(), I am not sure how it might solve the problem. ------------- PR: https://git.openjdk.java.net/jdk/pull/3606 From kizune at openjdk.java.net Wed Apr 21 21:15:21 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Wed, 21 Apr 2021 21:15:21 GMT Subject: RFR: 8171381: [TEST_BUG] [macos] javax/swing/JPopupMenu/7156657/bug7156657.java fails on OS X In-Reply-To: References: <4bbWXhcUEX52kHgDS5PTdoIHqn-OEm8Y6FUAB-80_Ao=.6f5885fa-e8b6-448f-bf84-8ed1fb9a4d44@github.com> Message-ID: On Wed, 21 Apr 2021 19:43:40 GMT, Sergey Bylokhov wrote: > The Robot.waitForIdle() is implemented via SunToolkit.realSync(), I am not sure how it might solve the problem. It will not solve the problem as there is no problem as such. Test failed twice in two years on the same machine with the problematic OS configuration. Test has not failed before for 6 years and since configuration was fixed has not resurfaced. I'm just using this opportunity to get rid of the non-public API usage in a public test. ------------- PR: https://git.openjdk.java.net/jdk/pull/3606 From serb at openjdk.java.net Wed Apr 21 21:41:29 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Wed, 21 Apr 2021 21:41:29 GMT Subject: RFR: 8171381: [TEST_BUG] [macos] javax/swing/JPopupMenu/7156657/bug7156657.java fails on OS X In-Reply-To: <4bbWXhcUEX52kHgDS5PTdoIHqn-OEm8Y6FUAB-80_Ao=.6f5885fa-e8b6-448f-bf84-8ed1fb9a4d44@github.com> References: <4bbWXhcUEX52kHgDS5PTdoIHqn-OEm8Y6FUAB-80_Ao=.6f5885fa-e8b6-448f-bf84-8ed1fb9a4d44@github.com> Message-ID: On Wed, 21 Apr 2021 16:15:50 GMT, Alexander Zuev wrote: > Replaces usage of SunToolkit.realSync() with Robot.waitForIdle() test/jdk/javax/swing/JPopupMenu/7156657/bug7156657.java line 42: > 40: > 41: import sun.awt.SunToolkit; > 42: The "@modules java.desktop/sun.awt" should be removed as well? ------------- PR: https://git.openjdk.java.net/jdk/pull/3606 From serb at openjdk.java.net Wed Apr 21 21:41:28 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Wed, 21 Apr 2021 21:41:28 GMT Subject: RFR: 8171381: [TEST_BUG] [macos] javax/swing/JPopupMenu/7156657/bug7156657.java fails on OS X In-Reply-To: References: <4bbWXhcUEX52kHgDS5PTdoIHqn-OEm8Y6FUAB-80_Ao=.6f5885fa-e8b6-448f-bf84-8ed1fb9a4d44@github.com> Message-ID: On Wed, 21 Apr 2021 21:12:44 GMT, Alexander Zuev wrote: > It will not solve the problem as there is no problem as such. Ok, then please add this thing to the JBS. ------------- PR: https://git.openjdk.java.net/jdk/pull/3606 From kizune at openjdk.java.net Wed Apr 21 22:39:52 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Wed, 21 Apr 2021 22:39:52 GMT Subject: RFR: 8171381: [TEST_BUG] [macos] javax/swing/JPopupMenu/7156657/bug7156657.java fails on OS X [v2] In-Reply-To: <4bbWXhcUEX52kHgDS5PTdoIHqn-OEm8Y6FUAB-80_Ao=.6f5885fa-e8b6-448f-bf84-8ed1fb9a4d44@github.com> References: <4bbWXhcUEX52kHgDS5PTdoIHqn-OEm8Y6FUAB-80_Ao=.6f5885fa-e8b6-448f-bf84-8ed1fb9a4d44@github.com> Message-ID: <2_xZo-oOMnl1Tic39k6RLMBFfoOOfpAsCEE79BHtus0=.d5d0dd7c-6056-4fac-9c04-41e824abefcc@github.com> > Replaces usage of SunToolkit.realSync() with Robot.waitForIdle() Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: Remove modules clause ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3606/files - new: https://git.openjdk.java.net/jdk/pull/3606/files/e97cd56e..5cfff7e7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3606&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3606&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3606.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3606/head:pull/3606 PR: https://git.openjdk.java.net/jdk/pull/3606 From kizune at openjdk.java.net Wed Apr 21 22:39:53 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Wed, 21 Apr 2021 22:39:53 GMT Subject: RFR: 8171381: [TEST_BUG] [macos] javax/swing/JPopupMenu/7156657/bug7156657.java fails on OS X [v2] In-Reply-To: References: <4bbWXhcUEX52kHgDS5PTdoIHqn-OEm8Y6FUAB-80_Ao=.6f5885fa-e8b6-448f-bf84-8ed1fb9a4d44@github.com> Message-ID: On Wed, 21 Apr 2021 21:38:07 GMT, Sergey Bylokhov wrote: >> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove modules clause > > test/jdk/javax/swing/JPopupMenu/7156657/bug7156657.java line 42: > >> 40: >> 41: import sun.awt.SunToolkit; >> 42: > > The "@modules java.desktop/sun.awt" should be removed as well? Yes, sorry, forgot about it. Fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/3606 From serb at openjdk.java.net Wed Apr 21 23:21:24 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Wed, 21 Apr 2021 23:21:24 GMT Subject: RFR: 8171381: [TEST_BUG] [macos] javax/swing/JPopupMenu/7156657/bug7156657.java fails on OS X [v2] In-Reply-To: <2_xZo-oOMnl1Tic39k6RLMBFfoOOfpAsCEE79BHtus0=.d5d0dd7c-6056-4fac-9c04-41e824abefcc@github.com> References: <4bbWXhcUEX52kHgDS5PTdoIHqn-OEm8Y6FUAB-80_Ao=.6f5885fa-e8b6-448f-bf84-8ed1fb9a4d44@github.com> <2_xZo-oOMnl1Tic39k6RLMBFfoOOfpAsCEE79BHtus0=.d5d0dd7c-6056-4fac-9c04-41e824abefcc@github.com> Message-ID: On Wed, 21 Apr 2021 22:39:52 GMT, Alexander Zuev wrote: >> Replaces usage of SunToolkit.realSync() with Robot.waitForIdle() > > Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: > > Remove modules clause Marked as reviewed by serb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3606 From kizune at openjdk.java.net Wed Apr 21 23:24:23 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Wed, 21 Apr 2021 23:24:23 GMT Subject: Integrated: 8171381: [TEST_BUG] [macos] javax/swing/JPopupMenu/7156657/bug7156657.java fails on OS X In-Reply-To: <4bbWXhcUEX52kHgDS5PTdoIHqn-OEm8Y6FUAB-80_Ao=.6f5885fa-e8b6-448f-bf84-8ed1fb9a4d44@github.com> References: <4bbWXhcUEX52kHgDS5PTdoIHqn-OEm8Y6FUAB-80_Ao=.6f5885fa-e8b6-448f-bf84-8ed1fb9a4d44@github.com> Message-ID: On Wed, 21 Apr 2021 16:15:50 GMT, Alexander Zuev wrote: > Replaces usage of SunToolkit.realSync() with Robot.waitForIdle() This pull request has now been integrated. Changeset: ca6b1b49 Author: Alexander Zuev URL: https://git.openjdk.java.net/jdk/commit/ca6b1b49 Stats: 9 lines in 1 file changed: 0 ins; 5 del; 4 mod 8171381: [TEST_BUG] [macos] javax/swing/JPopupMenu/7156657/bug7156657.java fails on OS X Reviewed-by: serb ------------- PR: https://git.openjdk.java.net/jdk/pull/3606 From philip.race at oracle.com Fri Apr 23 20:10:46 2021 From: philip.race at oracle.com (Philip Race) Date: Fri, 23 Apr 2021 13:10:46 -0700 Subject: Heads up : JDK 17 b19 through b22 will use Metal instead of OpenGL for Java 2D rendering on macOS. Message-ID: <9826c9ab-273e-b387-a5f1-f44f855007f7@oracle.com> Heads up to anyone who is testing JDK 17 for running apps on macOS. Starting with build 19 [1], JDK 17 for macOS is *temporarily* switched from using OpenGL to using Apple's Metal API for Java 2D rendering. This should be invisible to applications. We expect to revert this temporary switch in JDK 17 build 23,meaning b22 will be the last build with Metal as default. See JEP 382 [2] for more information about how Metal is used by JDK. If you are running any kind of 2D / Swing/ AWT UI application on macOS, and see any rendering related problems starting with JDK 17 b19, please do report them to us at either the usual bug submission channel [3], or on the 2d-dev at openjdk.java.net OpenJDK mailing list [4] Please be ready to provide us with a test case and screen shots. You may also set "-Dsun.java2d.opengl=true" to re-enable OpenGL - which? implicitly disables Metal - to confirm that any problem you see is a Metal related rendering glitch. I will also forward this email to jdk-dev at openjdk.java.net -Phil. [1] https://jdk.java.net/17/ [2] https://openjdk.java.net/jeps/382 [3] https://bugreport.java.com/bugreport/ [4] https://mail.openjdk.java.net/mailman/listinfo/2d-dev From pbansal at openjdk.java.net Sun Apr 25 17:34:55 2021 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Sun, 25 Apr 2021 17:34:55 GMT Subject: RFR: 8163367: Test javax/swing/JComboBox/8033069/bug8033069NoScrollBar.java javax/swing/JComboBox/8033069/bug8033069ScrollBar.java fails intermittently Message-ID: The tests a javax/swing/JComboBox/8033069/bug8033069ScrollBar.java and javax/swing/JComboBox/8033069/bug8033069NoScrollBar.java fails intermittently. The tests have a few problems which could cause this behaviour and the are being fixed here. 1. Test access the Swing components without EDT thread at couple of places. 2. Test is not calling waitForIdle or delay after Robot.mouseMove operations. There is some additional cleanup done in the fix and moved the frame in centre. The tests pass with multiple iterations on CI. Link in the JBS. ------------- Commit messages: - Move frame to centre - 8163367: Test javax/swing/JComboBox/8033069/bug8033069NoScrollBar.java javax/swing/JComboBox/8033069/bug8033069ScrollBar.java fails intermittently Changes: https://git.openjdk.java.net/jdk/pull/3678/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3678&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8163367 Stats: 32 lines in 2 files changed: 16 ins; 7 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/3678.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3678/head:pull/3678 PR: https://git.openjdk.java.net/jdk/pull/3678 From serb at openjdk.java.net Sun Apr 25 20:53:49 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Sun, 25 Apr 2021 20:53:49 GMT Subject: RFR: 8163367: Test javax/swing/JComboBox/8033069/bug8033069NoScrollBar.java javax/swing/JComboBox/8033069/bug8033069ScrollBar.java fails intermittently In-Reply-To: References: Message-ID: On Sun, 25 Apr 2021 16:27:46 GMT, Pankaj Bansal wrote: > The tests a javax/swing/JComboBox/8033069/bug8033069ScrollBar.java and javax/swing/JComboBox/8033069/bug8033069NoScrollBar.java fails intermittently. The tests have a few problems which could cause this behaviour and the are being fixed here. > > 1. Test access the Swing components without EDT thread at couple of places. > 2. Test is not calling waitForIdle or delay after Robot.mouseMove operations. > > There is some additional cleanup done in the fix and moved the frame in centre. The tests pass with multiple iterations on CI. Link in the JBS. @aivanov-jdk please take a look ------------- PR: https://git.openjdk.java.net/jdk/pull/3678 From aivanov at openjdk.java.net Mon Apr 26 20:04:35 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Mon, 26 Apr 2021 20:04:35 GMT Subject: RFR: 8163367: Test javax/swing/JComboBox/8033069/bug8033069NoScrollBar.java javax/swing/JComboBox/8033069/bug8033069ScrollBar.java fails intermittently In-Reply-To: References: Message-ID: On Sun, 25 Apr 2021 16:27:46 GMT, Pankaj Bansal wrote: > The tests a javax/swing/JComboBox/8033069/bug8033069ScrollBar.java and javax/swing/JComboBox/8033069/bug8033069NoScrollBar.java fails intermittently. The tests have a few problems which could cause this behaviour and the are being fixed here. > > 1. Test access the Swing components without EDT thread at couple of places. > 2. Test is not calling waitForIdle or delay after Robot.mouseMove operations. > > There is some additional cleanup done in the fix and moved the frame in centre. The tests pass with multiple iterations on CI. Link in the JBS. test/jdk/javax/swing/JComboBox/8033069/bug8033069NoScrollBar.java line 64: > 62: > 63: private Point p; > 64: private Dimension d; Both should be `volatile` as they're accessed from two different threads. test/jdk/javax/swing/JComboBox/8033069/bug8033069NoScrollBar.java line 120: > 118: d = cb1.getSize(); > 119: }); > 120: robot.waitForIdle(); Is it needed here? The block above does not modify the state of the UI. test/jdk/javax/swing/JComboBox/8033069/bug8033069NoScrollBar.java line 123: > 121: > 122: robot.mouseMove(p.x + d.width / 2, p.y + d.height / 2); > 123: robot.waitForIdle(); I believe the delay between mouseMove and mousePress/Release is unneeded, does it really make a difference? test/jdk/javax/swing/JComboBox/8033069/bug8033069NoScrollBar.java line 175: > 173: if (frame != null) { > 174: SwingUtilities.invokeAndWait(frame::dispose); > 175: } The frame is still accessed from two different threads. ------------- PR: https://git.openjdk.java.net/jdk/pull/3678 From pbansal at openjdk.java.net Tue Apr 27 06:22:03 2021 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Tue, 27 Apr 2021 06:22:03 GMT Subject: RFR: 8163367: Test javax/swing/JComboBox/8033069/bug8033069NoScrollBar.java javax/swing/JComboBox/8033069/bug8033069ScrollBar.java fails intermittently [v2] In-Reply-To: References: Message-ID: > The tests a javax/swing/JComboBox/8033069/bug8033069ScrollBar.java and javax/swing/JComboBox/8033069/bug8033069NoScrollBar.java fails intermittently. The tests have a few problems which could cause this behaviour and the are being fixed here. > > 1. Test access the Swing components without EDT thread at couple of places. > 2. Test is not calling waitForIdle or delay after Robot.mouseMove operations. > > There is some additional cleanup done in the fix and moved the frame in centre. The tests pass with multiple iterations on CI. Link in the JBS. Pankaj Bansal has updated the pull request incrementally with one additional commit since the last revision: Incorporate review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3678/files - new: https://git.openjdk.java.net/jdk/pull/3678/files/b726d76a..5cb06612 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3678&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3678&range=00-01 Stats: 17 lines in 1 file changed: 6 ins; 8 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/3678.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3678/head:pull/3678 PR: https://git.openjdk.java.net/jdk/pull/3678 From trebari at openjdk.java.net Tue Apr 27 08:05:09 2021 From: trebari at openjdk.java.net (Tejpal Rebari) Date: Tue, 27 Apr 2021 08:05:09 GMT Subject: RFR: 8049700: Deprecate obsolete classes and methods in javax/swing/plaf/basic [v9] In-Reply-To: References: Message-ID: > 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&pr=1958&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1958&range=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 From aivanov at openjdk.java.net Tue Apr 27 10:32:37 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Tue, 27 Apr 2021 10:32:37 GMT Subject: RFR: 8163367: Test javax/swing/JComboBox/8033069/bug8033069NoScrollBar.java javax/swing/JComboBox/8033069/bug8033069ScrollBar.java fails intermittently [v2] In-Reply-To: References: Message-ID: <3dD3_SBZwFtMFFgge3NcFObWbgu99VVd3ZiUDsoD_9E=.8a16ba96-6fea-4ceb-9eb0-f749e03b6135@github.com> On Tue, 27 Apr 2021 06:22:03 GMT, Pankaj Bansal wrote: >> The tests a javax/swing/JComboBox/8033069/bug8033069ScrollBar.java and javax/swing/JComboBox/8033069/bug8033069NoScrollBar.java fails intermittently. The tests have a few problems which could cause this behaviour and the are being fixed here. >> >> 1. Test access the Swing components without EDT thread at couple of places. >> 2. Test is not calling waitForIdle or delay after Robot.mouseMove operations. >> >> There is some additional cleanup done in the fix and moved the frame in centre. The tests pass with multiple iterations on CI. Link in the JBS. > > Pankaj Bansal has updated the pull request incrementally with one additional commit since the last revision: > > Incorporate review comments test/jdk/javax/swing/JComboBox/8033069/bug8033069NoScrollBar.java line 64: > 62: > 63: volatile private Point p; > 64: volatile private Dimension d; Suggestion: private volatile Point p; private volatile Dimension d; ------------- PR: https://git.openjdk.java.net/jdk/pull/3678 From pbansal at openjdk.java.net Tue Apr 27 11:11:07 2021 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Tue, 27 Apr 2021 11:11:07 GMT Subject: RFR: 8163367: Test javax/swing/JComboBox/8033069/bug8033069NoScrollBar.java javax/swing/JComboBox/8033069/bug8033069ScrollBar.java fails intermittently [v3] In-Reply-To: References: Message-ID: <21R4VQnvFuJ6Dbtgjef9nv-Avj6U075ZnSL__-9tz3I=.9fe4e377-ea48-4b2a-a229-6b16c6bb2a54@github.com> > The tests a javax/swing/JComboBox/8033069/bug8033069ScrollBar.java and javax/swing/JComboBox/8033069/bug8033069NoScrollBar.java fails intermittently. The tests have a few problems which could cause this behaviour and the are being fixed here. > > 1. Test access the Swing components without EDT thread at couple of places. > 2. Test is not calling waitForIdle or delay after Robot.mouseMove operations. > > There is some additional cleanup done in the fix and moved the frame in centre. The tests pass with multiple iterations on CI. Link in the JBS. Pankaj Bansal has updated the pull request incrementally with one additional commit since the last revision: Update test/jdk/javax/swing/JComboBox/8033069/bug8033069NoScrollBar.java Review comments Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3678/files - new: https://git.openjdk.java.net/jdk/pull/3678/files/5cb06612..0fb35893 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3678&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3678&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3678.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3678/head:pull/3678 PR: https://git.openjdk.java.net/jdk/pull/3678 From aivanov at openjdk.java.net Tue Apr 27 11:19:38 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Tue, 27 Apr 2021 11:19:38 GMT Subject: RFR: 8163367: Test javax/swing/JComboBox/8033069/bug8033069NoScrollBar.java javax/swing/JComboBox/8033069/bug8033069ScrollBar.java fails intermittently [v3] In-Reply-To: <21R4VQnvFuJ6Dbtgjef9nv-Avj6U075ZnSL__-9tz3I=.9fe4e377-ea48-4b2a-a229-6b16c6bb2a54@github.com> References: <21R4VQnvFuJ6Dbtgjef9nv-Avj6U075ZnSL__-9tz3I=.9fe4e377-ea48-4b2a-a229-6b16c6bb2a54@github.com> Message-ID: <1J9qI4zAwpQ_halOvt8qqIW7kGEIZzuJ2CVGly8GdWI=.334a62c6-bf0e-4740-85d7-ee4cb62d5148@github.com> On Tue, 27 Apr 2021 11:11:07 GMT, Pankaj Bansal wrote: >> The tests a javax/swing/JComboBox/8033069/bug8033069ScrollBar.java and javax/swing/JComboBox/8033069/bug8033069NoScrollBar.java fails intermittently. The tests have a few problems which could cause this behaviour and the are being fixed here. >> >> 1. Test access the Swing components without EDT thread at couple of places. >> 2. Test is not calling waitForIdle or delay after Robot.mouseMove operations. >> >> There is some additional cleanup done in the fix and moved the frame in centre. The tests pass with multiple iterations on CI. Link in the JBS. > > Pankaj Bansal has updated the pull request incrementally with one additional commit since the last revision: > > Update test/jdk/javax/swing/JComboBox/8033069/bug8033069NoScrollBar.java > > Review comments > > Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> Marked as reviewed by aivanov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3678 From pbansal at openjdk.java.net Tue Apr 27 13:03:39 2021 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Tue, 27 Apr 2021 13:03:39 GMT Subject: Integrated: 8163367: Test javax/swing/JComboBox/8033069/bug8033069NoScrollBar.java javax/swing/JComboBox/8033069/bug8033069ScrollBar.java fails intermittently In-Reply-To: References: Message-ID: On Sun, 25 Apr 2021 16:27:46 GMT, Pankaj Bansal wrote: > The tests a javax/swing/JComboBox/8033069/bug8033069ScrollBar.java and javax/swing/JComboBox/8033069/bug8033069NoScrollBar.java fails intermittently. The tests have a few problems which could cause this behaviour and the are being fixed here. > > 1. Test access the Swing components without EDT thread at couple of places. > 2. Test is not calling waitForIdle or delay after Robot.mouseMove operations. > > There is some additional cleanup done in the fix and moved the frame in centre. The tests pass with multiple iterations on CI. Link in the JBS. This pull request has now been integrated. Changeset: 9481fad4 Author: Pankaj Bansal URL: https://git.openjdk.java.net/jdk/commit/9481fad4 Stats: 34 lines in 2 files changed: 16 ins; 9 del; 9 mod 8163367: Test javax/swing/JComboBox/8033069/bug8033069NoScrollBar.java javax/swing/JComboBox/8033069/bug8033069ScrollBar.java fails intermittently Reviewed-by: aivanov ------------- PR: https://git.openjdk.java.net/jdk/pull/3678 From iris at openjdk.java.net Tue Apr 27 17:26:46 2021 From: iris at openjdk.java.net (Iris Clark) Date: Tue, 27 Apr 2021 17:26:46 GMT Subject: RFR: 8049700: Deprecate obsolete classes and methods in javax/swing/plaf/basic [v9] In-Reply-To: References: Message-ID: On Tue, 27 Apr 2021 08:05:09 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. > > Tejpal Rebari has updated the pull request incrementally with one additional commit since the last revision: > > updated according to comments on the CSR Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1958 From kizune at openjdk.java.net Thu Apr 29 14:52:54 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Thu, 29 Apr 2021 14:52:54 GMT Subject: RFR: 8182043: Access to Windows Large Icons In-Reply-To: References: Message-ID: On Fri, 2 Apr 2021 21:20:49 GMT, Alexey Ivanov wrote: >> Fix updated after first round of review. > > src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java line 276: > >> 274: * >> 275: * @param f a File object >> 276: * @param size width and height of the icon in pixels > > Pixels could be ambiguous now. Usually, Swing deals with user's space. That is 16?16 icon should actually be 32?32 if the scale factor of the current display is 200%. > > Yes, this issue is somewhat irrelevant because the method returns multi-resolution icon. However, the terminology used must be unambiguous and clear; for consistency with other Swing API, it should be in terms of user's space coordinates, *virtual pixels*. Ok, fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/2875 From kizune at openjdk.java.net Thu Apr 29 15:02:52 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Thu, 29 Apr 2021 15:02:52 GMT Subject: RFR: 8182043: Access to Windows Large Icons In-Reply-To: References: Message-ID: <3IvJU9r5uoMB68PVBZ8fGa6TdalgcISznUWZcnrfivY=.07798fce-f9ba-4443-84aa-52129e1e6a77@github.com> On Wed, 10 Mar 2021 20:32:12 GMT, Alexey Ivanov wrote: >> Fix updated after first round of review. > > src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java line 1195: > >> 1193: */ >> 1194: static Image getShell32Icon(int iconID, int size) { >> 1195: boolean useVGAColors = true; // Will be ignored on XP and later > > I cannot see where `useVGAColors` is used. Since the supported OS are later than XP, it can be removed, can't it? I think so. Fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/2875 From kizune at openjdk.java.net Thu Apr 29 17:06:58 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Thu, 29 Apr 2021 17:06:58 GMT Subject: RFR: 8182043: Access to Windows Large Icons In-Reply-To: References: Message-ID: On Wed, 10 Mar 2021 20:27:44 GMT, Alexey Ivanov wrote: >> Fix updated after first round of review. > > src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java line 1114: > >> 1112: bothIcons.put(getLargeIcon? SMALL_ICON_SIZE : LARGE_ICON_SIZE, newIcon2); >> 1113: newIcon = new MultiResolutionIconImage(getLargeIcon ? LARGE_ICON_SIZE >> 1114: : SMALL_ICON_SIZE, bothIcons); > > I still propose to refactor this code to make it clearer. The code always returns two icons: _small + large_ or _large + small_ ? combined in `MultiResolutionIconImage`. > > You can get `smallIcon` and `largeIcon` and then wrap them into `MultiResolutionIconImage` in the correct order and store each icon in the cache. > > My opinion hasn't changed here. > > I still think there's not much value in getting smaller icon size in addition to larger one. Or does it provide an alternative image for the case where the system scaling is 200% and the window is moved to a monitor with scaling of 100%? Getting smaller icon is relevant in the case of the scaling. I do not think refactoring image caches from icons to multiresolution images will make code much cleaner - at the end we will have to extract images from the multiresolution image to repack them into different multiresolution image because the base size of the image will not be the same and it does matter in how they will be scaled on the different screens. And we still need to extract both images because sometimes small resolution image looks not like the large resolution one and for a reason - so small resolution image is not blurred by the small detail on the large icon when scaling on the low resolution screen. ------------- PR: https://git.openjdk.java.net/jdk/pull/2875 From kizune at openjdk.java.net Thu Apr 29 18:49:55 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Thu, 29 Apr 2021 18:49:55 GMT Subject: RFR: 8182043: Access to Windows Large Icons In-Reply-To: References: Message-ID: On Wed, 10 Mar 2021 20:17:05 GMT, Alexey Ivanov wrote: >> Fix updated after first round of review. > > src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java line 1044: > >> 1042: new BufferedImage(iconSize, iconSize, BufferedImage.TYPE_INT_ARGB); >> 1043: img.setRGB(0, 0, iconSize, iconSize, iconBits, 0, iconSize); >> 1044: return img; > > There are cases where the size of the buffered image is different from the requested size. It could affect the layout because it breaks the assumption that the returned image has the requested size but it may be larger. (Or is it no longer possible?) I think it should be wrapped into `MultiResolutionIconImage` in this case. Actually in makeImage we do not use requested size, we return the bits that system returns to us. How the generated image is treated depends on the implementation of the public methods - where it matters they are wrapped in the corresponding multi resolution images so it behaves correctly in UI. ------------- PR: https://git.openjdk.java.net/jdk/pull/2875 From kizune at openjdk.java.net Fri Apr 30 05:41:19 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Fri, 30 Apr 2021 05:41:19 GMT Subject: RFR: 8182043: Access to Windows Large Icons [v2] In-Reply-To: References: Message-ID: > Fix updated after first round of review. Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: Small fixes Remived size parameter from makeIcon Removed useVGAColors usage as irrelevant since it is ignored on all supported platforms now ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2875/files - new: https://git.openjdk.java.net/jdk/pull/2875/files/19a0efe0..6607b61f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2875&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2875&range=00-01 Stats: 27 lines in 3 files changed: 0 ins; 8 del; 19 mod Patch: https://git.openjdk.java.net/jdk/pull/2875.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2875/head:pull/2875 PR: https://git.openjdk.java.net/jdk/pull/2875 From kizune at openjdk.java.net Fri Apr 30 12:27:20 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Fri, 30 Apr 2021 12:27:20 GMT Subject: RFR: 8182043: Access to Windows Large Icons [v3] In-Reply-To: References: Message-ID: On Wed, 10 Mar 2021 20:44:19 GMT, Alexey Ivanov wrote: >> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: >> >> Update src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp >> >> Select one icon at a time. >> >> Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> > > src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java line 264: > >> 262: *

>> 263: * The default implementation gets information from the >> 264: * ShellFolder class. Whenever possible, the icon > > Do we continue using `` elements? I thought that {@code} is the preferred way to markup class names. Fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/2875 From kizune at openjdk.java.net Fri Apr 30 12:27:19 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Fri, 30 Apr 2021 12:27:19 GMT Subject: RFR: 8182043: Access to Windows Large Icons [v3] In-Reply-To: References: Message-ID: > Fix updated after first round of review. Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: Update src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp Select one icon at a time. Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2875/files - new: https://git.openjdk.java.net/jdk/pull/2875/files/6607b61f..4a360621 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2875&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2875&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2875.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2875/head:pull/2875 PR: https://git.openjdk.java.net/jdk/pull/2875 From aivanov at openjdk.java.net Fri Apr 30 20:40:57 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Fri, 30 Apr 2021 20:40:57 GMT Subject: RFR: 8182043: Access to Windows Large Icons [v3] In-Reply-To: References: Message-ID: <3hQNodTn6s3lrpoRv7bTa-fDV4OBwdEiHiV_vo3zJQY=.f5f64501-eb98-4ffa-83b1-b3841abf290b@github.com> On Fri, 30 Apr 2021 12:27:19 GMT, Alexander Zuev wrote: >> Fix updated after first round of review. > > Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: > > Update src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp > > Select one icon at a time. > > Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java line 267: > 265: * returned will be a multi-resolution icon image, > 266: * which will allow better scaling with different > 267: * magnification factors. I'm not sure what are the standard terms to refer to High DPI environments and the scale factors associated with High DPI. src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java line 275: > 273: * > 274: * > 275: * @param f a File object Suggestion: * @param f a {@code File} object src/java.desktop/share/classes/sun/awt/shell/ShellFolder.java line 213: > 211: * Returns the icon of the specified size used to display this shell folder. > 212: * > 213: * @param size size of the icon > 0 (Valid range: 1 to 256) I'm unsure the valid range of 1 to 256 makes sense provided the icon smaller than 16?16 is never returned (on Windows at least). src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java line 1193: > 1191: static Image getShell32Icon(int iconID, int size) { > 1192: Toolkit toolkit = Toolkit.getDefaultToolkit(); > 1193: String shellIconBPP = (String)toolkit.getDesktopProperty("win.icon.shellIconBPP"); Looks like these lines aren't used any more and should be removed too. ------------- PR: https://git.openjdk.java.net/jdk/pull/2875 From aivanov at openjdk.java.net Fri Apr 30 20:40:58 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Fri, 30 Apr 2021 20:40:58 GMT Subject: RFR: 8182043: Access to Windows Large Icons [v3] In-Reply-To: References: Message-ID: On Thu, 29 Apr 2021 18:47:27 GMT, Alexander Zuev wrote: >> src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java line 1044: >> >>> 1042: new BufferedImage(iconSize, iconSize, BufferedImage.TYPE_INT_ARGB); >>> 1043: img.setRGB(0, 0, iconSize, iconSize, iconBits, 0, iconSize); >>> 1044: return img; >> >> There are cases where the size of the buffered image is different from the requested size. It could affect the layout because it breaks the assumption that the returned image has the requested size but it may be larger. (Or is it no longer possible?) I think it should be wrapped into `MultiResolutionIconImage` in this case. > > Actually in makeImage we do not use requested size, we return the bits that system returns to us. How the generated image is treated depends on the implementation of the public methods - where it matters they are wrapped in the corresponding multi resolution images so it behaves correctly in UI. Okay, if it *always* wrapped in a multi-resolution image where it *matters*. ------------- PR: https://git.openjdk.java.net/jdk/pull/2875 From aivanov at openjdk.java.net Fri Apr 30 20:50:55 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Fri, 30 Apr 2021 20:50:55 GMT Subject: RFR: 8182043: Access to Windows Large Icons [v3] In-Reply-To: References: Message-ID: On Thu, 29 Apr 2021 17:04:17 GMT, Alexander Zuev wrote: >> src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java line 1114: >> >>> 1112: bothIcons.put(getLargeIcon? SMALL_ICON_SIZE : LARGE_ICON_SIZE, newIcon2); >>> 1113: newIcon = new MultiResolutionIconImage(getLargeIcon ? LARGE_ICON_SIZE >>> 1114: : SMALL_ICON_SIZE, bothIcons); >> >> I still propose to refactor this code to make it clearer. The code always returns two icons: _small + large_ or _large + small_ ? combined in `MultiResolutionIconImage`. >> >> You can get `smallIcon` and `largeIcon` and then wrap them into `MultiResolutionIconImage` in the correct order and store each icon in the cache. >> >> My opinion hasn't changed here. >> >> I still think there's not much value in getting smaller icon size in addition to larger one. Or does it provide an alternative image for the case where the system scaling is 200% and the window is moved to a monitor with scaling of 100%? > > Getting smaller icon is relevant in the case of the scaling. I do not think refactoring image caches from icons to multiresolution images will make code much cleaner - at the end we will have to extract images from the multiresolution image to repack them into different multiresolution image because the base size of the image will not be the same and it does matter in how they will be scaled on the different screens. And we still need to extract both images because sometimes small resolution image looks not like the large resolution one and for a reason - so small resolution image is not blurred by the small detail on the large icon when scaling on the low resolution screen. No, I can't see how it's relevant. If the scale factor is 100% and the requested icon size is 16, then 16?16 is used; if the window is moved to a monitor with scale factor 200%, then 32?32 icon is used for rendering which is already fetched and available in the multi-resolution image ? perfect, there's the benefit. But when is it possible that the scale factor is less than 100%? If `JFileChooser` requests a large icon that is 32?32, then it will be used for rendering when the scale factor is 100%. When the scale factor is 200%, the icon of 64?64 is required but it's not available, instead there's 16?16 icon. For this icon to be used, the scale factor needs to be 50%. ------------- PR: https://git.openjdk.java.net/jdk/pull/2875 From aivanov at openjdk.java.net Fri Apr 30 20:53:53 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Fri, 30 Apr 2021 20:53:53 GMT Subject: RFR: 8182043: Access to Windows Large Icons [v3] In-Reply-To: References: Message-ID: On Wed, 10 Mar 2021 20:40:40 GMT, Alexey Ivanov wrote: >> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: >> >> Update src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp >> >> Select one icon at a time. >> >> Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> > > test/jdk/javax/swing/JFileChooser/FileSystemView/SystemIconTest.java line 64: > >> 62: } >> 63: >> 64: if (icon.getIconWidth() != size) { > > Does it make sense to check that the icon is a multi-resolution image with the expected sizes? > We know for sure `explorer.exe` contains the entire set of icons. Since the test always expects a multi-resolution image, does it make sense to assert `icon instanceof MultiResolutionImage` at the very least? ------------- PR: https://git.openjdk.java.net/jdk/pull/2875 From aivanov at openjdk.java.net Fri Apr 30 20:57:02 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Fri, 30 Apr 2021 20:57:02 GMT Subject: RFR: 8182043: Access to Windows Large Icons [v3] In-Reply-To: References: Message-ID: On Wed, 10 Mar 2021 20:53:43 GMT, Alexey Ivanov wrote: >> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: >> >> Update src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp >> >> Select one icon at a time. >> >> Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> > > src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java line 1146: > >> 1144: } >> 1145: Map multiResolutionIcon = new HashMap<>(); >> 1146: int start = size > MAX_QUALITY_ICON ? ICON_RESOLUTIONS.length - 1 : 0; > > Does it make sense to always start at zero? > The icons of smaller size will never be used, will they? > Thus it's safe to start at the index which corresponds to the requested size if `size` matches, or the index such as `ICON_RESOLUTIONS[index] < size && ICON_RESOLUTIONS[index + 1] > size`. This comment is also about the case of not fetching icons of sizes smaller than requested size. ------------- PR: https://git.openjdk.java.net/jdk/pull/2875