From serb at openjdk.java.net Sun Aug 1 08:47:24 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Sun, 1 Aug 2021 08:47:24 GMT Subject: RFR: 8271456: Avoid looking up standard charsets in "java.desktop" module Message-ID: This is a request to clean up a desktop module as was done in JDK-8233884 for "java.base" module. In many places standard charsets are looked up via their names, for example: absolutePath.getBytes("UTF-8"); This could be done more efficiently(x20 time faster) with use of java.nio.charset.StandardCharsets: absolutePath.getBytes(StandardCharsets.UTF_8); The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant. Tested by the desktop headless/headful tests on linux/windows. ------------- Commit messages: - Initial fix for JDK-8271456 Changes: https://git.openjdk.java.net/jdk/pull/4951/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4951&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271456 Stats: 641 lines in 28 files changed: 276 ins; 237 del; 128 mod Patch: https://git.openjdk.java.net/jdk/pull/4951.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4951/head:pull/4951 PR: https://git.openjdk.java.net/jdk/pull/4951 From serb at openjdk.java.net Mon Aug 2 05:15:31 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Mon, 2 Aug 2021 05:15:31 GMT Subject: RFR: 8269130: Replace usages of Collection.toArray() with Collection.toArray(T[]) to avoid redundant array copying In-Reply-To: References: Message-ID: On Mon, 14 Jun 2021 17:00:29 GMT, Andrey Turbanov wrote: > I found few places, where code initially perform `Object[] Colleciton.toArray()` call and then manually copy array into another array with required type. > This PR cleanups such places to more shorter call `T[] Collection.toArray(T[])`. Changes in the desktop module looks fine. ------------- Marked as reviewed by serb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4487 From serb at openjdk.java.net Mon Aug 2 05:56:39 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Mon, 2 Aug 2021 05:56:39 GMT Subject: RFR: 8267385: Create NSAccessibilityElement implementation for JavaComponentAccessibility [v8] In-Reply-To: References: <0N6YS5JRnmBXewFWAvMpuVUFJPaetSS1d9WNCuBcw5c=.d84596a3-66a9-4627-8eab-f65ec7b00eb7@github.com> Message-ID: On Wed, 21 Jul 2021 13:16:46 GMT, Artem Semenov wrote: >> The comment states that it is not necessary to call ExceptionCheck, but it will be done before by the CHECK_EXCEPTION. The macro also will log it when necessary. > > Done I suggest doing the opposite, leave the CHECK_EXCEPTION and remove the chech and the logging. The CHECK_EXCEPTION is better since it can be configured via properties, and it will chech itself on what thread the current code is executed. ------------- PR: https://git.openjdk.java.net/jdk/pull/4412 From serb at openjdk.java.net Mon Aug 2 05:56:38 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Mon, 2 Aug 2021 05:56:38 GMT Subject: RFR: 8267385: Create NSAccessibilityElement implementation for JavaComponentAccessibility [v8] In-Reply-To: References: <0N6YS5JRnmBXewFWAvMpuVUFJPaetSS1d9WNCuBcw5c=.d84596a3-66a9-4627-8eab-f65ec7b00eb7@github.com> Message-ID: On Wed, 21 Jul 2021 17:25:48 GMT, Artem Semenov wrote: >> src/java.desktop/macosx/classes/sun/lwawt/macosx/CAccessibility.java line 556: >> >>> 554: ((JList) parent).setSelectedIndex(i); >>> 555: return; >>> 556: } >> >> Looks like the a11y interface miss "setSelectedIndex" method? The code above will not work for the custom component which uses the "AccessibleJListChild" a11y object? > > Unfortunately, the current a11y interface does not allow this action. > As for the custom AccessibleJListChild, I prepared a [sample project](https://github.com/savoptik/AccessibilityJListItemA11yExample) in which I implemented a custom child. The experiment showed that there are no negative consequences. The custom child works as intended. In the example, you use a JList class, and the checks in the code above works, but if some other "AccessibleJList" class will be used then it will not work, right? This is the reason why implementations of a11y classes usually use specific interfaces like "AccessibleJList". >> src/java.desktop/macosx/native/libawt_lwawt/awt/JavaComponentAccessibility.m line 50: >> >>> 48: #define JAVA_AX_ALL_CHILDREN (-1) >>> 49: #define JAVA_AX_SELECTED_CHILDREN (-2) >>> 50: #define JAVA_AX_VISIBLE_CHILDREN (-3) >> >> Why not mark them as @native in the CAccessibility and use constants generated by the javac? > > Done But the code above still exits or it is a github glitch? >> src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/TableAccessibility.m line 155: >> >>> 153: - (NSArray *)accessibilitySelectedChildren >>> 154: { >>> 155: return [self accessibilitySelectedRows]; >> >> Does it mean that the children of the table are rows and columns and not "cells".? How it will work if only one cell is selected? > > As @ azuev-java canceled below this is not functional regression. > However, cell navigation will be implemented later in [JDK-8271071](https://bugs.openjdk.java.net/browse/JDK-8271071). ok ------------- PR: https://git.openjdk.java.net/jdk/pull/4412 From github.com+36081106+savoptik at openjdk.java.net Mon Aug 2 07:38:33 2021 From: github.com+36081106+savoptik at openjdk.java.net (Artem Semenov) Date: Mon, 2 Aug 2021 07:38:33 GMT Subject: RFR: 8267385: Create NSAccessibilityElement implementation for JavaComponentAccessibility [v8] In-Reply-To: References: <0N6YS5JRnmBXewFWAvMpuVUFJPaetSS1d9WNCuBcw5c=.d84596a3-66a9-4627-8eab-f65ec7b00eb7@github.com> Message-ID: <2QaOnc93p0FXbubf9S8womqJTVtxCVLXhQf2aaY7DBg=.9afc2536-9f17-478f-8c02-c22b51d6618c@github.com> On Mon, 2 Aug 2021 05:53:25 GMT, Sergey Bylokhov wrote: >> Done > > But the code above still exits or it is a github glitch? By convention with @ azuev-java, we try to either not change at all, or change the minimum legacy code. ------------- PR: https://git.openjdk.java.net/jdk/pull/4412 From github.com+36081106+savoptik at openjdk.java.net Mon Aug 2 09:00:14 2021 From: github.com+36081106+savoptik at openjdk.java.net (Artem Semenov) Date: Mon, 2 Aug 2021 09:00:14 GMT Subject: RFR: 8267385: Create NSAccessibilityElement implementation for JavaComponentAccessibility [v9] In-Reply-To: <0N6YS5JRnmBXewFWAvMpuVUFJPaetSS1d9WNCuBcw5c=.d84596a3-66a9-4627-8eab-f65ec7b00eb7@github.com> References: <0N6YS5JRnmBXewFWAvMpuVUFJPaetSS1d9WNCuBcw5c=.d84596a3-66a9-4627-8eab-f65ec7b00eb7@github.com> Message-ID: <_6TBLlVpkwjyUYmfn-Yhij_kSAVWtSvEd-kVJMTiy48=.6244371c-dc44-4c4f-b8d6-0bf17ae78668@github.com> > 8267385: Create NSAccessibilityElement implementation for JavaComponentAccessibility > This pull request contains solutions for the following tickets: > * JDK-8267385 Create NSAccessibilityElement implementation for JavaComponentAccessibility; > * JDK-8262031 Create implementation for NSAccessibilityNavigableStaticText protocol; > * JDK-8264287 Create implementation for NSAccessibilityComboBox protocol peer; > * JDK-8264303 Create implementation for NSAccessibilityTabGroup protocol peer; > * JDK-8264292 Create implementation for NSAccessibilityList protocol peer; > * JDK-8267387 Create implementation for NSAccessibilityOutline protocol; > * JDK-8267388 Create implementation for NSAccessibilityTable protocol. Artem Semenov has updated the pull request incrementally with one additional commit since the last revision: 1. Fixed problems with vertical navigation in table cells; 2. I suggest doing the opposite, leave the CHECK_EXCEPTION and remove the chech and the logging. The CHECK_EXCEPTION is better since it can be configured via properties, and it will chech itself on what thread the current code is executed. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4412/files - new: https://git.openjdk.java.net/jdk/pull/4412/files/65053348..a13d6a6b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4412&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4412&range=07-08 Stats: 19 lines in 4 files changed: 1 ins; 11 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/4412.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4412/head:pull/4412 PR: https://git.openjdk.java.net/jdk/pull/4412 From github.com+36081106+savoptik at openjdk.java.net Mon Aug 2 09:00:15 2021 From: github.com+36081106+savoptik at openjdk.java.net (Artem Semenov) Date: Mon, 2 Aug 2021 09:00:15 GMT Subject: RFR: 8267385: Create NSAccessibilityElement implementation for JavaComponentAccessibility [v9] In-Reply-To: References: <0N6YS5JRnmBXewFWAvMpuVUFJPaetSS1d9WNCuBcw5c=.d84596a3-66a9-4627-8eab-f65ec7b00eb7@github.com> Message-ID: On Mon, 2 Aug 2021 05:50:09 GMT, Sergey Bylokhov wrote: >> Done > > I suggest doing the opposite, leave the CHECK_EXCEPTION and remove the chech and the logging. The CHECK_EXCEPTION is better since it can be configured via properties, and it will chech itself on what thread the current code is executed. Done ------------- PR: https://git.openjdk.java.net/jdk/pull/4412 From github.com+36081106+savoptik at openjdk.java.net Mon Aug 2 10:03:32 2021 From: github.com+36081106+savoptik at openjdk.java.net (Artem Semenov) Date: Mon, 2 Aug 2021 10:03:32 GMT Subject: RFR: 8267385: Create NSAccessibilityElement implementation for JavaComponentAccessibility [v9] In-Reply-To: References: <0N6YS5JRnmBXewFWAvMpuVUFJPaetSS1d9WNCuBcw5c=.d84596a3-66a9-4627-8eab-f65ec7b00eb7@github.com> Message-ID: On Mon, 2 Aug 2021 05:38:42 GMT, Sergey Bylokhov wrote: >> Unfortunately, the current a11y interface does not allow this action. >> As for the custom AccessibleJListChild, I prepared a [sample project](https://github.com/savoptik/AccessibilityJListItemA11yExample) in which I implemented a custom child. The experiment showed that there are no negative consequences. The custom child works as intended. > > In the example, you use a JList class, and the checks in the code above works, but if some other "AccessibleJList" class will be used then it will not work, right? This is the reason why implementations of a11y classes usually use specific interfaces like "AccessibleJList". Yes, this will not work with a custom list not inherited from JList. Unfortunately AccessibleJList is not perfect and the functionality you need is not there. If you have a better solution, please share it. - Could you please advice on what we can do here? ------------- PR: https://git.openjdk.java.net/jdk/pull/4412 From redestad at openjdk.java.net Mon Aug 2 11:22:44 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 2 Aug 2021 11:22:44 GMT Subject: RFR: 8268113: Re-use Long.hashCode() where possible [v11] In-Reply-To: References: <7TGw6Vzvw38bqmNOQsuVuGXMe98OqH25nmexLUghcMU=.5e7b347c-0d83-4e54-acc3-9847c08cdc29@github.com> Message-ID: <1tMR5seQ0nt1U7RbpVx7RNgvMl9Eov8JRVmmjASa5HQ=.b4f65b78-74ee-457b-b9db-e1acbfff80c2@github.com> On Mon, 26 Jul 2021 08:27:14 GMT, ?????? ??????? wrote: >> There is a few JDK classes duplicating the contents of Long.hashCode() for hash code calculation. They should explicitly delegate to Long.hashCode(). > > ?????? ??????? 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 13 additional commits since the last revision: > > - Merge branch 'master' into 8268113 > - 8270160 Revert changes in BitSet.hashCode > - Merge branch 'master' into 8268113 > - 8270160 Revert changes in BitSet.hashCode > - Merge branch 'master' into 8268113 > - Merge branch 'master' into 8268113 > - Merge branch 'master' into 8268113 > - Merge branch 'master' into 8268113 > - Merge branch 'master' into 8268113 > - Merge branch 'master' into 8268113 > - ... and 3 more: https://git.openjdk.java.net/jdk/compare/1d801fa0...bd762b7d All changes look good to me, though 3rd party sources like xerces/.../DoubleDV.java should probably be dealt with in the upstream first. @AlanBateman probably knows who maintains and downstreams this usually (or whether we are now practically maintaining a fork of xerces)? ------------- Marked as reviewed by redestad (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4309 From github.com+10835776+stsypanov at openjdk.java.net Mon Aug 2 12:52:34 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 2 Aug 2021 12:52:34 GMT Subject: Integrated: 8268113: Re-use Long.hashCode() where possible In-Reply-To: <7TGw6Vzvw38bqmNOQsuVuGXMe98OqH25nmexLUghcMU=.5e7b347c-0d83-4e54-acc3-9847c08cdc29@github.com> References: <7TGw6Vzvw38bqmNOQsuVuGXMe98OqH25nmexLUghcMU=.5e7b347c-0d83-4e54-acc3-9847c08cdc29@github.com> Message-ID: On Wed, 2 Jun 2021 14:10:38 GMT, ?????? ??????? wrote: > There is a few JDK classes duplicating the contents of Long.hashCode() for hash code calculation. They should explicitly delegate to Long.hashCode(). This pull request has now been integrated. Changeset: 6a3f8343 Author: Sergey Tsypanov Committer: Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/6a3f8343bc0e92c29a87c5840cbef9ab2988f153 Stats: 10 lines in 6 files changed: 0 ins; 4 del; 6 mod 8268113: Re-use Long.hashCode() where possible Reviewed-by: redestad ------------- PR: https://git.openjdk.java.net/jdk/pull/4309 From github.com+10835776+stsypanov at openjdk.java.net Mon Aug 2 14:37:29 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 2 Aug 2021 14:37:29 GMT Subject: RFR: 8271456: Avoid looking up standard charsets in "java.desktop" module In-Reply-To: References: Message-ID: On Sun, 1 Aug 2021 07:07:21 GMT, Sergey Bylokhov wrote: > This is a request to clean up a desktop module as was done in JDK-8233884 for "java.base" module. > > In many places standard charsets are looked up via their names, for example: > absolutePath.getBytes("UTF-8"); > > This could be done more efficiently(x20 time faster) with use of java.nio.charset.StandardCharsets: > absolutePath.getBytes(StandardCharsets.UTF_8); > > The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant. > > Tested by the desktop headless/headful tests on linux/windows. Marked as reviewed by stsypanov at github.com (no known OpenJDK username). ------------- PR: https://git.openjdk.java.net/jdk/pull/4951 From serb at openjdk.java.net Mon Aug 2 18:29:33 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Mon, 2 Aug 2021 18:29:33 GMT Subject: RFR: 8266079: Lanai: AlphaComposite shows differences on Metal compared to OpenGL In-Reply-To: <7FfjAXZJPIzx2OfaLY8dlET6NVnF-XAiaAI7mJwNGeo=.2381d679-8860-4c79-a7bd-4749f10bb90e@github.com> References: <7FfjAXZJPIzx2OfaLY8dlET6NVnF-XAiaAI7mJwNGeo=.2381d679-8860-4c79-a7bd-4749f10bb90e@github.com> Message-ID: On Fri, 30 Jul 2021 15:39:19 GMT, Alexey Ushakov wrote: > Keep MTLLayer opacity in sync with window content view > Keep layer translucent for translucent windows src/java.desktop/macosx/classes/sun/lwawt/LWWindowPeer.java line 199: > 197: > 198: platformWindow.initialize(target, this, ownerDelegate); > 199: platformWindow.setOpaque(!isTranslucent()); !isTranslucent() uses the opaque flag which will be initialised in the code below(see setOpaque(getTarget().isOpaque());) ------------- PR: https://git.openjdk.java.net/jdk/pull/4946 From avu at openjdk.java.net Mon Aug 2 20:07:32 2021 From: avu at openjdk.java.net (Alexey Ushakov) Date: Mon, 2 Aug 2021 20:07:32 GMT Subject: RFR: 8266079: Lanai: AlphaComposite shows differences on Metal compared to OpenGL In-Reply-To: References: <7FfjAXZJPIzx2OfaLY8dlET6NVnF-XAiaAI7mJwNGeo=.2381d679-8860-4c79-a7bd-4749f10bb90e@github.com> Message-ID: On Mon, 2 Aug 2021 18:26:45 GMT, Sergey Bylokhov wrote: >> Keep MTLLayer opacity in sync with window content view >> Keep layer translucent for translucent windows > > src/java.desktop/macosx/classes/sun/lwawt/LWWindowPeer.java line 199: > >> 197: >> 198: platformWindow.initialize(target, this, ownerDelegate); >> 199: platformWindow.setOpaque(!isTranslucent()); > > !isTranslucent() uses the opaque flag which will be initialised in the code below(see setOpaque(getTarget().isOpaque());) Yes, and we need this call here to initialise content view with correct default value CPlatformWindow.java:931 contentView.setWindowLayerOpaque(isOpaque); ------------- PR: https://git.openjdk.java.net/jdk/pull/4946 From serb at openjdk.java.net Mon Aug 2 21:56:32 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Mon, 2 Aug 2021 21:56:32 GMT Subject: RFR: 8266079: Lanai: AlphaComposite shows differences on Metal compared to OpenGL In-Reply-To: References: <7FfjAXZJPIzx2OfaLY8dlET6NVnF-XAiaAI7mJwNGeo=.2381d679-8860-4c79-a7bd-4749f10bb90e@github.com> Message-ID: On Mon, 2 Aug 2021 20:04:43 GMT, Alexey Ushakov wrote: >> src/java.desktop/macosx/classes/sun/lwawt/LWWindowPeer.java line 199: >> >>> 197: >>> 198: platformWindow.initialize(target, this, ownerDelegate); >>> 199: platformWindow.setOpaque(!isTranslucent()); >> >> !isTranslucent() uses the opaque flag which will be initialised in the code below(see setOpaque(getTarget().isOpaque());) > > Yes, and we need this call here to initialise content view with correct default value > CPlatformWindow.java:931 contentView.setWindowLayerOpaque(isOpaque); I need to look at it closely, I do not understand why we made the native layer opaque=NO by default while the java code uses opaque=true by default. And then we reset the native code from NO to yes by the code above. Why we cannot make both native/java use true/YES and when necessary it will be reset to false/NO by the existing code(via LWWindowPeer.setOpaque() and LWWindowPeer.updateOpaque?) BTW Probably implementation of LWWindowPeer.setTextured() should call the updateOpaque() as well. ------------- PR: https://git.openjdk.java.net/jdk/pull/4946 From serb at openjdk.java.net Mon Aug 2 21:59:37 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Mon, 2 Aug 2021 21:59:37 GMT Subject: RFR: 8267385: Create NSAccessibilityElement implementation for JavaComponentAccessibility [v9] In-Reply-To: References: <0N6YS5JRnmBXewFWAvMpuVUFJPaetSS1d9WNCuBcw5c=.d84596a3-66a9-4627-8eab-f65ec7b00eb7@github.com> Message-ID: On Mon, 2 Aug 2021 10:00:10 GMT, Artem Semenov wrote: >> In the example, you use a JList class, and the checks in the code above works, but if some other "AccessibleJList" class will be used then it will not work, right? This is the reason why implementations of a11y classes usually use specific interfaces like "AccessibleJList". > > Yes, this will not work with a custom list not inherited from JList. Unfortunately AccessibleJList is not perfect and the functionality you need is not there. > If you have a better solution, please share it. - Could you please advice on what we can do here? This is what I meant in the first message, "a11y interface miss setSelectedIndex method". I suggest filing a separate issue to accumulate such use cases and then fix them by adding additional methods to a11y interfaces. Probably something similar will be found in the Table/etc. ------------- PR: https://git.openjdk.java.net/jdk/pull/4412 From avu at openjdk.java.net Tue Aug 3 06:49:30 2021 From: avu at openjdk.java.net (Alexey Ushakov) Date: Tue, 3 Aug 2021 06:49:30 GMT Subject: RFR: 8266079: Lanai: AlphaComposite shows differences on Metal compared to OpenGL In-Reply-To: References: <7FfjAXZJPIzx2OfaLY8dlET6NVnF-XAiaAI7mJwNGeo=.2381d679-8860-4c79-a7bd-4749f10bb90e@github.com> Message-ID: On Mon, 2 Aug 2021 21:53:02 GMT, Sergey Bylokhov wrote: >> Yes, and we need this call here to initialise content view with correct default value >> CPlatformWindow.java:931 contentView.setWindowLayerOpaque(isOpaque); > > I need to look at it closely, I do not understand why we made the native layer opaque=NO by default while the java code uses opaque=true by default. And then we reset the native code from NO to yes by the code above. Why we cannot make both native/java use true/YES and when necessary it will be reset to false/NO by the existing code(via LWWindowPeer.setOpaque() and LWWindowPeer.updateOpaque?) > BTW Probably implementation of LWWindowPeer.setTextured() should call the updateOpaque() as well. Yes, sounds reasonable. Moreover, It was my initial attempt but I faced with some regressions in SwingSet2 demo. In some cases background of tree nodes become black and this artifact was reproducible only if some other tabs were clicked before. It was hot time for jdk17 so I decided not to fight with this regression. Now we have more time, so I can spend more time on this. ------------- PR: https://git.openjdk.java.net/jdk/pull/4946 From jdv at openjdk.java.net Tue Aug 3 09:35:30 2021 From: jdv at openjdk.java.net (Jayathirth D V) Date: Tue, 3 Aug 2021 09:35:30 GMT Subject: RFR: 8271456: Avoid looking up standard charsets in "java.desktop" module In-Reply-To: References: Message-ID: On Sun, 1 Aug 2021 07:07:21 GMT, Sergey Bylokhov wrote: > This is a request to clean up a desktop module as was done in JDK-8233884 for "java.base" module. > > In many places standard charsets are looked up via their names, for example: > absolutePath.getBytes("UTF-8"); > > This could be done more efficiently(x20 time faster) with use of java.nio.charset.StandardCharsets: > absolutePath.getBytes(StandardCharsets.UTF_8); > > The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant. > > Tested by the desktop headless/headful tests on linux/windows. Marked as reviewed by jdv (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4951 From jdv at openjdk.java.net Tue Aug 3 10:01:29 2021 From: jdv at openjdk.java.net (Jayathirth D V) Date: Tue, 3 Aug 2021 10:01:29 GMT Subject: RFR: 8270312: Error: Not a test or directory containing tests: java/awt/print/PrinterJob/XparColor.java In-Reply-To: References: Message-ID: On Tue, 13 Jul 2021 14:57:30 GMT, lawrence.andrews wrote: > 1) This testcase was throwing error saying Error: Not a test or directory containing tests: java/awt/print/PrinterJob/XparColor.java > 2) Added @test tag so that this testcase can be run > 3) Since Applet is deprecated and its not supported any more in the future release remove applet and make the testcase to run as main > 4) Since this is a manual testcase instruction frame or dailog was not visible just print dialog was visible so fixed it. > 5) When the testcase was run via main method two print dialog was shown one was from main method and one more was from constructor. Fixed to show just one print dialog. > 6) Since JDK 17 introduce metal rendering touching the java2d code thought this testcase will be useful to checking the rendering. > > @shurymury Since you mentioned about using metal rendering path to verify things. We need to pass -Dsun.java2d.metal=true as of now to run this test case using metal. We can add additional @run with metal enabled for this use case. ------------- PR: https://git.openjdk.java.net/jdk/pull/4769 From azvegint at openjdk.java.net Tue Aug 3 13:40:32 2021 From: azvegint at openjdk.java.net (Alexander Zvegintsev) Date: Tue, 3 Aug 2021 13:40:32 GMT Subject: RFR: 8271456: Avoid looking up standard charsets in "java.desktop" module In-Reply-To: References: Message-ID: On Sun, 1 Aug 2021 07:07:21 GMT, Sergey Bylokhov wrote: > This is a request to clean up a desktop module as was done in JDK-8233884 for "java.base" module. > > In many places standard charsets are looked up via their names, for example: > absolutePath.getBytes("UTF-8"); > > This could be done more efficiently(x20 time faster) with use of java.nio.charset.StandardCharsets: > absolutePath.getBytes(StandardCharsets.UTF_8); > > The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant. > > Tested by the desktop headless/headful tests on linux/windows. src/java.desktop/share/classes/com/sun/imageio/plugins/wbmp/WBMPMetadata.java line 25: > 23: * questions. > 24: */ > 25: Since you updating a copyright year in all other files, you probably might want to update in this file too. ------------- PR: https://git.openjdk.java.net/jdk/pull/4951 From kizune at openjdk.java.net Tue Aug 3 15:51:38 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Tue, 3 Aug 2021 15:51:38 GMT Subject: RFR: 8267385: Create NSAccessibilityElement implementation for JavaComponentAccessibility [v9] In-Reply-To: <_6TBLlVpkwjyUYmfn-Yhij_kSAVWtSvEd-kVJMTiy48=.6244371c-dc44-4c4f-b8d6-0bf17ae78668@github.com> References: <0N6YS5JRnmBXewFWAvMpuVUFJPaetSS1d9WNCuBcw5c=.d84596a3-66a9-4627-8eab-f65ec7b00eb7@github.com> <_6TBLlVpkwjyUYmfn-Yhij_kSAVWtSvEd-kVJMTiy48=.6244371c-dc44-4c4f-b8d6-0bf17ae78668@github.com> Message-ID: On Mon, 2 Aug 2021 09:00:14 GMT, Artem Semenov wrote: >> 8267385: Create NSAccessibilityElement implementation for JavaComponentAccessibility >> This pull request contains solutions for the following tickets: >> * JDK-8267385 Create NSAccessibilityElement implementation for JavaComponentAccessibility; >> * JDK-8262031 Create implementation for NSAccessibilityNavigableStaticText protocol; >> * JDK-8264287 Create implementation for NSAccessibilityComboBox protocol peer; >> * JDK-8264303 Create implementation for NSAccessibilityTabGroup protocol peer; >> * JDK-8264292 Create implementation for NSAccessibilityList protocol peer; >> * JDK-8267387 Create implementation for NSAccessibilityOutline protocol; >> * JDK-8267388 Create implementation for NSAccessibilityTable protocol. > > Artem Semenov has updated the pull request incrementally with one additional commit since the last revision: > > 1. Fixed problems with vertical navigation in table cells; > 2. I suggest doing the opposite, leave the CHECK_EXCEPTION and remove the chech and the logging. The CHECK_EXCEPTION is better since it can be configured via properties, and it will chech itself on what thread the current code is executed. There are still some issues - namely, accessibility cursor got stuck inside combobox popup after popup is closed and voiceover shortcuts such as control option space announced in combobox but do nothing - but they can be fixed in separate bugs. Overall the new API is working and the functional difference can be overcome later in separate changes. ------------- Marked as reviewed by kizune (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4412 From serb at openjdk.java.net Tue Aug 3 17:05:30 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Tue, 3 Aug 2021 17:05:30 GMT Subject: RFR: 8271456: Avoid looking up standard charsets in "java.desktop" module In-Reply-To: References: Message-ID: <44GDUiqRvJh0JOAHeby5i8wQW5YgM5fwRdXS896Pnu8=.b76fd6ac-bb13-46a3-ae22-800dfeea9553@github.com> On Tue, 3 Aug 2021 13:30:28 GMT, Alexander Zvegintsev wrote: >> This is a request to clean up a desktop module as was done in JDK-8233884 for "java.base" module. >> >> In many places standard charsets are looked up via their names, for example: >> absolutePath.getBytes("UTF-8"); >> >> This could be done more efficiently(x20 time faster) with use of java.nio.charset.StandardCharsets: >> absolutePath.getBytes(StandardCharsets.UTF_8); >> >> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant. >> >> Tested by the desktop headless/headful tests on linux/windows. > > src/java.desktop/share/classes/com/sun/imageio/plugins/wbmp/WBMPMetadata.java line 25: > >> 23: * questions. >> 24: */ >> 25: > > Since you updating a copyright year in all other files, you probably might want to update in this file too. I did not update it since this is the only file where the imports are updated only(the UnsupportedEncodingException is removed). ------------- PR: https://git.openjdk.java.net/jdk/pull/4951 From vdyakov at openjdk.java.net Tue Aug 3 17:44:33 2021 From: vdyakov at openjdk.java.net (Victor Dyakov) Date: Tue, 3 Aug 2021 17:44:33 GMT Subject: RFR: 8267385: Create NSAccessibilityElement implementation for JavaComponentAccessibility [v2] In-Reply-To: References: <0N6YS5JRnmBXewFWAvMpuVUFJPaetSS1d9WNCuBcw5c=.d84596a3-66a9-4627-8eab-f65ec7b00eb7@github.com> <6j0d_4-6BRHlcDoGqYi5GwaCgbi3C7mF3a_R8u22644=.68bb35b5-8b69-4cfb-98ae-daf60d3bc353@github.com> Message-ID: On Tue, 6 Jul 2021 10:43:51 GMT, Pankaj Bansal wrote: >> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision: >> >> Even on Linux? I meant if the test will be run on the platform where a11y is not implemented then this will be > > I tested the NavigableStaticTextAccessibility functionality for TextFields, TaxtPane and PasswordField. It works fine and I don't see any issue in VO output with this change. @pankaj-bansal please review the latest revision ------------- PR: https://git.openjdk.java.net/jdk/pull/4412 From azvegint at openjdk.java.net Tue Aug 3 18:05:32 2021 From: azvegint at openjdk.java.net (Alexander Zvegintsev) Date: Tue, 3 Aug 2021 18:05:32 GMT Subject: RFR: 8271456: Avoid looking up standard charsets in "java.desktop" module In-Reply-To: References: Message-ID: On Sun, 1 Aug 2021 07:07:21 GMT, Sergey Bylokhov wrote: > This is a request to clean up a desktop module as was done in JDK-8233884 for "java.base" module. > > In many places standard charsets are looked up via their names, for example: > absolutePath.getBytes("UTF-8"); > > This could be done more efficiently(x20 time faster) with use of java.nio.charset.StandardCharsets: > absolutePath.getBytes(StandardCharsets.UTF_8); > > The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant. > > Tested by the desktop headless/headful tests on linux/windows. Marked as reviewed by azvegint (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4951 From github.com+79671271+rajamah at openjdk.java.net Tue Aug 3 18:33:29 2021 From: github.com+79671271+rajamah at openjdk.java.net (rajat mahajan) Date: Tue, 3 Aug 2021 18:33:29 GMT Subject: RFR: 8270116: Expand ButtonGroupLayoutTraversalTest.java to run in all LaFs, including Aqua on macOS In-Reply-To: References: Message-ID: On Fri, 30 Jul 2021 05:35:58 GMT, Prasanta Sadhukhan wrote: >> Summary: Expanded ButtonGroupLayoutTraversalTest.java to run in all LAFs on all OS. Added synchronization for focusCnt. > > test/jdk/java/awt/Focus/FocusTraversalPolicy/ButtonGroupLayoutTraversal/ButtonGroupLayoutTraversalTest.java line 54: > >> 52: public class ButtonGroupLayoutTraversalTest { >> 53: >> 54: private static final int nx = 3; > > Normally, as per coding standard, for static final modifier, the variable should be named in CAPS...but is there any need of making it final? @prsadhuk I did what you asked, do you have any more questions or comments ?, if not could you please approve this PR, thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/4937 From serb at openjdk.java.net Tue Aug 3 19:37:04 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Tue, 3 Aug 2021 19:37:04 GMT Subject: RFR: 8271456: Avoid looking up standard charsets in "java.desktop" module [v2] In-Reply-To: References: Message-ID: <_b2JI_4pIcqDyEX0gBXAkD4DzzL3V2IOinLOq2dGksU=.3a99501e-1444-4298-b695-1519a8a2e227@github.com> > This is a request to clean up a desktop module as was done in JDK-8233884 for "java.base" module. > > In many places standard charsets are looked up via their names, for example: > absolutePath.getBytes("UTF-8"); > > This could be done more efficiently(x20 time faster) with use of java.nio.charset.StandardCharsets: > absolutePath.getBytes(StandardCharsets.UTF_8); > > The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant. > > Tested by the desktop headless/headful tests on linux/windows. Sergey Bylokhov 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 two additional commits since the last revision: - Merge branch 'master' into JDK-8271456 - Initial fix for JDK-8271456 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4951/files - new: https://git.openjdk.java.net/jdk/pull/4951/files/430c9b3a..886264aa Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4951&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4951&range=00-01 Stats: 1774 lines in 83 files changed: 1230 ins; 337 del; 207 mod Patch: https://git.openjdk.java.net/jdk/pull/4951.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4951/head:pull/4951 PR: https://git.openjdk.java.net/jdk/pull/4951 From avu at openjdk.java.net Tue Aug 3 19:56:28 2021 From: avu at openjdk.java.net (Alexey Ushakov) Date: Tue, 3 Aug 2021 19:56:28 GMT Subject: RFR: 8266079: Lanai: AlphaComposite shows differences on Metal compared to OpenGL In-Reply-To: References: <7FfjAXZJPIzx2OfaLY8dlET6NVnF-XAiaAI7mJwNGeo=.2381d679-8860-4c79-a7bd-4749f10bb90e@github.com> Message-ID: On Tue, 3 Aug 2021 06:46:07 GMT, Alexey Ushakov wrote: >> I need to look at it closely, I do not understand why we made the native layer opaque=NO by default while the java code uses opaque=true by default. And then we reset the native code from NO to yes by the code above. Why we cannot make both native/java use true/YES and when necessary it will be reset to false/NO by the existing code(via LWWindowPeer.setOpaque() and LWWindowPeer.updateOpaque?) >> BTW Probably implementation of LWWindowPeer.setTextured() should call the updateOpaque() as well. > > Yes, sounds reasonable. Moreover, It was my initial attempt but I faced with some regressions in SwingSet2 demo. In some cases background of tree nodes become black and this artifact was reproducible only if some other tabs were clicked before. It was hot time for jdk17 so I decided not to fight with this regression. Now we have more time, so I can spend more time on this. Looks like making MTLLayer opaque by default require much more time that I expected. I tried different things to resolve artefacts that I mentioned before but nothing seems to work. So, I suggest to stick with my latest approach. It passes all the tests and don't break SwingSet2. > BTW Probably implementation of LWWindowPeer.setTextured() should call the updateOpaque() as well. I'll add this change ------------- PR: https://git.openjdk.java.net/jdk/pull/4946 From serb at openjdk.java.net Tue Aug 3 19:56:29 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Tue, 3 Aug 2021 19:56:29 GMT Subject: RFR: 8266079: Lanai: AlphaComposite shows differences on Metal compared to OpenGL In-Reply-To: References: <7FfjAXZJPIzx2OfaLY8dlET6NVnF-XAiaAI7mJwNGeo=.2381d679-8860-4c79-a7bd-4749f10bb90e@github.com> Message-ID: On Tue, 3 Aug 2021 19:51:30 GMT, Alexey Ushakov wrote: >> Yes, sounds reasonable. Moreover, It was my initial attempt but I faced with some regressions in SwingSet2 demo. In some cases background of tree nodes become black and this artifact was reproducible only if some other tabs were clicked before. It was hot time for jdk17 so I decided not to fight with this regression. Now we have more time, so I can spend more time on this. > > Looks like making MTLLayer opaque by default require much more time that I expected. I tried different things to resolve artefacts that I mentioned before but nothing seems to work. So, I suggest to stick with my latest approach. It passes all the tests and don't break SwingSet2. > >> BTW Probably implementation of LWWindowPeer.setTextured() should call the updateOpaque() as well. > > I'll add this change How to reproduce that artifact? ------------- PR: https://git.openjdk.java.net/jdk/pull/4946 From avu at openjdk.java.net Tue Aug 3 20:07:29 2021 From: avu at openjdk.java.net (Alexey Ushakov) Date: Tue, 3 Aug 2021 20:07:29 GMT Subject: RFR: 8266079: Lanai: AlphaComposite shows differences on Metal compared to OpenGL In-Reply-To: References: <7FfjAXZJPIzx2OfaLY8dlET6NVnF-XAiaAI7mJwNGeo=.2381d679-8860-4c79-a7bd-4749f10bb90e@github.com> Message-ID: On Tue, 3 Aug 2021 19:53:22 GMT, Sergey Bylokhov wrote: >> Looks like making MTLLayer opaque by default require much more time that I expected. I tried different things to resolve artefacts that I mentioned before but nothing seems to work. So, I suggest to stick with my latest approach. It passes all the tests and don't break SwingSet2. >> >>> BTW Probably implementation of LWWindowPeer.setTextured() should call the updateOpaque() as well. >> >> I'll add this change > > How to reproduce that artifact? 1. Run SwingSet2 2. Click on all tabs starting from the second one 3. On the tab with swing tree control try to expand some tree nodes -> you'll see black rectangles while performing the clicks It may not be reproduced on a first attempt. On my machine it's reproducible with probability at least 50% ------------- PR: https://git.openjdk.java.net/jdk/pull/4946 From aivanov at openjdk.java.net Tue Aug 3 21:22:36 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Tue, 3 Aug 2021 21:22:36 GMT Subject: RFR: 8271456: Avoid looking up standard charsets in "java.desktop" module [v2] In-Reply-To: <_b2JI_4pIcqDyEX0gBXAkD4DzzL3V2IOinLOq2dGksU=.3a99501e-1444-4298-b695-1519a8a2e227@github.com> References: <_b2JI_4pIcqDyEX0gBXAkD4DzzL3V2IOinLOq2dGksU=.3a99501e-1444-4298-b695-1519a8a2e227@github.com> Message-ID: On Tue, 3 Aug 2021 19:37:04 GMT, Sergey Bylokhov wrote: >> This is a request to clean up a desktop module as was done in JDK-8233884 for "java.base" module. >> >> In many places standard charsets are looked up via their names, for example: >> absolutePath.getBytes("UTF-8"); >> >> This could be done more efficiently(x20 time faster) with use of java.nio.charset.StandardCharsets: >> absolutePath.getBytes(StandardCharsets.UTF_8); >> >> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant. >> >> Tested by the desktop headless/headful tests on linux/windows. > > Sergey Bylokhov 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 two additional commits since the last revision: > > - Merge branch 'master' into JDK-8271456 > - Initial fix for JDK-8271456 Marked as reviewed by aivanov (Reviewer). src/java.desktop/windows/classes/sun/awt/windows/WDataTransferer.java line 270: > 268: charset = new String((byte[])localeTransferable. > 269: getTransferData(javaTextEncodingFlavor), > 270: StandardCharsets.UTF_8); Suggestion: getTransferData(javaTextEncodingFlavor), StandardCharsets.UTF_8); The parameter on the second line should probably be aligned with the first parameter as it's done in the snippet above. ------------- PR: https://git.openjdk.java.net/jdk/pull/4951 From serb at openjdk.java.net Tue Aug 3 21:42:33 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Tue, 3 Aug 2021 21:42:33 GMT Subject: RFR: 8271456: Avoid looking up standard charsets in "java.desktop" module [v2] In-Reply-To: References: <_b2JI_4pIcqDyEX0gBXAkD4DzzL3V2IOinLOq2dGksU=.3a99501e-1444-4298-b695-1519a8a2e227@github.com> Message-ID: On Tue, 3 Aug 2021 21:18:40 GMT, Alexey Ivanov wrote: >> Sergey Bylokhov 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 two additional commits since the last revision: >> >> - Merge branch 'master' into JDK-8271456 >> - Initial fix for JDK-8271456 > > src/java.desktop/windows/classes/sun/awt/windows/WDataTransferer.java line 270: > >> 268: charset = new String((byte[])localeTransferable. >> 269: getTransferData(javaTextEncodingFlavor), >> 270: StandardCharsets.UTF_8); > > Suggestion: > > getTransferData(javaTextEncodingFlavor), > StandardCharsets.UTF_8); > > The parameter on the second line should probably be aligned with the first parameter as it's done in the snippet above. it is aligned already, the StandardCharsets.UTF_8 is parameter of "new String()", not the getTransferData. ------------- PR: https://git.openjdk.java.net/jdk/pull/4951 From aivanov at openjdk.java.net Tue Aug 3 21:57:31 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Tue, 3 Aug 2021 21:57:31 GMT Subject: RFR: 8271456: Avoid looking up standard charsets in "java.desktop" module [v2] In-Reply-To: References: <_b2JI_4pIcqDyEX0gBXAkD4DzzL3V2IOinLOq2dGksU=.3a99501e-1444-4298-b695-1519a8a2e227@github.com> Message-ID: <4RktX4CxkaDcFgd7NqmaEM5BbHnKYkpeE2EnYiOoux0=.2b753022-90b6-48fc-9c17-3a87eda87606@github.com> On Tue, 3 Aug 2021 21:39:14 GMT, Sergey Bylokhov wrote: >> src/java.desktop/windows/classes/sun/awt/windows/WDataTransferer.java line 270: >> >>> 268: charset = new String((byte[])localeTransferable. >>> 269: getTransferData(javaTextEncodingFlavor), >>> 270: StandardCharsets.UTF_8); >> >> Suggestion: >> >> getTransferData(javaTextEncodingFlavor), >> StandardCharsets.UTF_8); >> >> The parameter on the second line should probably be aligned with the first parameter as it's done in the snippet above. > > it is aligned already, the StandardCharsets.UTF_8 is parameter of "new String()", not the getTransferData. Ah, right! But it's confusing: it looks as if `StandardCharsets.UTF_8` is a parameter to `getTransferData`. Maybe avoid breaking the line and leave `UTF_8` on the same line? If you import `UTF_8` and `UTF_16LE` statically, line break is unnecessary. ------------- PR: https://git.openjdk.java.net/jdk/pull/4951 From serb at openjdk.java.net Tue Aug 3 22:06:29 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Tue, 3 Aug 2021 22:06:29 GMT Subject: RFR: 8271456: Avoid looking up standard charsets in "java.desktop" module [v2] In-Reply-To: <4RktX4CxkaDcFgd7NqmaEM5BbHnKYkpeE2EnYiOoux0=.2b753022-90b6-48fc-9c17-3a87eda87606@github.com> References: <_b2JI_4pIcqDyEX0gBXAkD4DzzL3V2IOinLOq2dGksU=.3a99501e-1444-4298-b695-1519a8a2e227@github.com> <4RktX4CxkaDcFgd7NqmaEM5BbHnKYkpeE2EnYiOoux0=.2b753022-90b6-48fc-9c17-3a87eda87606@github.com> Message-ID: On Tue, 3 Aug 2021 21:54:08 GMT, Alexey Ivanov wrote: >> it is aligned already, the StandardCharsets.UTF_8 is parameter of "new String()", not the getTransferData. > > Ah, right! > But it's confusing: it looks as if `StandardCharsets.UTF_8` is a parameter to `getTransferData`. Maybe avoid breaking the line and leave `UTF_8` on the same line? If you import `UTF_8` and `UTF_16LE` statically, line break is unnecessary. I am fine to do that, if there are no objections I can change the whole fix. ------------- PR: https://git.openjdk.java.net/jdk/pull/4951 From aivanov at openjdk.java.net Tue Aug 3 22:45:27 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Tue, 3 Aug 2021 22:45:27 GMT Subject: RFR: 8271456: Avoid looking up standard charsets in "java.desktop" module [v2] In-Reply-To: References: <_b2JI_4pIcqDyEX0gBXAkD4DzzL3V2IOinLOq2dGksU=.3a99501e-1444-4298-b695-1519a8a2e227@github.com> <4RktX4CxkaDcFgd7NqmaEM5BbHnKYkpeE2EnYiOoux0=.2b753022-90b6-48fc-9c17-3a87eda87606@github.com> Message-ID: On Tue, 3 Aug 2021 22:03:54 GMT, Sergey Bylokhov wrote: > > I am fine to do that, if there are no objections I can change the whole fix. Modifying the entire changeset seems like an overkill. Using static imports in only one file is _inconsistent_, yet it makes the places where the encodings are used clearer. ------------- PR: https://git.openjdk.java.net/jdk/pull/4951 From serb at openjdk.java.net Tue Aug 3 23:35:55 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Tue, 3 Aug 2021 23:35:55 GMT Subject: RFR: 8271456: Avoid looking up standard charsets in "java.desktop" module [v3] In-Reply-To: References: Message-ID: > This is a request to clean up a desktop module as was done in JDK-8233884 for "java.base" module. > > In many places standard charsets are looked up via their names, for example: > absolutePath.getBytes("UTF-8"); > > This could be done more efficiently(x20 time faster) with use of java.nio.charset.StandardCharsets: > absolutePath.getBytes(StandardCharsets.UTF_8); > > The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant. > > Tested by the desktop headless/headful tests on linux/windows. Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision: static import StandardCharsets ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4951/files - new: https://git.openjdk.java.net/jdk/pull/4951/files/886264aa..e4e82c83 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4951&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4951&range=01-02 Stats: 245 lines in 31 files changed: 93 ins; 63 del; 89 mod Patch: https://git.openjdk.java.net/jdk/pull/4951.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4951/head:pull/4951 PR: https://git.openjdk.java.net/jdk/pull/4951 From serb at openjdk.java.net Tue Aug 3 23:42:55 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Tue, 3 Aug 2021 23:42:55 GMT Subject: RFR: 8271456: Avoid looking up standard charsets in "java.desktop" module [v2] In-Reply-To: References: <_b2JI_4pIcqDyEX0gBXAkD4DzzL3V2IOinLOq2dGksU=.3a99501e-1444-4298-b695-1519a8a2e227@github.com> <4RktX4CxkaDcFgd7NqmaEM5BbHnKYkpeE2EnYiOoux0=.2b753022-90b6-48fc-9c17-3a87eda87606@github.com> Message-ID: On Tue, 3 Aug 2021 22:42:55 GMT, Alexey Ivanov wrote: >> I am fine to do that, if there are no objections I can change the whole fix. > >> >> I am fine to do that, if there are no objections I can change the whole fix. > > Modifying the entire changeset seems like an overkill. > Using static imports in only one file is _inconsistent_, yet it makes the places where the encodings are used clearer. Updated ------------- PR: https://git.openjdk.java.net/jdk/pull/4951 From serb at openjdk.java.net Tue Aug 3 23:42:55 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Tue, 3 Aug 2021 23:42:55 GMT Subject: RFR: 8271456: Avoid looking up standard charsets in "java.desktop" module [v4] In-Reply-To: References: Message-ID: > This is a request to clean up a desktop module as was done in JDK-8233884 for "java.base" module. > > In many places standard charsets are looked up via their names, for example: > absolutePath.getBytes("UTF-8"); > > This could be done more efficiently(x20 time faster) with use of java.nio.charset.StandardCharsets: > absolutePath.getBytes(StandardCharsets.UTF_8); > > The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant. > > Tested by the desktop headless/headful tests on linux/windows. Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision: Update IPPPrintService.java ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4951/files - new: https://git.openjdk.java.net/jdk/pull/4951/files/e4e82c83..47ed1e81 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4951&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4951&range=02-03 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/4951.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4951/head:pull/4951 PR: https://git.openjdk.java.net/jdk/pull/4951 From psadhukhan at openjdk.java.net Wed Aug 4 05:09:30 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Wed, 4 Aug 2021 05:09:30 GMT Subject: RFR: 8270116: Expand ButtonGroupLayoutTraversalTest.java to run in all LaFs, including Aqua on macOS In-Reply-To: References: Message-ID: On Tue, 3 Aug 2021 18:30:09 GMT, rajat mahajan wrote: >> test/jdk/java/awt/Focus/FocusTraversalPolicy/ButtonGroupLayoutTraversal/ButtonGroupLayoutTraversalTest.java line 54: >> >>> 52: public class ButtonGroupLayoutTraversalTest { >>> 53: >>> 54: private static final int nx = 3; >> >> Normally, as per coding standard, for static final modifier, the variable should be named in CAPS...but is there any need of making it final? > > @prsadhuk I did what you asked, do you have any more questions or comments ?, if not could you please approve this PR, thanks. I still think nx, ny should be made CAPS...It seems to be the case for static final constant variables in java/awt test folder...I don't think it will increase noise as it will impact only in l57 ------------- PR: https://git.openjdk.java.net/jdk/pull/4937 From pbansal at openjdk.java.net Wed Aug 4 07:26:40 2021 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Wed, 4 Aug 2021 07:26:40 GMT Subject: RFR: 8267385: Create NSAccessibilityElement implementation for JavaComponentAccessibility [v9] In-Reply-To: <_6TBLlVpkwjyUYmfn-Yhij_kSAVWtSvEd-kVJMTiy48=.6244371c-dc44-4c4f-b8d6-0bf17ae78668@github.com> References: <0N6YS5JRnmBXewFWAvMpuVUFJPaetSS1d9WNCuBcw5c=.d84596a3-66a9-4627-8eab-f65ec7b00eb7@github.com> <_6TBLlVpkwjyUYmfn-Yhij_kSAVWtSvEd-kVJMTiy48=.6244371c-dc44-4c4f-b8d6-0bf17ae78668@github.com> Message-ID: On Mon, 2 Aug 2021 09:00:14 GMT, Artem Semenov wrote: >> 8267385: Create NSAccessibilityElement implementation for JavaComponentAccessibility >> This pull request contains solutions for the following tickets: >> * JDK-8267385 Create NSAccessibilityElement implementation for JavaComponentAccessibility; >> * JDK-8262031 Create implementation for NSAccessibilityNavigableStaticText protocol; >> * JDK-8264287 Create implementation for NSAccessibilityComboBox protocol peer; >> * JDK-8264303 Create implementation for NSAccessibilityTabGroup protocol peer; >> * JDK-8264292 Create implementation for NSAccessibilityList protocol peer; >> * JDK-8267387 Create implementation for NSAccessibilityOutline protocol; >> * JDK-8267388 Create implementation for NSAccessibilityTable protocol. > > Artem Semenov has updated the pull request incrementally with one additional commit since the last revision: > > 1. Fixed problems with vertical navigation in table cells; > 2. I suggest doing the opposite, leave the CHECK_EXCEPTION and remove the chech and the logging. The CHECK_EXCEPTION is better since it can be configured via properties, and it will chech itself on what thread the current code is executed. I tested the latest version and all the problems I had mentioned earlier are no longer present. I also used few components like Combobox, Sliders, Buttons etc and things look good. As Alex mentioned, if there are small issues present, they can be fixed later in follow up bugs. ------------- Marked as reviewed by pbansal (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4412 From github.com+36081106+savoptik at openjdk.java.net Wed Aug 4 09:31:34 2021 From: github.com+36081106+savoptik at openjdk.java.net (Artem Semenov) Date: Wed, 4 Aug 2021 09:31:34 GMT Subject: RFR: 8267385: Create NSAccessibilityElement implementation for JavaComponentAccessibility [v9] In-Reply-To: References: <0N6YS5JRnmBXewFWAvMpuVUFJPaetSS1d9WNCuBcw5c=.d84596a3-66a9-4627-8eab-f65ec7b00eb7@github.com> Message-ID: On Mon, 2 Aug 2021 21:56:37 GMT, Sergey Bylokhov wrote: >> Yes, this will not work with a custom list not inherited from JList. Unfortunately AccessibleJList is not perfect and the functionality you need is not there. >> If you have a better solution, please share it. - Could you please advice on what we can do here? > > This is what I meant in the first message, "a11y interface miss setSelectedIndex method". I suggest filing a separate issue to accumulate such use cases and then fix them by adding additional methods to a11y interfaces. Probably something similar will be found in the Table/etc. Done. [JDK-8271846](https://bugs.openjdk.java.net/browse/JDK-8271846) ------------- PR: https://git.openjdk.java.net/jdk/pull/4412 From aivanov at openjdk.java.net Wed Aug 4 14:25:35 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Wed, 4 Aug 2021 14:25:35 GMT Subject: RFR: 8271456: Avoid looking up standard charsets in "java.desktop" module [v4] In-Reply-To: References: Message-ID: On Tue, 3 Aug 2021 23:42:55 GMT, Sergey Bylokhov wrote: >> This is a request to clean up a desktop module as was done in JDK-8233884 for "java.base" module. >> >> In many places standard charsets are looked up via their names, for example: >> absolutePath.getBytes("UTF-8"); >> >> This could be done more efficiently(x20 time faster) with use of java.nio.charset.StandardCharsets: >> absolutePath.getBytes(StandardCharsets.UTF_8); >> >> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant. >> >> Tested by the desktop headless/headful tests on linux/windows. > > Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision: > > Update IPPPrintService.java I admit I prefer static imports in this case: the code is shorter and is as clear. It's pretty obvious where the encoding comes from. ------------- Marked as reviewed by aivanov (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4951 From aivanov at openjdk.java.net Wed Aug 4 14:38:32 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Wed, 4 Aug 2021 14:38:32 GMT Subject: RFR: 8270116: Expand ButtonGroupLayoutTraversalTest.java to run in all LaFs, including Aqua on macOS In-Reply-To: References: Message-ID: On Wed, 4 Aug 2021 05:06:13 GMT, Prasanta Sadhukhan wrote: >> @prsadhuk I did what you asked, do you have any more questions or comments ?, if not could you please approve this PR, thanks. > > I still think nx, ny should be made CAPS...It seems to be the case for static final constant variables in java/awt test folder...I don't think it will increase noise as it will impact only in l57 It will affect more lines; these constants are used in for-loops to move focus between buttons as well as to validate the results. Let it be. ------------- PR: https://git.openjdk.java.net/jdk/pull/4937 From github.com+87324768+lawrence-andrew at openjdk.java.net Wed Aug 4 14:38:50 2021 From: github.com+87324768+lawrence-andrew at openjdk.java.net (lawrence.andrews) Date: Wed, 4 Aug 2021 14:38:50 GMT Subject: RFR: 8270312: Error: Not a test or directory containing tests: java/awt/print/PrinterJob/XparColor.java In-Reply-To: References: Message-ID: On Tue, 13 Jul 2021 14:57:30 GMT, lawrence.andrews wrote: > 1) This testcase was throwing error saying Error: Not a test or directory containing tests: java/awt/print/PrinterJob/XparColor.java > 2) Added @test tag so that this testcase can be run > 3) Since Applet is deprecated and its not supported any more in the future release remove applet and make the testcase to run as main > 4) Since this is a manual testcase instruction frame or dailog was not visible just print dialog was visible so fixed it. > 5) When the testcase was run via main method two print dialog was shown one was from main method and one more was from constructor. Fixed to show just one print dialog. > 6) Since JDK 17 introduce metal rendering touching the java2d code thought this testcase will be useful to checking the rendering. > > @shurymury Now this test will be executed both on metal and opengl ------------- PR: https://git.openjdk.java.net/jdk/pull/4769 From github.com+87324768+lawrence-andrew at openjdk.java.net Wed Aug 4 14:38:49 2021 From: github.com+87324768+lawrence-andrew at openjdk.java.net (lawrence.andrews) Date: Wed, 4 Aug 2021 14:38:49 GMT Subject: RFR: 8270312: Error: Not a test or directory containing tests: java/awt/print/PrinterJob/XparColor.java [v2] In-Reply-To: References: Message-ID: > 1) This testcase was throwing error saying Error: Not a test or directory containing tests: java/awt/print/PrinterJob/XparColor.java > 2) Added @test tag so that this testcase can be run > 3) Since Applet is deprecated and its not supported any more in the future release remove applet and make the testcase to run as main > 4) Since this is a manual testcase instruction frame or dailog was not visible just print dialog was visible so fixed it. > 5) When the testcase was run via main method two print dialog was shown one was from main method and one more was from constructor. Fixed to show just one print dialog. > 6) Since JDK 17 introduce metal rendering touching the java2d code thought this testcase will be useful to checking the rendering. > > @shurymury lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision: Added -Dsun.java2d.metal=true , test will be run both as metal as well as opengl ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4769/files - new: https://git.openjdk.java.net/jdk/pull/4769/files/a2682bb6..5400714b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4769&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4769&range=00-01 Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/4769.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4769/head:pull/4769 PR: https://git.openjdk.java.net/jdk/pull/4769 From serb at openjdk.java.net Wed Aug 4 18:48:32 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Wed, 4 Aug 2021 18:48:32 GMT Subject: Integrated: 8271456: Avoid looking up standard charsets in "java.desktop" module In-Reply-To: References: Message-ID: On Sun, 1 Aug 2021 07:07:21 GMT, Sergey Bylokhov wrote: > This is a request to clean up a desktop module as was done in JDK-8233884 for "java.base" module. > > In many places standard charsets are looked up via their names, for example: > absolutePath.getBytes("UTF-8"); > > This could be done more efficiently(x20 time faster) with use of java.nio.charset.StandardCharsets: > absolutePath.getBytes(StandardCharsets.UTF_8); > > The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant. > > Tested by the desktop headless/headful tests on linux/windows. This pull request has now been integrated. Changeset: 6b55ef3b Author: Sergey Bylokhov URL: https://git.openjdk.java.net/jdk/commit/6b55ef3b58ae405c46f440e06b5adb03cec3a500 Stats: 761 lines in 33 files changed: 337 ins; 269 del; 155 mod 8271456: Avoid looking up standard charsets in "java.desktop" module Reviewed-by: jdv, azvegint, aivanov ------------- PR: https://git.openjdk.java.net/jdk/pull/4951 From avu at openjdk.java.net Wed Aug 4 19:24:10 2021 From: avu at openjdk.java.net (Alexey Ushakov) Date: Wed, 4 Aug 2021 19:24:10 GMT Subject: RFR: 8266079: Lanai: AlphaComposite shows differences on Metal compared to OpenGL [v2] In-Reply-To: <7FfjAXZJPIzx2OfaLY8dlET6NVnF-XAiaAI7mJwNGeo=.2381d679-8860-4c79-a7bd-4749f10bb90e@github.com> References: <7FfjAXZJPIzx2OfaLY8dlET6NVnF-XAiaAI7mJwNGeo=.2381d679-8860-4c79-a7bd-4749f10bb90e@github.com> Message-ID: > Keep MTLLayer opacity in sync with window content view > Keep layer translucent for translucent windows Alexey Ushakov has updated the pull request incrementally with one additional commit since the last revision: 8266079: Lanai: AlphaComposite shows differences on Metal compared to OpenGL Update opacity on textured property change ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4946/files - new: https://git.openjdk.java.net/jdk/pull/4946/files/2a77de60..9324a279 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4946&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4946&range=00-01 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4946.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4946/head:pull/4946 PR: https://git.openjdk.java.net/jdk/pull/4946 From prr at openjdk.java.net Wed Aug 4 20:10:52 2021 From: prr at openjdk.java.net (Phil Race) Date: Wed, 4 Aug 2021 20:10:52 GMT Subject: RFR: 8268824: Remove unused jdk.accessibility APIs deprecated for removal in JDK 9 [v2] In-Reply-To: References: Message-ID: On Wed, 21 Jul 2021 07:19:02 GMT, Sergey Bylokhov wrote: >> Phil Race has updated the pull request incrementally with one additional commit since the last revision: >> >> 8268824: Remove unused jdk.accessibility APIs deprecated for removal in JDK 9 > > src/jdk.accessibility/share/classes/com/sun/java/accessibility/util/AWTEventMonitor.java line 53: > >> 51: public AWTEventMonitor() {} >> 52: >> 53: static private Component componentWithFocus_private = null; > > Can we rename the "new" "xx_private" fields to the shorter version? The javadoc for the protected fields can be applied to the "private version"(but w/o @Deprecated tag). > > So in fact we can change "protected" to the "private", drop the "@Deprecated" tags, and delete the "xx_private" versions of the fields. I don't think the javadoc is needed since these are now private fields. I can however rename them to remove _private. ------------- PR: https://git.openjdk.java.net/jdk/pull/4845 From prr at openjdk.java.net Wed Aug 4 20:10:50 2021 From: prr at openjdk.java.net (Phil Race) Date: Wed, 4 Aug 2021 20:10:50 GMT Subject: RFR: 8268824: Remove unused jdk.accessibility APIs deprecated for removal in JDK 9 [v2] In-Reply-To: References: Message-ID: <8s65wwjUmv_ScFNISHRBT18K23VVCFxxq9e06maXvKQ=.aa16fa79-f8a0-4d1e-ba60-4954923f86c6@github.com> > These fields > - have not been used by the implementation since JDK8, > - are not supposed to be used by applications, > - have been deprecated for removal since JDK 9 > - are non-standard, JDK not Java, classes > - very few clients are expected to be using these classes : just those implementing ATs > > > The CSR for this is https://bugs.openjdk.java.net/browse/JDK-8270918 Phil Race has updated the pull request incrementally with one additional commit since the last revision: 8268824: Remove unused jdk.accessibility APIs deprecated for removal in JDK 9 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4845/files - new: https://git.openjdk.java.net/jdk/pull/4845/files/ba3932f3..c376e501 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4845&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4845&range=00-01 Stats: 134 lines in 1 file changed: 0 ins; 0 del; 134 mod Patch: https://git.openjdk.java.net/jdk/pull/4845.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4845/head:pull/4845 PR: https://git.openjdk.java.net/jdk/pull/4845 From github.com+79671271+rajamah at openjdk.java.net Wed Aug 4 21:43:53 2021 From: github.com+79671271+rajamah at openjdk.java.net (rajat mahajan) Date: Wed, 4 Aug 2021 21:43:53 GMT Subject: RFR: 8270116: Expand ButtonGroupLayoutTraversalTest.java to run in all LaFs, including Aqua on macOS [v2] In-Reply-To: References: Message-ID: > Summary: Expanded ButtonGroupLayoutTraversalTest.java to run in all LAFs on all OS. Added synchronization for focusCnt. rajat mahajan has updated the pull request incrementally with one additional commit since the last revision: make variables with static final modifier CAPS, as per coding standard. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4937/files - new: https://git.openjdk.java.net/jdk/pull/4937/files/7f683d1e..b05f3d4a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4937&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4937&range=00-01 Stats: 10 lines in 1 file changed: 0 ins; 0 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/4937.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4937/head:pull/4937 PR: https://git.openjdk.java.net/jdk/pull/4937 From github.com+79671271+rajamah at openjdk.java.net Wed Aug 4 21:43:53 2021 From: github.com+79671271+rajamah at openjdk.java.net (rajat mahajan) Date: Wed, 4 Aug 2021 21:43:53 GMT Subject: RFR: 8270116: Expand ButtonGroupLayoutTraversalTest.java to run in all LaFs, including Aqua on macOS [v2] In-Reply-To: References: Message-ID: On Wed, 4 Aug 2021 14:35:34 GMT, Alexey Ivanov wrote: >> I still think nx, ny should be made CAPS...It seems to be the case for static final constant variables in java/awt test folder...I don't think it will increase noise as it will impact only in l57 > > It will affect more lines; these constants are used in for-loops to move focus between buttons as well as to validate the results. Let it be. Updated nx, ny with CAPS version. ------------- PR: https://git.openjdk.java.net/jdk/pull/4937 From serb at openjdk.java.net Wed Aug 4 23:09:29 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Wed, 4 Aug 2021 23:09:29 GMT Subject: RFR: 8266079: Lanai: AlphaComposite shows differences on Metal compared to OpenGL [v2] In-Reply-To: References: <7FfjAXZJPIzx2OfaLY8dlET6NVnF-XAiaAI7mJwNGeo=.2381d679-8860-4c79-a7bd-4749f10bb90e@github.com> Message-ID: On Tue, 3 Aug 2021 20:04:14 GMT, Alexey Ushakov wrote: >> How to reproduce that artifact? > > 1. Run SwingSet2 > 2. Click on all tabs starting from the second one > 3. On the tab with swing tree control try to expand some tree nodes -> you'll see black rectangles while performing the clicks > > It may not be reproduced on a first attempt. On my machine it's reproducible with probability at least 50% Thank you, looking into it. ------------- PR: https://git.openjdk.java.net/jdk/pull/4946 From serb at openjdk.java.net Wed Aug 4 23:14:34 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Wed, 4 Aug 2021 23:14:34 GMT Subject: RFR: 8268824: Remove unused jdk.accessibility APIs deprecated for removal in JDK 9 [v2] In-Reply-To: <8s65wwjUmv_ScFNISHRBT18K23VVCFxxq9e06maXvKQ=.aa16fa79-f8a0-4d1e-ba60-4954923f86c6@github.com> References: <8s65wwjUmv_ScFNISHRBT18K23VVCFxxq9e06maXvKQ=.aa16fa79-f8a0-4d1e-ba60-4954923f86c6@github.com> Message-ID: On Wed, 4 Aug 2021 20:10:50 GMT, Phil Race wrote: >> These fields >> - have not been used by the implementation since JDK8, >> - are not supposed to be used by applications, >> - have been deprecated for removal since JDK 9 >> - are non-standard, JDK not Java, classes >> - very few clients are expected to be using these classes : just those implementing ATs >> >> >> The CSR for this is https://bugs.openjdk.java.net/browse/JDK-8270918 > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8268824: Remove unused jdk.accessibility APIs deprecated for removal in JDK 9 Marked as reviewed by serb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4845 From yyang at openjdk.java.net Thu Aug 5 03:11:30 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Thu, 5 Aug 2021 03:11:30 GMT Subject: RFR: 8270058: Use Objects.check{Index, FromIndexSize} for java.desktop [v3] In-Reply-To: References: Message-ID: On Fri, 30 Jul 2021 08:59:31 GMT, Jayathirth D V wrote: >> Objects.checkIndex itself throws exceptions for wrong values. So this should be ok. No? > > We have specific message here like "Tab count" which we are not passing and will be helpful for debugging in future. Restored. ------------- PR: https://git.openjdk.java.net/jdk/pull/4718 From yyang at openjdk.java.net Thu Aug 5 03:11:30 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Thu, 5 Aug 2021 03:11:30 GMT Subject: RFR: 8270058: Use Objects.check{Index, FromIndexSize} for java.desktop [v3] In-Reply-To: References: Message-ID: On Thu, 22 Jul 2021 06:29:13 GMT, Yi Yang wrote: >> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase. >> >> As Mandy suggested, I create this PR for changes involving client code: >> >> src/java.desktop/share/classes/com/sun/media/sound/AudioFloatInputStream.java >> src/java.desktop/share/classes/javax/swing/JTabbedPane.java >> test/jdk/java/awt/print/PrinterJob/ImagePrinting/ClippedImages.java >> test/jdk/javax/imageio/AppletResourceTest.java >> test/jdk/javax/imageio/ImageReaderReadAll.java >> test/jdk/javax/imageio/metadata/IIOMetadataFormat/UserPluginMetadataFormatTest.java > > Yi Yang has updated the pull request incrementally with one additional commit since the last revision: > > typo Thanks @mrserb @prsadhuk @jayathirthrao and @pankaj-bansal for reviews! ------------- PR: https://git.openjdk.java.net/jdk/pull/4718 From yyang at openjdk.java.net Thu Aug 5 03:25:49 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Thu, 5 Aug 2021 03:25:49 GMT Subject: RFR: 8270058: Use Objects.check{Index, FromIndexSize} for java.desktop [v4] In-Reply-To: References: Message-ID: > After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase. > > As Mandy suggested, I create this PR for changes involving client code: > > src/java.desktop/share/classes/com/sun/media/sound/AudioFloatInputStream.java > src/java.desktop/share/classes/javax/swing/JTabbedPane.java > test/jdk/java/awt/print/PrinterJob/ImagePrinting/ClippedImages.java > test/jdk/javax/imageio/AppletResourceTest.java > test/jdk/javax/imageio/ImageReaderReadAll.java > test/jdk/javax/imageio/metadata/IIOMetadataFormat/UserPluginMetadataFormatTest.java Yi Yang has updated the pull request incrementally with one additional commit since the last revision: review from @jayathirthrao ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4718/files - new: https://git.openjdk.java.net/jdk/pull/4718/files/1db9e872..83ad6590 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4718&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4718&range=02-03 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4718.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4718/head:pull/4718 PR: https://git.openjdk.java.net/jdk/pull/4718 From jdv at openjdk.java.net Thu Aug 5 03:59:32 2021 From: jdv at openjdk.java.net (Jayathirth D V) Date: Thu, 5 Aug 2021 03:59:32 GMT Subject: RFR: 8270058: Use Objects.check{Index, FromIndexSize} for java.desktop [v4] In-Reply-To: References: Message-ID: On Thu, 5 Aug 2021 03:25:49 GMT, Yi Yang wrote: >> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase. >> >> As Mandy suggested, I create this PR for changes involving client code: >> >> src/java.desktop/share/classes/com/sun/media/sound/AudioFloatInputStream.java >> src/java.desktop/share/classes/javax/swing/JTabbedPane.java >> test/jdk/java/awt/print/PrinterJob/ImagePrinting/ClippedImages.java >> test/jdk/javax/imageio/AppletResourceTest.java >> test/jdk/javax/imageio/ImageReaderReadAll.java >> test/jdk/javax/imageio/metadata/IIOMetadataFormat/UserPluginMetadataFormatTest.java > > Yi Yang has updated the pull request incrementally with one additional commit since the last revision: > > review from @jayathirthrao Marked as reviewed by jdv (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4718 From psadhukhan at openjdk.java.net Thu Aug 5 05:24:28 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Thu, 5 Aug 2021 05:24:28 GMT Subject: RFR: 8270116: Expand ButtonGroupLayoutTraversalTest.java to run in all LaFs, including Aqua on macOS [v2] In-Reply-To: References: Message-ID: <7qcnGVby99w7-keaTNlqJHoR5_tP6MEJwdGZPzkRpPs=.6d5dbc1b-386d-424a-a41e-7dc75cba47f4@github.com> On Wed, 4 Aug 2021 21:43:53 GMT, rajat mahajan wrote: >> Summary: Expanded ButtonGroupLayoutTraversalTest.java to run in all LAFs on all OS. Added synchronization for focusCnt. > > rajat mahajan has updated the pull request incrementally with one additional commit since the last revision: > > make variables with static final modifier CAPS, as per coding standard. Marked as reviewed by psadhukhan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4937 From yyang at openjdk.java.net Thu Aug 5 06:42:34 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Thu, 5 Aug 2021 06:42:34 GMT Subject: Integrated: 8270058: Use Objects.check{Index, FromIndexSize} for java.desktop In-Reply-To: References: Message-ID: On Thu, 8 Jul 2021 08:32:49 GMT, Yi Yang wrote: > After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase. > > As Mandy suggested, I create this PR for changes involving client code: > > src/java.desktop/share/classes/com/sun/media/sound/AudioFloatInputStream.java > src/java.desktop/share/classes/javax/swing/JTabbedPane.java > test/jdk/java/awt/print/PrinterJob/ImagePrinting/ClippedImages.java > test/jdk/javax/imageio/AppletResourceTest.java > test/jdk/javax/imageio/ImageReaderReadAll.java > test/jdk/javax/imageio/metadata/IIOMetadataFormat/UserPluginMetadataFormatTest.java This pull request has now been integrated. Changeset: ea9a5952 Author: Yi Yang URL: https://git.openjdk.java.net/jdk/commit/ea9a59520de45fe1c2a6706b2a924cbc856a06c6 Stats: 41 lines in 6 files changed: 7 ins; 19 del; 15 mod 8270058: Use Objects.check{Index,FromIndexSize} for java.desktop Reviewed-by: psadhukhan, pbansal, jdv ------------- PR: https://git.openjdk.java.net/jdk/pull/4718 From aivanov at openjdk.java.net Thu Aug 5 11:27:31 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Thu, 5 Aug 2021 11:27:31 GMT Subject: RFR: 8270116: Expand ButtonGroupLayoutTraversalTest.java to run in all LaFs, including Aqua on macOS [v2] In-Reply-To: References: Message-ID: <0UqktRfc4nkFPuNqnWVhnVhYTLInkKgRbN5FVqF-_xk=.be2d1523-2f64-42e7-b44b-d1a3fd9b591c@github.com> On Wed, 4 Aug 2021 21:43:53 GMT, rajat mahajan wrote: >> Summary: Expanded ButtonGroupLayoutTraversalTest.java to run in all LAFs on all OS. Added synchronization for focusCnt. > > rajat mahajan has updated the pull request incrementally with one additional commit since the last revision: > > make variables with static final modifier CAPS, as per coding standard. Marked as reviewed by aivanov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4937 From vdyakov at openjdk.java.net Thu Aug 5 16:07:31 2021 From: vdyakov at openjdk.java.net (Victor Dyakov) Date: Thu, 5 Aug 2021 16:07:31 GMT Subject: RFR: 8267385: Create NSAccessibilityElement implementation for JavaComponentAccessibility [v9] In-Reply-To: References: <0N6YS5JRnmBXewFWAvMpuVUFJPaetSS1d9WNCuBcw5c=.d84596a3-66a9-4627-8eab-f65ec7b00eb7@github.com> Message-ID: On Mon, 2 Aug 2021 05:45:35 GMT, Sergey Bylokhov wrote: >> As @ azuev-java canceled below this is not functional regression. >> However, cell navigation will be implemented later in [JDK-8271071](https://bugs.openjdk.java.net/browse/JDK-8271071). > > ok Ok ------------- PR: https://git.openjdk.java.net/jdk/pull/4412 From github.com+79671271+rajamah at openjdk.java.net Thu Aug 5 17:44:34 2021 From: github.com+79671271+rajamah at openjdk.java.net (rajat mahajan) Date: Thu, 5 Aug 2021 17:44:34 GMT Subject: Integrated: 8270116: Expand ButtonGroupLayoutTraversalTest.java to run in all LaFs, including Aqua on macOS In-Reply-To: References: Message-ID: <2gy8wioCL1MIpDkv0UVPcZBSWp8NO6hh0TGE3wsdj5Y=.5013b556-19ec-405c-9cb0-b58b63266afb@github.com> On Thu, 29 Jul 2021 20:29:31 GMT, rajat mahajan wrote: > Summary: Expanded ButtonGroupLayoutTraversalTest.java to run in all LAFs on all OS. Added synchronization for focusCnt. This pull request has now been integrated. Changeset: cb368802 Author: Rajat Mahajan Committer: Alexey Ivanov URL: https://git.openjdk.java.net/jdk/commit/cb368802815c465f8eef7aa930d6cbb6540d0fa8 Stats: 114 lines in 1 file changed: 44 ins; 28 del; 42 mod 8270116: Expand ButtonGroupLayoutTraversalTest.java to run in all LaFs, including Aqua on macOS Reviewed-by: psadhukhan, aivanov ------------- PR: https://git.openjdk.java.net/jdk/pull/4937 From alexsch at openjdk.java.net Thu Aug 5 19:23:27 2021 From: alexsch at openjdk.java.net (Alexander Scherbatiy) Date: Thu, 5 Aug 2021 19:23:27 GMT Subject: RFR: 8181571: printing to CUPS fails on mac sandbox app In-Reply-To: <63JwCGX6p50e5FOnMIuUEOUKrfIm4HkJXEO55VBeHWg=.ea74605e-ff56-4526-b2f8-a5d5f1fd8995@github.com> References: <2Mgxu1zmn4d0AJ1JsWHH4oO5PtUDtNfCQE8UYu7hkmc=.a080d861-8fec-4677-aa7b-dabdf431b5b4@github.com> <63JwCGX6p50e5FOnMIuUEOUKrfIm4HkJXEO55VBeHWg=.ea74605e-ff56-4526-b2f8-a5d5f1fd8995@github.com> Message-ID: On Wed, 28 Jul 2021 17:18:12 GMT, NikolayTach wrote: > [JDK-8247768 ](https://bugs.openjdk.java.net/browse/JDK-8247768) > Same here played 6 times yet moved, 8 issues missed. What is the relation between JDK-8247768 and the current pull request? Should something be updated in the pull request description? ------------- PR: https://git.openjdk.java.net/jdk/pull/4861 From github.com+87324768+lawrence-andrew at openjdk.java.net Fri Aug 6 15:17:48 2021 From: github.com+87324768+lawrence-andrew at openjdk.java.net (lawrence.andrews) Date: Fri, 6 Aug 2021 15:17:48 GMT Subject: RFR: 8270312: Error: Not a test or directory containing tests: java/awt/print/PrinterJob/XparColor.java [v3] In-Reply-To: References: Message-ID: <9TyU0eZWa6tLRCRchazdGiJZ9QOfF7XAaTN5xlAdU-s=.b0975dc4-4d1c-46f3-b0d8-7bc057a1a3a4@github.com> > 1) This testcase was throwing error saying Error: Not a test or directory containing tests: java/awt/print/PrinterJob/XparColor.java > 2) Added @test tag so that this testcase can be run > 3) Since Applet is deprecated and its not supported any more in the future release remove applet and make the testcase to run as main > 4) Since this is a manual testcase instruction frame or dailog was not visible just print dialog was visible so fixed it. > 5) When the testcase was run via main method two print dialog was shown one was from main method and one more was from constructor. Fixed to show just one print dialog. > 6) Since JDK 17 introduce metal rendering touching the java2d code thought this testcase will be useful to checking the rendering. > > @shurymury lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision: Fixed jcheck issue ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4769/files - new: https://git.openjdk.java.net/jdk/pull/4769/files/5400714b..fe4dc73d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4769&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4769&range=01-02 Stats: 10 lines in 1 file changed: 0 ins; 0 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/4769.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4769/head:pull/4769 PR: https://git.openjdk.java.net/jdk/pull/4769 From github.com+87324768+lawrence-andrew at openjdk.java.net Fri Aug 6 17:44:39 2021 From: github.com+87324768+lawrence-andrew at openjdk.java.net (lawrence.andrews) Date: Fri, 6 Aug 2021 17:44:39 GMT Subject: RFR: 8270331: [TESTBUG] Error: Not a test or directory containing tests: java/awt/print/PrinterJob/InitToBlack.java Message-ID: <6nU9tbBxyjpAPR8G72jAMJiRHOhM8yhqrtxKBKhfnc4=.fc28c161-ff74-4b39-b1c7-ec23591413ce@github.com> 1) Removed Testcase depending on InitToBlack.html file which makes the testcase to executed independently. 2) Removed Applet class dependent. 3) Moved applet/manual=yesno to main/manual InitToBlack @shurymury ------------- Commit messages: - 8270331:Error: Not a test or directory containing tests: java/awt/print/PrinterJob/InitToBlack.java Changes: https://git.openjdk.java.net/jdk/pull/5035/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5035&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8270331 Stats: 279 lines in 1 file changed: 264 ins; 0 del; 15 mod Patch: https://git.openjdk.java.net/jdk/pull/5035.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5035/head:pull/5035 PR: https://git.openjdk.java.net/jdk/pull/5035 From serb at openjdk.java.net Fri Aug 6 18:46:37 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Fri, 6 Aug 2021 18:46:37 GMT Subject: RFR: 8267385: Create NSAccessibilityElement implementation for JavaComponentAccessibility [v9] In-Reply-To: <_6TBLlVpkwjyUYmfn-Yhij_kSAVWtSvEd-kVJMTiy48=.6244371c-dc44-4c4f-b8d6-0bf17ae78668@github.com> References: <0N6YS5JRnmBXewFWAvMpuVUFJPaetSS1d9WNCuBcw5c=.d84596a3-66a9-4627-8eab-f65ec7b00eb7@github.com> <_6TBLlVpkwjyUYmfn-Yhij_kSAVWtSvEd-kVJMTiy48=.6244371c-dc44-4c4f-b8d6-0bf17ae78668@github.com> Message-ID: On Mon, 2 Aug 2021 09:00:14 GMT, Artem Semenov wrote: >> 8267385: Create NSAccessibilityElement implementation for JavaComponentAccessibility >> This pull request contains solutions for the following tickets: >> * JDK-8267385 Create NSAccessibilityElement implementation for JavaComponentAccessibility; >> * JDK-8262031 Create implementation for NSAccessibilityNavigableStaticText protocol; >> * JDK-8264287 Create implementation for NSAccessibilityComboBox protocol peer; >> * JDK-8264303 Create implementation for NSAccessibilityTabGroup protocol peer; >> * JDK-8264292 Create implementation for NSAccessibilityList protocol peer; >> * JDK-8267387 Create implementation for NSAccessibilityOutline protocol; >> * JDK-8267388 Create implementation for NSAccessibilityTable protocol. > > Artem Semenov has updated the pull request incrementally with one additional commit since the last revision: > > 1. Fixed problems with vertical navigation in table cells; > 2. I suggest doing the opposite, leave the CHECK_EXCEPTION and remove the chech and the logging. The CHECK_EXCEPTION is better since it can be configured via properties, and it will chech itself on what thread the current code is executed. Marked as reviewed by serb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4412 From serb at openjdk.java.net Sun Aug 8 23:32:30 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Sun, 8 Aug 2021 23:32:30 GMT Subject: RFR: 8266079: Lanai: AlphaComposite shows differences on Metal compared to OpenGL [v2] In-Reply-To: References: <7FfjAXZJPIzx2OfaLY8dlET6NVnF-XAiaAI7mJwNGeo=.2381d679-8860-4c79-a7bd-4749f10bb90e@github.com> Message-ID: On Wed, 4 Aug 2021 23:06:54 GMT, Sergey Bylokhov wrote: >> 1. Run SwingSet2 >> 2. Click on all tabs starting from the second one >> 3. On the tab with swing tree control try to expand some tree nodes -> you'll see black rectangles while performing the clicks >> >> It may not be reproduced on a first attempt. On my machine it's reproducible with probability at least 50% > > Thank you, looking into it. I check the steps below and was able to reproduce the same artifacts(black rectangles) in the tree tab with the current version of the fix. And I do not see a big difference between setting the layer to YES at the beginning or a little bit later, at the end, it will be opaque and artifacts occur. 1. Run SwingSet2 2. Click on all tabs starting from the second one, delay on each tab for the second or so 3. On the tab with swing tree control try to expand some tree nodes -> you'll see black rectangles while performing the clicks 4. Repeat from step 2 if no artifacts are visible ------------- PR: https://git.openjdk.java.net/jdk/pull/4946 From prr at openjdk.java.net Mon Aug 9 03:28:49 2021 From: prr at openjdk.java.net (Phil Race) Date: Mon, 9 Aug 2021 03:28:49 GMT Subject: RFR: 8272123: Problem list 4 jtreg tests which regularly fail on macos-aach64 Message-ID: As per the bug comments, these tests fail too often on macOS arm. This will be too noisy for CI. So I would like to problem list them for mac-arm ------------- Commit messages: - 8272123: Problem list 4 jtreg tests which regularly fail on macos-aarch64 Changes: https://git.openjdk.java.net/jdk/pull/5044/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5044&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272123 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5044.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5044/head:pull/5044 PR: https://git.openjdk.java.net/jdk/pull/5044 From jdv at openjdk.java.net Mon Aug 9 03:53:30 2021 From: jdv at openjdk.java.net (Jayathirth D V) Date: Mon, 9 Aug 2021 03:53:30 GMT Subject: RFR: 8272123: Problem list 4 jtreg tests which regularly fail on macos-aach64 In-Reply-To: References: Message-ID: On Mon, 9 Aug 2021 03:17:20 GMT, Phil Race wrote: > As per the bug comments, these tests fail too often on macOS arm. > This will be too noisy for CI. So I would like to problem list them for mac-arm Marked as reviewed by jdv (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5044 From serb at openjdk.java.net Mon Aug 9 04:32:32 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Mon, 9 Aug 2021 04:32:32 GMT Subject: RFR: 8272123: Problem list 4 jtreg tests which regularly fail on macos-aach64 In-Reply-To: References: Message-ID: On Mon, 9 Aug 2021 03:17:20 GMT, Phil Race wrote: > As per the bug comments, these tests fail too often on macOS arm. > This will be too noisy for CI. So I would like to problem list them for mac-arm test/jdk/ProblemList.txt line 532: > 530: > 531: java/awt/Window/GetScreenLocation/GetScreenLocationTest.java 8225787 linux-x64 > 532: java/awt/Dialog/MakeWindowAlwaysOnTop/MakeWindowAlwaysOnTop.java 8252813 macosx-aarch64 Looks like this bug is a closed one, can it be open? ------------- PR: https://git.openjdk.java.net/jdk/pull/5044 From psadhukhan at openjdk.java.net Mon Aug 9 04:42:37 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Mon, 9 Aug 2021 04:42:37 GMT Subject: RFR: 8272123: Problem list 4 jtreg tests which regularly fail on macos-aach64 In-Reply-To: References: Message-ID: On Mon, 9 Aug 2021 04:28:28 GMT, Sergey Bylokhov wrote: >> As per the bug comments, these tests fail too often on macOS arm. >> This will be too noisy for CI. So I would like to problem list them for mac-arm > > test/jdk/ProblemList.txt line 532: > >> 530: >> 531: java/awt/Window/GetScreenLocation/GetScreenLocationTest.java 8225787 linux-x64 >> 532: java/awt/Dialog/MakeWindowAlwaysOnTop/MakeWindowAlwaysOnTop.java 8252813 macosx-aarch64 > > Looks like this bug is a closed one, can it be open? Maybe we should use JDK-8266243 instead. Other one has other tests as well. ------------- PR: https://git.openjdk.java.net/jdk/pull/5044 From github.com+741251+turbanoff at openjdk.java.net Mon Aug 9 07:19:35 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Mon, 9 Aug 2021 07:19:35 GMT Subject: RFR: 8269130: Replace usages of Collection.toArray() with Collection.toArray(T[]) to avoid redundant array copying In-Reply-To: References: Message-ID: On Mon, 26 Jul 2021 19:55:09 GMT, Brett Okken wrote: >> I found few places, where code initially perform `Object[] Colleciton.toArray()` call and then manually copy array into another array with required type. >> This PR cleanups such places to more shorter call `T[] Collection.toArray(T[])`. > > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/SystemDictionaryHelper.java line 92: > >> 90: } >> 91: >> 92: InstanceKlass[] searchResult = tmp.toArray(new InstanceKlass[0]); > > Is it too far outside the scope of these changes to make `tmp` an `ArrayList` rather than a `Vector`? I'll create separate PRs to migrate Vector usages to ArrayList. ------------- PR: https://git.openjdk.java.net/jdk/pull/4487 From github.com+741251+turbanoff at openjdk.java.net Mon Aug 9 07:21:47 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Mon, 9 Aug 2021 07:21:47 GMT Subject: RFR: 8271603: Unnecessary Vector usage in java.desktop Message-ID: Usage of thread-safe collection `Vector` is unnecessary. It's recommended to use `ArrayList` if a thread-safe implementation is not needed. In post-BiasedLocking times, this is gets worse, as every access is synchronized. I checked only places where `Vector` was used as local variable. ------------- Commit messages: - [PATCH] Unnecessary Vector usage in java.desktop - [PATCH] Unnecessary Vector usage in java.desktop Changes: https://git.openjdk.java.net/jdk/pull/4680/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4680&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271603 Stats: 51 lines in 5 files changed: 3 ins; 16 del; 32 mod Patch: https://git.openjdk.java.net/jdk/pull/4680.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4680/head:pull/4680 PR: https://git.openjdk.java.net/jdk/pull/4680 From github.com+10835776+stsypanov at openjdk.java.net Mon Aug 9 07:21:47 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 9 Aug 2021 07:21:47 GMT Subject: RFR: 8271603: Unnecessary Vector usage in java.desktop In-Reply-To: References: Message-ID: On Sun, 4 Jul 2021 20:42:41 GMT, Andrey Turbanov wrote: > Usage of thread-safe collection `Vector` is unnecessary. It's recommended to use `ArrayList` if a thread-safe implementation is not needed. In post-BiasedLocking times, this is gets worse, as every access is synchronized. > I checked only places where `Vector` was used as local variable. @turbanoff hi, I've filed an issue for this: https://bugs.openjdk.java.net/browse/JDK-8271603 src/java.desktop/share/classes/java/awt/Menu.java line 489: > 487: } > 488: > 489: synchronized Enumeration shortcuts() { I'm not sure whether it's ok to change return type here, probably it'd be better to keep `Enumeration` and use `return Collections.enumeration(shortcuts);` in the last line src/java.desktop/share/classes/javax/sound/sampled/AudioSystem.java line 244: > 242: } > 243: > 244: return list.toArray(new Line.Info[list.size()]); Shouldn't it be `new Line.Info[0]` as in the class below? ------------- PR: https://git.openjdk.java.net/jdk/pull/4680 From github.com+10835776+stsypanov at openjdk.java.net Mon Aug 9 07:21:49 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 9 Aug 2021 07:21:49 GMT Subject: RFR: 8271603: Unnecessary Vector usage in java.desktop In-Reply-To: References: Message-ID: On Mon, 5 Jul 2021 19:03:49 GMT, Andrey Turbanov wrote: >> src/java.desktop/share/classes/java/awt/Menu.java line 489: >> >>> 487: } >>> 488: >>> 489: synchronized Enumeration shortcuts() { >> >> I'm not sure whether it's ok to change return type here, probably it'd be better to keep `Enumeration` and use `return Collections.enumeration(shortcuts);` in the last line > > It's not a public API. As I see from other PR/commits changing package-private methods shouldn't be a problem. Even non-public method can be called via reflection, so I'd be cautios about changing return type ------------- PR: https://git.openjdk.java.net/jdk/pull/4680 From github.com+741251+turbanoff at openjdk.java.net Mon Aug 9 07:21:48 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Mon, 9 Aug 2021 07:21:48 GMT Subject: RFR: 8271603: Unnecessary Vector usage in java.desktop In-Reply-To: References: Message-ID: On Mon, 5 Jul 2021 14:03:18 GMT, ?????? ??????? wrote: >> Usage of thread-safe collection `Vector` is unnecessary. It's recommended to use `ArrayList` if a thread-safe implementation is not needed. In post-BiasedLocking times, this is gets worse, as every access is synchronized. >> I checked only places where `Vector` was used as local variable. > > src/java.desktop/share/classes/java/awt/Menu.java line 489: > >> 487: } >> 488: >> 489: synchronized Enumeration shortcuts() { > > I'm not sure whether it's ok to change return type here, probably it'd be better to keep `Enumeration` and use `return Collections.enumeration(shortcuts);` in the last line It's not a public API. As I see from other PR/commits changing package-private methods shouldn't be a problem. ------------- PR: https://git.openjdk.java.net/jdk/pull/4680 From serb at openjdk.java.net Mon Aug 9 07:21:49 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Mon, 9 Aug 2021 07:21:49 GMT Subject: RFR: 8271603: Unnecessary Vector usage in java.desktop In-Reply-To: References: Message-ID: On Sun, 4 Jul 2021 20:42:41 GMT, Andrey Turbanov wrote: > Usage of thread-safe collection `Vector` is unnecessary. It's recommended to use `ArrayList` if a thread-safe implementation is not needed. In post-BiasedLocking times, this is gets worse, as every access is synchronized. > I checked only places where `Vector` was used as local variable. src/java.desktop/share/classes/java/awt/MenuBar.java line 348: > 346: Iterator e = getMenu(i).shortcuts(); > 347: while (e.hasNext()) { > 348: shortcuts.addElement(e.next()); I think it is fine to replace the Enumeration with the Iterator in most of the places, but here we will get a kind of mix of both, since we cannot remove the usage of Enumeration in the return time. src/java.desktop/share/classes/javax/print/MimeType.java line 576: > 574: ArrayList thePieces = new ArrayList<>(); > 575: boolean mediaTypeIsText; > 576: boolean parameterNameIsCharset; Default values might be removed as a separate cleanup. ------------- PR: https://git.openjdk.java.net/jdk/pull/4680 From serb at openjdk.java.net Mon Aug 9 07:21:50 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Mon, 9 Aug 2021 07:21:50 GMT Subject: RFR: 8271603: Unnecessary Vector usage in java.desktop In-Reply-To: References: Message-ID: On Mon, 5 Jul 2021 14:00:07 GMT, ?????? ??????? wrote: >> Usage of thread-safe collection `Vector` is unnecessary. It's recommended to use `ArrayList` if a thread-safe implementation is not needed. In post-BiasedLocking times, this is gets worse, as every access is synchronized. >> I checked only places where `Vector` was used as local variable. > > src/java.desktop/share/classes/javax/sound/sampled/AudioSystem.java line 244: > >> 242: } >> 243: >> 244: return list.toArray(new Line.Info[list.size()]); > > Shouldn't it be `new Line.Info[0]` as in the class below? It looks fine to change. ------------- PR: https://git.openjdk.java.net/jdk/pull/4680 From github.com+741251+turbanoff at openjdk.java.net Mon Aug 9 07:22:32 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Mon, 9 Aug 2021 07:22:32 GMT Subject: RFR: 8269130: Replace usages of Collection.toArray() with Collection.toArray(T[]) to avoid redundant array copying In-Reply-To: References: Message-ID: On Mon, 26 Jul 2021 19:15:55 GMT, Brett Okken wrote: >> I found few places, where code initially perform `Object[] Colleciton.toArray()` call and then manually copy array into another array with required type. >> This PR cleanups such places to more shorter call `T[] Collection.toArray(T[])`. > > src/java.base/share/classes/java/security/Security.java line 656: > >> 654: return null; >> 655: >> 656: return candidates.toArray(new Provider[0]); > > Is this called often enough to warrant creating a constant of `new Provider[0]` (benefits of this covered in the _Wisdom of the Ancients_ blog linked)? May be yes, may be not. I like `0`-sized array approach more. 1. It looks clearer and easier to read 2. It should be faster than original code anyway ------------- PR: https://git.openjdk.java.net/jdk/pull/4487 From prr at openjdk.java.net Mon Aug 9 15:06:55 2021 From: prr at openjdk.java.net (Phil Race) Date: Mon, 9 Aug 2021 15:06:55 GMT Subject: RFR: 8272123: Problem list 4 jtreg tests which regularly fail on macos-aach64 [v2] In-Reply-To: References: Message-ID: > As per the bug comments, these tests fail too often on macOS arm. > This will be too noisy for CI. So I would like to problem list them for mac-arm Phil Race has updated the pull request incrementally with one additional commit since the last revision: 8272123: Problem list 4 jtreg tests which regularly fail on macos-aarch64 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5044/files - new: https://git.openjdk.java.net/jdk/pull/5044/files/3cabf620..ecbbca3d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5044&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5044&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5044.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5044/head:pull/5044 PR: https://git.openjdk.java.net/jdk/pull/5044 From prr at openjdk.java.net Mon Aug 9 15:06:55 2021 From: prr at openjdk.java.net (Phil Race) Date: Mon, 9 Aug 2021 15:06:55 GMT Subject: RFR: 8272123: Problem list 4 jtreg tests which regularly fail on macos-aach64 [v2] In-Reply-To: References: Message-ID: <8vTTZFCJKpGIPriTxdL5pyNa9Rlxh_maNZ9_AZiJSKc=.ee728df0-e20f-4193-9bdb-765c36ec6141@github.com> On Mon, 9 Aug 2021 04:39:02 GMT, Prasanta Sadhukhan wrote: > Maybe we should use JDK-8266243 instead. Other one has other tests as well. I can do that. Somehow my search missed that as an option. > Looks like this bug is a closed one, can it be open? I think it can be open but it won't be listed here with the changeI just made to reference 8266243 ------------- PR: https://git.openjdk.java.net/jdk/pull/5044 From psadhukhan at openjdk.java.net Mon Aug 9 15:22:34 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Mon, 9 Aug 2021 15:22:34 GMT Subject: RFR: 8272123: Problem list 4 jtreg tests which regularly fail on macos-aach64 [v2] In-Reply-To: References: Message-ID: On Mon, 9 Aug 2021 15:06:55 GMT, Phil Race wrote: >> As per the bug comments, these tests fail too often on macOS arm. >> This will be too noisy for CI. So I would like to problem list them for mac-arm > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8272123: Problem list 4 jtreg tests which regularly fail on macos-aarch64 Marked as reviewed by psadhukhan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5044 From prr at openjdk.java.net Mon Aug 9 16:01:37 2021 From: prr at openjdk.java.net (Phil Race) Date: Mon, 9 Aug 2021 16:01:37 GMT Subject: Integrated: 8272123: Problem list 4 jtreg tests which regularly fail on macos-aarch64 In-Reply-To: References: Message-ID: <1i8F6oTq_1WfVRbdhod0iy-Bvq2RHztFLZDM2dLrF5w=.c6364a09-230e-4229-a43f-635d8f567d6d@github.com> On Mon, 9 Aug 2021 03:17:20 GMT, Phil Race wrote: > As per the bug comments, these tests fail too often on macOS arm. > This will be too noisy for CI. So I would like to problem list them for mac-arm This pull request has now been integrated. Changeset: 0ac2be9b Author: Phil Race URL: https://git.openjdk.java.net/jdk/commit/0ac2be9b35c56b4b1574cf03fe81111d3f39bedb Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod 8272123: Problem list 4 jtreg tests which regularly fail on macos-aarch64 Reviewed-by: jdv, psadhukhan ------------- PR: https://git.openjdk.java.net/jdk/pull/5044 From github.com+36081106+savoptik at openjdk.java.net Mon Aug 9 16:25:43 2021 From: github.com+36081106+savoptik at openjdk.java.net (Artem Semenov) Date: Mon, 9 Aug 2021 16:25:43 GMT Subject: Integrated: 8267385: Create NSAccessibilityElement implementation for JavaComponentAccessibility In-Reply-To: <0N6YS5JRnmBXewFWAvMpuVUFJPaetSS1d9WNCuBcw5c=.d84596a3-66a9-4627-8eab-f65ec7b00eb7@github.com> References: <0N6YS5JRnmBXewFWAvMpuVUFJPaetSS1d9WNCuBcw5c=.d84596a3-66a9-4627-8eab-f65ec7b00eb7@github.com> Message-ID: <_IyhOwEBryM9h8AAIb5LH7tKqa3Cve3hC_Rm0P-0Ztg=.7fb99882-3d05-42cd-8116-35e78b1caae8@github.com> On Tue, 8 Jun 2021 13:06:53 GMT, Artem Semenov wrote: > 8267385: Create NSAccessibilityElement implementation for JavaComponentAccessibility > This pull request contains solutions for the following tickets: > * JDK-8267385 Create NSAccessibilityElement implementation for JavaComponentAccessibility; > * JDK-8262031 Create implementation for NSAccessibilityNavigableStaticText protocol; > * JDK-8264287 Create implementation for NSAccessibilityComboBox protocol peer; > * JDK-8264303 Create implementation for NSAccessibilityTabGroup protocol peer; > * JDK-8264292 Create implementation for NSAccessibilityList protocol peer; > * JDK-8267387 Create implementation for NSAccessibilityOutline protocol; > * JDK-8267388 Create implementation for NSAccessibilityTable protocol. This pull request has now been integrated. Changeset: 9c6457f2 Author: Artem Semenov Committer: Anton Tarasov URL: https://git.openjdk.java.net/jdk/commit/9c6457f222e702b60fef4247c3e241c669eb9491 Stats: 4886 lines in 52 files changed: 4656 ins; 110 del; 120 mod 8267385: Create NSAccessibilityElement implementation for JavaComponentAccessibility 8262031: Create implementation for NSAccessibilityNavigableStaticText protocol 8264287: Create implementation for NSAccessibilityComboBox protocol peer 8264303: Create implementation for NSAccessibilityTabGroup protocol peer 8264292: Create implementation for NSAccessibilityList protocol peer 8267387: Create implementation for NSAccessibilityOutline protocol 8267388: Create implementation for NSAccessibilityTable protocol 8264286: Create implementation for NSAccessibilityColumn protocol peer 8264298: Create implementation for NSAccessibilityRow protocol peer 8264291: Create implementation for NSAccessibilityCell protocol peer Reviewed-by: kizune, pbansal, serb ------------- PR: https://git.openjdk.java.net/jdk/pull/4412 From ant at openjdk.java.net Mon Aug 9 16:37:46 2021 From: ant at openjdk.java.net (Anton Tarasov) Date: Mon, 9 Aug 2021 16:37:46 GMT Subject: RFR: 8267385: Create NSAccessibilityElement implementation for JavaComponentAccessibility [v9] In-Reply-To: <_6TBLlVpkwjyUYmfn-Yhij_kSAVWtSvEd-kVJMTiy48=.6244371c-dc44-4c4f-b8d6-0bf17ae78668@github.com> References: <0N6YS5JRnmBXewFWAvMpuVUFJPaetSS1d9WNCuBcw5c=.d84596a3-66a9-4627-8eab-f65ec7b00eb7@github.com> <_6TBLlVpkwjyUYmfn-Yhij_kSAVWtSvEd-kVJMTiy48=.6244371c-dc44-4c4f-b8d6-0bf17ae78668@github.com> Message-ID: On Mon, 2 Aug 2021 09:00:14 GMT, Artem Semenov wrote: >> 8267385: Create NSAccessibilityElement implementation for JavaComponentAccessibility >> This pull request contains solutions for the following tickets: >> * JDK-8267385 Create NSAccessibilityElement implementation for JavaComponentAccessibility; >> * JDK-8262031 Create implementation for NSAccessibilityNavigableStaticText protocol; >> * JDK-8264287 Create implementation for NSAccessibilityComboBox protocol peer; >> * JDK-8264303 Create implementation for NSAccessibilityTabGroup protocol peer; >> * JDK-8264292 Create implementation for NSAccessibilityList protocol peer; >> * JDK-8267387 Create implementation for NSAccessibilityOutline protocol; >> * JDK-8267388 Create implementation for NSAccessibilityTable protocol. > > Artem Semenov has updated the pull request incrementally with one additional commit since the last revision: > > 1. Fixed problems with vertical navigation in table cells; > 2. I suggest doing the opposite, leave the CHECK_EXCEPTION and remove the chech and the logging. The CHECK_EXCEPTION is better since it can be configured via properties, and it will chech itself on what thread the current code is executed. Thanks all for the thorough review and deep testing! ------------- PR: https://git.openjdk.java.net/jdk/pull/4412 From prr at openjdk.java.net Mon Aug 9 18:18:35 2021 From: prr at openjdk.java.net (Phil Race) Date: Mon, 9 Aug 2021 18:18:35 GMT Subject: Integrated: 8268824: Remove unused jdk.accessibility APIs deprecated for removal in JDK 9 In-Reply-To: References: Message-ID: On Tue, 20 Jul 2021 19:34:30 GMT, Phil Race wrote: > These fields > - have not been used by the implementation since JDK8, > - are not supposed to be used by applications, > - have been deprecated for removal since JDK 9 > - are non-standard, JDK not Java, classes > - very few clients are expected to be using these classes : just those implementing ATs > > > The CSR for this is https://bugs.openjdk.java.net/browse/JDK-8270918 This pull request has now been integrated. Changeset: 4548677e Author: Phil Race URL: https://git.openjdk.java.net/jdk/commit/4548677e89fb7807639602d29b87dcaabe7b6d8d Stats: 277 lines in 1 file changed: 0 ins; 143 del; 134 mod 8268824: Remove unused jdk.accessibility APIs deprecated for removal in JDK 9 Reviewed-by: serb ------------- PR: https://git.openjdk.java.net/jdk/pull/4845 From pbansal at openjdk.java.net Mon Aug 9 19:18:30 2021 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Mon, 9 Aug 2021 19:18:30 GMT Subject: RFR: 8270331: [TESTBUG] Error: Not a test or directory containing tests: java/awt/print/PrinterJob/InitToBlack.java In-Reply-To: <6nU9tbBxyjpAPR8G72jAMJiRHOhM8yhqrtxKBKhfnc4=.fc28c161-ff74-4b39-b1c7-ec23591413ce@github.com> References: <6nU9tbBxyjpAPR8G72jAMJiRHOhM8yhqrtxKBKhfnc4=.fc28c161-ff74-4b39-b1c7-ec23591413ce@github.com> Message-ID: On Fri, 6 Aug 2021 17:35:22 GMT, lawrence.andrews wrote: > 1) Removed Testcase depending on InitToBlack.html file which makes the testcase to executed independently. > 2) Removed Applet class dependent. > 3) Moved applet/manual=yesno to main/manual InitToBlack > > @shurymury There is no InitToBlack.html at the location of the test. I guess this test was some how moved from closed to open without moving the html file. That is why there is a InitToBlack.html file present at this location in closed repo without any corresponding .java file. I think you will need to delete that .html file also with a closed review. ------------- PR: https://git.openjdk.java.net/jdk/pull/5035 From github.com+87324768+lawrence-andrew at openjdk.java.net Mon Aug 9 19:23:29 2021 From: github.com+87324768+lawrence-andrew at openjdk.java.net (lawrence.andrews) Date: Mon, 9 Aug 2021 19:23:29 GMT Subject: RFR: 8270331: [TESTBUG] Error: Not a test or directory containing tests: java/awt/print/PrinterJob/InitToBlack.java In-Reply-To: <6nU9tbBxyjpAPR8G72jAMJiRHOhM8yhqrtxKBKhfnc4=.fc28c161-ff74-4b39-b1c7-ec23591413ce@github.com> References: <6nU9tbBxyjpAPR8G72jAMJiRHOhM8yhqrtxKBKhfnc4=.fc28c161-ff74-4b39-b1c7-ec23591413ce@github.com> Message-ID: On Fri, 6 Aug 2021 17:35:22 GMT, lawrence.andrews wrote: > 1) Removed Testcase depending on InitToBlack.html file which makes the testcase to executed independently. > 2) Removed Applet class dependent. > 3) Moved applet/manual=yesno to main/manual InitToBlack > > @shurymury Yes, I will file a bug and remove the InitToBlack.html file from closed. ------------- PR: https://git.openjdk.java.net/jdk/pull/5035 From prr at openjdk.java.net Tue Aug 10 00:08:32 2021 From: prr at openjdk.java.net (Phil Race) Date: Tue, 10 Aug 2021 00:08:32 GMT Subject: RFR: 8271603: Unnecessary Vector usage in java.desktop In-Reply-To: References: Message-ID: <6aLgG4zX_4XfiEmKpjHSYsUxPUKP50F5S4oJWSpdt4Y=.84c7399e-c0dc-46f6-a659-53969ad8b182@github.com> On Tue, 6 Jul 2021 11:32:18 GMT, ?????? ??????? wrote: >> It's not a public API. As I see from other PR/commits changing package-private methods shouldn't be a problem. > > Even non-public method can be called via reflection, so I'd be cautios about changing return type Apps should not be doing that and the desktop module along with most of the rest of the JDK is strongly encapsulated and illegal access will be denied. But given the relationship with the sole (?) caller I think this is not worth the churn. Not exactly an MT hotspot. I'd revert the changes here and in MenuBar. ------------- PR: https://git.openjdk.java.net/jdk/pull/4680 From prr at openjdk.java.net Tue Aug 10 00:08:31 2021 From: prr at openjdk.java.net (Phil Race) Date: Tue, 10 Aug 2021 00:08:31 GMT Subject: RFR: 8271603: Unnecessary Vector usage in java.desktop In-Reply-To: References: Message-ID: <_jCZjHKPkgh1QTGI_xpoQs0U6tFb9jgDSzav3DK9t8I=.cb2a0c00-48dc-4946-abef-6b2f4877149b@github.com> On Sun, 4 Jul 2021 20:42:41 GMT, Andrey Turbanov wrote: > Usage of thread-safe collection `Vector` is unnecessary. It's recommended to use `ArrayList` if a thread-safe implementation is not needed. In post-BiasedLocking times, this is gets worse, as every access is synchronized. > I checked only places where `Vector` was used as local variable. Changes requested by prr (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4680 From github.com+741251+turbanoff at openjdk.java.net Tue Aug 10 13:31:33 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Tue, 10 Aug 2021 13:31:33 GMT Subject: Integrated: 8269130: Replace usages of Collection.toArray() with Collection.toArray(T[]) to avoid redundant array copying In-Reply-To: References: Message-ID: On Mon, 14 Jun 2021 17:00:29 GMT, Andrey Turbanov wrote: > I found few places, where code initially perform `Object[] Colleciton.toArray()` call and then manually copy array into another array with required type. > This PR cleanups such places to more shorter call `T[] Collection.toArray(T[])`. This pull request has now been integrated. Changeset: 35b399ac Author: Andrey Turbanov Committer: Jayathirth D V URL: https://git.openjdk.java.net/jdk/commit/35b399aca810db63371ff65046f047ef0b955161 Stats: 70 lines in 8 files changed: 0 ins; 54 del; 16 mod 8269130: Replace usages of Collection.toArray() with Collection.toArray(T[]) to avoid redundant array copying Reviewed-by: mullan, serb ------------- PR: https://git.openjdk.java.net/jdk/pull/4487 From jdv at openjdk.java.net Tue Aug 10 13:38:31 2021 From: jdv at openjdk.java.net (Jayathirth D V) Date: Tue, 10 Aug 2021 13:38:31 GMT Subject: RFR: 8270312: Error: Not a test or directory containing tests: java/awt/print/PrinterJob/XparColor.java [v3] In-Reply-To: <9TyU0eZWa6tLRCRchazdGiJZ9QOfF7XAaTN5xlAdU-s=.b0975dc4-4d1c-46f3-b0d8-7bc057a1a3a4@github.com> References: <9TyU0eZWa6tLRCRchazdGiJZ9QOfF7XAaTN5xlAdU-s=.b0975dc4-4d1c-46f3-b0d8-7bc057a1a3a4@github.com> Message-ID: On Fri, 6 Aug 2021 15:17:48 GMT, lawrence.andrews wrote: >> 1) This testcase was throwing error saying Error: Not a test or directory containing tests: java/awt/print/PrinterJob/XparColor.java >> 2) Added @test tag so that this testcase can be run >> 3) Since Applet is deprecated and its not supported any more in the future release remove applet and make the testcase to run as main >> 4) Since this is a manual testcase instruction frame or dailog was not visible just print dialog was visible so fixed it. >> 5) When the testcase was run via main method two print dialog was shown one was from main method and one more was from constructor. Fixed to show just one print dialog. >> 6) Since JDK 17 introduce metal rendering touching the java2d code thought this testcase will be useful to checking the rendering. >> >> @shurymury > > lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision: > > Fixed jcheck issue Marked as reviewed by jdv (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4769 From serb at openjdk.java.net Tue Aug 10 23:05:44 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Tue, 10 Aug 2021 23:05:44 GMT Subject: RFR: 8267161 : Write automated test case for JDK-4479161 In-Reply-To: References: Message-ID: On Mon, 9 Aug 2021 18:36:07 GMT, lawrence.andrews wrote: > 1) Automated the manual test case. > 2) Removed html dependent file > 3) Removed javax.swing.JApplet dependent. > 4) Test case can be executed independently as well with jtreg framework. > 5) Added methods to know that JFrame and Other component is visible before starting the user action via Robot. > > @shurymury test/jdk/java/awt/im/4959409/bug4959409.java line 55: > 53: > 54: public JFrame createUIAndTest() throws Exception { > 55: final JFrame frame = new JFrame("Test bug4959409"); Please make sure that the Swing components, created/used/disposed on the EDT. ------------- PR: https://git.openjdk.java.net/jdk/pull/5058 From github.com+87324768+lawrence-andrew at openjdk.java.net Tue Aug 10 23:05:43 2021 From: github.com+87324768+lawrence-andrew at openjdk.java.net (lawrence.andrews) Date: Tue, 10 Aug 2021 23:05:43 GMT Subject: RFR: 8267161 : Write automated test case for JDK-4479161 Message-ID: 1) Automated the manual test case. 2) Removed html dependent file 3) Removed javax.swing.JApplet dependent. 4) Test case can be executed independently as well with jtreg framework. 5) Added methods to know that JFrame and Other component is visible before starting the user action via Robot. @shurymury ------------- Commit messages: - Creating swing components with in EDT - 8267161:Write automated test case for JDK-4479161 Changes: https://git.openjdk.java.net/jdk/pull/5058/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5058&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267161 Stats: 211 lines in 2 files changed: 129 ins; 50 del; 32 mod Patch: https://git.openjdk.java.net/jdk/pull/5058.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5058/head:pull/5058 PR: https://git.openjdk.java.net/jdk/pull/5058 From github.com+87324768+lawrence-andrew at openjdk.java.net Tue Aug 10 23:05:43 2021 From: github.com+87324768+lawrence-andrew at openjdk.java.net (lawrence.andrews) Date: Tue, 10 Aug 2021 23:05:43 GMT Subject: RFR: 8267161 : Write automated test case for JDK-4479161 In-Reply-To: References: Message-ID: On Mon, 9 Aug 2021 18:36:07 GMT, lawrence.andrews wrote: > 1) Automated the manual test case. > 2) Removed html dependent file > 3) Removed javax.swing.JApplet dependent. > 4) Test case can be executed independently as well with jtreg framework. > 5) Added methods to know that JFrame and Other component is visible before starting the user action via Robot. > > @shurymury @mrserb , thanks for reviewing. Created all the swing components within EDT ------------- PR: https://git.openjdk.java.net/jdk/pull/5058 From psadhukhan at openjdk.java.net Wed Aug 11 04:00:25 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Wed, 11 Aug 2021 04:00:25 GMT Subject: RFR: 8270312: Error: Not a test or directory containing tests: java/awt/print/PrinterJob/XparColor.java [v3] In-Reply-To: <9TyU0eZWa6tLRCRchazdGiJZ9QOfF7XAaTN5xlAdU-s=.b0975dc4-4d1c-46f3-b0d8-7bc057a1a3a4@github.com> References: <9TyU0eZWa6tLRCRchazdGiJZ9QOfF7XAaTN5xlAdU-s=.b0975dc4-4d1c-46f3-b0d8-7bc057a1a3a4@github.com> Message-ID: On Fri, 6 Aug 2021 15:17:48 GMT, lawrence.andrews wrote: >> 1) This testcase was throwing error saying Error: Not a test or directory containing tests: java/awt/print/PrinterJob/XparColor.java >> 2) Added @test tag so that this testcase can be run >> 3) Since Applet is deprecated and its not supported any more in the future release remove applet and make the testcase to run as main >> 4) Since this is a manual testcase instruction frame or dailog was not visible just print dialog was visible so fixed it. >> 5) When the testcase was run via main method two print dialog was shown one was from main method and one more was from constructor. Fixed to show just one print dialog. >> 6) Since JDK 17 introduce metal rendering touching the java2d code thought this testcase will be useful to checking the rendering. >> >> @shurymury > > lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision: > > Fixed jcheck issue test/jdk/java/awt/print/PrinterJob/XparColor.java line 157: > 155: throw new RuntimeException("Timed out after " + sleepTime / 1000 + " seconds"); > 156: } catch (InterruptedException e) { > 157: if (!testGeneratedInterrupt) throw e; I guess timeout code is there here but for somehow it is not working as expected..Could you check? Otherwise there are other ways of handling user interaction done in java/awt/print/PrinterJob/BannerTest.java java/awt/print/PrinterJob/TestSaveFileWithoutPrinter.java ------------- PR: https://git.openjdk.java.net/jdk/pull/4769 From kizune at openjdk.java.net Wed Aug 11 11:30:41 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Wed, 11 Aug 2021 11:30:41 GMT Subject: RFR: 8269951: [macos] Focus not painted in JButton when setBorderPainted(false) is invoked Message-ID: Initial implementation and a test case. ------------- Commit messages: - Test fixes - 8269951: [macos] Focus not painted in JButton when setBorderPainted(false) is invoked Changes: https://git.openjdk.java.net/jdk/pull/5082/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5082&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8269951 Stats: 99 lines in 2 files changed: 99 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5082.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5082/head:pull/5082 PR: https://git.openjdk.java.net/jdk/pull/5082 From avu at openjdk.java.net Wed Aug 11 12:51:26 2021 From: avu at openjdk.java.net (Alexey Ushakov) Date: Wed, 11 Aug 2021 12:51:26 GMT Subject: RFR: 8266079: Lanai: AlphaComposite shows differences on Metal compared to OpenGL [v2] In-Reply-To: References: <7FfjAXZJPIzx2OfaLY8dlET6NVnF-XAiaAI7mJwNGeo=.2381d679-8860-4c79-a7bd-4749f10bb90e@github.com> Message-ID: On Sun, 8 Aug 2021 23:29:48 GMT, Sergey Bylokhov wrote: >> Thank you, looking into it. > > I check the steps below and was able to reproduce the same artifacts(black rectangles) in the tree tab with the current version of the fix. And I do not see a big difference between setting the layer to YES at the beginning or a little bit later, at the end, it will be opaque and artifacts occur. > > 1. Run SwingSet2 > 2. Click on all tabs starting from the second one, delay on each tab for the second or so > 3. On the tab with swing tree control try to expand some tree nodes -> you'll see black rectangles while performing the clicks > 4. Repeat from step 2 if no artifacts are visible Interesting, now I'm also able to reproduce this problem with the latest version of the fix. Actually, looks like the problem exists even without the fix. We get invalid background with the same scenario. It's not so visible because of default L&F (light). Nevertheless, the color of the background is not exact the same. If we provide apple.awt.application.appearance=NSAppearanceNameDarkAqua VM option, the problem became visible with metal and not reproducible with OGL. ------------- PR: https://git.openjdk.java.net/jdk/pull/4946 From psadhukhan at openjdk.java.net Wed Aug 11 15:19:26 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Wed, 11 Aug 2021 15:19:26 GMT Subject: RFR: 8269951: [macos] Focus not painted in JButton when setBorderPainted(false) is invoked In-Reply-To: References: Message-ID: On Wed, 11 Aug 2021 11:22:50 GMT, Alexander Zuev wrote: > Initial implementation and a test case. > > The problem is that Aqua LaF shows the focused component with the glow on the border, hence when the border is not painted the foxus is not displayed. The idea is to paint the glowing border on the focused component anyways. src/java.desktop/macosx/classes/com/apple/laf/AquaButtonUI.java line 333: > 331: final Border border = b.getBorder(); > 332: if (border instanceof AquaButtonBorder) { > 333: ((AquaButtonBorder)border).paintButton(b, g, 0, 0, b.getWidth(), b.getHeight()); Does having 0,0 not create a problem in multiscreen environment? ------------- PR: https://git.openjdk.java.net/jdk/pull/5082 From github.com+87324768+lawrence-andrew at openjdk.java.net Wed Aug 11 15:35:43 2021 From: github.com+87324768+lawrence-andrew at openjdk.java.net (lawrence.andrews) Date: Wed, 11 Aug 2021 15:35:43 GMT Subject: RFR: 8270312: Error: Not a test or directory containing tests: java/awt/print/PrinterJob/XparColor.java [v4] In-Reply-To: References: Message-ID: > 1) This testcase was throwing error saying Error: Not a test or directory containing tests: java/awt/print/PrinterJob/XparColor.java > 2) Added @test tag so that this testcase can be run > 3) Since Applet is deprecated and its not supported any more in the future release remove applet and make the testcase to run as main > 4) Since this is a manual testcase instruction frame or dailog was not visible just print dialog was visible so fixed it. > 5) When the testcase was run via main method two print dialog was shown one was from main method and one more was from constructor. Fixed to show just one print dialog. > 6) Since JDK 17 introduce metal rendering touching the java2d code thought this testcase will be useful to checking the rendering. > > @shurymury lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision: Rewrote the code for better starting the test and timeout ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4769/files - new: https://git.openjdk.java.net/jdk/pull/4769/files/fe4dc73d..00999140 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4769&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4769&range=02-03 Stats: 400 lines in 1 file changed: 139 ins; 259 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/4769.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4769/head:pull/4769 PR: https://git.openjdk.java.net/jdk/pull/4769 From github.com+87324768+lawrence-andrew at openjdk.java.net Wed Aug 11 15:35:44 2021 From: github.com+87324768+lawrence-andrew at openjdk.java.net (lawrence.andrews) Date: Wed, 11 Aug 2021 15:35:44 GMT Subject: RFR: 8270312: Error: Not a test or directory containing tests: java/awt/print/PrinterJob/XparColor.java [v3] In-Reply-To: <9TyU0eZWa6tLRCRchazdGiJZ9QOfF7XAaTN5xlAdU-s=.b0975dc4-4d1c-46f3-b0d8-7bc057a1a3a4@github.com> References: <9TyU0eZWa6tLRCRchazdGiJZ9QOfF7XAaTN5xlAdU-s=.b0975dc4-4d1c-46f3-b0d8-7bc057a1a3a4@github.com> Message-ID: <_HIydP_OfxL_aEn10XbXpjyvdZJOghhn2kJ8mn3NhLE=.6adbd54c-177a-4394-8d29-34e335180a8a@github.com> On Fri, 6 Aug 2021 15:17:48 GMT, lawrence.andrews wrote: >> 1) This testcase was throwing error saying Error: Not a test or directory containing tests: java/awt/print/PrinterJob/XparColor.java >> 2) Added @test tag so that this testcase can be run >> 3) Since Applet is deprecated and its not supported any more in the future release remove applet and make the testcase to run as main >> 4) Since this is a manual testcase instruction frame or dailog was not visible just print dialog was visible so fixed it. >> 5) When the testcase was run via main method two print dialog was shown one was from main method and one more was from constructor. Fixed to show just one print dialog. >> 6) Since JDK 17 introduce metal rendering touching the java2d code thought this testcase will be useful to checking the rendering. >> >> @shurymury > > lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision: > > Fixed jcheck issue Rewrote the code so that test can be started after pressing startTest button and now timeout is taken care. ------------- PR: https://git.openjdk.java.net/jdk/pull/4769 From psadhukhan at openjdk.java.net Wed Aug 11 16:36:28 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Wed, 11 Aug 2021 16:36:28 GMT Subject: RFR: 8270312: Error: Not a test or directory containing tests: java/awt/print/PrinterJob/XparColor.java [v4] In-Reply-To: References: Message-ID: On Wed, 11 Aug 2021 15:35:43 GMT, lawrence.andrews wrote: >> 1) This testcase was throwing error saying Error: Not a test or directory containing tests: java/awt/print/PrinterJob/XparColor.java >> 2) Added @test tag so that this testcase can be run >> 3) Since Applet is deprecated and its not supported any more in the future release remove applet and make the testcase to run as main >> 4) Since this is a manual testcase instruction frame or dailog was not visible just print dialog was visible so fixed it. >> 5) When the testcase was run via main method two print dialog was shown one was from main method and one more was from constructor. Fixed to show just one print dialog. >> 6) Since JDK 17 introduce metal rendering touching the java2d code thought this testcase will be useful to checking the rendering. >> >> @shurymury > > lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision: > > Rewrote the code for better starting the test and timeout test/jdk/java/awt/print/PrinterJob/XparColor.java line 122: > 120: > 121: private static void createAndShowTestDialog() { > 122: String testInstruction = "This testcase will be launched twice, once for opengl and once for metal.\n" + The test is supposed to be run in all platforms, not only in mac. Since the default pipeline is not opengl in non-mac platform and also metal is not supported in non-mac platform, so this test instruction that it will run in opengl and metal is wrong in non-mac platform. You probably need to modify to say it will be run in default pipeline for a particular platform and metal and subsequently check if the platform is non-mac and bail out if metal=true system property is set and inform user that metal cannot be run in present non-mac platform ------------- PR: https://git.openjdk.java.net/jdk/pull/4769 From github.com+87324768+lawrence-andrew at openjdk.java.net Wed Aug 11 16:56:28 2021 From: github.com+87324768+lawrence-andrew at openjdk.java.net (lawrence.andrews) Date: Wed, 11 Aug 2021 16:56:28 GMT Subject: RFR: 8270312: Error: Not a test or directory containing tests: java/awt/print/PrinterJob/XparColor.java [v4] In-Reply-To: References: Message-ID: <6xlw_XMJUjXSQmoZx8_HNl77VY5IPv_XEGInii3IGCE=.645e5692-3432-4718-8248-e70eb720d31c@github.com> On Wed, 11 Aug 2021 16:33:19 GMT, Prasanta Sadhukhan wrote: >> lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision: >> >> Rewrote the code for better starting the test and timeout > > test/jdk/java/awt/print/PrinterJob/XparColor.java line 122: > >> 120: >> 121: private static void createAndShowTestDialog() { >> 122: String testInstruction = "This testcase will be launched twice, once for opengl and once for metal.\n" + > > The test is supposed to be run in all platforms, not only in mac. Since the default pipeline is not opengl in non-mac platform and also metal is not supported in non-mac platform, so this test instruction that it will run in opengl and metal is wrong in non-mac platform. > You probably need to modify to say it will be run in default pipeline for a particular platform and metal and subsequently check if the platform is non-mac and bail out if metal=true system property is set and inform user that metal cannot be run in present non-mac platform Thanks @prsadhuk, will modify the instruction ------------- PR: https://git.openjdk.java.net/jdk/pull/4769 From kizune at openjdk.java.net Wed Aug 11 16:58:23 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Wed, 11 Aug 2021 16:58:23 GMT Subject: RFR: 8269951: [macos] Focus not painted in JButton when setBorderPainted(false) is invoked In-Reply-To: References: Message-ID: <7rcRtKuC6P2b8dD_70Q7a3IEf_p2wJ7TGKyNzZXfIKI=.ee7486d9-238b-4c84-a29c-fafe16520253@github.com> On Wed, 11 Aug 2021 15:16:22 GMT, Prasanta Sadhukhan wrote: > Does having 0,0 not create a problem in multiscreen environment? These coordinates are relative within the Graphics clip of the button so no, that does not cause any issue. Plus, if it would then button painting would be broken already since that's exactly what is passed to the border painter in case when borders are not switched off. ------------- PR: https://git.openjdk.java.net/jdk/pull/5082 From github.com+87324768+lawrence-andrew at openjdk.java.net Wed Aug 11 21:16:43 2021 From: github.com+87324768+lawrence-andrew at openjdk.java.net (lawrence.andrews) Date: Wed, 11 Aug 2021 21:16:43 GMT Subject: RFR: 8270312: Error: Not a test or directory containing tests: java/awt/print/PrinterJob/XparColor.java [v5] In-Reply-To: References: Message-ID: > 1) This testcase was throwing error saying Error: Not a test or directory containing tests: java/awt/print/PrinterJob/XparColor.java > 2) Added @test tag so that this testcase can be run > 3) Since Applet is deprecated and its not supported any more in the future release remove applet and make the testcase to run as main > 4) Since this is a manual testcase instruction frame or dailog was not visible just print dialog was visible so fixed it. > 5) When the testcase was run via main method two print dialog was shown one was from main method and one more was from constructor. Fixed to show just one print dialog. > 6) Since JDK 17 introduce metal rendering touching the java2d code thought this testcase will be useful to checking the rendering. > > @shurymury lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision: Fixed test instruction and execute the testcase on metal only for mac ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4769/files - new: https://git.openjdk.java.net/jdk/pull/4769/files/00999140..9995b356 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4769&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4769&range=03-04 Stats: 13 lines in 1 file changed: 12 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4769.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4769/head:pull/4769 PR: https://git.openjdk.java.net/jdk/pull/4769 From github.com+87324768+lawrence-andrew at openjdk.java.net Wed Aug 11 21:16:43 2021 From: github.com+87324768+lawrence-andrew at openjdk.java.net (lawrence.andrews) Date: Wed, 11 Aug 2021 21:16:43 GMT Subject: RFR: 8270312: Error: Not a test or directory containing tests: java/awt/print/PrinterJob/XparColor.java [v4] In-Reply-To: References: Message-ID: <6pT2S70E3D0yaTnuKawwO-5h27r-9X5pThvgGkbSDdc=.988c4c02-4add-46e5-8895-398deca8cc51@github.com> On Wed, 11 Aug 2021 15:35:43 GMT, lawrence.andrews wrote: >> 1) This testcase was throwing error saying Error: Not a test or directory containing tests: java/awt/print/PrinterJob/XparColor.java >> 2) Added @test tag so that this testcase can be run >> 3) Since Applet is deprecated and its not supported any more in the future release remove applet and make the testcase to run as main >> 4) Since this is a manual testcase instruction frame or dailog was not visible just print dialog was visible so fixed it. >> 5) When the testcase was run via main method two print dialog was shown one was from main method and one more was from constructor. Fixed to show just one print dialog. >> 6) Since JDK 17 introduce metal rendering touching the java2d code thought this testcase will be useful to checking the rendering. >> >> @shurymury > > lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision: > > Rewrote the code for better starting the test and timeout Fixed test instruction & add changes to execute the testcase on mac with default and metal pipeline and for non mac execute the testcase with default pipeline. ------------- PR: https://git.openjdk.java.net/jdk/pull/4769 From serb at openjdk.java.net Thu Aug 12 02:17:28 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Thu, 12 Aug 2021 02:17:28 GMT Subject: RFR: 8267161 : Write automated test case for JDK-4479161 In-Reply-To: References: Message-ID: On Mon, 9 Aug 2021 18:36:07 GMT, lawrence.andrews wrote: > 1) Automated the manual test case. > 2) Removed html dependent file > 3) Removed javax.swing.JApplet dependent. > 4) Test case can be executed independently as well with jtreg framework. > 5) Added methods to know that JFrame and Other component is visible before starting the user action via Robot. > > @shurymury test/jdk/java/awt/im/4959409/bug4959409.java line 193: > 191: } finally { > 192: if (jFrames[0] != null) { > 193: jFrames[0].dispose(); dispose() should be called on EDT as well. ------------- PR: https://git.openjdk.java.net/jdk/pull/5058 From serb at openjdk.java.net Thu Aug 12 02:18:23 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Thu, 12 Aug 2021 02:18:23 GMT Subject: RFR: 8269951: [macos] Focus not painted in JButton when setBorderPainted(false) is invoked In-Reply-To: References: Message-ID: <6S6M60JTVZPGTJJjpiBJ74VJeKSD-c8B-va8Mkt5Llc=.b9675135-6c08-4e87-8090-63f0bf4c5144@github.com> On Wed, 11 Aug 2021 11:22:50 GMT, Alexander Zuev wrote: > Initial implementation and a test case. > > The problem is that Aqua LaF shows the focused component with the glow on the border, hence when the border is not painted the foxus is not displayed. The idea is to paint the glowing border on the focused component anyways. Painting the border while the user tries to disable the border via setBorderPainted(false) does not look like a correct solution. The user might be drawn something there already. I remember we discussed a similar a11y bug related to focus and the only possible solution was to draw the focus ourselves or request this feature in the JRS. ------------- PR: https://git.openjdk.java.net/jdk/pull/5082 From kizune at openjdk.java.net Thu Aug 12 11:09:26 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Thu, 12 Aug 2021 11:09:26 GMT Subject: RFR: 8269951: [macos] Focus not painted in JButton when setBorderPainted(false) is invoked In-Reply-To: <6S6M60JTVZPGTJJjpiBJ74VJeKSD-c8B-va8Mkt5Llc=.b9675135-6c08-4e87-8090-63f0bf4c5144@github.com> References: <6S6M60JTVZPGTJJjpiBJ74VJeKSD-c8B-va8Mkt5Llc=.b9675135-6c08-4e87-8090-63f0bf4c5144@github.com> Message-ID: On Thu, 12 Aug 2021 02:15:06 GMT, Sergey Bylokhov wrote: > Painting the border while the user tries to disable the border via setBorderPainted(false) does not look like a correct solution. The user might be drawn something there already. I remember we discussed a similar a11y bug related to focus and the only possible solution was to draw the focus ourselves or request this feature in the JRS. There is no other way on Mac OS to indicate focused button but the glowing border. The same situation happens on Motif L&F - the only way to differentiate focused button from unfocused is by the border and in Motif - just as in Aqua - once border painting is disabled there is no way to tell if button is focused or not. User might draw something but if button becomes focused the focus indication will be drawn over it. If focus indicator disrupts user's painting on top of the button insets area user can always disable focus painting on such a component deliberately by calling JButton.setFocusPainted(boolean) ------------- PR: https://git.openjdk.java.net/jdk/pull/5082 From duke at openjdk.java.net Thu Aug 12 11:30:28 2021 From: duke at openjdk.java.net (duke) Date: Thu, 12 Aug 2021 11:30:28 GMT Subject: Withdrawn: 8240756: [macos] SwingSet2:TableDemo:Printed Japanese characters were garbled In-Reply-To: References: Message-ID: On Thu, 22 Apr 2021 09:21:20 GMT, Toshio Nakamura wrote: > Hi, > > Could you review the fix? > When non-English characters were printed from JTable on MacOS, CTextPipe.doDrawGlyphs was called by OSXSurfaceData.drawGlyphs. However, CTextPipe seems not support glyph with slot number of composite fonts. > > The slot data mask of GlyphVector is 0xff000000. In my environment, Japanese font was loaded at slot 4, and glyph data is like [0x40003e5]. Then, unexpected glyph was drawn. > > This patch checks slot data of each character. If slot data exists, it will branch to GlyphVector's drawing path. > > Well, I couldn't create automatic test for this fix. This method seems to be called for printing only. I appreciate any advice. > Tested java/awt and javax/swing on MacOS BigSur, and there was no regression. > > Regards, > Toshio Nakamura This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/3619 From psadhukhan at openjdk.java.net Thu Aug 12 12:02:28 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Thu, 12 Aug 2021 12:02:28 GMT Subject: RFR: 8270312: Error: Not a test or directory containing tests: java/awt/print/PrinterJob/XparColor.java [v5] In-Reply-To: References: Message-ID: On Wed, 11 Aug 2021 21:16:43 GMT, lawrence.andrews wrote: >> 1) This testcase was throwing error saying Error: Not a test or directory containing tests: java/awt/print/PrinterJob/XparColor.java >> 2) Added @test tag so that this testcase can be run >> 3) Since Applet is deprecated and its not supported any more in the future release remove applet and make the testcase to run as main >> 4) Since this is a manual testcase instruction frame or dailog was not visible just print dialog was visible so fixed it. >> 5) When the testcase was run via main method two print dialog was shown one was from main method and one more was from constructor. Fixed to show just one print dialog. >> 6) Since JDK 17 introduce metal rendering touching the java2d code thought this testcase will be useful to checking the rendering. >> >> @shurymury > > lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision: > > Fixed test instruction and execute the testcase on metal only for mac test/jdk/java/awt/print/PrinterJob/XparColor.java line 134: > 132: private static void createAndShowTestDialog() { > 133: String testInstruction = "This testcase will be launched twice on mac platform and once on non mac platform.\n" + > 134: "On Mac once with default pipeline and once again with Metal pipeline.\n" + I think it will be better to rephrase this line with "This test will be run with default pipeline in all OS and additionally with metal pipeline only in macOS" ------------- PR: https://git.openjdk.java.net/jdk/pull/4769 From psadhukhan at openjdk.java.net Thu Aug 12 12:08:27 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Thu, 12 Aug 2021 12:08:27 GMT Subject: RFR: 8270312: Error: Not a test or directory containing tests: java/awt/print/PrinterJob/XparColor.java [v5] In-Reply-To: References: Message-ID: On Thu, 12 Aug 2021 11:59:14 GMT, Prasanta Sadhukhan wrote: >> lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed test instruction and execute the testcase on metal only for mac > > test/jdk/java/awt/print/PrinterJob/XparColor.java line 134: > >> 132: private static void createAndShowTestDialog() { >> 133: String testInstruction = "This testcase will be launched twice on mac platform and once on non mac platform.\n" + >> 134: "On Mac once with default pipeline and once again with Metal pipeline.\n" + > > I think it will be better to rephrase this line with "This test will be run with default pipeline in all OS and additionally with metal pipeline only in macOS" although I am not sure why it is important to run in metal pipeline. I don't think metal has any effect on printing par se. ------------- PR: https://git.openjdk.java.net/jdk/pull/4769 From avu at openjdk.java.net Thu Aug 12 13:45:54 2021 From: avu at openjdk.java.net (Alexey Ushakov) Date: Thu, 12 Aug 2021 13:45:54 GMT Subject: RFR: 8266079: Lanai: AlphaComposite shows differences on Metal compared to OpenGL [v3] In-Reply-To: <7FfjAXZJPIzx2OfaLY8dlET6NVnF-XAiaAI7mJwNGeo=.2381d679-8860-4c79-a7bd-4749f10bb90e@github.com> References: <7FfjAXZJPIzx2OfaLY8dlET6NVnF-XAiaAI7mJwNGeo=.2381d679-8860-4c79-a7bd-4749f10bb90e@github.com> Message-ID: > Keep MTLLayer opacity in sync with window content view > Keep layer translucent for translucent windows Alexey Ushakov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: 8266079: Lanai: AlphaComposite shows differences on Metal compared to OpenGL Keep MTLLayer opacity in sync with window content view Keep layer translucent for translucent windows Update opacity on textured property change Make native MTLLayer opaque by default to match java component state ------------- Changes: https://git.openjdk.java.net/jdk/pull/4946/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4946&range=02 Stats: 274 lines in 7 files changed: 269 ins; 1 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/4946.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4946/head:pull/4946 PR: https://git.openjdk.java.net/jdk/pull/4946 From github.com+87324768+lawrence-andrew at openjdk.java.net Thu Aug 12 15:42:48 2021 From: github.com+87324768+lawrence-andrew at openjdk.java.net (lawrence.andrews) Date: Thu, 12 Aug 2021 15:42:48 GMT Subject: RFR: 8270312: Error: Not a test or directory containing tests: java/awt/print/PrinterJob/XparColor.java [v6] In-Reply-To: References: Message-ID: > 1) This testcase was throwing error saying Error: Not a test or directory containing tests: java/awt/print/PrinterJob/XparColor.java > 2) Added @test tag so that this testcase can be run > 3) Since Applet is deprecated and its not supported any more in the future release remove applet and make the testcase to run as main > 4) Since this is a manual testcase instruction frame or dailog was not visible just print dialog was visible so fixed it. > 5) When the testcase was run via main method two print dialog was shown one was from main method and one more was from constructor. Fixed to show just one print dialog. > 6) Since JDK 17 introduce metal rendering touching the java2d code thought this testcase will be useful to checking the rendering. > > @shurymury lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision: Removed runnung the testcase in metal and corrected the instruction ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4769/files - new: https://git.openjdk.java.net/jdk/pull/4769/files/9995b356..7ba220d5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4769&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4769&range=04-05 Stats: 15 lines in 1 file changed: 0 ins; 14 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4769.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4769/head:pull/4769 PR: https://git.openjdk.java.net/jdk/pull/4769 From github.com+87324768+lawrence-andrew at openjdk.java.net Thu Aug 12 15:42:49 2021 From: github.com+87324768+lawrence-andrew at openjdk.java.net (lawrence.andrews) Date: Thu, 12 Aug 2021 15:42:49 GMT Subject: RFR: 8270312: Error: Not a test or directory containing tests: java/awt/print/PrinterJob/XparColor.java [v5] In-Reply-To: References: Message-ID: <2kpNYslWQPl8PMJv2XkXL_ypyMh9wIiPSktUbxup_mA=.b7141eca-00eb-4bc7-a000-291672cbb8d6@github.com> On Wed, 11 Aug 2021 21:16:43 GMT, lawrence.andrews wrote: >> 1) This testcase was throwing error saying Error: Not a test or directory containing tests: java/awt/print/PrinterJob/XparColor.java >> 2) Added @test tag so that this testcase can be run >> 3) Since Applet is deprecated and its not supported any more in the future release remove applet and make the testcase to run as main >> 4) Since this is a manual testcase instruction frame or dailog was not visible just print dialog was visible so fixed it. >> 5) When the testcase was run via main method two print dialog was shown one was from main method and one more was from constructor. Fixed to show just one print dialog. >> 6) Since JDK 17 introduce metal rendering touching the java2d code thought this testcase will be useful to checking the rendering. >> >> @shurymury > > lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision: > > Fixed test instruction and execute the testcase on metal only for mac Removed running the testcase in metal pipeline and corrected the instruction as per above comments. ------------- PR: https://git.openjdk.java.net/jdk/pull/4769 From github.com+87324768+lawrence-andrew at openjdk.java.net Thu Aug 12 15:46:43 2021 From: github.com+87324768+lawrence-andrew at openjdk.java.net (lawrence.andrews) Date: Thu, 12 Aug 2021 15:46:43 GMT Subject: RFR: 8267161 : Write automated test case for JDK-4479161 [v2] In-Reply-To: References: Message-ID: <0EZv83zabHvGzXvdAOfBAJXIzX1NHlc_yJFuP2PT4Jc=.48fd129d-6da1-4048-a87a-87c7457bd398@github.com> > 1) Automated the manual test case. > 2) Removed html dependent file > 3) Removed javax.swing.JApplet dependent. > 4) Test case can be executed independently as well with jtreg framework. > 5) Added methods to know that JFrame and Other component is visible before starting the user action via Robot. > > @shurymury lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision: Fixed the frame dispose with in EDT ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5058/files - new: https://git.openjdk.java.net/jdk/pull/5058/files/cedce6b8..fb92d3a4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5058&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5058&range=00-01 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5058.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5058/head:pull/5058 PR: https://git.openjdk.java.net/jdk/pull/5058 From github.com+87324768+lawrence-andrew at openjdk.java.net Thu Aug 12 15:46:43 2021 From: github.com+87324768+lawrence-andrew at openjdk.java.net (lawrence.andrews) Date: Thu, 12 Aug 2021 15:46:43 GMT Subject: RFR: 8267161 : Write automated test case for JDK-4479161 In-Reply-To: References: Message-ID: On Mon, 9 Aug 2021 18:36:07 GMT, lawrence.andrews wrote: > 1) Automated the manual test case. > 2) Removed html dependent file > 3) Removed javax.swing.JApplet dependent. > 4) Test case can be executed independently as well with jtreg framework. > 5) Added methods to know that JFrame and Other component is visible before starting the user action via Robot. > > @shurymury Sorry, missed disposed with in EDT added it now. ------------- PR: https://git.openjdk.java.net/jdk/pull/5058 From psadhukhan at openjdk.java.net Thu Aug 12 17:17:25 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Thu, 12 Aug 2021 17:17:25 GMT Subject: RFR: 8270312: Error: Not a test or directory containing tests: java/awt/print/PrinterJob/XparColor.java [v6] In-Reply-To: References: Message-ID: On Thu, 12 Aug 2021 15:42:48 GMT, lawrence.andrews wrote: >> 1) This testcase was throwing error saying Error: Not a test or directory containing tests: java/awt/print/PrinterJob/XparColor.java >> 2) Added @test tag so that this testcase can be run >> 3) Since Applet is deprecated and its not supported any more in the future release remove applet and make the testcase to run as main >> 4) Since this is a manual testcase instruction frame or dailog was not visible just print dialog was visible so fixed it. >> 5) When the testcase was run via main method two print dialog was shown one was from main method and one more was from constructor. Fixed to show just one print dialog. >> 6) Since JDK 17 introduce metal rendering touching the java2d code thought this testcase will be useful to checking the rendering. >> >> @shurymury > > lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision: > > Removed runnung the testcase in metal and corrected the instruction test/jdk/java/awt/print/PrinterJob/XparColor.java line 180: > 178: failButton.addActionListener((e) -> { > 179: dialog.dispose(); > 180: fail("PrinterException thrown."); Looks ok now.. Just this minor thing of failure message should be corrected as PrinterException is not actually being thrown when it fails...probably the message should be "transparent ring colors are not printed correctly" ------------- PR: https://git.openjdk.java.net/jdk/pull/4769 From serb at openjdk.java.net Thu Aug 12 18:20:23 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Thu, 12 Aug 2021 18:20:23 GMT Subject: RFR: 8269951: [macos] Focus not painted in JButton when setBorderPainted(false) is invoked In-Reply-To: References: Message-ID: <7JolkPWVae9EMn_gAZuzIXB-PqUWGqH79SrivV7KC8A=.53bff0f3-27c0-471b-b0ef-8c86e4af8359@github.com> On Wed, 11 Aug 2021 11:22:50 GMT, Alexander Zuev wrote: > Initial implementation and a test case. > > The problem is that Aqua LaF shows the focused component with the glow on the border, hence when the border is not painted the foxus is not displayed. The idea is to paint the glowing border on the focused component anyways. The motif L&F is not supported for a while and is ready to remove, so that L&F behavior cannot be referenced as a proper way to work. The focused button on macOS is highlighted by the "blue" rounded rectangle. There are two choices: draw this rectangle ourselves or request this feature from the JRS. But the change should not break the behavior of the "setBorderPainted(false)". ------------- PR: https://git.openjdk.java.net/jdk/pull/5082 From serb at openjdk.java.net Thu Aug 12 18:47:25 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Thu, 12 Aug 2021 18:47:25 GMT Subject: RFR: 8269951: [macos] Focus not painted in JButton when setBorderPainted(false) is invoked In-Reply-To: References: Message-ID: On Wed, 11 Aug 2021 11:22:50 GMT, Alexander Zuev wrote: > Initial implementation and a test case. > > The problem is that Aqua LaF shows the focused component with the glow on the border, hence when the border is not painted the foxus is not displayed. The idea is to paint the glowing border on the focused component anyways. BTW this issue was known for a long time, and even the spec was updated specifically for it: https://bugs.openjdk.java.net/browse/JDK-4416026 ------------- PR: https://git.openjdk.java.net/jdk/pull/5082 From serb at openjdk.java.net Thu Aug 12 18:54:24 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Thu, 12 Aug 2021 18:54:24 GMT Subject: RFR: 8269951: [macos] Focus not painted in JButton when setBorderPainted(false) is invoked In-Reply-To: References: Message-ID: <0X2hUh3oRZws_7VsKtvtCxGet3P-pgy0gEWCtIHPZkk=.f3586214-d01e-4232-9791-93ca72c943b6@github.com> On Wed, 11 Aug 2021 11:22:50 GMT, Alexander Zuev wrote: > Initial implementation and a test case. > > The problem is that Aqua LaF shows the focused component with the glow on the border, hence when the border is not painted the foxus is not displayed. The idea is to paint the glowing border on the focused component anyways. Probably solution should be somewhere similar to this one: https://github.com/openjdk/jdk/commit/440db35e ------------- PR: https://git.openjdk.java.net/jdk/pull/5082 From avu at openjdk.java.net Thu Aug 12 19:02:24 2021 From: avu at openjdk.java.net (Alexey Ushakov) Date: Thu, 12 Aug 2021 19:02:24 GMT Subject: RFR: 8266079: Lanai: AlphaComposite shows differences on Metal compared to OpenGL [v3] In-Reply-To: References: <7FfjAXZJPIzx2OfaLY8dlET6NVnF-XAiaAI7mJwNGeo=.2381d679-8860-4c79-a7bd-4749f10bb90e@github.com> Message-ID: On Wed, 11 Aug 2021 12:48:47 GMT, Alexey Ushakov wrote: >> I check the steps below and was able to reproduce the same artifacts(black rectangles) in the tree tab with the current version of the fix. And I do not see a big difference between setting the layer to YES at the beginning or a little bit later, at the end, it will be opaque and artifacts occur. >> >> 1. Run SwingSet2 >> 2. Click on all tabs starting from the second one, delay on each tab for the second or so >> 3. On the tab with swing tree control try to expand some tree nodes -> you'll see black rectangles while performing the clicks >> 4. Repeat from step 2 if no artifacts are visible > > Interesting, now I'm also able to reproduce this problem with the latest version of the fix. Actually, looks like the problem exists even without the fix. We get invalid background with the same scenario. It's not so visible because of default L&F (light). Nevertheless, the color of the background is not exact the same. If we provide apple.awt.application.appearance=NSAppearanceNameDarkAqua VM option, the problem became visible with metal and not reproducible with OGL. I've filed a separate CR for this problem JDK-8272392 ------------- PR: https://git.openjdk.java.net/jdk/pull/4946 From github.com+87324768+lawrence-andrew at openjdk.java.net Thu Aug 12 19:37:51 2021 From: github.com+87324768+lawrence-andrew at openjdk.java.net (lawrence.andrews) Date: Thu, 12 Aug 2021 19:37:51 GMT Subject: RFR: 8270312: Error: Not a test or directory containing tests: java/awt/print/PrinterJob/XparColor.java [v7] In-Reply-To: References: Message-ID: > 1) This testcase was throwing error saying Error: Not a test or directory containing tests: java/awt/print/PrinterJob/XparColor.java > 2) Added @test tag so that this testcase can be run > 3) Since Applet is deprecated and its not supported any more in the future release remove applet and make the testcase to run as main > 4) Since this is a manual testcase instruction frame or dailog was not visible just print dialog was visible so fixed it. > 5) When the testcase was run via main method two print dialog was shown one was from main method and one more was from constructor. Fixed to show just one print dialog. > 6) Since JDK 17 introduce metal rendering touching the java2d code thought this testcase will be useful to checking the rendering. > > @shurymury lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision: Fixed exception string ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4769/files - new: https://git.openjdk.java.net/jdk/pull/4769/files/7ba220d5..b9427548 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4769&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4769&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4769.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4769/head:pull/4769 PR: https://git.openjdk.java.net/jdk/pull/4769 From github.com+87324768+lawrence-andrew at openjdk.java.net Thu Aug 12 19:37:52 2021 From: github.com+87324768+lawrence-andrew at openjdk.java.net (lawrence.andrews) Date: Thu, 12 Aug 2021 19:37:52 GMT Subject: RFR: 8270312: Error: Not a test or directory containing tests: java/awt/print/PrinterJob/XparColor.java [v6] In-Reply-To: References: Message-ID: On Thu, 12 Aug 2021 15:42:48 GMT, lawrence.andrews wrote: >> 1) This testcase was throwing error saying Error: Not a test or directory containing tests: java/awt/print/PrinterJob/XparColor.java >> 2) Added @test tag so that this testcase can be run >> 3) Since Applet is deprecated and its not supported any more in the future release remove applet and make the testcase to run as main >> 4) Since this is a manual testcase instruction frame or dailog was not visible just print dialog was visible so fixed it. >> 5) When the testcase was run via main method two print dialog was shown one was from main method and one more was from constructor. Fixed to show just one print dialog. >> 6) Since JDK 17 introduce metal rendering touching the java2d code thought this testcase will be useful to checking the rendering. >> >> @shurymury > > lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision: > > Removed runnung the testcase in metal and corrected the instruction Fixed the exception string. ------------- PR: https://git.openjdk.java.net/jdk/pull/4769 From prr at openjdk.java.net Thu Aug 12 19:53:27 2021 From: prr at openjdk.java.net (Phil Race) Date: Thu, 12 Aug 2021 19:53:27 GMT Subject: RFR: 8181571: printing to CUPS fails on mac sandbox app In-Reply-To: <2Mgxu1zmn4d0AJ1JsWHH4oO5PtUDtNfCQE8UYu7hkmc=.a080d861-8fec-4677-aa7b-dabdf431b5b4@github.com> References: <2Mgxu1zmn4d0AJ1JsWHH4oO5PtUDtNfCQE8UYu7hkmc=.a080d861-8fec-4677-aa7b-dabdf431b5b4@github.com> Message-ID: On Wed, 21 Jul 2021 15:45:55 GMT, Alexander Scherbatiy wrote: > The issue is reproduced on macOS Big Sur 11.0.1 with jdk 16.0.1+9. > > Create a native macOS app from the Hello.java file, sign and run it in sandbox: > > import javax.print.*; > import javax.swing.*; > > public class Hello { > > public static void main(String[] args) throws Exception { > SwingUtilities.invokeAndWait(() -> { > boolean isSandboxed = System.getenv("APP_SANDBOX_CONTAINER_ID") != null; > PrintService defaultPrinter = PrintServiceLookup.lookupDefaultPrintService(); > PrintService[] services = PrintServiceLookup.lookupPrintServices(null, null); > > StringBuilder builder = new StringBuilder(); > builder.append("is sandboxed: ").append(isSandboxed).append("\n"); > builder.append("default printer: ").append(defaultPrinter).append("\n"); > int size = services.length; > for (int i = 0; i < size; i++) { > builder.append("printer[").append(i).append("]=").append(services[i]).append("\n"); > } > JOptionPane.showMessageDialog(null, builder.toString()); > }); > } > } > > The signed app in sandbox shows null default printer and PrintServiceLookup.lookupPrintServices(null, null) returns "Unix Printer: lp". > ![PrintSandboxedApp](https://bugs.openjdk.java.net/secure/attachment/95629/PrintSandboxedApp.png) > > The problem has been discussed on 2d-dev mail list: > https://mail.openjdk.java.net/pipermail/2d-dev/2017-June/008375.html > https://mail.openjdk.java.net/pipermail/2d-dev/2017-July/008418.html > > According to the discussion: > >> I've submitted a DTS incident to Apple and a friend there has followed-up. >> Their unofficial position is that java should be connecting to the cups interface returned >> by the cupsServer() function and not changing the interface string to "localhost". >> Security changes in 10.12.4 reject the TCP connection which they say confuses >> network-client access with print access. They don't seem interested in loosening that change. > > > The proposed solution is to use the domain socket pathname in httpConnect(...) cups function and cupsGetDests(...) to get list of printers from cups when the app is signed and is run in sandbox on MacOs. Changes requested by prr (Reviewer). src/java.desktop/unix/classes/sun/print/CUPSPrinter.java line 96: > 94: libFound = initIDs(); > 95: if (libFound) { > 96: cupsServer = getCupsServer(); I think we should wrap all the new lines in isMac() Also can you explain the reasons for the logic that implies we may have a server starting with "/" in which case your always change the cupServer to localhost even if it is not sandboxed ? I ask because it seems to contradict what you pasted "by the cupsServer() function and not changing the interface string to "localhost"" src/java.desktop/unix/classes/sun/print/CUPSPrinter.java line 399: > 397: return printerURIs; > 398: } > 399: } So if getCupsDefaultPrinters() doesn't find anything you always continue to the original code even though it would seem that you know we are in a sandboxed app and it won't find anything ? src/java.desktop/unix/classes/sun/print/CUPSPrinter.java line 489: > 487: return domainSocketPathname; > 488: } > 489: You will need to suppress deprecation warnings here. src/java.desktop/unix/classes/sun/print/CUPSPrinter.java line 506: > 504: IPPPrintService.debug_println(debugPrefix+"libFound "+libFound); > 505: if (libFound) { > 506: String server = getDomainSocketPathname() != null ? getDomainSocketPathname() : getServer(); Split this long line src/java.desktop/unix/native/common/awt/CUPSfuncs.c line 244: > 242: DPRINTF("CUPSfuncs::bad alloc new array\n", "") > 243: (*env)->ExceptionClear(env); > 244: JNU_ThrowOutOfMemoryError(env, "OutOfMemoryError"); I find this weird. What is the ExceptionClear for ? The only possible exception here is for an OOME which might be thrown by NewObjectArray. So you clear that and then re-create it ? And who do will catch this ? What's the point ? Maybe just clear and return null. src/java.desktop/unix/native/common/awt/CUPSfuncs.c line 253: > 251: j2d_cupsFreeDests(num_dests, dests); > 252: DPRINTF("CUPSfuncs::bad alloc new string ->name\n", "") > 253: JNU_ThrowOutOfMemoryError(env, "OutOfMemoryError"); similar comments to above plus I am fairly sure you want to delete nameArray since it isn't returned. For that matter if the NewString fails on the 4th printer you want to free the 3 previous ones too before returning. ------------- PR: https://git.openjdk.java.net/jdk/pull/4861 From serb at openjdk.java.net Thu Aug 12 22:08:29 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Thu, 12 Aug 2021 22:08:29 GMT Subject: RFR: 8266079: Lanai: AlphaComposite shows differences on Metal compared to OpenGL [v3] In-Reply-To: References: <7FfjAXZJPIzx2OfaLY8dlET6NVnF-XAiaAI7mJwNGeo=.2381d679-8860-4c79-a7bd-4749f10bb90e@github.com> Message-ID: On Thu, 12 Aug 2021 18:58:59 GMT, Alexey Ushakov wrote: >> Interesting, now I'm also able to reproduce this problem with the latest version of the fix. Actually, looks like the problem exists even without the fix. We get invalid background with the same scenario. It's not so visible because of default L&F (light). Nevertheless, the color of the background is not exact the same. If we provide apple.awt.application.appearance=NSAppearanceNameDarkAqua VM option, the problem became visible with metal and not reproducible with OGL. > > I've filed a separate CR for this problem JDK-8272392 Then you can roll back this change to the default opaque layer? ------------- PR: https://git.openjdk.java.net/jdk/pull/4946 From avu at openjdk.java.net Thu Aug 12 23:36:27 2021 From: avu at openjdk.java.net (Alexey Ushakov) Date: Thu, 12 Aug 2021 23:36:27 GMT Subject: RFR: 8266079: Lanai: AlphaComposite shows differences on Metal compared to OpenGL [v3] In-Reply-To: References: <7FfjAXZJPIzx2OfaLY8dlET6NVnF-XAiaAI7mJwNGeo=.2381d679-8860-4c79-a7bd-4749f10bb90e@github.com> Message-ID: On Thu, 12 Aug 2021 22:05:03 GMT, Sergey Bylokhov wrote: >> I've filed a separate CR for this problem JDK-8272392 > > Then you can roll back this change to the default opaque layer? Did you mean to make MTLLayer opaque by default? Yes, I did it in the latest version. ------------- PR: https://git.openjdk.java.net/jdk/pull/4946 From serb at openjdk.java.net Fri Aug 13 01:49:23 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Fri, 13 Aug 2021 01:49:23 GMT Subject: RFR: 8266079: Lanai: AlphaComposite shows differences on Metal compared to OpenGL [v3] In-Reply-To: References: <7FfjAXZJPIzx2OfaLY8dlET6NVnF-XAiaAI7mJwNGeo=.2381d679-8860-4c79-a7bd-4749f10bb90e@github.com> Message-ID: On Thu, 12 Aug 2021 23:33:51 GMT, Alexey Ushakov wrote: >> Then you can roll back this change to the default opaque layer? > > Did you mean to make MTLLayer opaque by default? Yes, I did it in the latest version. Then why do you need " platformWindow.setOpaque(!isTranslucent());" above? ------------- PR: https://git.openjdk.java.net/jdk/pull/4946 From psadhukhan at openjdk.java.net Fri Aug 13 04:10:27 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Fri, 13 Aug 2021 04:10:27 GMT Subject: RFR: 8270312: Error: Not a test or directory containing tests: java/awt/print/PrinterJob/XparColor.java [v7] In-Reply-To: References: Message-ID: On Thu, 12 Aug 2021 19:37:51 GMT, lawrence.andrews wrote: >> 1) This testcase was throwing error saying Error: Not a test or directory containing tests: java/awt/print/PrinterJob/XparColor.java >> 2) Added @test tag so that this testcase can be run >> 3) Since Applet is deprecated and its not supported any more in the future release remove applet and make the testcase to run as main >> 4) Since this is a manual testcase instruction frame or dailog was not visible just print dialog was visible so fixed it. >> 5) When the testcase was run via main method two print dialog was shown one was from main method and one more was from constructor. Fixed to show just one print dialog. >> 6) Since JDK 17 introduce metal rendering touching the java2d code thought this testcase will be useful to checking the rendering. >> >> @shurymury > > lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision: > > Fixed exception string Marked as reviewed by psadhukhan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4769 From kizune at openjdk.java.net Fri Aug 13 06:06:49 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Fri, 13 Aug 2021 06:06:49 GMT Subject: RFR: 8269951: [macos] Focus not painted in JButton when setBorderPainted(false) is invoked [v2] In-Reply-To: References: Message-ID: > Initial implementation and a test case. > > The problem is that Aqua LaF shows the focused component with the glow on the border, hence when the border is not painted the foxus is not displayed. The idea is to paint the glowing border on the focused component anyways. Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: Changed to only paing focus ring without the entire border painting ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5082/files - new: https://git.openjdk.java.net/jdk/pull/5082/files/d4b21edc..bda91782 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5082&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5082&range=00-01 Stats: 9 lines in 1 file changed: 6 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/5082.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5082/head:pull/5082 PR: https://git.openjdk.java.net/jdk/pull/5082 From kizune at openjdk.java.net Fri Aug 13 06:06:49 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Fri, 13 Aug 2021 06:06:49 GMT Subject: RFR: 8269951: [macos] Focus not painted in JButton when setBorderPainted(false) is invoked In-Reply-To: <7JolkPWVae9EMn_gAZuzIXB-PqUWGqH79SrivV7KC8A=.53bff0f3-27c0-471b-b0ef-8c86e4af8359@github.com> References: <7JolkPWVae9EMn_gAZuzIXB-PqUWGqH79SrivV7KC8A=.53bff0f3-27c0-471b-b0ef-8c86e4af8359@github.com> Message-ID: On Thu, 12 Aug 2021 18:17:47 GMT, Sergey Bylokhov wrote: > There are two choices: draw this rectangle ourselves or request this feature from the JRS. There i pushed the code that only draws the focus ring without the rest of the border. ------------- PR: https://git.openjdk.java.net/jdk/pull/5082 From kizune at openjdk.java.net Fri Aug 13 06:18:49 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Fri, 13 Aug 2021 06:18:49 GMT Subject: RFR: 8269951: [macos] Focus not painted in JButton when setBorderPainted(false) is invoked [v3] In-Reply-To: References: Message-ID: > Initial implementation and a test case. > > The problem is that Aqua LaF shows the focused component with the glow on the border, hence when the border is not painted the foxus is not displayed. The idea is to paint the glowing border on the focused component anyways. Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: Update copyright year ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5082/files - new: https://git.openjdk.java.net/jdk/pull/5082/files/bda91782..fefcd37d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5082&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5082&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5082.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5082/head:pull/5082 PR: https://git.openjdk.java.net/jdk/pull/5082 From psadhukhan at openjdk.java.net Fri Aug 13 12:18:23 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Fri, 13 Aug 2021 12:18:23 GMT Subject: RFR: 8269951: [macos] Focus not painted in JButton when setBorderPainted(false) is invoked [v3] In-Reply-To: References: Message-ID: On Fri, 13 Aug 2021 06:18:49 GMT, Alexander Zuev wrote: >> Initial implementation and a test case. >> >> The problem is that Aqua LaF shows the focused component with the glow on the border, hence when the border is not painted the foxus is not displayed. The idea is to paint the glowing border on the focused component anyways. > > Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright year src/java.desktop/macosx/classes/com/apple/laf/AquaButtonUI.java line 338: > 336: > 337: } > 338: Color ringColor = UIManager.getLookAndFeelDefaults().getColor("Focus.color"); I guess we normally call like this in Basic L&F which is extended by different L&Fs so that it will pick up the defaults from the particular L&F in question, otherwise UIManager.getColor(). should suffice as Focus.color is defined in AquaLookAndFeel. But I am not sure with this hardcoded values..Can't we leverage viewRect or textRect to get the required coordinates? ------------- PR: https://git.openjdk.java.net/jdk/pull/5082 From avu at openjdk.java.net Fri Aug 13 14:30:58 2021 From: avu at openjdk.java.net (Alexey Ushakov) Date: Fri, 13 Aug 2021 14:30:58 GMT Subject: RFR: 8266079: Lanai: AlphaComposite shows differences on Metal compared to OpenGL [v4] In-Reply-To: <7FfjAXZJPIzx2OfaLY8dlET6NVnF-XAiaAI7mJwNGeo=.2381d679-8860-4c79-a7bd-4749f10bb90e@github.com> References: <7FfjAXZJPIzx2OfaLY8dlET6NVnF-XAiaAI7mJwNGeo=.2381d679-8860-4c79-a7bd-4749f10bb90e@github.com> Message-ID: > Keep MTLLayer opacity in sync with window content view > Keep layer translucent for translucent windows Alexey Ushakov has updated the pull request incrementally with one additional commit since the last revision: 8266079: Lanai: AlphaComposite shows differences on Metal compared to OpenGL Removed unnecessary initialisation of opacity ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4946/files - new: https://git.openjdk.java.net/jdk/pull/4946/files/f7a003af..02056138 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4946&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4946&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4946.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4946/head:pull/4946 PR: https://git.openjdk.java.net/jdk/pull/4946 From avu at openjdk.java.net Fri Aug 13 14:36:25 2021 From: avu at openjdk.java.net (Alexey Ushakov) Date: Fri, 13 Aug 2021 14:36:25 GMT Subject: RFR: 8266079: Lanai: AlphaComposite shows differences on Metal compared to OpenGL [v4] In-Reply-To: References: <7FfjAXZJPIzx2OfaLY8dlET6NVnF-XAiaAI7mJwNGeo=.2381d679-8860-4c79-a7bd-4749f10bb90e@github.com> Message-ID: On Fri, 13 Aug 2021 01:46:20 GMT, Sergey Bylokhov wrote: >> Did you mean to make MTLLayer opaque by default? Yes, I did it in the latest version. > > Then why do you need " platformWindow.setOpaque(!isTranslucent());" above? Ah, I see. Updated. ------------- PR: https://git.openjdk.java.net/jdk/pull/4946 From serb at openjdk.java.net Fri Aug 13 18:39:23 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Fri, 13 Aug 2021 18:39:23 GMT Subject: RFR: 8266079: Lanai: AlphaComposite shows differences on Metal compared to OpenGL [v4] In-Reply-To: References: <7FfjAXZJPIzx2OfaLY8dlET6NVnF-XAiaAI7mJwNGeo=.2381d679-8860-4c79-a7bd-4749f10bb90e@github.com> Message-ID: On Fri, 13 Aug 2021 14:30:58 GMT, Alexey Ushakov wrote: >> Keep MTLLayer opacity in sync with window content view >> Keep layer translucent for translucent windows > > Alexey Ushakov has updated the pull request incrementally with one additional commit since the last revision: > > 8266079: Lanai: AlphaComposite shows differences on Metal compared to OpenGL > > Removed unnecessary initialisation of opacity Marked as reviewed by serb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4946 From kizune at openjdk.java.net Fri Aug 13 19:17:13 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Fri, 13 Aug 2021 19:17:13 GMT Subject: RFR: 8269951: [macos] Focus not painted in JButton when setBorderPainted(false) is invoked [v4] In-Reply-To: References: Message-ID: > Initial implementation and a test case. > > The problem is that Aqua LaF shows the focused component with the glow on the border, hence when the border is not painted the foxus is not displayed. The idea is to paint the glowing border on the focused component anyways. Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: Remove getLookAndFeelDefaults() call ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5082/files - new: https://git.openjdk.java.net/jdk/pull/5082/files/fefcd37d..df34ab0b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5082&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5082&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5082.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5082/head:pull/5082 PR: https://git.openjdk.java.net/jdk/pull/5082 From kizune at openjdk.java.net Fri Aug 13 19:26:29 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Fri, 13 Aug 2021 19:26:29 GMT Subject: RFR: 8269951: [macos] Focus not painted in JButton when setBorderPainted(false) is invoked [v3] In-Reply-To: References: Message-ID: On Fri, 13 Aug 2021 12:15:38 GMT, Prasanta Sadhukhan wrote: > UIManager.getColor(). should suffice Fixed. > But I am not sure with this hardcoded values..Can't we leverage viewRect or textRect to get the required coordinates? viewRect is set to be exactly (0, 0, b.width, b.height). Insets are buried deep inside JRS classes and used as hardcoded valued, i can not get them from there and both textRect and iconRect are not representing what needs to be drawn to be consistent with the way OS draws focus. Plus they are being initialized only later down the code and at the time of this call they are empty. Not that it would matter. ------------- PR: https://git.openjdk.java.net/jdk/pull/5082 From github.com+79671271+rajamah at openjdk.java.net Fri Aug 13 19:29:35 2021 From: github.com+79671271+rajamah at openjdk.java.net (rajat mahajan) Date: Fri, 13 Aug 2021 19:29:35 GMT Subject: RFR: 8272342: [TEST_BUG] java/awt/print/PrinterJob/PageDialogMarginTest.java catches all exceptions Message-ID: Removed try catch block so the test can function as expected and fail when it ought to, rather than passing all the time because of catch block catching all exceptions and Passing test even there is a failure. ------------- Commit messages: - 8272342: [TEST_BUG] java/awt/print/PrinterJob/PageDialogMarginTest.java catches all exceptions Changes: https://git.openjdk.java.net/jdk/pull/5115/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5115&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272342 Stats: 16 lines in 1 file changed: 0 ins; 3 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/5115.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5115/head:pull/5115 PR: https://git.openjdk.java.net/jdk/pull/5115 From aivanov at openjdk.java.net Fri Aug 13 19:47:29 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Fri, 13 Aug 2021 19:47:29 GMT Subject: RFR: 8272342: [TEST_BUG] java/awt/print/PrinterJob/PageDialogMarginTest.java catches all exceptions In-Reply-To: References: Message-ID: On Fri, 13 Aug 2021 19:23:21 GMT, rajat mahajan wrote: > Removed try catch block so the test can function as expected and fail > when it ought to, rather than passing all the time because of catch > block catching all exceptions and Passing test even there is a failure. Please add Locale.setDefault(Locale.US); as the first line in `main()`, otherwise the Page Format dialog uses millimetres instead of inches for non-US locales. Please resolve IDE warnings: 1. Use Java style array declaration in main: `String[] args`. 2. Line 51: Casting 'null' to 'Component' is redundant. 3. Line 50: Statement lambda can be replaced with expression lambda. Please update the copyright year. test/jdk/java/awt/print/PrinterJob/PageDialogMarginTest.java line 58: > 56: HashPrintRequestAttributeSet aset = new HashPrintRequestAttributeSet(); > 57: PageFormat pf; > 58: pf = pj.pageDialog(aset); I suggest merging these two lines: Suggestion: PageFormat pf = pj.pageDialog(aset); ------------- Changes requested by aivanov (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5115 From github.com+79671271+rajamah at openjdk.java.net Sat Aug 14 01:15:45 2021 From: github.com+79671271+rajamah at openjdk.java.net (rajat mahajan) Date: Sat, 14 Aug 2021 01:15:45 GMT Subject: RFR: 8272342: [TEST_BUG] java/awt/print/PrinterJob/PageDialogMarginTest.java catches all exceptions [v2] In-Reply-To: References: Message-ID: > Removed try catch block so the test can function as expected and fail > when it ought to, rather than passing all the time because of catch > block catching all exceptions and Passing test even there is a failure. rajat mahajan has updated the pull request incrementally with one additional commit since the last revision: Fix IDE warnings, added Default Locale as US, fixed Copyright to include current year. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5115/files - new: https://git.openjdk.java.net/jdk/pull/5115/files/a5c18b2d..2c181a8a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5115&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5115&range=00-01 Stats: 15 lines in 1 file changed: 6 ins; 2 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/5115.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5115/head:pull/5115 PR: https://git.openjdk.java.net/jdk/pull/5115 From github.com+79671271+rajamah at openjdk.java.net Sat Aug 14 01:15:49 2021 From: github.com+79671271+rajamah at openjdk.java.net (rajat mahajan) Date: Sat, 14 Aug 2021 01:15:49 GMT Subject: RFR: 8272342: [TEST_BUG] java/awt/print/PrinterJob/PageDialogMarginTest.java catches all exceptions [v2] In-Reply-To: References: Message-ID: <8zUdNG-wrkgUuuf7HTfgl7VMqtuKszlKqMdes7X2oAA=.4bd8ab5d-70ab-4cec-95b0-45dc17f6a773@github.com> On Fri, 13 Aug 2021 19:38:12 GMT, Alexey Ivanov wrote: >> rajat mahajan has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix IDE warnings, added Default Locale as US, fixed Copyright to include current year. > > test/jdk/java/awt/print/PrinterJob/PageDialogMarginTest.java line 58: > >> 56: HashPrintRequestAttributeSet aset = new HashPrintRequestAttributeSet(); >> 57: PageFormat pf; >> 58: pf = pj.pageDialog(aset); > > I suggest merging these two lines: > Suggestion: > > PageFormat pf = pj.pageDialog(aset); Made the changes you asked. ------------- PR: https://git.openjdk.java.net/jdk/pull/5115 From avu at openjdk.java.net Sat Aug 14 10:44:28 2021 From: avu at openjdk.java.net (Alexey Ushakov) Date: Sat, 14 Aug 2021 10:44:28 GMT Subject: Integrated: 8266079: Lanai: AlphaComposite shows differences on Metal compared to OpenGL In-Reply-To: <7FfjAXZJPIzx2OfaLY8dlET6NVnF-XAiaAI7mJwNGeo=.2381d679-8860-4c79-a7bd-4749f10bb90e@github.com> References: <7FfjAXZJPIzx2OfaLY8dlET6NVnF-XAiaAI7mJwNGeo=.2381d679-8860-4c79-a7bd-4749f10bb90e@github.com> Message-ID: On Fri, 30 Jul 2021 15:39:19 GMT, Alexey Ushakov wrote: > Keep MTLLayer opacity in sync with window content view > Keep layer translucent for translucent windows This pull request has now been integrated. Changeset: 17b93500 Author: Alexey Ushakov URL: https://git.openjdk.java.net/jdk/commit/17b93500237e74dca964e1805e65c857e7980bbe Stats: 274 lines in 7 files changed: 269 ins; 2 del; 3 mod 8266079: Lanai: AlphaComposite shows differences on Metal compared to OpenGL Reviewed-by: serb ------------- PR: https://git.openjdk.java.net/jdk/pull/4946 From pbansal at openjdk.java.net Sat Aug 14 18:36:28 2021 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Sat, 14 Aug 2021 18:36:28 GMT Subject: RFR: 8272342: [TEST_BUG] java/awt/print/PrinterJob/PageDialogMarginTest.java catches all exceptions [v2] In-Reply-To: References: Message-ID: On Sat, 14 Aug 2021 01:15:45 GMT, rajat mahajan wrote: >> Removed try catch block so the test can function as expected and fail >> when it ought to, rather than passing all the time because of catch >> block catching all exceptions and Passing test even there is a failure. > > rajat mahajan has updated the pull request incrementally with one additional commit since the last revision: > > Fix IDE warnings, added Default Locale as US, fixed Copyright to include current year. Marked as reviewed by pbansal (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5115 From aivanov at openjdk.java.net Sun Aug 15 10:30:29 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Sun, 15 Aug 2021 10:30:29 GMT Subject: RFR: 8272342: [TEST_BUG] java/awt/print/PrinterJob/PageDialogMarginTest.java catches all exceptions [v2] In-Reply-To: References: Message-ID: On Sat, 14 Aug 2021 01:15:45 GMT, rajat mahajan wrote: >> Removed try catch block so the test can function as expected and fail >> when it ought to, rather than passing all the time because of catch >> block catching all exceptions and Passing test even there is a failure. > > rajat mahajan has updated the pull request incrementally with one additional commit since the last revision: > > Fix IDE warnings, added Default Locale as US, fixed Copyright to include current year. Changes requested by aivanov (Reviewer). test/jdk/java/awt/print/PrinterJob/PageDialogMarginTest.java line 2: > 1: /* > 2: * Copyright (c) 2016, 2021, Oracle and/or its affiliates. All rights reserved. Suggestion: * Copyright (c) 2016, 2021, Oracle and/or its affiliates. All rights reserved. Two many spaces, there should be one space after the comma. test/jdk/java/awt/print/PrinterJob/PageDialogMarginTest.java line 40: > 38: import javax.swing.JOptionPane; > 39: import javax.swing.SwingUtilities; > 40: import java.text.MessageFormat; I wonder where do DialogTypeSelection and MessageFormat come from? The imports should be sorted by default, usually your IDE handles it perfectly on its own. ------------- PR: https://git.openjdk.java.net/jdk/pull/5115 From kizune at openjdk.java.net Sun Aug 15 11:31:30 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Sun, 15 Aug 2021 11:31:30 GMT Subject: RFR: 8269951: [macos] Focus not painted in JButton when setBorderPainted(false) is invoked In-Reply-To: <0X2hUh3oRZws_7VsKtvtCxGet3P-pgy0gEWCtIHPZkk=.f3586214-d01e-4232-9791-93ca72c943b6@github.com> References: <0X2hUh3oRZws_7VsKtvtCxGet3P-pgy0gEWCtIHPZkk=.f3586214-d01e-4232-9791-93ca72c943b6@github.com> Message-ID: On Thu, 12 Aug 2021 18:51:10 GMT, Sergey Bylokhov wrote: > Probably solution should be somewhere similar to this one That works for icons but for text it would create a terrible mess, text with glow effect will be unreadable. I made code that draws the focus ring instead without drawing the rest of the border. ------------- PR: https://git.openjdk.java.net/jdk/pull/5082 From serb at openjdk.java.net Mon Aug 16 02:19:28 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Mon, 16 Aug 2021 02:19:28 GMT Subject: RFR: 8269951: [macos] Focus not painted in JButton when setBorderPainted(false) is invoked [v4] In-Reply-To: References: Message-ID: <7LY1Ss4dbeqC0gRlccImv8WTfFBz3GbVFsehmXYZMX0=.7eda8ed7-3d51-4dd8-87c6-ff0282711188@github.com> On Fri, 13 Aug 2021 19:17:13 GMT, Alexander Zuev wrote: >> Initial implementation and a test case. >> >> The problem is that Aqua LaF shows the focused component with the glow on the border, hence when the border is not painted the foxus is not displayed. The idea is to paint the glowing border on the focused component anyways. > > Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: > > Remove getLookAndFeelDefaults() call Can you please create of blend of two images, one for common focused button(with border) and another one w/o. Just to check that the border is drawn in the similar location and using similar "shape". ------------- PR: https://git.openjdk.java.net/jdk/pull/5082 From kizune at openjdk.java.net Mon Aug 16 18:38:29 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Mon, 16 Aug 2021 18:38:29 GMT Subject: RFR: 8269951: [macos] Focus not painted in JButton when setBorderPainted(false) is invoked [v4] In-Reply-To: <7LY1Ss4dbeqC0gRlccImv8WTfFBz3GbVFsehmXYZMX0=.7eda8ed7-3d51-4dd8-87c6-ff0282711188@github.com> References: <7LY1Ss4dbeqC0gRlccImv8WTfFBz3GbVFsehmXYZMX0=.7eda8ed7-3d51-4dd8-87c6-ff0282711188@github.com> Message-ID: On Mon, 16 Aug 2021 02:15:55 GMT, Sergey Bylokhov wrote: > Can you please create of blend of two images, one for common focused button(with border) and another one w/o. Just to check that the border is drawn in the similar location and using similar "shape". Here is the overlap of two images - with and without borders painted, the without borders painted has 80% opacity so borders look faint. I do not think that the focus ring will always be pixel perfect match with the natively painted - but they are close enough that switching border painting on and off i can not tell difference visually and the new focus ring is always contained within the button shape so it will not disrupt anything beyond it. ![focus1b](https://user-images.githubusercontent.com/69642324/129612749-21283e4f-b97e-4aa0-aee1-451b9e60f151.png) ------------- PR: https://git.openjdk.java.net/jdk/pull/5082 From serb at openjdk.java.net Mon Aug 16 18:52:27 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Mon, 16 Aug 2021 18:52:27 GMT Subject: RFR: 8269951: [macos] Focus not painted in JButton when setBorderPainted(false) is invoked [v4] In-Reply-To: References: Message-ID: On Fri, 13 Aug 2021 19:17:13 GMT, Alexander Zuev wrote: >> Initial implementation and a test case. >> >> The problem is that Aqua LaF shows the focused component with the glow on the border, hence when the border is not painted the foxus is not displayed. The idea is to paint the glowing border on the focused component anyways. > > Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: > > Remove getLookAndFeelDefaults() call That looks great. src/java.desktop/macosx/classes/com/apple/laf/AquaButtonUI.java line 340: > 338: Color ringColor = UIManager.getColor("Focus.color"); > 339: g.setColor(ringColor); > 340: g.drawRoundRect(5, 3, b.getWidth() - 10, b.getHeight() - 7, 15, 15); Don't you need to restore the properties of Graphics2D? ------------- PR: https://git.openjdk.java.net/jdk/pull/5082 From github.com+79671271+rajamah at openjdk.java.net Mon Aug 16 19:40:49 2021 From: github.com+79671271+rajamah at openjdk.java.net (rajat mahajan) Date: Mon, 16 Aug 2021 19:40:49 GMT Subject: RFR: 8272342: [TEST_BUG] java/awt/print/PrinterJob/PageDialogMarginTest.java catches all exceptions [v3] In-Reply-To: References: Message-ID: <-1j15TQMUWK_oUc4asp4PZ8FQ2ElVoF7bQwuYKNQoDs=.f4afbff9-12c0-406d-8169-3decfde9acf1@github.com> > Removed try catch block so the test can function as expected and fail > when it ought to, rather than passing all the time because of catch > block catching all exceptions and Passing test even there is a failure. rajat mahajan has updated the pull request incrementally with one additional commit since the last revision: Update test/jdk/java/awt/print/PrinterJob/PageDialogMarginTest.java Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5115/files - new: https://git.openjdk.java.net/jdk/pull/5115/files/2c181a8a..e970bb25 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5115&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5115&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5115.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5115/head:pull/5115 PR: https://git.openjdk.java.net/jdk/pull/5115 From serb at openjdk.java.net Mon Aug 16 19:45:26 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Mon, 16 Aug 2021 19:45:26 GMT Subject: RFR: 8267161 : Write automated test case for JDK-4479161 [v2] In-Reply-To: <0EZv83zabHvGzXvdAOfBAJXIzX1NHlc_yJFuP2PT4Jc=.48fd129d-6da1-4048-a87a-87c7457bd398@github.com> References: <0EZv83zabHvGzXvdAOfBAJXIzX1NHlc_yJFuP2PT4Jc=.48fd129d-6da1-4048-a87a-87c7457bd398@github.com> Message-ID: <0Wtk-2MKLnnBCJE2h1qE9ypLYP7Y8twdAKn8f1kC-SA=.849a5812-e313-4713-baf7-291e367533c3@github.com> On Thu, 12 Aug 2021 15:46:43 GMT, lawrence.andrews wrote: >> 1) Automated the manual test case. >> 2) Removed html dependent file >> 3) Removed javax.swing.JApplet dependent. >> 4) Test case can be executed independently as well with jtreg framework. >> 5) Added methods to know that JFrame and Other component is visible before starting the user action via Robot. >> >> @shurymury > > lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision: > > Fixed the frame dispose with in EDT test/jdk/java/awt/im/4959409/bug4959409.java line 111: > 109: frame.setAlwaysOnTop(true); > 110: frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); > 111: frame.setVisible(true); A small suggestion is to move the frame to the center of the screen via frame.setLocationRelativeTo(null); before "frame.setVisible(true);" ------------- PR: https://git.openjdk.java.net/jdk/pull/5058 From kizune at openjdk.java.net Mon Aug 16 19:49:56 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Mon, 16 Aug 2021 19:49:56 GMT Subject: RFR: 8269951: [macos] Focus not painted in JButton when setBorderPainted(false) is invoked [v5] In-Reply-To: References: Message-ID: > Initial implementation and a test case. > > The problem is that Aqua LaF shows the focused component with the glow on the border, hence when the border is not painted the foxus is not displayed. The idea is to paint the glowing border on the focused component anyways. Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: Restore Graphics2D rendering state so we do not interfere with next stages of button painting. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5082/files - new: https://git.openjdk.java.net/jdk/pull/5082/files/df34ab0b..87ab3e3a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5082&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5082&range=03-04 Stats: 15 lines in 1 file changed: 13 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5082.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5082/head:pull/5082 PR: https://git.openjdk.java.net/jdk/pull/5082 From kizune at openjdk.java.net Mon Aug 16 19:49:57 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Mon, 16 Aug 2021 19:49:57 GMT Subject: RFR: 8269951: [macos] Focus not painted in JButton when setBorderPainted(false) is invoked [v4] In-Reply-To: References: Message-ID: On Mon, 16 Aug 2021 18:49:31 GMT, Sergey Bylokhov wrote: > Don't you need to restore the properties of Graphics2D? I might as well. ------------- PR: https://git.openjdk.java.net/jdk/pull/5082 From github.com+87324768+lawrence-andrew at openjdk.java.net Mon Aug 16 20:05:58 2021 From: github.com+87324768+lawrence-andrew at openjdk.java.net (lawrence.andrews) Date: Mon, 16 Aug 2021 20:05:58 GMT Subject: RFR: 8267161 : Write automated test case for JDK-4479161 [v3] In-Reply-To: References: Message-ID: > 1) Automated the manual test case. > 2) Removed html dependent file > 3) Removed javax.swing.JApplet dependent. > 4) Test case can be executed independently as well with jtreg framework. > 5) Added methods to know that JFrame and Other component is visible before starting the user action via Robot. > > @shurymury lawrence.andrews has updated the pull request incrementally with two additional commits since the last revision: - Fixed a single space issue - Add frame.setLocationRelativeTo to get the frame to center of the screen ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5058/files - new: https://git.openjdk.java.net/jdk/pull/5058/files/fb92d3a4..730c8f72 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5058&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5058&range=01-02 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5058.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5058/head:pull/5058 PR: https://git.openjdk.java.net/jdk/pull/5058 From github.com+87324768+lawrence-andrew at openjdk.java.net Mon Aug 16 20:06:03 2021 From: github.com+87324768+lawrence-andrew at openjdk.java.net (lawrence.andrews) Date: Mon, 16 Aug 2021 20:06:03 GMT Subject: RFR: 8267161 : Write automated test case for JDK-4479161 [v2] In-Reply-To: <0Wtk-2MKLnnBCJE2h1qE9ypLYP7Y8twdAKn8f1kC-SA=.849a5812-e313-4713-baf7-291e367533c3@github.com> References: <0EZv83zabHvGzXvdAOfBAJXIzX1NHlc_yJFuP2PT4Jc=.48fd129d-6da1-4048-a87a-87c7457bd398@github.com> <0Wtk-2MKLnnBCJE2h1qE9ypLYP7Y8twdAKn8f1kC-SA=.849a5812-e313-4713-baf7-291e367533c3@github.com> Message-ID: On Mon, 16 Aug 2021 19:42:37 GMT, Sergey Bylokhov wrote: >> lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed the frame dispose with in EDT > > test/jdk/java/awt/im/4959409/bug4959409.java line 111: > >> 109: frame.setAlwaysOnTop(true); >> 110: frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); >> 111: frame.setVisible(true); > > A small suggestion is to move the frame to the center of the screen via frame.setLocationRelativeTo(null); before "frame.setVisible(true);" Added frame.setLocationRelativeTo(null); & tested now I can see the frame is shown at the center of the screen. ------------- PR: https://git.openjdk.java.net/jdk/pull/5058 From serb at openjdk.java.net Mon Aug 16 20:19:27 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Mon, 16 Aug 2021 20:19:27 GMT Subject: RFR: 8267161 : Write automated test case for JDK-4479161 [v3] In-Reply-To: References: Message-ID: On Mon, 16 Aug 2021 20:05:58 GMT, lawrence.andrews wrote: >> 1) Automated the manual test case. >> 2) Removed html dependent file >> 3) Removed javax.swing.JApplet dependent. >> 4) Test case can be executed independently as well with jtreg framework. >> 5) Added methods to know that JFrame and Other component is visible before starting the user action via Robot. >> >> @shurymury > > lawrence.andrews has updated the pull request incrementally with two additional commits since the last revision: > > - Fixed a single space issue > - Add frame.setLocationRelativeTo to get the frame to center of the screen Marked as reviewed by serb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5058 From github.com+79671271+rajamah at openjdk.java.net Mon Aug 16 20:29:51 2021 From: github.com+79671271+rajamah at openjdk.java.net (rajat mahajan) Date: Mon, 16 Aug 2021 20:29:51 GMT Subject: RFR: 8272342: [TEST_BUG] java/awt/print/PrinterJob/PageDialogMarginTest.java catches all exceptions [v4] In-Reply-To: References: Message-ID: > Removed try catch block so the test can function as expected and fail > when it ought to, rather than passing all the time because of catch > block catching all exceptions and Passing test even there is a failure. rajat mahajan has updated the pull request incrementally with one additional commit since the last revision: remove unneccessary imports. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5115/files - new: https://git.openjdk.java.net/jdk/pull/5115/files/e970bb25..48dce3b4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5115&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5115&range=02-03 Stats: 9 lines in 1 file changed: 2 ins; 6 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5115.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5115/head:pull/5115 PR: https://git.openjdk.java.net/jdk/pull/5115 From aivanov at openjdk.java.net Mon Aug 16 20:52:30 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Mon, 16 Aug 2021 20:52:30 GMT Subject: RFR: 8272342: [TEST_BUG] java/awt/print/PrinterJob/PageDialogMarginTest.java catches all exceptions [v4] In-Reply-To: References: Message-ID: On Mon, 16 Aug 2021 20:29:51 GMT, rajat mahajan wrote: >> Removed try catch block so the test can function as expected and fail >> when it ought to, rather than passing all the time because of catch >> block catching all exceptions and Passing test even there is a failure. > > rajat mahajan has updated the pull request incrementally with one additional commit since the last revision: > > remove unneccessary imports. Marked as reviewed by aivanov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5115 From serb at openjdk.java.net Mon Aug 16 20:57:25 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Mon, 16 Aug 2021 20:57:25 GMT Subject: RFR: 8269951: [macos] Focus not painted in JButton when setBorderPainted(false) is invoked [v4] In-Reply-To: References: Message-ID: On Mon, 16 Aug 2021 19:45:11 GMT, Alexander Zuev wrote: >> src/java.desktop/macosx/classes/com/apple/laf/AquaButtonUI.java line 340: >> >>> 338: Color ringColor = UIManager.getColor("Focus.color"); >>> 339: g.setColor(ringColor); >>> 340: g.drawRoundRect(5, 3, b.getWidth() - 10, b.getHeight() - 7, 15, 15); >> >> Don't you need to restore the properties of Graphics2D? > >> Don't you need to restore the properties of Graphics2D? > > I might as well. What about the color property? ------------- PR: https://git.openjdk.java.net/jdk/pull/5082 From aivanov at openjdk.java.net Mon Aug 16 21:17:28 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Mon, 16 Aug 2021 21:17:28 GMT Subject: RFR: 8267161 : Write automated test case for JDK-4479161 [v3] In-Reply-To: References: Message-ID: On Mon, 16 Aug 2021 20:05:58 GMT, lawrence.andrews wrote: >> 1) Automated the manual test case. >> 2) Removed html dependent file >> 3) Removed javax.swing.JApplet dependent. >> 4) Test case can be executed independently as well with jtreg framework. >> 5) Added methods to know that JFrame and Other component is visible before starting the user action via Robot. >> >> @shurymury > > lawrence.andrews has updated the pull request incrementally with two additional commits since the last revision: > > - Fixed a single space issue > - Add frame.setLocationRelativeTo to get the frame to center of the screen test/jdk/java/awt/im/4959409/bug4959409.java line 47: > 45: import java.awt.Robot; > 46: import java.util.concurrent.CountDownLatch; > 47: import java.util.concurrent.TimeUnit; Usually in JDK, `javax.*` imports go after `java.*`. test/jdk/java/awt/im/4959409/bug4959409.java line 124: > 122: } > 123: > 124: Robot robot = new Robot(); Won't using `robot.setAutoDelay(DELAY)` give the same effect without the need to interleave key presses and mouse moves with explicit delay? test/jdk/java/awt/im/4959409/bug4959409.java line 144: > 142: robot.delay(DELAY); > 143: robot.keyRelease(KeyEvent.VK_1); > 144: robot.delay(DELAY); Shall we not release '1' first and then Shift? Isn't it the case mentioned in #5079 ? test/jdk/java/awt/im/4959409/bug4959409.java line 173: > 171: while (count <= 5) { > 172: TimeUnit.SECONDS.sleep(1); > 173: if (component.isVisible()) { Should `component.isVisible()` also be called on EDT? test/jdk/java/awt/im/4959409/bug4959409.java line 198: > 196: }); > 197: } > 198: } Probably this could be simplified to: Suggestion: try { createUIAndTest(); } finally { SwingUtilities.invokeAndWait(()-> { if (frame != null) { frame.dispose(); } }); } With the assumption `createUIAndTest()` is made static. ------------- PR: https://git.openjdk.java.net/jdk/pull/5058 From github.com+87324768+lawrence-andrew at openjdk.java.net Mon Aug 16 21:25:30 2021 From: github.com+87324768+lawrence-andrew at openjdk.java.net (lawrence.andrews) Date: Mon, 16 Aug 2021 21:25:30 GMT Subject: RFR: 8267161 : Write automated test case for JDK-4479161 [v3] In-Reply-To: References: Message-ID: On Mon, 16 Aug 2021 20:05:58 GMT, lawrence.andrews wrote: >> 1) Automated the manual test case. >> 2) Removed html dependent file >> 3) Removed javax.swing.JApplet dependent. >> 4) Test case can be executed independently as well with jtreg framework. >> 5) Added methods to know that JFrame and Other component is visible before starting the user action via Robot. >> >> @shurymury > > lawrence.andrews has updated the pull request incrementally with two additional commits since the last revision: > > - Fixed a single space issue > - Add frame.setLocationRelativeTo to get the frame to center of the screen Thanks @aivanov-jdk aivanov-jdk for reviewing. Yes, I can fixes your review. ------------- PR: https://git.openjdk.java.net/jdk/pull/5058 From github.com+79671271+rajamah at openjdk.java.net Mon Aug 16 22:26:33 2021 From: github.com+79671271+rajamah at openjdk.java.net (rajat mahajan) Date: Mon, 16 Aug 2021 22:26:33 GMT Subject: Integrated: 8272342: [TEST_BUG] java/awt/print/PrinterJob/PageDialogMarginTest.java catches all exceptions In-Reply-To: References: Message-ID: <8ttwVeG9x9HBKh1xV5wr-3f5Vqy7phJVZTp9Y1bmInw=.a125edca-c4cd-41f6-a744-3419c6ba133b@github.com> On Fri, 13 Aug 2021 19:23:21 GMT, rajat mahajan wrote: > Removed try catch block so the test can function as expected and fail > when it ought to, rather than passing all the time because of catch > block catching all exceptions and Passing test even there is a failure. This pull request has now been integrated. Changeset: a5ad7720 Author: Rajat Mahajan Committer: Alexey Ivanov URL: https://git.openjdk.java.net/jdk/commit/a5ad7720d235610ad45fc341c61f164805f82a54 Stats: 26 lines in 1 file changed: 2 ins; 5 del; 19 mod 8272342: [TEST_BUG] java/awt/print/PrinterJob/PageDialogMarginTest.java catches all exceptions Reviewed-by: aivanov, pbansal ------------- PR: https://git.openjdk.java.net/jdk/pull/5115 From kizune at openjdk.java.net Mon Aug 16 23:42:30 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Mon, 16 Aug 2021 23:42:30 GMT Subject: RFR: 8269951: [macos] Focus not painted in JButton when setBorderPainted(false) is invoked [v4] In-Reply-To: References: Message-ID: On Mon, 16 Aug 2021 20:53:56 GMT, Sergey Bylokhov wrote: > What about the color property? That would be unnecessary, whoever does painting does not just assumes that the color is set to his preferred choice, everywhere in the code color is set up before doing any painting and i do not see anywhere that old color being preserved. ------------- PR: https://git.openjdk.java.net/jdk/pull/5082 From serb at openjdk.java.net Mon Aug 16 23:49:30 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Mon, 16 Aug 2021 23:49:30 GMT Subject: RFR: 8269951: [macos] Focus not painted in JButton when setBorderPainted(false) is invoked [v4] In-Reply-To: References: Message-ID: On Mon, 16 Aug 2021 23:39:05 GMT, Alexander Zuev wrote: >> What about the color property? > >> What about the color property? > > That would be unnecessary, whoever does painting does not just assumes that the color is set to his preferred choice, everywhere in the code color is set up before doing any painting and i do not see anywhere that old color being preserved. You can trace the usage of graphics.getColor() for example in AquaMenuItemUI/WindowsMenuUI/BevelBorder/etc to check that the old color property is usually saved and then restored. ------------- PR: https://git.openjdk.java.net/jdk/pull/5082 From kizune at openjdk.java.net Tue Aug 17 06:09:51 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Tue, 17 Aug 2021 06:09:51 GMT Subject: RFR: 8269951: [macos] Focus not painted in JButton when setBorderPainted(false) is invoked [v4] In-Reply-To: References: Message-ID: <7i1w0_Dw8390kdsrRbvwMpNn1t8B_uhL4CfzRlOw2iM=.a0b35600-ea7a-483d-8a3e-060075938fa7@github.com> On Mon, 16 Aug 2021 23:46:18 GMT, Sergey Bylokhov wrote: > You can trace the usage of graphics.getColor() for example in AquaMenuItemUI/WindowsMenuUI/BevelBorder/etc to check that the old color property is usually saved and then restored. A few lines above paintFocus() is called there is a section that sets color to something different in case of opaque button and that does not affect the next step - text painting - since text painter will grab text color and set the graphics draw color to it. However in the interest of moving forward i will ad saving the color - after al it is not a performance critical task. ------------- PR: https://git.openjdk.java.net/jdk/pull/5082 From kizune at openjdk.java.net Tue Aug 17 06:09:51 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Tue, 17 Aug 2021 06:09:51 GMT Subject: RFR: 8269951: [macos] Focus not painted in JButton when setBorderPainted(false) is invoked [v6] In-Reply-To: References: Message-ID: > Initial implementation and a test case. > > The problem is that Aqua LaF shows the focused component with the glow on the border, hence when the border is not painted the foxus is not displayed. The idea is to paint the glowing border on the focused component anyways. Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: Restore Graphics color before leaving paintFocus() ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5082/files - new: https://git.openjdk.java.net/jdk/pull/5082/files/87ab3e3a..3b81c977 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5082&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5082&range=04-05 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5082.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5082/head:pull/5082 PR: https://git.openjdk.java.net/jdk/pull/5082 From github.com+87324768+lawrence-andrew at openjdk.java.net Tue Aug 17 07:47:29 2021 From: github.com+87324768+lawrence-andrew at openjdk.java.net (lawrence.andrews) Date: Tue, 17 Aug 2021 07:47:29 GMT Subject: Integrated: 8270312: Error: Not a test or directory containing tests: java/awt/print/PrinterJob/XparColor.java In-Reply-To: References: Message-ID: <4iwsK_Z-aBUcbv6lnQL_zxqUpIYudvY9NliS5aVzqzU=.99173948-9e04-4cff-9e5b-d07d377a0609@github.com> On Tue, 13 Jul 2021 14:57:30 GMT, lawrence.andrews wrote: > 1) This testcase was throwing error saying Error: Not a test or directory containing tests: java/awt/print/PrinterJob/XparColor.java > 2) Added @test tag so that this testcase can be run > 3) Since Applet is deprecated and its not supported any more in the future release remove applet and make the testcase to run as main > 4) Since this is a manual testcase instruction frame or dailog was not visible just print dialog was visible so fixed it. > 5) When the testcase was run via main method two print dialog was shown one was from main method and one more was from constructor. Fixed to show just one print dialog. > 6) Since JDK 17 introduce metal rendering touching the java2d code thought this testcase will be useful to checking the rendering. > > @shurymury This pull request has now been integrated. Changeset: c5c84b8f Author: lawrence.andrews Committer: Prasanta Sadhukhan URL: https://git.openjdk.java.net/jdk/commit/c5c84b8fdc0d52bc45ed7290011b39337f3bbe35 Stats: 306 lines in 1 file changed: 121 ins; 141 del; 44 mod 8270312: Error: Not a test or directory containing tests: java/awt/print/PrinterJob/XparColor.java Reviewed-by: psadhukhan, jdv ------------- PR: https://git.openjdk.java.net/jdk/pull/4769 From github.com+87324768+lawrence-andrew at openjdk.java.net Tue Aug 17 15:50:56 2021 From: github.com+87324768+lawrence-andrew at openjdk.java.net (lawrence.andrews) Date: Tue, 17 Aug 2021 15:50:56 GMT Subject: RFR: 8267161 : Write automated test case for JDK-4479161 [v4] In-Reply-To: References: Message-ID: > 1) Automated the manual test case. > 2) Removed html dependent file > 3) Removed javax.swing.JApplet dependent. > 4) Test case can be executed independently as well with jtreg framework. > 5) Added methods to know that JFrame and Other component is visible before starting the user action via Robot. > > @shurymury lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision: Fixed review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5058/files - new: https://git.openjdk.java.net/jdk/pull/5058/files/730c8f72..82af0725 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5058&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5058&range=02-03 Stats: 76 lines in 1 file changed: 39 ins; 20 del; 17 mod Patch: https://git.openjdk.java.net/jdk/pull/5058.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5058/head:pull/5058 PR: https://git.openjdk.java.net/jdk/pull/5058 From github.com+87324768+lawrence-andrew at openjdk.java.net Tue Aug 17 15:50:58 2021 From: github.com+87324768+lawrence-andrew at openjdk.java.net (lawrence.andrews) Date: Tue, 17 Aug 2021 15:50:58 GMT Subject: RFR: 8267161 : Write automated test case for JDK-4479161 [v3] In-Reply-To: References: Message-ID: On Mon, 16 Aug 2021 20:05:58 GMT, lawrence.andrews wrote: >> 1) Automated the manual test case. >> 2) Removed html dependent file >> 3) Removed javax.swing.JApplet dependent. >> 4) Test case can be executed independently as well with jtreg framework. >> 5) Added methods to know that JFrame and Other component is visible before starting the user action via Robot. >> >> @shurymury > > lawrence.andrews has updated the pull request incrementally with two additional commits since the last revision: > > - Fixed a single space issue > - Add frame.setLocationRelativeTo to get the frame to center of the screen @aivanov-jdk , fixed all the comments that you have asked for. ------------- PR: https://git.openjdk.java.net/jdk/pull/5058 From serb at openjdk.java.net Tue Aug 17 20:02:25 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Tue, 17 Aug 2021 20:02:25 GMT Subject: RFR: 8269951: [macos] Focus not painted in JButton when setBorderPainted(false) is invoked [v6] In-Reply-To: References: Message-ID: <-oDUkyBkkN9MrkW3JuW47Tj7d5CeJ34bpzv2QPgmbkc=.d2ad0753-c689-42a8-b669-54fa75a20758@github.com> On Tue, 17 Aug 2021 06:09:51 GMT, Alexander Zuev wrote: >> Initial implementation and a test case. >> >> The problem is that Aqua LaF shows the focused component with the glow on the border, hence when the border is not painted the foxus is not displayed. The idea is to paint the glowing border on the focused component anyways. > > Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: > > Restore Graphics color before leaving paintFocus() Marked as reviewed by serb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5082 From psadhukhan at openjdk.java.net Wed Aug 18 05:02:23 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Wed, 18 Aug 2021 05:02:23 GMT Subject: RFR: 8269951: [macos] Focus not painted in JButton when setBorderPainted(false) is invoked [v4] In-Reply-To: <7i1w0_Dw8390kdsrRbvwMpNn1t8B_uhL4CfzRlOw2iM=.a0b35600-ea7a-483d-8a3e-060075938fa7@github.com> References: <7i1w0_Dw8390kdsrRbvwMpNn1t8B_uhL4CfzRlOw2iM=.a0b35600-ea7a-483d-8a3e-060075938fa7@github.com> Message-ID: On Tue, 17 Aug 2021 06:04:39 GMT, Alexander Zuev wrote: >> You can trace the usage of graphics.getColor() for example in AquaMenuItemUI/WindowsMenuUI/BevelBorder/etc to check that the old color property is usually saved and then restored. > >> You can trace the usage of graphics.getColor() for example in AquaMenuItemUI/WindowsMenuUI/BevelBorder/etc to check that the old color property is usually saved and then restored. > > A few lines above paintFocus() is called there is a section that sets color to something different in case of opaque button and that does not affect the next step - text painting - since text painter will grab text color and set the graphics draw color to it. However in the interest of moving forward i will ad saving the color - after al it is not a performance critical task. Have you checked if button does not have any text? It might affect the drawRoundRect values which are hardcoded now...In MetalButtonUI#paintFocus, it seems they cater to Button focus ring with and without text by taking care of setBounds(). Do we need to do something similar here? ------------- PR: https://git.openjdk.java.net/jdk/pull/5082 From kizune at openjdk.java.net Wed Aug 18 05:35:29 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Wed, 18 Aug 2021 05:35:29 GMT Subject: RFR: 8269951: [macos] Focus not painted in JButton when setBorderPainted(false) is invoked [v4] In-Reply-To: References: <7i1w0_Dw8390kdsrRbvwMpNn1t8B_uhL4CfzRlOw2iM=.a0b35600-ea7a-483d-8a3e-060075938fa7@github.com> Message-ID: On Wed, 18 Aug 2021 04:59:36 GMT, Prasanta Sadhukhan wrote: > Have you checked if button does not have any text? Yes, i did. Neither my code nor native focus painter is affected by it. ------------- PR: https://git.openjdk.java.net/jdk/pull/5082 From psadhukhan at openjdk.java.net Wed Aug 18 05:41:29 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Wed, 18 Aug 2021 05:41:29 GMT Subject: RFR: 8269951: [macos] Focus not painted in JButton when setBorderPainted(false) is invoked [v6] In-Reply-To: References: Message-ID: On Tue, 17 Aug 2021 06:09:51 GMT, Alexander Zuev wrote: >> Initial implementation and a test case. >> >> The problem is that Aqua LaF shows the focused component with the glow on the border, hence when the border is not painted the foxus is not displayed. The idea is to paint the glowing border on the focused component anyways. > > Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: > > Restore Graphics color before leaving paintFocus() Marked as reviewed by psadhukhan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5082 From kizune at openjdk.java.net Wed Aug 18 05:52:36 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Wed, 18 Aug 2021 05:52:36 GMT Subject: Integrated: 8269951: [macos] Focus not painted in JButton when setBorderPainted(false) is invoked In-Reply-To: References: Message-ID: On Wed, 11 Aug 2021 11:22:50 GMT, Alexander Zuev wrote: > Initial implementation and a test case. > > The problem is that Aqua LaF shows the focused component with the glow on the border, hence when the border is not painted the foxus is not displayed. The idea is to paint the glowing border on the focused component anyways. This pull request has now been integrated. Changeset: 481c1f05 Author: Alexander Zuev URL: https://git.openjdk.java.net/jdk/commit/481c1f0549e361e8e83fcf0530acc4ebdb60104b Stats: 121 lines in 2 files changed: 120 ins; 0 del; 1 mod 8269951: [macos] Focus not painted in JButton when setBorderPainted(false) is invoked Reviewed-by: serb, psadhukhan ------------- PR: https://git.openjdk.java.net/jdk/pull/5082 From aivanov at openjdk.java.net Wed Aug 18 22:29:27 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Wed, 18 Aug 2021 22:29:27 GMT Subject: RFR: 8267161 : Write automated test case for JDK-4479161 [v4] In-Reply-To: References: Message-ID: On Tue, 17 Aug 2021 15:50:56 GMT, lawrence.andrews wrote: >> 1) Automated the manual test case. >> 2) Removed html dependent file >> 3) Removed javax.swing.JApplet dependent. >> 4) Test case can be executed independently as well with jtreg framework. >> 5) Added methods to know that JFrame and Other component is visible before starting the user action via Robot. >> >> @shurymury > > lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision: > > Fixed review comments Changes requested by aivanov (Reviewer). test/jdk/java/awt/im/4959409/bug4959409.java line 24: > 22: */ > 23: > 24: /** I suggest to remove the second `*` to avoid the warning from the IDE about the dangling Javadoc comment. test/jdk/java/awt/im/4959409/bug4959409.java line 65: > 63: final CountDownLatch keyPressedEventLatch = new CountDownLatch(1); > 64: final Point points[] = new Point[1]; > 65: final Rectangle rect[] = new Rectangle[1]; Suggestion: final Point[] points = new Point[1]; final Rectangle[] rect = new Rectangle[1]; The IDE issues a warning about C-style array declaration. test/jdk/java/awt/im/4959409/bug4959409.java line 103: > 101: } else { > 102: jLabel.setText("Did not received KEY PRESS for Shift+1"); > 103: System.out.println("Did not received KEY PRESS for Shift+1"); Suggestion: jLabel.setText("Did not receive KEY PRESS for Shift+1"); System.out.println("Did not receive KEY PRESS for Shift+1"); Probably it makes sense to spell ?KEYPRESS?, without the space, for consistency. test/jdk/java/awt/im/4959409/bug4959409.java line 147: > 145: > 146: if (!keyPressedEventLatch.await(TIMEOUT, TimeUnit.SECONDS)) { > 147: throw new RuntimeException("Did not received KEY PRESS for Shift + 1 , test failed"); Suggestion: throw new RuntimeException("Did not receive KEY PRESS for Shift + 1 , test failed"); And the same for ?KEY PRESS?. test/jdk/java/awt/im/4959409/bug4959409.java line 162: > 160: } > 161: > 162: public static void checkSwingTopLevelVisible(javax.swing.JFrame jFrame, CountDownLatch topLevelVisibleLatch) throws InterruptedException, InvocationTargetException { Is there a reason why you use the fully qualified `javax.swing.JFrame` when it's imported? I suggest wrapping `throws` declaration to next line; this line is longer than 100. Both comments apply to the method below. test/jdk/java/awt/im/4959409/bug4959409.java line 170: > 168: } > 169: > 170: public static boolean isTopLevelVisible(javax.swing.JFrame jFrame, CountDownLatch topLevelVisibleLatch) throws Exception { The logic in this method polls `jFrame.isVisible` instead of waiting for it to become visible. Nothing wrong with this approach yet the last call `topLevelVisibleLatch.await(TIMEOUT, TimeUnit.SECONDS)` doesn't make sense in this case as the latch can't reach 0 if it's not zero. So, if something goes wrong, the test still waits for `TIMEOUT` (30) seconds for the condition that can never be satisfied. I suggest returning `topLevelVisibleLatch.getCount() == 0` and save 30 seconds. Probably it's enough to check whether the text field is visible. The text field can become visible only if frame is visible, both likely become visible at the same moment anyway. test/jdk/java/awt/im/4959409/bug4959409.java line 177: > 175: TimeUnit.SECONDS.sleep(1); > 176: checkSwingTopLevelVisible(jFrame, topLevelVisibleLatch); > 177: if (topLevelVisibleLatch.getCount() == 0) { Maybe this condition could be in the while loop? while (count <= 5 && topLevelVisibleLatch.getCount() != 0) Then there's no need for explicit premature break from the loop. test/jdk/java/awt/im/4959409/bug4959409.java line 186: > 184: } > 185: > 186: public static void checkJComponentVisible(javax.swing.JComponent jComponent, CountDownLatch componentVisibleLatch) throws InterruptedException, InvocationTargetException { You're using fully qualified `javax.swing.JComponent` here: `JComponent` isn't imported. Why not import it? Please also wrap `throws` declaration to the next line. test/jdk/java/awt/im/4959409/bug4959409.java line 216: > 214: if (frame != null) { > 215: SwingUtilities.invokeAndWait(frame::dispose); > 216: } This has inconsistency where `frame != null` is run on main thread without synchronisation. The null check should also be run on the EDT as I originally suggested. ------------- PR: https://git.openjdk.java.net/jdk/pull/5058 From github.com+87324768+lawrence-andrew at openjdk.java.net Wed Aug 18 23:34:24 2021 From: github.com+87324768+lawrence-andrew at openjdk.java.net (lawrence.andrews) Date: Wed, 18 Aug 2021 23:34:24 GMT Subject: RFR: 8267161 : Write automated test case for JDK-4479161 [v3] In-Reply-To: References: Message-ID: On Mon, 16 Aug 2021 20:58:08 GMT, Alexey Ivanov wrote: >> lawrence.andrews has updated the pull request incrementally with two additional commits since the last revision: >> >> - Fixed a single space issue >> - Add frame.setLocationRelativeTo to get the frame to center of the screen > > test/jdk/java/awt/im/4959409/bug4959409.java line 47: > >> 45: import java.awt.Robot; >> 46: import java.util.concurrent.CountDownLatch; >> 47: import java.util.concurrent.TimeUnit; > > Usually in JDK, `javax.*` imports go after `java.*`. moved javax.swing after java.* ------------- PR: https://git.openjdk.java.net/jdk/pull/5058 From prr at openjdk.java.net Thu Aug 19 00:06:48 2021 From: prr at openjdk.java.net (Phil Race) Date: Thu, 19 Aug 2021 00:06:48 GMT Subject: RFR: 8272602: [macos] not all KEY_PRESSED events sent when control modifier is used Message-ID: When Ctrl+Space is pressed mac generates a string that contains the single unicode code point zero. The fn that converts it from an NSString to a Java String is using NewStringUTF. The input to that is a null terminated string which also has zero as the code point it contains, so we actually end up with a zero length Java string instead of the intended one code point in length. So the fix is to change the way we convert the string. There's an existing test CtrlAscii.java which sort of tests some of this but it isn't asserting that you get what you expect, its mostly testing you don't get something *unexpected* .. it will happily pass if you don't get keyevents. I did not want to change the purpose of that test for this. So I wrote a test specific to this Ctrl+Space to verify the fix but also ran all the standard automated tests too. ------------- Commit messages: - 8272602: [macos] not all KEY_PRESSED events sent when control modifier is used - 8272602: [macos] not all KEY_PRESSED events sent when control modifier is used Changes: https://git.openjdk.java.net/jdk/pull/5177/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5177&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272602 Stats: 110 lines in 2 files changed: 108 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5177.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5177/head:pull/5177 PR: https://git.openjdk.java.net/jdk/pull/5177 From psadhukhan at openjdk.java.net Thu Aug 19 07:27:22 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Thu, 19 Aug 2021 07:27:22 GMT Subject: RFR: 8272602: [macos] not all KEY_PRESSED events sent when control modifier is used In-Reply-To: References: Message-ID: On Wed, 18 Aug 2021 23:57:38 GMT, Phil Race wrote: > When Ctrl+Space is pressed mac generates a string that contains the single unicode code point zero. > The fn that converts it from an NSString to a Java String is using NewStringUTF. > The input to that is a null terminated string which also has zero as the code point it contains, so > we actually end up with a zero length Java string instead of the intended one code point in length. > So the fix is to change the way we convert the string. > > There's an existing test CtrlAscii.java which sort of tests some of this but it isn't asserting that you > get what you expect, its mostly testing you don't get something *unexpected* .. it will happily pass if > you don't get keyevents. I did not want to change the purpose of that test for this. > So I wrote a test specific to this Ctrl+Space to verify the fix but also ran all the standard automated tests too. src/java.desktop/macosx/native/libosxapp/JNIUtilities.m line 55: > 53: jstring jStr = (*env)->NewString(env, buffer, len); > 54: free(buffer); > 55: CHECK_EXCEPTION(); Shouldn't it be better to call CHECK_EXCEPTION_NULL_RETURN() here to return null in case NewString throw exception in which case, I guess jStr will have garbage. Also, it seems https://developer.apple.com/documentation/foundation/nsstring/1408720-getcharacters says the buffer must be large enough...aRange.length*sizeof(unichar) so shouldn't the NSRange be created for (0, len * sizeof(unichar)) ------------- PR: https://git.openjdk.java.net/jdk/pull/5177 From avu at openjdk.java.net Thu Aug 19 12:26:40 2021 From: avu at openjdk.java.net (Alexey Ushakov) Date: Thu, 19 Aug 2021 12:26:40 GMT Subject: RFR: 8272481: [macos] javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java fails Message-ID: Update opacity only if the component is visible ------------- Commit messages: - 8272481: [macos] javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java fails - 8272481: [macos] javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java fails Changes: https://git.openjdk.java.net/jdk/pull/5172/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5172&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272481 Stats: 2 lines in 2 files changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5172.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5172/head:pull/5172 PR: https://git.openjdk.java.net/jdk/pull/5172 From serb at openjdk.java.net Thu Aug 19 12:26:41 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Thu, 19 Aug 2021 12:26:41 GMT Subject: RFR: 8272481: [macos] javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java fails In-Reply-To: References: Message-ID: On Wed, 18 Aug 2021 21:07:28 GMT, Alexey Ushakov wrote: > Update opacity only if the component is visible src/java.desktop/macosx/classes/sun/lwawt/LWWindowPeer.java line 524: > 522: if (textured != isTextured) { > 523: textured = isTextured; > 524: if (isVisible()) updateOpaque(); What is the root cause of the problem? Why we do not change the surface if the peer is invisible? If the texture property will be changed while the peer is invisible who and when will call the "updateOpaque"? ------------- PR: https://git.openjdk.java.net/jdk/pull/5172 From kizune at openjdk.java.net Thu Aug 19 15:43:26 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Thu, 19 Aug 2021 15:43:26 GMT Subject: RFR: 8272602: [macos] not all KEY_PRESSED events sent when control modifier is used In-Reply-To: References: Message-ID: On Wed, 18 Aug 2021 23:57:38 GMT, Phil Race wrote: > When Ctrl+Space is pressed mac generates a string that contains the single unicode code point zero. > The fn that converts it from an NSString to a Java String is using NewStringUTF. > The input to that is a null terminated string which also has zero as the code point it contains, so > we actually end up with a zero length Java string instead of the intended one code point in length. > So the fix is to change the way we convert the string. > > There's an existing test CtrlAscii.java which sort of tests some of this but it isn't asserting that you > get what you expect, its mostly testing you don't get something *unexpected* .. it will happily pass if > you don't get keyevents. I did not want to change the purpose of that test for this. > So I wrote a test specific to this Ctrl+Space to verify the fix but also ran all the standard automated tests too. Checked - fix works and it does not break input handling including multibyte characters. ------------- Marked as reviewed by kizune (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5177 From github.com+87324768+lawrence-andrew at openjdk.java.net Thu Aug 19 15:49:25 2021 From: github.com+87324768+lawrence-andrew at openjdk.java.net (lawrence.andrews) Date: Thu, 19 Aug 2021 15:49:25 GMT Subject: RFR: 8267161 : Write automated test case for JDK-4479161 [v4] In-Reply-To: References: Message-ID: On Tue, 10 Aug 2021 18:08:55 GMT, Sergey Bylokhov wrote: >> lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed review comments > > test/jdk/java/awt/im/4959409/bug4959409.java line 55: > >> 53: >> 54: public JFrame createUIAndTest() throws Exception { >> 55: final JFrame frame = new JFrame("Test bug4959409"); > > Please make sure that the Swing components, created/used/disposed on the EDT. Added EDT ------------- PR: https://git.openjdk.java.net/jdk/pull/5058 From github.com+87324768+lawrence-andrew at openjdk.java.net Thu Aug 19 15:49:26 2021 From: github.com+87324768+lawrence-andrew at openjdk.java.net (lawrence.andrews) Date: Thu, 19 Aug 2021 15:49:26 GMT Subject: RFR: 8267161 : Write automated test case for JDK-4479161 [v4] In-Reply-To: References: Message-ID: On Wed, 18 Aug 2021 21:58:04 GMT, Alexey Ivanov wrote: >> lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed review comments > > test/jdk/java/awt/im/4959409/bug4959409.java line 65: > >> 63: final CountDownLatch keyPressedEventLatch = new CountDownLatch(1); >> 64: final Point points[] = new Point[1]; >> 65: final Rectangle rect[] = new Rectangle[1]; > > Suggestion: > > final Point[] points = new Point[1]; > final Rectangle[] rect = new Rectangle[1]; > > > The IDE issues a warning about C-style array declaration. corrected and now the IDE does not issue the warning. ------------- PR: https://git.openjdk.java.net/jdk/pull/5058 From github.com+87324768+lawrence-andrew at openjdk.java.net Thu Aug 19 15:49:28 2021 From: github.com+87324768+lawrence-andrew at openjdk.java.net (lawrence.andrews) Date: Thu, 19 Aug 2021 15:49:28 GMT Subject: RFR: 8267161 : Write automated test case for JDK-4479161 [v3] In-Reply-To: References: Message-ID: On Mon, 16 Aug 2021 21:00:47 GMT, Alexey Ivanov wrote: >> lawrence.andrews has updated the pull request incrementally with two additional commits since the last revision: >> >> - Fixed a single space issue >> - Add frame.setLocationRelativeTo to get the frame to center of the screen > > test/jdk/java/awt/im/4959409/bug4959409.java line 124: > >> 122: } >> 123: >> 124: Robot robot = new Robot(); > > Won't using `robot.setAutoDelay(DELAY)` give the same effect without the need to interleave key presses and mouse moves with explicit delay? added > test/jdk/java/awt/im/4959409/bug4959409.java line 144: > >> 142: robot.delay(DELAY); >> 143: robot.keyRelease(KeyEvent.VK_1); >> 144: robot.delay(DELAY); > > Shall we not release '1' first and then Shift? > > Isn't it the case mentioned in #5079 ? done > test/jdk/java/awt/im/4959409/bug4959409.java line 173: > >> 171: while (count <= 5) { >> 172: TimeUnit.SECONDS.sleep(1); >> 173: if (component.isVisible()) { > > Should `component.isVisible()` also be called on EDT? done > test/jdk/java/awt/im/4959409/bug4959409.java line 198: > >> 196: }); >> 197: } >> 198: } > > Probably this could be simplified to: > Suggestion: > > try { > createUIAndTest(); > } finally { > SwingUtilities.invokeAndWait(()-> { > if (frame != null) { > frame.dispose(); > } > }); > } > > > With the assumption `createUIAndTest()` is made static. done ------------- PR: https://git.openjdk.java.net/jdk/pull/5058 From kizune at openjdk.java.net Thu Aug 19 15:50:25 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Thu, 19 Aug 2021 15:50:25 GMT Subject: RFR: 8272602: [macos] not all KEY_PRESSED events sent when control modifier is used In-Reply-To: References: Message-ID: On Wed, 18 Aug 2021 23:57:38 GMT, Phil Race wrote: > When Ctrl+Space is pressed mac generates a string that contains the single unicode code point zero. > The fn that converts it from an NSString to a Java String is using NewStringUTF. > The input to that is a null terminated string which also has zero as the code point it contains, so > we actually end up with a zero length Java string instead of the intended one code point in length. > So the fix is to change the way we convert the string. > > There's an existing test CtrlAscii.java which sort of tests some of this but it isn't asserting that you > get what you expect, its mostly testing you don't get something *unexpected* .. it will happily pass if > you don't get keyevents. I did not want to change the purpose of that test for this. > So I wrote a test specific to this Ctrl+Space to verify the fix but also ran all the standard automated tests too. On the other hand i now see that AFTER i did a multibyte character input every time i switch into application with - i get following output in the terminal: 2021-08-19 08:44:24.155 java[18144:1448976] Apple AWT Internal Exception: Java Exception ------------- PR: https://git.openjdk.java.net/jdk/pull/5177 From kizune at openjdk.java.net Thu Aug 19 15:56:23 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Thu, 19 Aug 2021 15:56:23 GMT Subject: RFR: 8272602: [macos] not all KEY_PRESSED events sent when control modifier is used In-Reply-To: References: Message-ID: On Wed, 18 Aug 2021 23:57:38 GMT, Phil Race wrote: > When Ctrl+Space is pressed mac generates a string that contains the single unicode code point zero. > The fn that converts it from an NSString to a Java String is using NewStringUTF. > The input to that is a null terminated string which also has zero as the code point it contains, so > we actually end up with a zero length Java string instead of the intended one code point in length. > So the fix is to change the way we convert the string. > > There's an existing test CtrlAscii.java which sort of tests some of this but it isn't asserting that you > get what you expect, its mostly testing you don't get something *unexpected* .. it will happily pass if > you don't get keyevents. I did not want to change the purpose of that test for this. > So I wrote a test specific to this Ctrl+Space to verify the fix but also ran all the standard automated tests too. > On the other hand i now see that AFTER i did a multibyte character input every time i switch into application with - i get following output in the terminal: > 2021-08-19 08:44:24.155 java[18144:1448976] Apple AWT Internal Exception: Java Exception It is not related to this change, i rolled it back and the issue persists so has nothing to do with this fix. ------------- PR: https://git.openjdk.java.net/jdk/pull/5177 From aivanov at openjdk.java.net Thu Aug 19 16:42:29 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Thu, 19 Aug 2021 16:42:29 GMT Subject: RFR: 8267161 : Write automated test case for JDK-4479161 [v4] In-Reply-To: References: Message-ID: On Tue, 17 Aug 2021 15:50:56 GMT, lawrence.andrews wrote: >> 1) Automated the manual test case. >> 2) Removed html dependent file >> 3) Removed javax.swing.JApplet dependent. >> 4) Test case can be executed independently as well with jtreg framework. >> 5) Added methods to know that JFrame and Other component is visible before starting the user action via Robot. >> >> @shurymury > > lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision: > > Fixed review comments Hi Lawrence, I played a bit with the test and it looks it can be simplified. First of all, `jTextField.isVisible` is always `true`. So it makes no sense to check its value. As for the frame, you have `ComponentListener` which decreases the value of `frameVisibleLatch`. Alternatively, you could use `WindowListener` and its `windowOpened`. Once the frame is displayed, the text field is also displayed. So it looks like the code could be simplified to the following: SwingUtilities.invokeAndWait( /* create the frame and components */); robot.waitForIdle(); if (!frameVisibleLatch.await(TIMEOUT, TimeUnit.SECONDS)) { new RuntimeException("Frame is not visible after " + TIMEOUT + " seconds"); } robot.waitForIdle(); performMouseAction(); // And so on What do you think? I suggest renaming `performMouseAction` to something more specific and descriptive, like `clickTextField` ? this way the purpose of the action / method is obvious without opening its code. ------------- PR: https://git.openjdk.java.net/jdk/pull/5058 From github.com+87324768+lawrence-andrew at openjdk.java.net Thu Aug 19 18:38:27 2021 From: github.com+87324768+lawrence-andrew at openjdk.java.net (lawrence.andrews) Date: Thu, 19 Aug 2021 18:38:27 GMT Subject: RFR: 8267161 : Write automated test case for JDK-4479161 [v4] In-Reply-To: References: Message-ID: On Wed, 18 Aug 2021 21:56:51 GMT, Alexey Ivanov wrote: >> lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed review comments > > test/jdk/java/awt/im/4959409/bug4959409.java line 24: > >> 22: */ >> 23: >> 24: /** > > I suggest to remove the second `*` to avoid the warning from the IDE about the dangling Javadoc comment. removed > test/jdk/java/awt/im/4959409/bug4959409.java line 147: > >> 145: >> 146: if (!keyPressedEventLatch.await(TIMEOUT, TimeUnit.SECONDS)) { >> 147: throw new RuntimeException("Did not received KEY PRESS for Shift + 1 , test failed"); > > Suggestion: > > throw new RuntimeException("Did not receive KEY PRESS for Shift + 1 , test failed"); > > And the same for ?KEY PRESS?. Done > test/jdk/java/awt/im/4959409/bug4959409.java line 170: > >> 168: } >> 169: >> 170: public static boolean isTopLevelVisible(javax.swing.JFrame jFrame, CountDownLatch topLevelVisibleLatch) throws Exception { > > The logic in this method polls `jFrame.isVisible` instead of waiting for it to become visible. Nothing wrong with this approach yet the last call `topLevelVisibleLatch.await(TIMEOUT, TimeUnit.SECONDS)` doesn't make sense in this case as the latch can't reach 0 if it's not zero. > > So, if something goes wrong, the test still waits for `TIMEOUT` (30) seconds for the condition that can never be satisfied. I suggest returning `topLevelVisibleLatch.getCount() == 0` and save 30 seconds. > > Probably it's enough to check whether the text field is visible. The text field can become visible only if frame is visible, both likely become visible at the same moment anyway. Removed this method > test/jdk/java/awt/im/4959409/bug4959409.java line 216: > >> 214: if (frame != null) { >> 215: SwingUtilities.invokeAndWait(frame::dispose); >> 216: } > > This has inconsistency where `frame != null` is run on main thread without synchronisation. The null check should also be run on the EDT as I originally suggested. Done ------------- PR: https://git.openjdk.java.net/jdk/pull/5058 From github.com+87324768+lawrence-andrew at openjdk.java.net Thu Aug 19 18:54:48 2021 From: github.com+87324768+lawrence-andrew at openjdk.java.net (lawrence.andrews) Date: Thu, 19 Aug 2021 18:54:48 GMT Subject: RFR: 8267161 : Write automated test case for JDK-4479161 [v5] In-Reply-To: References: Message-ID: > 1) Automated the manual test case. > 2) Removed html dependent file > 3) Removed javax.swing.JApplet dependent. > 4) Test case can be executed independently as well with jtreg framework. > 5) Added methods to know that JFrame and Other component is visible before starting the user action via Robot. > > @shurymury lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision: Added WindowListener to check Frame is opened and simplified the testcase ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5058/files - new: https://git.openjdk.java.net/jdk/pull/5058/files/82af0725..b40a1353 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5058&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5058&range=03-04 Stats: 115 lines in 1 file changed: 15 ins; 76 del; 24 mod Patch: https://git.openjdk.java.net/jdk/pull/5058.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5058/head:pull/5058 PR: https://git.openjdk.java.net/jdk/pull/5058 From github.com+87324768+lawrence-andrew at openjdk.java.net Thu Aug 19 18:54:49 2021 From: github.com+87324768+lawrence-andrew at openjdk.java.net (lawrence.andrews) Date: Thu, 19 Aug 2021 18:54:49 GMT Subject: RFR: 8267161 : Write automated test case for JDK-4479161 [v4] In-Reply-To: References: Message-ID: On Wed, 18 Aug 2021 22:05:18 GMT, Alexey Ivanov wrote: >> lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed review comments > > test/jdk/java/awt/im/4959409/bug4959409.java line 162: > >> 160: } >> 161: >> 162: public static void checkSwingTopLevelVisible(javax.swing.JFrame jFrame, CountDownLatch topLevelVisibleLatch) throws InterruptedException, InvocationTargetException { > > Is there a reason why you use the fully qualified `javax.swing.JFrame` when it's imported? > > I suggest wrapping `throws` declaration to next line; this line is longer than 100. > > Both comments apply to the method below. done > test/jdk/java/awt/im/4959409/bug4959409.java line 186: > >> 184: } >> 185: >> 186: public static void checkJComponentVisible(javax.swing.JComponent jComponent, CountDownLatch componentVisibleLatch) throws InterruptedException, InvocationTargetException { > > You're using fully qualified `javax.swing.JComponent` here: `JComponent` isn't imported. Why not import it? > > Please also wrap `throws` declaration to the next line. Removed ------------- PR: https://git.openjdk.java.net/jdk/pull/5058 From prr at openjdk.java.net Thu Aug 19 20:28:26 2021 From: prr at openjdk.java.net (Phil Race) Date: Thu, 19 Aug 2021 20:28:26 GMT Subject: RFR: 8272602: [macos] not all KEY_PRESSED events sent when control modifier is used In-Reply-To: References: Message-ID: On Wed, 18 Aug 2021 23:57:38 GMT, Phil Race wrote: > When Ctrl+Space is pressed mac generates a string that contains the single unicode code point zero. > The fn that converts it from an NSString to a Java String is using NewStringUTF. > The input to that is a null terminated string which also has zero as the code point it contains, so > we actually end up with a zero length Java string instead of the intended one code point in length. > So the fix is to change the way we convert the string. > > There's an existing test CtrlAscii.java which sort of tests some of this but it isn't asserting that you > get what you expect, its mostly testing you don't get something *unexpected* .. it will happily pass if > you don't get keyevents. I did not want to change the purpose of that test for this. > So I wrote a test specific to this Ctrl+Space to verify the fix but also ran all the standard automated tests too. Yep, it is unrelated to what is being touched in this fix so should be handled separately. It needs a new bug report and this fix can go ahead. ------------- PR: https://git.openjdk.java.net/jdk/pull/5177 From prr at openjdk.java.net Thu Aug 19 20:28:27 2021 From: prr at openjdk.java.net (Phil Race) Date: Thu, 19 Aug 2021 20:28:27 GMT Subject: RFR: 8272602: [macos] not all KEY_PRESSED events sent when control modifier is used In-Reply-To: References: Message-ID: On Thu, 19 Aug 2021 07:23:19 GMT, Prasanta Sadhukhan wrote: >> Shouldn't it be better to call CHECK_EXCEPTION_NULL_RETURN() If the jstring were garbage in such a case we would NOT want to check it against null, since that would be a definite problem. As it is NewString is specified to return NULL if there is a problem so the existing code is fine although the alternative pattern of CHECK_EXCEPTION_NULL_RETURN(jstr, NULL) would also work. SInce I'm not changing this I think it fine to stick with the existing code. >> the buffer must be large enough...aRange.length*sizeof(unichar) so shouldn't the NSRange be created for (0, len * sizeof(unichar)) The buffer *is* large enough buffer = (unichar*) calloc(len, sizeof(unichar)); the NSRange is the *number of elements* to copy. It is not the buffer storage ------------- PR: https://git.openjdk.java.net/jdk/pull/5177 From serb at openjdk.java.net Thu Aug 19 21:08:24 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Thu, 19 Aug 2021 21:08:24 GMT Subject: RFR: 8272602: [macos] not all KEY_PRESSED events sent when control modifier is used In-Reply-To: References: Message-ID: On Wed, 18 Aug 2021 23:57:38 GMT, Phil Race wrote: > When Ctrl+Space is pressed mac generates a string that contains the single unicode code point zero. > The fn that converts it from an NSString to a Java String is using NewStringUTF. > The input to that is a null terminated string which also has zero as the code point it contains, so > we actually end up with a zero length Java string instead of the intended one code point in length. > So the fix is to change the way we convert the string. > > There's an existing test CtrlAscii.java which sort of tests some of this but it isn't asserting that you > get what you expect, its mostly testing you don't get something *unexpected* .. it will happily pass if > you don't get keyevents. I did not want to change the purpose of that test for this. > So I wrote a test specific to this Ctrl+Space to verify the fix but also ran all the standard automated tests too. src/java.desktop/macosx/native/libosxapp/JNIUtilities.m line 47: > 45: return NULL; > 46: } > 47: jstring jStr = (*env)->NewStringUTF(env, [str UTF8String]); Probably we should cleanup all usage of [nsstring UTF8String] in the code at some point. ------------- PR: https://git.openjdk.java.net/jdk/pull/5177 From prr at openjdk.java.net Thu Aug 19 21:28:22 2021 From: prr at openjdk.java.net (Phil Race) Date: Thu, 19 Aug 2021 21:28:22 GMT Subject: RFR: 8272602: [macos] not all KEY_PRESSED events sent when control modifier is used In-Reply-To: References: Message-ID: On Thu, 19 Aug 2021 21:05:46 GMT, Sergey Bylokhov wrote: >> When Ctrl+Space is pressed mac generates a string that contains the single unicode code point zero. >> The fn that converts it from an NSString to a Java String is using NewStringUTF. >> The input to that is a null terminated string which also has zero as the code point it contains, so >> we actually end up with a zero length Java string instead of the intended one code point in length. >> So the fix is to change the way we convert the string. >> >> There's an existing test CtrlAscii.java which sort of tests some of this but it isn't asserting that you >> get what you expect, its mostly testing you don't get something *unexpected* .. it will happily pass if >> you don't get keyevents. I did not want to change the purpose of that test for this. >> So I wrote a test specific to this Ctrl+Space to verify the fix but also ran all the standard automated tests too. > > src/java.desktop/macosx/native/libosxapp/JNIUtilities.m line 47: > >> 45: return NULL; >> 46: } >> 47: jstring jStr = (*env)->NewStringUTF(env, [str UTF8String]); > > Probably we should cleanup all usage of [nsstring UTF8String] in the code at some point. Depends on what the source data is. FWIW in the macOS code in java.desktop there are just 5 others and none of them were touched/added/changed by the JNF work. They are all pre-existing. ------------- PR: https://git.openjdk.java.net/jdk/pull/5177 From prr at openjdk.java.net Fri Aug 20 00:12:34 2021 From: prr at openjdk.java.net (Phil Race) Date: Fri, 20 Aug 2021 00:12:34 GMT Subject: Integrated: 8272602: [macos] not all KEY_PRESSED events sent when control modifier is used In-Reply-To: References: Message-ID: On Wed, 18 Aug 2021 23:57:38 GMT, Phil Race wrote: > When Ctrl+Space is pressed mac generates a string that contains the single unicode code point zero. > The fn that converts it from an NSString to a Java String is using NewStringUTF. > The input to that is a null terminated string which also has zero as the code point it contains, so > we actually end up with a zero length Java string instead of the intended one code point in length. > So the fix is to change the way we convert the string. > > There's an existing test CtrlAscii.java which sort of tests some of this but it isn't asserting that you > get what you expect, its mostly testing you don't get something *unexpected* .. it will happily pass if > you don't get keyevents. I did not want to change the purpose of that test for this. > So I wrote a test specific to this Ctrl+Space to verify the fix but also ran all the standard automated tests too. This pull request has now been integrated. Changeset: ddcd851c Author: Phil Race URL: https://git.openjdk.java.net/jdk/commit/ddcd851c43aa97477c7e406490c0c7c7d71ac629 Stats: 110 lines in 2 files changed: 108 ins; 1 del; 1 mod 8272602: [macos] not all KEY_PRESSED events sent when control modifier is used Reviewed-by: kizune ------------- PR: https://git.openjdk.java.net/jdk/pull/5177 From github.com+10835776+stsypanov at openjdk.java.net Fri Aug 20 09:48:36 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Fri, 20 Aug 2021 09:48:36 GMT Subject: RFR: 8272756: Remove unnecessary explicit initialization of volatile variables in java.desktop Message-ID: This is a continuation of - https://bugs.openjdk.java.net/browse/JDK-6736490 - https://bugs.openjdk.java.net/browse/JDK-8035284 - https://bugs.openjdk.java.net/browse/JDK-8145680 - https://bugs.openjdk.java.net/browse/JDK-8251548 As mentioned in JDK-6736490: _An explicit initialization of a volatile class instance variable, such as private volatile Object = null; or private volatile int scale = 0; is unnecessary since the Java spec automatically initializes objects to null and primitive type short, int, long, float and double to 0 and boolean to false. Explicit initialization of volatile variable to a value the same as the default implicit initialized value results in an unnecessary store and membar operation._ ------------- Commit messages: - 8272756: Remove unnecessary explicit initialization of volatile fields in java.desktop Changes: https://git.openjdk.java.net/jdk/pull/5197/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5197&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272756 Stats: 50 lines in 25 files changed: 0 ins; 0 del; 50 mod Patch: https://git.openjdk.java.net/jdk/pull/5197.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5197/head:pull/5197 PR: https://git.openjdk.java.net/jdk/pull/5197 From aivanov at openjdk.java.net Fri Aug 20 13:48:27 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Fri, 20 Aug 2021 13:48:27 GMT Subject: RFR: 8267161 : Write automated test case for JDK-4479161 [v5] In-Reply-To: References: Message-ID: On Thu, 19 Aug 2021 18:54:48 GMT, lawrence.andrews wrote: >> 1) Automated the manual test case. >> 2) Removed html dependent file >> 3) Removed javax.swing.JApplet dependent. >> 4) Test case can be executed independently as well with jtreg framework. >> 5) Added methods to know that JFrame and Other component is visible before starting the user action via Robot. >> >> @shurymury > > lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision: > > Added WindowListener to check Frame is opened and simplified the testcase Marked as reviewed by aivanov (Reviewer). test/jdk/java/awt/im/4959409/bug4959409.java line 59: > 57: private static JLabel jLabel; > 58: > 59: public static void createUIAndTest() throws InterruptedException, InvocationTargetException, AWTException { `throws Exception` would be enough and shorter: Suggestion: public static void createUIAndTest() throws Exception { It's a test code, any exception means the test fails, so we don't care much about which specific exceptions can be thrown. test/jdk/java/awt/im/4959409/bug4959409.java line 80: > 78: > 79: jTextField.addKeyListener(new KeyAdapter() { > 80: I'd remove this blank line for consistency with the anonymous class above. test/jdk/java/awt/im/4959409/bug4959409.java line 92: > 90: } else { > 91: jLabel.setText("Did not received keyPressed for Shift+1"); > 92: System.out.println("Did not received keyPressed for Shift+1"); The grammar: Suggestion: jLabel.setText("Did not receive keyPressed for Shift+1"); System.out.println("Did not receive keyPressed for Shift+1"); test/jdk/java/awt/im/4959409/bug4959409.java line 120: > 118: }); > 119: > 120: clickTextField(robot, points[0].x + rect[0].width / 2, points[0].y + rect[0].height / 2); I'd probably wrap this line, it doesn't fit even in 120 columns. test/jdk/java/awt/im/4959409/bug4959409.java line 131: > 129: > 130: if (!keyPressedEventLatch.await(TIMEOUT, TimeUnit.SECONDS)) { > 131: throw new RuntimeException("Did not received keyPressed for Shift + 1 , test failed"); The grammar: Suggestion: throw new RuntimeException("Did not receive keyPressed for Shift + 1 , test failed"); test/jdk/java/awt/im/4959409/bug4959409.java line 147: > 145: > 146: public static void main(String[] args) throws InterruptedException, InvocationTargetException, > 147: AWTException { Suggestion: public static void main(String[] args) throws Exception { Shorter. ------------- PR: https://git.openjdk.java.net/jdk/pull/5058 From github.com+87324768+lawrence-andrew at openjdk.java.net Fri Aug 20 14:43:29 2021 From: github.com+87324768+lawrence-andrew at openjdk.java.net (lawrence.andrews) Date: Fri, 20 Aug 2021 14:43:29 GMT Subject: RFR: 8267161 : Write automated test case for JDK-4479161 [v5] In-Reply-To: References: Message-ID: <00uVRcP3hskuaLL9dNoye9kHbK4R_kt4YDnTRZKG5Dc=.bf72f348-8f61-416c-9362-cf9883d14d62@github.com> On Fri, 20 Aug 2021 13:39:58 GMT, Alexey Ivanov wrote: >> lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision: >> >> Added WindowListener to check Frame is opened and simplified the testcase > > test/jdk/java/awt/im/4959409/bug4959409.java line 59: > >> 57: private static JLabel jLabel; >> 58: >> 59: public static void createUIAndTest() throws InterruptedException, InvocationTargetException, AWTException { > > `throws Exception` would be enough and shorter: > Suggestion: > > public static void createUIAndTest() throws Exception { > > > It's a test code, any exception means the test fails, so we don't care much about which specific exceptions can be thrown. Okay > test/jdk/java/awt/im/4959409/bug4959409.java line 80: > >> 78: >> 79: jTextField.addKeyListener(new KeyAdapter() { >> 80: > > I'd remove this blank line for consistency with the anonymous class above. Done > test/jdk/java/awt/im/4959409/bug4959409.java line 92: > >> 90: } else { >> 91: jLabel.setText("Did not received keyPressed for Shift+1"); >> 92: System.out.println("Did not received keyPressed for Shift+1"); > > The grammar: > Suggestion: > > jLabel.setText("Did not receive keyPressed for Shift+1"); > System.out.println("Did not receive keyPressed for Shift+1"); done ------------- PR: https://git.openjdk.java.net/jdk/pull/5058 From github.com+87324768+lawrence-andrew at openjdk.java.net Fri Aug 20 14:50:51 2021 From: github.com+87324768+lawrence-andrew at openjdk.java.net (lawrence.andrews) Date: Fri, 20 Aug 2021 14:50:51 GMT Subject: RFR: 8267161 : Write automated test case for JDK-4479161 [v6] In-Reply-To: References: Message-ID: > 1) Automated the manual test case. > 2) Removed html dependent file > 3) Removed javax.swing.JApplet dependent. > 4) Test case can be executed independently as well with jtreg framework. > 5) Added methods to know that JFrame and Other component is visible before starting the user action via Robot. > > @shurymury lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision: Fixed review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5058/files - new: https://git.openjdk.java.net/jdk/pull/5058/files/b40a1353..f85ad4f4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5058&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5058&range=04-05 Stats: 13 lines in 1 file changed: 1 ins; 3 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/5058.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5058/head:pull/5058 PR: https://git.openjdk.java.net/jdk/pull/5058 From github.com+87324768+lawrence-andrew at openjdk.java.net Fri Aug 20 14:50:53 2021 From: github.com+87324768+lawrence-andrew at openjdk.java.net (lawrence.andrews) Date: Fri, 20 Aug 2021 14:50:53 GMT Subject: RFR: 8267161 : Write automated test case for JDK-4479161 [v5] In-Reply-To: References: Message-ID: On Fri, 20 Aug 2021 13:45:23 GMT, Alexey Ivanov wrote: >> lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision: >> >> Added WindowListener to check Frame is opened and simplified the testcase > > test/jdk/java/awt/im/4959409/bug4959409.java line 120: > >> 118: }); >> 119: >> 120: clickTextField(robot, points[0].x + rect[0].width / 2, points[0].y + rect[0].height / 2); > > I'd probably wrap this line, it doesn't fit even in 120 columns. done > test/jdk/java/awt/im/4959409/bug4959409.java line 131: > >> 129: >> 130: if (!keyPressedEventLatch.await(TIMEOUT, TimeUnit.SECONDS)) { >> 131: throw new RuntimeException("Did not received keyPressed for Shift + 1 , test failed"); > > The grammar: > Suggestion: > > throw new RuntimeException("Did not receive keyPressed for Shift + 1 , test failed"); done > test/jdk/java/awt/im/4959409/bug4959409.java line 147: > >> 145: >> 146: public static void main(String[] args) throws InterruptedException, InvocationTargetException, >> 147: AWTException { > > Suggestion: > > public static void main(String[] args) throws Exception { > > Shorter. done ------------- PR: https://git.openjdk.java.net/jdk/pull/5058 From aivanov at openjdk.java.net Fri Aug 20 15:05:28 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Fri, 20 Aug 2021 15:05:28 GMT Subject: RFR: 8267161 : Write automated test case for JDK-4479161 [v6] In-Reply-To: References: Message-ID: On Fri, 20 Aug 2021 14:50:51 GMT, lawrence.andrews wrote: >> 1) Automated the manual test case. >> 2) Removed html dependent file >> 3) Removed javax.swing.JApplet dependent. >> 4) Test case can be executed independently as well with jtreg framework. >> 5) Added methods to know that JFrame and Other component is visible before starting the user action via Robot. >> >> @shurymury > > lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision: > > Fixed review comments test/jdk/java/awt/im/4959409/bug4959409.java line 87: > 85: keyPressedEventLatch.countDown(); > 86: jLabel.setText("keyPressed receive for Shift+1"); > 87: System.out.println("keyPressed receive for Shift+1"); Here, it was correct: ?received?. ------------- PR: https://git.openjdk.java.net/jdk/pull/5058 From github.com+87324768+lawrence-andrew at openjdk.java.net Fri Aug 20 15:13:46 2021 From: github.com+87324768+lawrence-andrew at openjdk.java.net (lawrence.andrews) Date: Fri, 20 Aug 2021 15:13:46 GMT Subject: RFR: 8267161 : Write automated test case for JDK-4479161 [v7] In-Reply-To: References: Message-ID: > 1) Automated the manual test case. > 2) Removed html dependent file > 3) Removed javax.swing.JApplet dependent. > 4) Test case can be executed independently as well with jtreg framework. > 5) Added methods to know that JFrame and Other component is visible before starting the user action via Robot. > > @shurymury lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision: Fixed the right word ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5058/files - new: https://git.openjdk.java.net/jdk/pull/5058/files/f85ad4f4..c4b2649f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5058&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5058&range=05-06 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5058.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5058/head:pull/5058 PR: https://git.openjdk.java.net/jdk/pull/5058 From aivanov at openjdk.java.net Fri Aug 20 15:13:47 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Fri, 20 Aug 2021 15:13:47 GMT Subject: RFR: 8267161 : Write automated test case for JDK-4479161 [v7] In-Reply-To: References: Message-ID: On Fri, 20 Aug 2021 15:10:41 GMT, lawrence.andrews wrote: >> 1) Automated the manual test case. >> 2) Removed html dependent file >> 3) Removed javax.swing.JApplet dependent. >> 4) Test case can be executed independently as well with jtreg framework. >> 5) Added methods to know that JFrame and Other component is visible before starting the user action via Robot. >> >> @shurymury > > lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision: > > Fixed the right word Marked as reviewed by aivanov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5058 From github.com+87324768+lawrence-andrew at openjdk.java.net Fri Aug 20 15:13:48 2021 From: github.com+87324768+lawrence-andrew at openjdk.java.net (lawrence.andrews) Date: Fri, 20 Aug 2021 15:13:48 GMT Subject: RFR: 8267161 : Write automated test case for JDK-4479161 [v6] In-Reply-To: References: Message-ID: <9Llo38HXGR8EagbAupPWp6QihVCazT7d6JWGrjtivLw=.8e144902-de8a-46b4-b63b-ed8a020bd84a@github.com> On Fri, 20 Aug 2021 15:01:35 GMT, Alexey Ivanov wrote: >> lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed review comments > > test/jdk/java/awt/im/4959409/bug4959409.java line 87: > >> 85: keyPressedEventLatch.countDown(); >> 86: jLabel.setText("keyPressed receive for Shift+1"); >> 87: System.out.println("keyPressed receive for Shift+1"); > > Here, it was correct: ?received?. Over curiously did search and replace . Corrected ------------- PR: https://git.openjdk.java.net/jdk/pull/5058 From github.com+87324768+lawrence-andrew at openjdk.java.net Fri Aug 20 17:49:33 2021 From: github.com+87324768+lawrence-andrew at openjdk.java.net (lawrence.andrews) Date: Fri, 20 Aug 2021 17:49:33 GMT Subject: Integrated: 8267161 : Write automated test case for JDK-4479161 In-Reply-To: References: Message-ID: On Mon, 9 Aug 2021 18:36:07 GMT, lawrence.andrews wrote: > 1) Automated the manual test case. > 2) Removed html dependent file > 3) Removed javax.swing.JApplet dependent. > 4) Test case can be executed independently as well with jtreg framework. > 5) Added methods to know that JFrame and Other component is visible before starting the user action via Robot. > > @shurymury This pull request has now been integrated. Changeset: d85560ed Author: lawrence.andrews Committer: Alexey Ivanov URL: https://git.openjdk.java.net/jdk/commit/d85560ed0f10a586b659db1c0201373457f1a5a9 Stats: 172 lines in 2 files changed: 88 ins; 50 del; 34 mod 8267161: Write automated test case for JDK-4479161 Reviewed-by: serb, aivanov ------------- PR: https://git.openjdk.java.net/jdk/pull/5058 From serb at openjdk.java.net Fri Aug 20 21:29:25 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Fri, 20 Aug 2021 21:29:25 GMT Subject: RFR: 8272756: Remove unnecessary explicit initialization of volatile variables in java.desktop In-Reply-To: References: Message-ID: <5D1AIPvGtkcbri_67kjwE9GuRe8F4P8A0KZmJ2s68hs=.351bc6fb-b1a6-491d-9cb8-e4738cf7ac2c@github.com> On Fri, 20 Aug 2021 09:41:15 GMT, ?????? ??????? wrote: > This is a continuation of > > - https://bugs.openjdk.java.net/browse/JDK-6736490 > - https://bugs.openjdk.java.net/browse/JDK-8035284 > - https://bugs.openjdk.java.net/browse/JDK-8145680 > - https://bugs.openjdk.java.net/browse/JDK-8251548 > > As mentioned in JDK-6736490: > > _An explicit initialization of a volatile class instance variable, such as private volatile Object = null; or private volatile int scale = 0; is unnecessary since the Java spec automatically initializes objects to null and primitive type short, int, long, float and double to 0 and boolean to false. Explicit initialization of volatile variable to a value the same as the default implicit initialized value results in an unnecessary store and membar operation._ src/java.desktop/share/classes/com/sun/imageio/plugins/tiff/TIFFIFD.java line 64: > 62: Set tags = essentialTags; > 63: if (tags == null) { > 64: essentialTags = Set.of( What is the purpose of the local tags here? ------------- PR: https://git.openjdk.java.net/jdk/pull/5197 From github.com+9004656+yaaz at openjdk.java.net Sun Aug 22 00:45:30 2021 From: github.com+9004656+yaaz at openjdk.java.net (Nikita Gubarkov) Date: Sun, 22 Aug 2021 00:45:30 GMT Subject: RFR: 8269806: Emoji rendering on Linux In-Reply-To: References: Message-ID: On Thu, 15 Jul 2021 17:29:01 GMT, Nikita Gubarkov wrote: > It was implemented in JetBrains Runtime a year ago and was ported & refactored for this PR > It includes: > - Bitmap glyph loading via Freetype > - Manual scaling & transformation of bitmap glyphs with nearest-neighbor or bilinear-mipmap style algorithms depending on the text antialiasing hint > - Storing BGRA glyphs in glyph cache & rendering them as plain images, as currently used XRender text drawing functions doesn't support colored glyphs > - Small fixes in related code like null-checks which could cause NPE & comment typos @prrace could you take a look, please? ------------- PR: https://git.openjdk.java.net/jdk/pull/4798 From prr at openjdk.java.net Sun Aug 22 19:53:39 2021 From: prr at openjdk.java.net (Phil Race) Date: Sun, 22 Aug 2021 19:53:39 GMT Subject: RFR: 8272806: [macOS] "Apple AWT Internal Exception" when input method is changed Message-ID: <_LPMeJrHJf9_qj9lPYH9A6u9OrY0_MHW79-6I6XkNAM=.5bbe4315-f595-4f84-adf2-18fccad17544@github.com> There's a long eval in the bug report : https://bugs.openjdk.java.net/browse/JDK-8272806 but here's the summary When focus is lost by the app a message is sent down to native setting a native reference to the input method to null which is a sort of signal not to notify upwards anything to the input method (which internally will NPE if there's no focused component as is the case after focus is lost). But we aren't actually setting it to null because of a check for null which previously checked the wrapper for the JNI ref was not null but is now obsolete. So just remove the check for null. The steps to reproduce this bug are very manual and involve installing additional input methods and toggling them at the system level. So I didn't see a way to write a useful regression test but if you follow the bug report steps you should be able to verify the fix. I've run all automated tests just for good measure and they all pass. ------------- Commit messages: - 8272806: [macOS] "Apple AWT Internal Exception" when input method is changed Changes: https://git.openjdk.java.net/jdk/pull/5211/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5211&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272806 Stats: 4 lines in 2 files changed: 1 ins; 2 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5211.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5211/head:pull/5211 PR: https://git.openjdk.java.net/jdk/pull/5211 From prr at openjdk.java.net Sun Aug 22 23:38:23 2021 From: prr at openjdk.java.net (Phil Race) Date: Sun, 22 Aug 2021 23:38:23 GMT Subject: RFR: 8269806: Emoji rendering on Linux In-Reply-To: References: Message-ID: <-JIpbhv_iLWOo58V6WjshEQnkrGYAyNOO9RqCc874UI=.af9f2174-1f6e-475e-baf0-abe2c3ec7181@github.com> On Thu, 15 Jul 2021 17:29:01 GMT, Nikita Gubarkov wrote: > It was implemented in JetBrains Runtime a year ago and was ported & refactored for this PR > It includes: > - Bitmap glyph loading via Freetype > - Manual scaling & transformation of bitmap glyphs with nearest-neighbor or bilinear-mipmap style algorithms depending on the text antialiasing hint > - Storing BGRA glyphs in glyph cache & rendering them as plain images, as currently used XRender text drawing functions doesn't support colored glyphs > - Small fixes in related code like null-checks which could cause NPE & comment typos I'm in the early stages but 1) It doesn't build on the OL6.4 "official" build environment (note SFAIK the latest info is still here : https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms) Maybe there'll be an update for JDK 18 but it hasn't happened yet src/java.desktop/share/native/libfontmanager/freetypeScaler.c:1193:24: error: 'FT_LOAD_COLOR' undeclared (first use in this function) renderFlags |= FT_LOAD_COLOR; ^~~~~~~~~~~~~ src/java.desktop/share/native/libfontmanager/freetypeScaler.c:1193:24: note: each undeclared identifier is reported only once for each function it appears in src/java.desktop/share/native/libfontmanager/freetypeScaler.c:1259:50: error: 'FT_PIXEL_MODE_BGRA' undeclared (first use in this function); did you mean 'FT_PIXEL_MODE_GRAY'? } else if (ftglyph->bitmap.pixel_mode == FT_PIXEL_MODE_BGRA) { ^~~~~~~~~~~~~~~~~~ FT_PIXEL_MODE_GRAY At the very least this means you will need to include defines for these if they aren't defined and make sure that symbols that may be similarly from a later freetype than available on older linuxes are loaded dynamically and the support skipped where it doesn't exist. 2) I see Xrender code changes but am wondering what happens with the X11 and OpenGL pipelines ? Errors of some code ? Silently behaves like this new code doesn't exist ? OK I can partially answer that one - garbage rendering with X11 on Ubuntu 20.04 Looks like you are supplying the BRGA glyphs but no loops to handle it. This needs to be implemented for X11 and OpenGL ------------- PR: https://git.openjdk.java.net/jdk/pull/4798 From prr at openjdk.java.net Mon Aug 23 04:55:29 2021 From: prr at openjdk.java.net (Phil Race) Date: Mon, 23 Aug 2021 04:55:29 GMT Subject: RFR: 8269806: Emoji rendering on Linux In-Reply-To: References: Message-ID: On Thu, 15 Jul 2021 17:29:01 GMT, Nikita Gubarkov wrote: > It was implemented in JetBrains Runtime a year ago and was ported & refactored for this PR > It includes: > - Bitmap glyph loading via Freetype > - Manual scaling & transformation of bitmap glyphs with nearest-neighbor or bilinear-mipmap style algorithms depending on the text antialiasing hint > - Storing BGRA glyphs in glyph cache & rendering them as plain images, as currently used XRender text drawing functions doesn't support colored glyphs > - Small fixes in related code like null-checks which could cause NPE & comment typos In addition I think the test is a bit flaky "Noto Color Emoji" *may not* be available on all Linuxes and for whatever reason your update makes the test fail on Mac. test result: Error. can't find Emoji in test directory or libraries So lots to do here before I look again. ------------- PR: https://git.openjdk.java.net/jdk/pull/4798 From github.com+10835776+stsypanov at openjdk.java.net Mon Aug 23 06:38:27 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 23 Aug 2021 06:38:27 GMT Subject: RFR: 8272756: Remove unnecessary explicit initialization of volatile variables in java.desktop In-Reply-To: <5D1AIPvGtkcbri_67kjwE9GuRe8F4P8A0KZmJ2s68hs=.351bc6fb-b1a6-491d-9cb8-e4738cf7ac2c@github.com> References: <5D1AIPvGtkcbri_67kjwE9GuRe8F4P8A0KZmJ2s68hs=.351bc6fb-b1a6-491d-9cb8-e4738cf7ac2c@github.com> Message-ID: On Fri, 20 Aug 2021 21:26:41 GMT, Sergey Bylokhov wrote: >> This is a continuation of >> >> - https://bugs.openjdk.java.net/browse/JDK-6736490 >> - https://bugs.openjdk.java.net/browse/JDK-8035284 >> - https://bugs.openjdk.java.net/browse/JDK-8145680 >> - https://bugs.openjdk.java.net/browse/JDK-8251548 >> >> As mentioned in JDK-6736490: >> >> _An explicit initialization of a volatile class instance variable, such as private volatile Object = null; or private volatile int scale = 0; is unnecessary since the Java spec automatically initializes objects to null and primitive type short, int, long, float and double to 0 and boolean to false. Explicit initialization of volatile variable to a value the same as the default implicit initialized value results in an unnecessary store and membar operation._ > > src/java.desktop/share/classes/com/sun/imageio/plugins/tiff/TIFFIFD.java line 64: > >> 62: Set tags = essentialTags; >> 63: if (tags == null) { >> 64: essentialTags = Set.of( > > What is the purpose of the local tags here? Looks like there's no purpose, `tags` is not used after assignment ------------- PR: https://git.openjdk.java.net/jdk/pull/5197 From aivanov at openjdk.java.net Mon Aug 23 13:11:29 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Mon, 23 Aug 2021 13:11:29 GMT Subject: RFR: 8272756: Remove unnecessary explicit initialization of volatile variables in java.desktop In-Reply-To: References: <5D1AIPvGtkcbri_67kjwE9GuRe8F4P8A0KZmJ2s68hs=.351bc6fb-b1a6-491d-9cb8-e4738cf7ac2c@github.com> Message-ID: On Mon, 23 Aug 2021 06:35:34 GMT, ?????? ??????? wrote: >> src/java.desktop/share/classes/com/sun/imageio/plugins/tiff/TIFFIFD.java line 64: >> >>> 62: Set tags = essentialTags; >>> 63: if (tags == null) { >>> 64: essentialTags = Set.of( >> >> What is the purpose of the local tags here? > > Looks like there's no purpose, `tags` is not used after assignment Maybe it's kind of a protection from a race. Yet it's possible either way: another thread could see `essentialTags == null` before this one initialises the field. ------------- PR: https://git.openjdk.java.net/jdk/pull/5197 From avu at openjdk.java.net Mon Aug 23 17:57:45 2021 From: avu at openjdk.java.net (Alexey Ushakov) Date: Mon, 23 Aug 2021 17:57:45 GMT Subject: RFR: 8272481: [macos] javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java fails [v2] In-Reply-To: References: Message-ID: <79EInhsrtzoe_Eoyhro6R3Q2Vc9kROr1gWIvrIU-HhA=.2196740f-f397-46cc-acec-1c3d2f14ff03@github.com> > Update opacity only if the component is visible Alexey Ushakov has updated the pull request incrementally with one additional commit since the last revision: 8272481: [macos] javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java fails Update window layer opacity to align with the peer translucency ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5172/files - new: https://git.openjdk.java.net/jdk/pull/5172/files/010e004a..9948d356 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5172&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5172&range=00-01 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5172.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5172/head:pull/5172 PR: https://git.openjdk.java.net/jdk/pull/5172 From serb at openjdk.java.net Mon Aug 23 18:00:28 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Mon, 23 Aug 2021 18:00:28 GMT Subject: RFR: 8272756: Remove unnecessary explicit initialization of volatile variables in java.desktop In-Reply-To: References: <5D1AIPvGtkcbri_67kjwE9GuRe8F4P8A0KZmJ2s68hs=.351bc6fb-b1a6-491d-9cb8-e4738cf7ac2c@github.com> Message-ID: On Mon, 23 Aug 2021 13:08:02 GMT, Alexey Ivanov wrote: >> Looks like there's no purpose, `tags` is not used after assignment > > Maybe it's kind of a protection from a race. Yet it's possible either way: another thread could see `essentialTags == null` before this one initialises the field. I think we can drop it completely. ------------- PR: https://git.openjdk.java.net/jdk/pull/5197 From aivanov at openjdk.java.net Mon Aug 23 18:34:24 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Mon, 23 Aug 2021 18:34:24 GMT Subject: RFR: 8272756: Remove unnecessary explicit initialization of volatile variables in java.desktop In-Reply-To: References: <5D1AIPvGtkcbri_67kjwE9GuRe8F4P8A0KZmJ2s68hs=.351bc6fb-b1a6-491d-9cb8-e4738cf7ac2c@github.com> Message-ID: On Mon, 23 Aug 2021 17:57:52 GMT, Sergey Bylokhov wrote: >> Maybe it's kind of a protection from a race. Yet it's possible either way: another thread could see `essentialTags == null` before this one initialises the field. > > I think we can drop it completely. Agree. ------------- PR: https://git.openjdk.java.net/jdk/pull/5197 From serb at openjdk.java.net Mon Aug 23 21:23:26 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Mon, 23 Aug 2021 21:23:26 GMT Subject: RFR: 8272481: [macos] javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java fails [v2] In-Reply-To: <79EInhsrtzoe_Eoyhro6R3Q2Vc9kROr1gWIvrIU-HhA=.2196740f-f397-46cc-acec-1c3d2f14ff03@github.com> References: <79EInhsrtzoe_Eoyhro6R3Q2Vc9kROr1gWIvrIU-HhA=.2196740f-f397-46cc-acec-1c3d2f14ff03@github.com> Message-ID: On Mon, 23 Aug 2021 17:57:45 GMT, Alexey Ushakov wrote: >> Update opacity only if the component is visible > > Alexey Ushakov has updated the pull request incrementally with one additional commit since the last revision: > > 8272481: [macos] javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java fails > > Update window layer opacity to align with the peer translucency src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformView.java line 70: > 68: if (peer.isTranslucent()) { > 69: this.windowLayer.setOpaque(false); > 70: } Do we still need the " if (isVisible())" check in the LWWindowPeer.java? I would like to double-check the reason we need the code above: * All our opaque properties are true by default(this is the properties used inside isTranslucent() method) * If any of the properties are actually set to false by the user, then we will reset the property of the layer to NO * The shape property will trigger: LWWindowPeer->applyShapeImpl->updateOpaque->getPlatformWindow().setOpaque(!isTranslucent()); * The opaque property will trigger: LWWindowPeer->setOpaque->updateOpaque->getPlatformWindow().setOpaque(!isTranslucent()); And the only problematic property is textured: * During initialisation we call "peer.setTextured" from the getInitialStyleBits(), this is before we call contentView.initialize inside CPlatformWindow.initialize(). I think we should move the call "peer.setTextured" to the CPlatformWindow.java:337 after contentView.initialize() This is same as DECORATED property is used in the same method. * If the textured property is changed after initialisation we did not update the "java" textuted property. See ClientPropertyApplicator: new Property(WINDOW_BRUSH_METAL_LOOK) { public void applyProperty(final CPlatformWindow c, final Object value) { c.setStyleBits(TEXTURED, Boolean.parseBoolean(value.toString())); }}, ------------- PR: https://git.openjdk.java.net/jdk/pull/5172 From serb at openjdk.java.net Mon Aug 23 23:39:24 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Mon, 23 Aug 2021 23:39:24 GMT Subject: RFR: 8272806: [macOS] "Apple AWT Internal Exception" when input method is changed In-Reply-To: <_LPMeJrHJf9_qj9lPYH9A6u9OrY0_MHW79-6I6XkNAM=.5bbe4315-f595-4f84-adf2-18fccad17544@github.com> References: <_LPMeJrHJf9_qj9lPYH9A6u9OrY0_MHW79-6I6XkNAM=.5bbe4315-f595-4f84-adf2-18fccad17544@github.com> Message-ID: <7drr8ftMXxeYYm_gqRX2bhjK4WIk-9FOELkLllysLpQ=.b2f06f32-268e-4213-b6fa-d25a9c963067@github.com> On Sun, 22 Aug 2021 19:46:49 GMT, Phil Race wrote: > There's a long eval in the bug report : https://bugs.openjdk.java.net/browse/JDK-8272806 but here's the summary > > When focus is lost by the app a message is sent down to native setting a native reference to the input method to null > which is a sort of signal not to notify upwards anything to the input method (which internally will NPE if there's > no focused component as is the case after focus is lost). > But we aren't actually setting it to null because of a check for null which previously checked the wrapper for > the JNI ref was not null but is now obsolete. So just remove the check for null. > > The steps to reproduce this bug are very manual and involve installing additional input methods and toggling them > at the system level. So I didn't see a way to write a useful regression test but if you follow the bug report steps you > should be able to verify the fix. > > I've run all automated tests just for good measure and they all pass. Marked as reviewed by serb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5211 From dmarkov at openjdk.java.net Tue Aug 24 05:58:28 2021 From: dmarkov at openjdk.java.net (Dmitry Markov) Date: Tue, 24 Aug 2021 05:58:28 GMT Subject: RFR: 8272806: [macOS] "Apple AWT Internal Exception" when input method is changed In-Reply-To: <_LPMeJrHJf9_qj9lPYH9A6u9OrY0_MHW79-6I6XkNAM=.5bbe4315-f595-4f84-adf2-18fccad17544@github.com> References: <_LPMeJrHJf9_qj9lPYH9A6u9OrY0_MHW79-6I6XkNAM=.5bbe4315-f595-4f84-adf2-18fccad17544@github.com> Message-ID: On Sun, 22 Aug 2021 19:46:49 GMT, Phil Race wrote: > There's a long eval in the bug report : https://bugs.openjdk.java.net/browse/JDK-8272806 but here's the summary > > When focus is lost by the app a message is sent down to native setting a native reference to the input method to null > which is a sort of signal not to notify upwards anything to the input method (which internally will NPE if there's > no focused component as is the case after focus is lost). > But we aren't actually setting it to null because of a check for null which previously checked the wrapper for > the JNI ref was not null but is now obsolete. So just remove the check for null. > > The steps to reproduce this bug are very manual and involve installing additional input methods and toggling them > at the system level. So I didn't see a way to write a useful regression test but if you follow the bug report steps you > should be able to verify the fix. > > I've run all automated tests just for good measure and they all pass. Marked as reviewed by dmarkov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5211 From github.com+741251+turbanoff at openjdk.java.net Tue Aug 24 06:22:38 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Tue, 24 Aug 2021 06:22:38 GMT Subject: RFR: 8272863: Replace usages of Collections.sort with List.sort call in public java modules Message-ID: Collections.sort is just a wrapper, so it is better to use an instance method directly. ------------- Commit messages: - [PATCH] Replace usages of Collections.sort with List.sort call in public java modules Changes: https://git.openjdk.java.net/jdk/pull/5229/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5229&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272863 Stats: 27 lines in 10 files changed: 0 ins; 8 del; 19 mod Patch: https://git.openjdk.java.net/jdk/pull/5229.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5229/head:pull/5229 PR: https://git.openjdk.java.net/jdk/pull/5229 From serb at openjdk.java.net Tue Aug 24 06:22:38 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Tue, 24 Aug 2021 06:22:38 GMT Subject: RFR: 8272863: Replace usages of Collections.sort with List.sort call in public java modules In-Reply-To: References: Message-ID: On Mon, 23 Aug 2021 21:01:48 GMT, Andrey Turbanov wrote: > Collections.sort is just a wrapper, so it is better to use an instance method directly. The changes in the src/java.desktop/ looks fine. Filed: https://bugs.openjdk.java.net/browse/JDK-8272863 ------------- Marked as reviewed by serb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5229 From dfuchs at openjdk.java.net Tue Aug 24 10:59:27 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 24 Aug 2021 10:59:27 GMT Subject: RFR: 8272863: Replace usages of Collections.sort with List.sort call in public java modules In-Reply-To: References: Message-ID: On Mon, 23 Aug 2021 21:01:48 GMT, Andrey Turbanov wrote: > Collections.sort is just a wrapper, so it is better to use an instance method directly. java/net and sun/net changes LGTM ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5229 From azvegint at openjdk.java.net Tue Aug 24 11:51:26 2021 From: azvegint at openjdk.java.net (Alexander Zvegintsev) Date: Tue, 24 Aug 2021 11:51:26 GMT Subject: RFR: 8272863: Replace usages of Collections.sort with List.sort call in public java modules In-Reply-To: References: Message-ID: On Mon, 23 Aug 2021 21:01:48 GMT, Andrey Turbanov wrote: > Collections.sort is just a wrapper, so it is better to use an instance method directly. There are a bunch of calls to `Collections.sort()` without a comparator specified (at least in java.desktop): https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/sun/java2d/Spans.java#L144 https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/sun/awt/DebugSettings.java#L278 https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/sun/swing/text/TextComponentPrintable.java#L787 https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/DefaultRowSorter.java#L1070 https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/DefaultRowSorter.java#L1204 https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/GroupLayout.java#L2137 It is also a wrapper to `list.sort(null)`. Is there any reason to not touch them along with this fix? ------------- PR: https://git.openjdk.java.net/jdk/pull/5229 From azvegint at openjdk.java.net Tue Aug 24 12:08:25 2021 From: azvegint at openjdk.java.net (Alexander Zvegintsev) Date: Tue, 24 Aug 2021 12:08:25 GMT Subject: RFR: 8272806: [macOS] "Apple AWT Internal Exception" when input method is changed In-Reply-To: <_LPMeJrHJf9_qj9lPYH9A6u9OrY0_MHW79-6I6XkNAM=.5bbe4315-f595-4f84-adf2-18fccad17544@github.com> References: <_LPMeJrHJf9_qj9lPYH9A6u9OrY0_MHW79-6I6XkNAM=.5bbe4315-f595-4f84-adf2-18fccad17544@github.com> Message-ID: <9hGh5d6XTbjLT8eTh7a5xv1JOHuGJ_clCQIlm02KUAM=.d8a2ffa2-d07c-44a9-873c-58033a410d90@github.com> On Sun, 22 Aug 2021 19:46:49 GMT, Phil Race wrote: > There's a long eval in the bug report : https://bugs.openjdk.java.net/browse/JDK-8272806 but here's the summary > > When focus is lost by the app a message is sent down to native setting a native reference to the input method to null > which is a sort of signal not to notify upwards anything to the input method (which internally will NPE if there's > no focused component as is the case after focus is lost). > But we aren't actually setting it to null because of a check for null which previously checked the wrapper for > the JNI ref was not null but is now obsolete. So just remove the check for null. > > The steps to reproduce this bug are very manual and involve installing additional input methods and toggling them > at the system level. So I didn't see a way to write a useful regression test but if you follow the bug report steps you > should be able to verify the fix. > > I've run all automated tests just for good measure and they all pass. Marked as reviewed by azvegint (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5211 From avu at openjdk.java.net Tue Aug 24 15:09:51 2021 From: avu at openjdk.java.net (Alexey Ushakov) Date: Tue, 24 Aug 2021 15:09:51 GMT Subject: RFR: 8272481: [macos] javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java fails [v3] In-Reply-To: References: Message-ID: <9Ar9ze-p5zdHSB4JSnP254ir6aLkxKjYc9MRI_ceLSk=.33b9ac46-c668-4bbb-8dee-e968dc323790@github.com> > Update opacity only if the component is visible Alexey Ushakov has updated the pull request incrementally with one additional commit since the last revision: 8272481: [macos] javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java fails Moved peer.setTextured() to the place where windowLayer is initialized ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5172/files - new: https://git.openjdk.java.net/jdk/pull/5172/files/9948d356..3f59951b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5172&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5172&range=01-02 Stats: 11 lines in 3 files changed: 2 ins; 7 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5172.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5172/head:pull/5172 PR: https://git.openjdk.java.net/jdk/pull/5172 From prr at openjdk.java.net Tue Aug 24 15:26:29 2021 From: prr at openjdk.java.net (Phil Race) Date: Tue, 24 Aug 2021 15:26:29 GMT Subject: Integrated: 8272806: [macOS] "Apple AWT Internal Exception" when input method is changed In-Reply-To: <_LPMeJrHJf9_qj9lPYH9A6u9OrY0_MHW79-6I6XkNAM=.5bbe4315-f595-4f84-adf2-18fccad17544@github.com> References: <_LPMeJrHJf9_qj9lPYH9A6u9OrY0_MHW79-6I6XkNAM=.5bbe4315-f595-4f84-adf2-18fccad17544@github.com> Message-ID: On Sun, 22 Aug 2021 19:46:49 GMT, Phil Race wrote: > There's a long eval in the bug report : https://bugs.openjdk.java.net/browse/JDK-8272806 but here's the summary > > When focus is lost by the app a message is sent down to native setting a native reference to the input method to null > which is a sort of signal not to notify upwards anything to the input method (which internally will NPE if there's > no focused component as is the case after focus is lost). > But we aren't actually setting it to null because of a check for null which previously checked the wrapper for > the JNI ref was not null but is now obsolete. So just remove the check for null. > > The steps to reproduce this bug are very manual and involve installing additional input methods and toggling them > at the system level. So I didn't see a way to write a useful regression test but if you follow the bug report steps you > should be able to verify the fix. > > I've run all automated tests just for good measure and they all pass. This pull request has now been integrated. Changeset: f681d654 Author: Phil Race URL: https://git.openjdk.java.net/jdk/commit/f681d6544ac2506cb72e45c1f9ed8dfbbde099f2 Stats: 4 lines in 2 files changed: 1 ins; 2 del; 1 mod 8272806: [macOS] "Apple AWT Internal Exception" when input method is changed Reviewed-by: serb, dmarkov, azvegint ------------- PR: https://git.openjdk.java.net/jdk/pull/5211 From alexsch at openjdk.java.net Tue Aug 24 15:37:53 2021 From: alexsch at openjdk.java.net (Alexander Scherbatiy) Date: Tue, 24 Aug 2021 15:37:53 GMT Subject: RFR: 8181571: printing to CUPS fails on mac sandbox app [v2] In-Reply-To: <2Mgxu1zmn4d0AJ1JsWHH4oO5PtUDtNfCQE8UYu7hkmc=.a080d861-8fec-4677-aa7b-dabdf431b5b4@github.com> References: <2Mgxu1zmn4d0AJ1JsWHH4oO5PtUDtNfCQE8UYu7hkmc=.a080d861-8fec-4677-aa7b-dabdf431b5b4@github.com> Message-ID: > The issue is reproduced on macOS Big Sur 11.0.1 with jdk 16.0.1+9. > > Create a native macOS app from the Hello.java file, sign and run it in sandbox: > > import javax.print.*; > import javax.swing.*; > > public class Hello { > > public static void main(String[] args) throws Exception { > SwingUtilities.invokeAndWait(() -> { > boolean isSandboxed = System.getenv("APP_SANDBOX_CONTAINER_ID") != null; > PrintService defaultPrinter = PrintServiceLookup.lookupDefaultPrintService(); > PrintService[] services = PrintServiceLookup.lookupPrintServices(null, null); > > StringBuilder builder = new StringBuilder(); > builder.append("is sandboxed: ").append(isSandboxed).append("\n"); > builder.append("default printer: ").append(defaultPrinter).append("\n"); > int size = services.length; > for (int i = 0; i < size; i++) { > builder.append("printer[").append(i).append("]=").append(services[i]).append("\n"); > } > JOptionPane.showMessageDialog(null, builder.toString()); > }); > } > } > > The signed app in sandbox shows null default printer and PrintServiceLookup.lookupPrintServices(null, null) returns "Unix Printer: lp". > ![PrintSandboxedApp](https://bugs.openjdk.java.net/secure/attachment/95629/PrintSandboxedApp.png) > > The problem has been discussed on 2d-dev mail list: > https://mail.openjdk.java.net/pipermail/2d-dev/2017-June/008375.html > https://mail.openjdk.java.net/pipermail/2d-dev/2017-July/008418.html > > According to the discussion: > >> I've submitted a DTS incident to Apple and a friend there has followed-up. >> Their unofficial position is that java should be connecting to the cups interface returned >> by the cupsServer() function and not changing the interface string to "localhost". >> Security changes in 10.12.4 reject the TCP connection which they say confuses >> network-client access with print access. They don't seem interested in loosening that change. > > > The proposed solution is to use the domain socket pathname in httpConnect(...) cups function and cupsGetDests(...) to get list of printers from cups when the app is signed and is run in sandbox on MacOs. Alexander Scherbatiy has updated the pull request incrementally with two additional commits since the last revision: - Clean utf_str and nameArray references - Split long line in CUPSPrinter.isCupsRunning() method ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4861/files - new: https://git.openjdk.java.net/jdk/pull/4861/files/072cc498..104e792b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4861&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4861&range=00-01 Stats: 11 lines in 2 files changed: 9 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/4861.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4861/head:pull/4861 PR: https://git.openjdk.java.net/jdk/pull/4861 From alexsch at openjdk.java.net Tue Aug 24 15:49:00 2021 From: alexsch at openjdk.java.net (Alexander Scherbatiy) Date: Tue, 24 Aug 2021 15:49:00 GMT Subject: RFR: 8181571: printing to CUPS fails on mac sandbox app [v3] In-Reply-To: <2Mgxu1zmn4d0AJ1JsWHH4oO5PtUDtNfCQE8UYu7hkmc=.a080d861-8fec-4677-aa7b-dabdf431b5b4@github.com> References: <2Mgxu1zmn4d0AJ1JsWHH4oO5PtUDtNfCQE8UYu7hkmc=.a080d861-8fec-4677-aa7b-dabdf431b5b4@github.com> Message-ID: > The issue is reproduced on macOS Big Sur 11.0.1 with jdk 16.0.1+9. > > Create a native macOS app from the Hello.java file, sign and run it in sandbox: > > import javax.print.*; > import javax.swing.*; > > public class Hello { > > public static void main(String[] args) throws Exception { > SwingUtilities.invokeAndWait(() -> { > boolean isSandboxed = System.getenv("APP_SANDBOX_CONTAINER_ID") != null; > PrintService defaultPrinter = PrintServiceLookup.lookupDefaultPrintService(); > PrintService[] services = PrintServiceLookup.lookupPrintServices(null, null); > > StringBuilder builder = new StringBuilder(); > builder.append("is sandboxed: ").append(isSandboxed).append("\n"); > builder.append("default printer: ").append(defaultPrinter).append("\n"); > int size = services.length; > for (int i = 0; i < size; i++) { > builder.append("printer[").append(i).append("]=").append(services[i]).append("\n"); > } > JOptionPane.showMessageDialog(null, builder.toString()); > }); > } > } > > The signed app in sandbox shows null default printer and PrintServiceLookup.lookupPrintServices(null, null) returns "Unix Printer: lp". > ![PrintSandboxedApp](https://bugs.openjdk.java.net/secure/attachment/95629/PrintSandboxedApp.png) > > The problem has been discussed on 2d-dev mail list: > https://mail.openjdk.java.net/pipermail/2d-dev/2017-June/008375.html > https://mail.openjdk.java.net/pipermail/2d-dev/2017-July/008418.html > > According to the discussion: > >> I've submitted a DTS incident to Apple and a friend there has followed-up. >> Their unofficial position is that java should be connecting to the cups interface returned >> by the cupsServer() function and not changing the interface string to "localhost". >> Security changes in 10.12.4 reject the TCP connection which they say confuses >> network-client access with print access. They don't seem interested in loosening that change. > > > The proposed solution is to use the domain socket pathname in httpConnect(...) cups function and cupsGetDests(...) to get list of printers from cups when the app is signed and is run in sandbox on MacOs. Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision: Return null if printers are not found in sandboxed app on MacOS ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4861/files - new: https://git.openjdk.java.net/jdk/pull/4861/files/104e792b..067d0025 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4861&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4861&range=01-02 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4861.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4861/head:pull/4861 PR: https://git.openjdk.java.net/jdk/pull/4861 From naoto at openjdk.java.net Tue Aug 24 15:55:30 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 24 Aug 2021 15:55:30 GMT Subject: RFR: 8272863: Replace usages of Collections.sort with List.sort call in public java modules In-Reply-To: References: Message-ID: On Mon, 23 Aug 2021 21:01:48 GMT, Andrey Turbanov wrote: > Collections.sort is just a wrapper, so it is better to use an instance method directly. java.time changes look good. ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5229 From alexsch at openjdk.java.net Tue Aug 24 16:34:30 2021 From: alexsch at openjdk.java.net (Alexander Scherbatiy) Date: Tue, 24 Aug 2021 16:34:30 GMT Subject: RFR: 8181571: printing to CUPS fails on mac sandbox app [v3] In-Reply-To: References: <2Mgxu1zmn4d0AJ1JsWHH4oO5PtUDtNfCQE8UYu7hkmc=.a080d861-8fec-4677-aa7b-dabdf431b5b4@github.com> Message-ID: On Thu, 12 Aug 2021 19:34:44 GMT, Phil Race wrote: >> Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision: >> >> Return null if printers are not found in sandboxed app on MacOS > > src/java.desktop/unix/classes/sun/print/CUPSPrinter.java line 96: > >> 94: libFound = initIDs(); >> 95: if (libFound) { >> 96: cupsServer = getCupsServer(); > > I think we should wrap all the new lines in isMac() > Also can you explain the reasons for the logic that implies we may have a server starting with "/" > in which case your always change the cupServer to localhost even if it is not sandboxed ? > > I ask because it seems to contradict what you pasted > "by the cupsServer() function and not changing the interface string to "localhost"" The logic which replaces a server starting with "/" to localhost is the original logic which is implemented in native level in the getCupsServer() function: https://github.com/openjdk/jdk/blob/f608e81ad8309a001b8a92563a93b8adee1ce2b8/src/java.desktop/unix/native/common/awt/CUPSfuncs.c#L176 The fix only moves this logic to the java level to store domainSocketPathname in case of sandboxed app on MacOS. > src/java.desktop/unix/classes/sun/print/CUPSPrinter.java line 399: > >> 397: return printerURIs; >> 398: } >> 399: } > > So if getCupsDefaultPrinters() doesn't find anything you always continue to the original code even though > it would seem that you know we are in a sandboxed app and it won't find anything ? I updated the code to return null in case there are no printer names from j2d_cupsGetDests() function in a sandboxed on MacOS. > src/java.desktop/unix/classes/sun/print/CUPSPrinter.java line 489: > >> 487: return domainSocketPathname; >> 488: } >> 489: > > You will need to suppress deprecation warnings here. Should I add `@SuppressWarnings("deprecation")` to the getDomainSocketPathname() method? I see that CUPSPrinter class has `@SuppressWarnings("removal")` but its private method do not have any SuppressWarnings annotations. > src/java.desktop/unix/classes/sun/print/CUPSPrinter.java line 506: > >> 504: IPPPrintService.debug_println(debugPrefix+"libFound "+libFound); >> 505: if (libFound) { >> 506: String server = getDomainSocketPathname() != null ? getDomainSocketPathname() : getServer(); > > Split this long line Updated. > src/java.desktop/unix/native/common/awt/CUPSfuncs.c line 244: > >> 242: DPRINTF("CUPSfuncs::bad alloc new array\n", "") >> 243: (*env)->ExceptionClear(env); >> 244: JNU_ThrowOutOfMemoryError(env, "OutOfMemoryError"); > > I find this weird. What is the ExceptionClear for ? The only possible exception here is for > an OOME which might be thrown by NewObjectArray. So you clear that and then re-create it ? > And who do will catch this ? What's the point ? Maybe just clear and return null. The array creation error handling is implemented in the similar way as it is done in the getMedia() function. The ExceptionClear() has been added to the getMedia() by `8031001: [Parfait] warnings from b121 for jdk/src/solaris/native/sun/awt: JNI-related warnings` I would prefer to have unified error handling in these methods. If ExceptionClear is not suitable in this place it would be better to recheck JDK-8031001 and update all places accordingly in a separate fix. > src/java.desktop/unix/native/common/awt/CUPSfuncs.c line 253: > >> 251: j2d_cupsFreeDests(num_dests, dests); >> 252: DPRINTF("CUPSfuncs::bad alloc new string ->name\n", "") >> 253: JNU_ThrowOutOfMemoryError(env, "OutOfMemoryError"); > > similar comments to above plus I am fairly sure you want to delete nameArray since it isn't returned. > For that matter if the NewString fails on the 4th printer you want to free the 3 previous ones too before returning. The code is updated to remove previously created strings and clear the nameArray in case of an error during new string creation. ------------- PR: https://git.openjdk.java.net/jdk/pull/4861 From github.com+741251+turbanoff at openjdk.java.net Tue Aug 24 20:21:52 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Tue, 24 Aug 2021 20:21:52 GMT Subject: RFR: 8272863: Replace usages of Collections.sort with List.sort call in public java modules [v2] In-Reply-To: References: Message-ID: > Collections.sort is just a wrapper, so it is better to use an instance method directly. Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: 8272863: Replace usages of Collections.sort with List.sort call in public java modules replace Collections.sort without comparator too ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5229/files - new: https://git.openjdk.java.net/jdk/pull/5229/files/e31936a5..d6dfc8bf Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5229&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5229&range=00-01 Stats: 21 lines in 10 files changed: 0 ins; 4 del; 17 mod Patch: https://git.openjdk.java.net/jdk/pull/5229.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5229/head:pull/5229 PR: https://git.openjdk.java.net/jdk/pull/5229 From github.com+741251+turbanoff at openjdk.java.net Tue Aug 24 20:21:52 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Tue, 24 Aug 2021 20:21:52 GMT Subject: RFR: 8272863: Replace usages of Collections.sort with List.sort call in public java modules In-Reply-To: References: Message-ID: On Tue, 24 Aug 2021 11:48:46 GMT, Alexander Zvegintsev wrote: > Is there any reason to not touch them along with this fix? Update them too. ------------- PR: https://git.openjdk.java.net/jdk/pull/5229 From github.com+741251+turbanoff at openjdk.java.net Tue Aug 24 21:13:59 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Tue, 24 Aug 2021 21:13:59 GMT Subject: RFR: 8271603: Unnecessary Vector usage in java.desktop [v2] In-Reply-To: <6aLgG4zX_4XfiEmKpjHSYsUxPUKP50F5S4oJWSpdt4Y=.84c7399e-c0dc-46f6-a659-53969ad8b182@github.com> References: <6aLgG4zX_4XfiEmKpjHSYsUxPUKP50F5S4oJWSpdt4Y=.84c7399e-c0dc-46f6-a659-53969ad8b182@github.com> Message-ID: On Mon, 9 Aug 2021 23:46:09 GMT, Phil Race wrote: >> Even non-public method can be called via reflection, so I'd be cautios about changing return type > > Apps should not be doing that and the desktop module along with most of the rest of the JDK is strongly encapsulated and illegal access will be denied. But given the relationship with the sole (?) caller I think this is not worth the churn. Not exactly an MT hotspot. I'd revert the changes here and in MenuBar. reverted ------------- PR: https://git.openjdk.java.net/jdk/pull/4680 From github.com+741251+turbanoff at openjdk.java.net Tue Aug 24 21:13:57 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Tue, 24 Aug 2021 21:13:57 GMT Subject: RFR: 8271603: Unnecessary Vector usage in java.desktop [v2] In-Reply-To: References: Message-ID: > Usage of thread-safe collection `Vector` is unnecessary. It's recommended to use `ArrayList` if a thread-safe implementation is not needed. In post-BiasedLocking times, this is gets worse, as every access is synchronized. > I checked only places where `Vector` was used as local variable. Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: 8271603: Unnecessary Vector usage in java.desktop revert back to Enumeration bring back default values ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4680/files - new: https://git.openjdk.java.net/jdk/pull/4680/files/12e39834..7a2393eb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4680&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4680&range=00-01 Stats: 15 lines in 4 files changed: 1 ins; 2 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/4680.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4680/head:pull/4680 PR: https://git.openjdk.java.net/jdk/pull/4680 From github.com+741251+turbanoff at openjdk.java.net Tue Aug 24 21:14:06 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Tue, 24 Aug 2021 21:14:06 GMT Subject: RFR: 8271603: Unnecessary Vector usage in java.desktop [v2] In-Reply-To: References: Message-ID: On Mon, 2 Aug 2021 05:19:32 GMT, Sergey Bylokhov wrote: >> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8271603: Unnecessary Vector usage in java.desktop >> revert back to Enumeration >> bring back default values > > src/java.desktop/share/classes/java/awt/MenuBar.java line 348: > >> 346: Iterator e = getMenu(i).shortcuts(); >> 347: while (e.hasNext()) { >> 348: shortcuts.addElement(e.next()); > > I think it is fine to replace the Enumeration with the Iterator in most of the places, but here we will get a kind of mix of both, since we cannot remove the usage of Enumeration in the return time. reverted back to Vector here > src/java.desktop/share/classes/javax/print/MimeType.java line 576: > >> 574: ArrayList thePieces = new ArrayList<>(); >> 575: boolean mediaTypeIsText; >> 576: boolean parameterNameIsCharset; > > Default values might be removed as a separate cleanup. reverted ------------- PR: https://git.openjdk.java.net/jdk/pull/4680 From serb at openjdk.java.net Tue Aug 24 23:12:28 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Tue, 24 Aug 2021 23:12:28 GMT Subject: RFR: 8271603: Unnecessary Vector usage in java.desktop [v2] In-Reply-To: References: Message-ID: On Tue, 24 Aug 2021 21:13:57 GMT, Andrey Turbanov wrote: >> Usage of thread-safe collection `Vector` is unnecessary. It's recommended to use `ArrayList` if a thread-safe implementation is not needed. In post-BiasedLocking times, this is gets worse, as every access is synchronized. >> I checked only places where `Vector` was used as local variable. > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8271603: Unnecessary Vector usage in java.desktop > revert back to Enumeration > bring back default values src/java.desktop/share/classes/javax/sound/sampled/AudioSystem.java line 244: > 242: } > 243: > 244: return list.toArray(new Line.Info[0]); I thought we already covered such changed under JDK-8269130, is there are any other missed cases? If yes then probably it will be good to extract such changes. ------------- PR: https://git.openjdk.java.net/jdk/pull/4680 From serb at openjdk.java.net Tue Aug 24 23:59:32 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Tue, 24 Aug 2021 23:59:32 GMT Subject: RFR: 8272481: [macos] javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java fails [v3] In-Reply-To: <9Ar9ze-p5zdHSB4JSnP254ir6aLkxKjYc9MRI_ceLSk=.33b9ac46-c668-4bbb-8dee-e968dc323790@github.com> References: <9Ar9ze-p5zdHSB4JSnP254ir6aLkxKjYc9MRI_ceLSk=.33b9ac46-c668-4bbb-8dee-e968dc323790@github.com> Message-ID: On Tue, 24 Aug 2021 15:09:51 GMT, Alexey Ushakov wrote: >> Update opacity only if the component is visible > > Alexey Ushakov has updated the pull request incrementally with one additional commit since the last revision: > > 8272481: [macos] javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java fails > > Moved peer.setTextured() to the place where windowLayer is initialized src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java line 339: > 337: if (peer != null) { // Not applicable to CWarningWindow > 338: peer.setTextured(IS(TEXTURED, styleBits)); > 339: } This probably works fine, but maybe we can move it after "setPtr(ref.get());" below? or that ptr is not used in this new call chain? ------------- PR: https://git.openjdk.java.net/jdk/pull/5172 From prr at openjdk.java.net Wed Aug 25 00:08:28 2021 From: prr at openjdk.java.net (Phil Race) Date: Wed, 25 Aug 2021 00:08:28 GMT Subject: RFR: 8271603: Unnecessary Vector usage in java.desktop [v2] In-Reply-To: References: Message-ID: On Tue, 24 Aug 2021 21:13:57 GMT, Andrey Turbanov wrote: >> Usage of thread-safe collection `Vector` is unnecessary. It's recommended to use `ArrayList` if a thread-safe implementation is not needed. In post-BiasedLocking times, this is gets worse, as every access is synchronized. >> I checked only places where `Vector` was used as local variable. > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8271603: Unnecessary Vector usage in java.desktop > revert back to Enumeration > bring back default values Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4680 From github.com+741251+turbanoff at openjdk.java.net Wed Aug 25 08:01:59 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Wed, 25 Aug 2021 08:01:59 GMT Subject: RFR: 8271603: Unnecessary Vector usage in java.desktop [v2] In-Reply-To: References: Message-ID: On Tue, 24 Aug 2021 21:13:57 GMT, Andrey Turbanov wrote: >> Usage of thread-safe collection `Vector` is unnecessary. It's recommended to use `ArrayList` if a thread-safe implementation is not needed. In post-BiasedLocking times, this is gets worse, as every access is synchronized. >> I checked only places where `Vector` was used as local variable. > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8271603: Unnecessary Vector usage in java.desktop > revert back to Enumeration > bring back default values I found many new places in java.desktop which can be migrated easily. Not sure how I did miss them in the first place. Sorry for inconvenience. Please re-review PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/4680 From github.com+741251+turbanoff at openjdk.java.net Wed Aug 25 08:02:03 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Wed, 25 Aug 2021 08:02:03 GMT Subject: RFR: 8271603: Unnecessary Vector usage in java.desktop [v2] In-Reply-To: References: Message-ID: On Tue, 24 Aug 2021 23:09:52 GMT, Sergey Bylokhov wrote: >> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8271603: Unnecessary Vector usage in java.desktop >> revert back to Enumeration >> bring back default values > > src/java.desktop/share/classes/javax/sound/sampled/AudioSystem.java line 244: > >> 242: } >> 243: >> 244: return list.toArray(new Line.Info[0]); > > I thought we already covered such changed under JDK-8269130, is there are any other missed cases? If yes then probably it will be good to extract such changes. In JDK-8269130 I fixed only usages of Collections.toArray. and didn't touch manual copying. Reverted usage of toArray where it wasn't used before. ------------- PR: https://git.openjdk.java.net/jdk/pull/4680 From github.com+741251+turbanoff at openjdk.java.net Wed Aug 25 08:01:55 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Wed, 25 Aug 2021 08:01:55 GMT Subject: RFR: 8271603: Unnecessary Vector usage in java.desktop [v3] In-Reply-To: References: Message-ID: <9rIUQGHMrydeLPZaYstCKjRH_ODj9rob0a3CGfmGONo=.beafecab-48dd-4686-a5f0-9f2e7501f8dd@github.com> > Usage of thread-safe collection `Vector` is unnecessary. It's recommended to use `ArrayList` if a thread-safe implementation is not needed. In post-BiasedLocking times, this is gets worse, as every access is synchronized. > I checked only places where `Vector` was used as local variable. Andrey Turbanov has updated the pull request incrementally with two additional commits since the last revision: - 8271603: Unnecessary Vector usage in java.desktop migrate more usages. Not sure how I missed them - 8271603: Unnecessary Vector usage in java.desktop revert back to use cycle to copy into array ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4680/files - new: https://git.openjdk.java.net/jdk/pull/4680/files/7a2393eb..97ca8477 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4680&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4680&range=01-02 Stats: 214 lines in 24 files changed: 26 ins; 11 del; 177 mod Patch: https://git.openjdk.java.net/jdk/pull/4680.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4680/head:pull/4680 PR: https://git.openjdk.java.net/jdk/pull/4680 From dfuchs at openjdk.java.net Wed Aug 25 08:33:26 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 25 Aug 2021 08:33:26 GMT Subject: RFR: 8272863: Replace usages of Collections.sort with List.sort call in public java modules [v2] In-Reply-To: References: Message-ID: On Tue, 24 Aug 2021 20:21:52 GMT, Andrey Turbanov wrote: >> Collections.sort is just a wrapper, so it is better to use an instance method directly. > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8272863: Replace usages of Collections.sort with List.sort call in public java modules > replace Collections.sort without comparator too src/java.base/share/classes/java/net/URLPermission.java line 222: > 220: > 221: List l = normalizeMethods(methods); > 222: l.sort(null); I am not opposed to this change, but I find this is slightly more ugly than `Collections.sort(l)`; so I have to ask: Is there any noticeable benefit? ------------- PR: https://git.openjdk.java.net/jdk/pull/5229 From github.com+741251+turbanoff at openjdk.java.net Wed Aug 25 12:50:27 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Wed, 25 Aug 2021 12:50:27 GMT Subject: RFR: 8272863: Replace usages of Collections.sort with List.sort call in public java modules [v2] In-Reply-To: References: Message-ID: On Wed, 25 Aug 2021 08:29:57 GMT, Daniel Fuchs wrote: >> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8272863: Replace usages of Collections.sort with List.sort call in public java modules >> replace Collections.sort without comparator too > > src/java.base/share/classes/java/net/URLPermission.java line 222: > >> 220: >> 221: List l = normalizeMethods(methods); >> 222: l.sort(null); > > I am not opposed to this change, but I find this is slightly more ugly than `Collections.sort(l)`; so I have to ask: Is there any noticeable benefit? Actually I agree with you. One more point is that List.sort(null) doesn't check at compile time that class implements `Comparable`. But Collections.sort have this check. I will revert last commit. @azvegint are you ok with that? ------------- PR: https://git.openjdk.java.net/jdk/pull/5229 From azvegint at openjdk.java.net Wed Aug 25 13:36:23 2021 From: azvegint at openjdk.java.net (Alexander Zvegintsev) Date: Wed, 25 Aug 2021 13:36:23 GMT Subject: RFR: 8272863: Replace usages of Collections.sort with List.sort call in public java modules [v2] In-Reply-To: References: Message-ID: On Wed, 25 Aug 2021 12:47:41 GMT, Andrey Turbanov wrote: >> src/java.base/share/classes/java/net/URLPermission.java line 222: >> >>> 220: >>> 221: List l = normalizeMethods(methods); >>> 222: l.sort(null); >> >> I am not opposed to this change, but I find this is slightly more ugly than `Collections.sort(l)`; so I have to ask: Is there any noticeable benefit? > > Actually I agree with you. > One more point is that List.sort(null) doesn't check at compile time that class implements `Comparable`. But Collections.sort have this check. > I will revert last commit. > @azvegint are you ok with that? No objections. ------------- PR: https://git.openjdk.java.net/jdk/pull/5229 From github.com+741251+turbanoff at openjdk.java.net Wed Aug 25 13:55:50 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Wed, 25 Aug 2021 13:55:50 GMT Subject: RFR: 8272863: Replace usages of Collections.sort with List.sort call in public java modules [v3] In-Reply-To: References: Message-ID: <8nANT75G1bu4pd892DJuQUV-g2p7jm9m5jQb82EWjfs=.0452ad76-845c-49ed-b0f7-df6641ec2102@github.com> > Collections.sort is just a wrapper, so it is better to use an instance method directly. Andrey Turbanov has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5229/files - new: https://git.openjdk.java.net/jdk/pull/5229/files/d6dfc8bf..e31936a5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5229&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5229&range=01-02 Stats: 21 lines in 10 files changed: 4 ins; 0 del; 17 mod Patch: https://git.openjdk.java.net/jdk/pull/5229.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5229/head:pull/5229 PR: https://git.openjdk.java.net/jdk/pull/5229 From avu at openjdk.java.net Wed Aug 25 17:32:47 2021 From: avu at openjdk.java.net (Alexey Ushakov) Date: Wed, 25 Aug 2021 17:32:47 GMT Subject: RFR: 8272481: [macos] javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java fails [v3] In-Reply-To: References: <9Ar9ze-p5zdHSB4JSnP254ir6aLkxKjYc9MRI_ceLSk=.33b9ac46-c668-4bbb-8dee-e968dc323790@github.com> Message-ID: On Tue, 24 Aug 2021 23:56:54 GMT, Sergey Bylokhov wrote: >> Alexey Ushakov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8272481: [macos] javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java fails >> >> Moved peer.setTextured() to the place where windowLayer is initialized > > src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java line 339: > >> 337: if (peer != null) { // Not applicable to CWarningWindow >> 338: peer.setTextured(IS(TEXTURED, styleBits)); >> 339: } > > This probably works fine, but maybe we can move it after "setPtr(ref.get());" below? or that ptr is not used in this new call chain? Yes, it does work. But it's a good idea to move the code here. ------------- PR: https://git.openjdk.java.net/jdk/pull/5172 From avu at openjdk.java.net Wed Aug 25 17:32:46 2021 From: avu at openjdk.java.net (Alexey Ushakov) Date: Wed, 25 Aug 2021 17:32:46 GMT Subject: RFR: 8272481: [macos] javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java fails [v4] In-Reply-To: References: Message-ID: > Update opacity only if the component is visible Alexey Ushakov has updated the pull request incrementally with one additional commit since the last revision: 8272481: [macos] javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java fails Move the initialization to better place ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5172/files - new: https://git.openjdk.java.net/jdk/pull/5172/files/3f59951b..e68e2687 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5172&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5172&range=02-03 Stats: 6 lines in 1 file changed: 2 ins; 2 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5172.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5172/head:pull/5172 PR: https://git.openjdk.java.net/jdk/pull/5172 From github.com+741251+turbanoff at openjdk.java.net Wed Aug 25 17:53:00 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Wed, 25 Aug 2021 17:53:00 GMT Subject: RFR: 8271603: Unnecessary Vector usage in java.desktop [v4] In-Reply-To: References: Message-ID: > Usage of thread-safe collection `Vector` is unnecessary. It's recommended to use `ArrayList` if a thread-safe implementation is not needed. In post-BiasedLocking times, this is gets worse, as every access is synchronized. > I checked only places where `Vector` was used as local variable. Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: 8271603: Unnecessary Vector usage in java.desktop migrate even more usages ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4680/files - new: https://git.openjdk.java.net/jdk/pull/4680/files/97ca8477..5727f6f2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4680&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4680&range=02-03 Stats: 30 lines in 7 files changed: 3 ins; 2 del; 25 mod Patch: https://git.openjdk.java.net/jdk/pull/4680.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4680/head:pull/4680 PR: https://git.openjdk.java.net/jdk/pull/4680 From serb at openjdk.java.net Wed Aug 25 18:38:32 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Wed, 25 Aug 2021 18:38:32 GMT Subject: RFR: 8272481: [macos] javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java fails [v4] In-Reply-To: References: Message-ID: <1cha-tIuOzVFF5cTif6xMLdZdK4r1vD0OHpt7UxTuu4=.0300d2b0-bb50-48f4-8b63-72b5bfe3eddc@github.com> On Wed, 25 Aug 2021 17:32:46 GMT, Alexey Ushakov wrote: >> Update opacity only if the component is visible > > Alexey Ushakov has updated the pull request incrementally with one additional commit since the last revision: > > 8272481: [macos] javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java fails > > Move the initialization to better place Marked as reviewed by serb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5172 From jdv at openjdk.java.net Thu Aug 26 12:43:28 2021 From: jdv at openjdk.java.net (Jayathirth D V) Date: Thu, 26 Aug 2021 12:43:28 GMT Subject: RFR: 8272481: [macos] javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java fails [v4] In-Reply-To: References: Message-ID: <1ZTNd8EZIKRAYg3HAWMeJ-TesNV-DRcmB-Dbrak8fLg=.65b51fa3-e0c6-4434-962a-6ae96b3e886e@github.com> On Wed, 25 Aug 2021 17:32:46 GMT, Alexey Ushakov wrote: >> Update opacity only if the component is visible > > Alexey Ushakov has updated the pull request incrementally with one additional commit since the last revision: > > 8272481: [macos] javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java fails > > Move the initialization to better place Marked as reviewed by jdv (Reviewer). With latest commit i see that Netbeans is launching properly and also i am not seeing https://bugs.openjdk.java.net/browse/JDK-8243547 issue which was present after initial commits. Also all test run with Metal and OpenGL pipeline is green. ------------- PR: https://git.openjdk.java.net/jdk/pull/5172 From avu at openjdk.java.net Thu Aug 26 12:59:31 2021 From: avu at openjdk.java.net (Alexey Ushakov) Date: Thu, 26 Aug 2021 12:59:31 GMT Subject: Integrated: 8272481: [macos] javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java fails In-Reply-To: References: Message-ID: <4c8P_LDc6msF8n50sfITUvn7vEFC3JwImx5eDMr4Ni0=.d2f2e0b4-51f6-424b-b024-a3a5025917a3@github.com> On Wed, 18 Aug 2021 21:07:28 GMT, Alexey Ushakov wrote: > Update opacity only if the component is visible This pull request has now been integrated. Changeset: c4205305 Author: Alexey Ushakov URL: https://git.openjdk.java.net/jdk/commit/c4205305496f73f49e58e64dd303154fca5bfafd Stats: 7 lines in 3 files changed: 3 ins; 3 del; 1 mod 8272481: [macos] javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java fails Reviewed-by: serb, jdv ------------- PR: https://git.openjdk.java.net/jdk/pull/5172 From github.com+741251+turbanoff at openjdk.java.net Thu Aug 26 20:50:27 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Thu, 26 Aug 2021 20:50:27 GMT Subject: Integrated: 8272863: Replace usages of Collections.sort with List.sort call in public java modules In-Reply-To: References: Message-ID: On Mon, 23 Aug 2021 21:01:48 GMT, Andrey Turbanov wrote: > Collections.sort is just a wrapper, so it is better to use an instance method directly. This pull request has now been integrated. Changeset: d732c309 Author: Andrey Turbanov Committer: Sergey Bylokhov URL: https://git.openjdk.java.net/jdk/commit/d732c3091fea0a7c6d6767227de89002564504e5 Stats: 27 lines in 10 files changed: 0 ins; 8 del; 19 mod 8272863: Replace usages of Collections.sort with List.sort call in public java modules Reviewed-by: serb, dfuchs, naoto ------------- PR: https://git.openjdk.java.net/jdk/pull/5229 From serb at openjdk.java.net Fri Aug 27 17:10:30 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Fri, 27 Aug 2021 17:10:30 GMT Subject: RFR: 8271603: Unnecessary Vector usage in java.desktop [v4] In-Reply-To: References: Message-ID: On Wed, 25 Aug 2021 17:53:00 GMT, Andrey Turbanov wrote: >> Usage of thread-safe collection `Vector` is unnecessary. It's recommended to use `ArrayList` if a thread-safe implementation is not needed. In post-BiasedLocking times, this is gets worse, as every access is synchronized. >> I checked only places where `Vector` was used as local variable. > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8271603: Unnecessary Vector usage in java.desktop > migrate even more usages src/java.desktop/share/classes/javax/swing/JMenu.java line 1340: > 1338: } > 1339: MenuElement[] me = new MenuElement[elements.size()]; > 1340: elements.toArray(me); Implementation of the "toArray([])" is not equivalent of "copyInto([])". Maybe no-arg "return elements.toArray()" will look better. Same comment about other removed usage of copyInto ------------- PR: https://git.openjdk.java.net/jdk/pull/4680 From github.com+741251+turbanoff at openjdk.java.net Fri Aug 27 17:55:24 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Fri, 27 Aug 2021 17:55:24 GMT Subject: RFR: 8271603: Unnecessary Vector usage in java.desktop [v4] In-Reply-To: References: Message-ID: On Fri, 27 Aug 2021 17:04:33 GMT, Sergey Bylokhov wrote: >> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8271603: Unnecessary Vector usage in java.desktop >> migrate even more usages > > src/java.desktop/share/classes/javax/swing/JMenu.java line 1340: > >> 1338: } >> 1339: MenuElement[] me = new MenuElement[elements.size()]; >> 1340: elements.toArray(me); > > Implementation of the "toArray([])" is not equivalent of "copyInto([])". Maybe no-arg "return elements.toArray()" will look better. Same comment about other removed usage of copyInto Can you please elaborate? As I can see if size of array is exactly the same as size of vector/arraylist, implementations are similar - they just call System.arraycopy ![???????????](https://user-images.githubusercontent.com/741251/131168809-480c05d6-2775-4812-91f5-c73833f9a396.png) ------------- PR: https://git.openjdk.java.net/jdk/pull/4680 From serb at openjdk.java.net Fri Aug 27 18:32:28 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Fri, 27 Aug 2021 18:32:28 GMT Subject: RFR: 8271603: Unnecessary Vector usage in java.desktop [v4] In-Reply-To: References: Message-ID: On Fri, 27 Aug 2021 17:52:19 GMT, Andrey Turbanov wrote: >> src/java.desktop/share/classes/javax/swing/JMenu.java line 1340: >> >>> 1338: } >>> 1339: MenuElement[] me = new MenuElement[elements.size()]; >>> 1340: elements.toArray(me); >> >> Implementation of the "toArray([])" is not equivalent of "copyInto([])". Maybe no-arg "return elements.toArray()" will look better. Same comment about other removed usage of copyInto > > Can you please elaborate? > As I can see if size of array is exactly the same as size of vector/arraylist, implementations are similar - they just call System.arraycopy > ![???????????](https://user-images.githubusercontent.com/741251/131168809-480c05d6-2775-4812-91f5-c73833f9a396.png) To confirm this you need to do the same check on every usage of added toArray([]), the simpler version like "return toArray()" or return toArray(new MenuElement[elements.size()]) is simpler, no need to check something. I guess in some previouse fixes it was confirmed that the "return toArray(new MenuElement[0])" is even faster. ------------- PR: https://git.openjdk.java.net/jdk/pull/4680 From github.com+741251+turbanoff at openjdk.java.net Tue Aug 31 08:37:36 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Tue, 31 Aug 2021 08:37:36 GMT Subject: RFR: 8273168: Remove superfluous use of boxing in java.desktop Message-ID: parseInt/parseLong/parseShort/parseByte/parseFloat should be preferred, as they return primitives. While valueOf returns boxed object. ------------- Commit messages: - [PATCH] Cleanup redundant boxing in java.desktop module Changes: https://git.openjdk.java.net/jdk/pull/5313/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5313&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273168 Stats: 18 lines in 7 files changed: 0 ins; 1 del; 17 mod Patch: https://git.openjdk.java.net/jdk/pull/5313.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5313/head:pull/5313 PR: https://git.openjdk.java.net/jdk/pull/5313