From serb at openjdk.java.net Sun Jan 3 05:12:01 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Sun, 3 Jan 2021 05:12:01 GMT Subject: Integrated: 8225116: Test OwnedWindowsLeak.java intermittently fails In-Reply-To: References: Message-ID: On Sat, 7 Nov 2020 06:55:09 GMT, Sergey Bylokhov wrote: > This test rarely fails in the past on some configurations but was never a problem listed, and according to the history of CI, it fails 2 times on its own this year. > > There are two possible reasons for the failure: > 1. At that time we had a memory leak, which was fixed. > 2. The test works too fast and it was not enough time for GC to eliminate 1000 windows. > > To make the future evaluation simpler I enhanced the test and make it stricter, see some comments inline. This pull request has now been integrated. Changeset: 497efefa Author: Sergey Bylokhov URL: https://git.openjdk.java.net/jdk/commit/497efefa Stats: 26 lines in 1 file changed: 4 ins; 12 del; 10 mod 8225116: Test OwnedWindowsLeak.java intermittently fails Reviewed-by: pbansal ------------- PR: https://git.openjdk.java.net/jdk/pull/1105 From serb at openjdk.java.net Sun Jan 3 08:50:59 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Sun, 3 Jan 2021 08:50:59 GMT Subject: RFR: 8252015: [macos11] java.awt.TrayIcon requires updates for template images [v2] In-Reply-To: References: Message-ID: On Fri, 4 Dec 2020 14:40:24 GMT, Peter Zhelezniakov wrote: >> [JDK-8252015: [macos11] java.awt.TrayIcon requires updates for template images](https://bugs.openjdk.java.net/browse/JDK-8252015) >> >> ### Problem >> According to Apple's human interface guidelines, developers should use template images for tray icons. This way icons look good when desktop theme or wallpaper change. On the API level, this means setting the `NSImage::isTemplate` flag. Currently there's no way in Java to set this flag. Even if one uses a template (black and transparent pixels only) image, MacOS will treat it as regular image. As a result, the image will not be visible when using dark theme. >> >> ### Solution: >> * Add a new system property, `java.awt.enableTemplateImages`, to indicate that template images are being used by tray icons.When this property is set, all tray icon images are treated as templates. It's the developers' responsibility to ensure their images are indeed templates. This property allows us to avoid new API and accidental behavior changes >> * Value of this property is passed from Java into `NSImage::setTemplate` >> * We need the tray icon image rendered by MacOS, so we use a button (rather than a view) to host the image >> >> To do after CSR approval: >> - [ ] Rename property `java.awt.` >> - [ ] Add `TrayIcon` javadoc, use `@systemProperty` tag there > > Peter Zhelezniakov has updated the pull request incrementally with two additional commits since the last revision: > > - 8252015: fixed failing tests; renamed system property > - 8252015: Added property description to TrayIcon javadoc Marked as reviewed by serb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/481 From psadhukhan at openjdk.java.net Mon Jan 4 06:47:56 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Mon, 4 Jan 2021 06:47:56 GMT Subject: RFR: 8213126: java/awt/Window/MainKeyWindow/TestMainKeyWindow.java time-out on mac10.13 In-Reply-To: References: Message-ID: On Thu, 29 Oct 2020 18:42:58 GMT, Sergey Bylokhov wrote: > Initially, this bug was filed because the test was run via jtreg without passing '-nativepath' option(the make file pass this option automatically). So we could just de-problem list the test, but on the macOS Catalina the "System Preferences.app" was moved so the test cannot run it. As a fix, I suggest running the java app via a separate process instead of "System Preferences.app". > > The test still fails before JDK-8194327, and passed after. test/jdk/java/awt/Window/MainKeyWindowTest/TestMainKeyWindow.java line 31: > 29: * @bug 8194327 > 30: * @summary [macosx] AWT windows have incorrect main/key window behaviors > 31: * @author Alan Snyder I guess we need to remove @author tag test/jdk/java/awt/Window/MainKeyWindowTest/TestMainKeyWindow.java line 397: > 395: Thread.sleep(20_000); > 396: System.exit(0); > 397: return; Can you please explain the reasoning for this snippet where we exit the test. What extra args can be passed? I guess it will exit the whole jtreg vm process cancelling all other tests that are to be run later if we call System.exit?!! or is this only for standalone execution? ------------- PR: https://git.openjdk.java.net/jdk/pull/941 From serb at openjdk.java.net Mon Jan 4 08:32:05 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Mon, 4 Jan 2021 08:32:05 GMT Subject: RFR: 8213126: java/awt/Window/MainKeyWindow/TestMainKeyWindow.java time-out on mac10.13 In-Reply-To: References: Message-ID: <7FSFnem0EPkHM05QF51p75DRZHNj_pZQX92HcJe8Da0=.b6b066f7-4742-4d51-9e5c-4ba8b290d775@github.com> On Mon, 4 Jan 2021 06:36:24 GMT, Prasanta Sadhukhan wrote: >> Initially, this bug was filed because the test was run via jtreg without passing '-nativepath' option(the make file pass this option automatically). So we could just de-problem list the test, but on the macOS Catalina the "System Preferences.app" was moved so the test cannot run it. As a fix, I suggest running the java app via a separate process instead of "System Preferences.app". >> >> The test still fails before JDK-8194327, and passed after. > > test/jdk/java/awt/Window/MainKeyWindowTest/TestMainKeyWindow.java line 31: > >> 29: * @bug 8194327 >> 30: * @summary [macosx] AWT windows have incorrect main/key window behaviors >> 31: * @author Alan Snyder > > I guess we need to remove @author tag I have left it to make credit an external contributor > test/jdk/java/awt/Window/MainKeyWindowTest/TestMainKeyWindow.java line 397: > >> 395: Thread.sleep(20_000); >> 396: System.exit(0); >> 397: return; > > Can you please explain the reasoning for this snippet where we exit the test. What extra args can be passed? I guess it will exit the whole jtreg vm process cancelling all other tests that are to be run later if we call System.exit?!! or is this only for standalone execution? This part of the code is executed by the test itself see this code above ProcessBuilder pb = ProcessTools.createJavaProcessBuilder( TestMainKeyWindow.class.getSimpleName(), "mark"); return ProcessTools.startProcess("Other frame", pb); ------------- PR: https://git.openjdk.java.net/jdk/pull/941 From serb at openjdk.java.net Mon Jan 4 08:41:58 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Mon, 4 Jan 2021 08:41:58 GMT Subject: RFR: 8257414: Drag n Drop target area is wrong on high DPI systems In-Reply-To: References: Message-ID: On Tue, 29 Dec 2020 20:56:06 GMT, Olga Mikhaltsova wrote: > Please, review this small fix for drag-n-drop on Linux with HiDPI turned on! > > This bug is due to the following reason: while scaling Java recalculates resolution (W x H) according to sun.java2d.uiScale (W/SCALE x H/SCALE) and works inside these new coordinates but at the same time the events, that come from the system, continue reporting positions in the old coordinates (W x H). > > The idea of the suggested fix is in division of coordinates on the scale when they come from the system to Java and multiplying them on the scale when they go back from Java to the system. It is similar to processing events from mouse and buttons. > > Testing is quite complicated because for reproducing this bug the following conditions should be met: > 1. HiDPI is turned on > 2. sun.java2d.uiScale.enabled = true and sun.java2d.uiScale != 100% > 3. the source of drag-n-drop is non-java application > > The step-by-step guide how to reproduce this bug is added to https://bugs.openjdk.java.net/browse/JDK-8257414. src/java.desktop/unix/classes/sun/awt/X11/XDnDDropTargetProtocol.java line 616: > 614: /* Translate mouse position from root coordinates > 615: to the target window coordinates. */ > 616: Point p = xwindow.toLocal(xwindow.scaleDown(x), xwindow.scaleDown(y)); I guess some clarification here is required. It is unclear what the coordinate system is used by the x/y above. Looks like before the fix the device space was always used, and after the fix the mix of device/user's space will be used. If the user's space should always be used(the scaled version of the device), then I suggest to scale these coordinates here: x = (int)(xclient.get_data(2) >> 16); y = (int)(xclient.get_data(2) & 0xFFFF); But you will need to check that all usage of the new coordinate system will be valid across the method. ------------- PR: https://git.openjdk.java.net/jdk/pull/1907 From prr at openjdk.java.net Mon Jan 4 21:11:58 2021 From: prr at openjdk.java.net (Phil Race) Date: Mon, 4 Jan 2021 21:11:58 GMT Subject: Integrated: 8257809: JNI warnings from Toolkit JPEG image decoding In-Reply-To: References: Message-ID: On Sun, 20 Dec 2020 01:37:47 GMT, Phil Race wrote: > The fix is to reverse the order of acquisition to get dst before src so that the call to GetArrayLength() comes first. > This also necessitates moving the RELEASE_ARRAYS() call on an error condition to the new "2nd" block. > > The new regression test passes on all platforms and all the other headless tests passed too. > So do the automated headful tests. This pull request has now been integrated. Changeset: e6f99260 Author: Phil Race URL: https://git.openjdk.java.net/jdk/commit/e6f99260 Stats: 126 lines in 4 files changed: 116 ins; 10 del; 0 mod 8257809: JNI warnings from Toolkit JPEG image decoding Reviewed-by: serb ------------- PR: https://git.openjdk.java.net/jdk/pull/1850 From psadhukhan at openjdk.java.net Tue Jan 5 08:33:06 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Tue, 5 Jan 2021 08:33:06 GMT Subject: [jdk16] RFR: 8259007: This test printed a blank page Message-ID: Backout JDK-8256264 fix. ------------- Commit messages: - 8259007: This test printed a blank page Changes: https://git.openjdk.java.net/jdk16/pull/80/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=80&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259007 Stats: 470 lines in 4 files changed: 0 ins; 459 del; 11 mod Patch: https://git.openjdk.java.net/jdk16/pull/80.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/80/head:pull/80 PR: https://git.openjdk.java.net/jdk16/pull/80 From github.com+654217+bastie at openjdk.java.net Tue Jan 5 16:11:57 2021 From: github.com+654217+bastie at openjdk.java.net (Sebastian Ritter) Date: Tue, 5 Jan 2021 16:11:57 GMT Subject: Withdrawn: 8066622 8066637: remove deprecated using java.io.File.toURL() in internal classes In-Reply-To: References: Message-ID: On Sat, 7 Nov 2020 07:55:03 GMT, Sebastian Ritter wrote: > In result of Javadoc to do not use java.io.File.toURL() > Change use java.io.File.toURL().toURI() instead. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/1108 From prr at openjdk.java.net Tue Jan 5 16:31:57 2021 From: prr at openjdk.java.net (Phil Race) Date: Tue, 5 Jan 2021 16:31:57 GMT Subject: [jdk16] RFR: 8259007: This test printed a blank page In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 08:28:28 GMT, Prasanta Sadhukhan wrote: > Backout JDK-8256264 fix. I assume you tested this does indeed fix the regressipn ? Approving on that understanding. ------------- Marked as reviewed by prr (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/80 From serb at openjdk.java.net Tue Jan 5 23:36:57 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Tue, 5 Jan 2021 23:36:57 GMT Subject: [jdk16] RFR: 8259007: This test printed a blank page In-Reply-To: References: Message-ID: <5IeE9I8sVWZ-UCgiS0IehFWbU3vKWkhl5TDl_1nTJGE=.feaecc78-2846-4229-a916-c420d496e546@github.com> On Tue, 5 Jan 2021 08:28:28 GMT, Prasanta Sadhukhan wrote: > Backout JDK-8256264 fix. Marked as reviewed by serb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk16/pull/80 From serb at openjdk.java.net Wed Jan 6 00:04:55 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Wed, 6 Jan 2021 00:04:55 GMT Subject: [jdk16] RFR: 8259007: This test printed a blank page In-Reply-To: <5IeE9I8sVWZ-UCgiS0IehFWbU3vKWkhl5TDl_1nTJGE=.feaecc78-2846-4229-a916-c420d496e546@github.com> References: <5IeE9I8sVWZ-UCgiS0IehFWbU3vKWkhl5TDl_1nTJGE=.feaecc78-2846-4229-a916-c420d496e546@github.com> Message-ID: On Tue, 5 Jan 2021 23:34:02 GMT, Sergey Bylokhov wrote: >> Backout JDK-8256264 fix. > > Marked as reviewed by serb (Reviewer). The fix for JDK-8256264 made an assumption that moveTo/lineTo methods are always wrapped by the beginPath/endPath. So that fix sets the scale in the beginPath/endPath and correct the passed parameters in the moveTo/lineTo. But this new code in the moveTo/lineTo does not work well if the beginPath was not called. ------------- PR: https://git.openjdk.java.net/jdk16/pull/80 From prr at openjdk.java.net Wed Jan 6 01:22:02 2021 From: prr at openjdk.java.net (Phil Race) Date: Wed, 6 Jan 2021 01:22:02 GMT Subject: RFR: 8259232: Bad JNI lookup during printing Message-ID: Didn't hit this because all the print testing I conducted used the swing print + page dialog but the logging made it easy to find the source of the problem. I've also done an audit of GET_METHOD_* usages for this pattern - I had previously done it for DECLARE_METHOD* which is the bulk. ------------- Commit messages: - 8259232: Bad JNI lookup during printing Changes: https://git.openjdk.java.net/jdk/pull/1952/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1952&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259232 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1952.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1952/head:pull/1952 PR: https://git.openjdk.java.net/jdk/pull/1952 From psadhukhan at openjdk.java.net Wed Jan 6 04:37:03 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Wed, 6 Jan 2021 04:37:03 GMT Subject: [jdk16] RFR: 8259007: This test printed a blank page In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 16:29:23 GMT, Phil Race wrote: > > > I assume you tested this does indeed fix the regressipn ? > Approving on that understanding. Yes, it does fix in my testing and I also got confirmation from EG that this patch fix the issues. ------------- PR: https://git.openjdk.java.net/jdk16/pull/80 From psadhukhan at openjdk.java.net Wed Jan 6 06:39:59 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Wed, 6 Jan 2021 06:39:59 GMT Subject: [jdk16] Integrated: 8259007: This test printed a blank page In-Reply-To: References: Message-ID: <592pk01b29mAgL-EDR7ndCQqKF6ysK32PSjt5zydSPY=.6fa34f64-5f5d-4a8e-ba81-c7c4239b0b49@github.com> On Tue, 5 Jan 2021 08:28:28 GMT, Prasanta Sadhukhan wrote: > Backout JDK-8256264 fix. This pull request has now been integrated. Changeset: 80110dac Author: Prasanta Sadhukhan URL: https://git.openjdk.java.net/jdk16/commit/80110dac Stats: 470 lines in 4 files changed: 0 ins; 459 del; 11 mod 8259007: This test printed a blank page Reviewed-by: prr, serb ------------- PR: https://git.openjdk.java.net/jdk16/pull/80 From psadhukhan at openjdk.java.net Wed Jan 6 07:02:55 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Wed, 6 Jan 2021 07:02:55 GMT Subject: RFR: 8259232: Bad JNI lookup during printing In-Reply-To: References: Message-ID: On Wed, 6 Jan 2021 01:17:02 GMT, Phil Race wrote: > Didn't hit this because all the print testing I conducted used the swing print + page dialog but the logging made it easy to find the source of the problem. > I've also done an audit of GET_METHOD_* usages for this pattern - I had previously done it for DECLARE_METHOD* which is the bulk. Marked as reviewed by psadhukhan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1952 From psadhukhan at openjdk.java.net Wed Jan 6 07:20:56 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Wed, 6 Jan 2021 07:20:56 GMT Subject: RFR: 8213126: java/awt/Window/MainKeyWindow/TestMainKeyWindow.java time-out on mac10.13 In-Reply-To: References: Message-ID: On Thu, 29 Oct 2020 18:42:58 GMT, Sergey Bylokhov wrote: > Initially, this bug was filed because the test was run via jtreg without passing '-nativepath' option(the make file pass this option automatically). So we could just de-problem list the test, but on the macOS Catalina the "System Preferences.app" was moved so the test cannot run it. As a fix, I suggest running the java app via a separate process instead of "System Preferences.app". > > The test still fails before JDK-8194327, and passed after. Marked as reviewed by psadhukhan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/941 From prr at openjdk.java.net Wed Jan 6 17:36:55 2021 From: prr at openjdk.java.net (Phil Race) Date: Wed, 6 Jan 2021 17:36:55 GMT Subject: Integrated: 8259232: Bad JNI lookup during printing In-Reply-To: References: Message-ID: On Wed, 6 Jan 2021 01:17:02 GMT, Phil Race wrote: > Didn't hit this because all the print testing I conducted used the swing print + page dialog but the logging made it easy to find the source of the problem. > I've also done an audit of GET_METHOD_* usages for this pattern - I had previously done it for DECLARE_METHOD* which is the bulk. This pull request has now been integrated. Changeset: 940b0530 Author: Phil Race URL: https://git.openjdk.java.net/jdk/commit/940b0530 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod 8259232: Bad JNI lookup during printing Reviewed-by: psadhukhan ------------- PR: https://git.openjdk.java.net/jdk/pull/1952 From serb at openjdk.java.net Wed Jan 6 19:39:02 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Wed, 6 Jan 2021 19:39:02 GMT Subject: RFR: 8259232: Bad JNI lookup during printing In-Reply-To: References: Message-ID: On Wed, 6 Jan 2021 01:17:02 GMT, Phil Race wrote: > Didn't hit this because all the print testing I conducted used the swing print + page dialog but the logging made it easy to find the source of the problem. > I've also done an audit of GET_METHOD_* usages for this pattern - I had previously done it for DECLARE_METHOD* which is the bulk. src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m line 59: > 57: GET_METHOD_RETURN(sjm_getNSPrintInfo, sjc_CPrinterJob, "getNSPrintInfo", "()J", ret); > 58: > 59: #define GET_CPRINTERDIALOG_METHOD_RETURN(ret) \ I guess the name of the macro should be renamed as well? ------------- PR: https://git.openjdk.java.net/jdk/pull/1952 From serb at openjdk.java.net Thu Jan 7 03:37:22 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Thu, 7 Jan 2021 03:37:22 GMT Subject: RFR: 8213126: java/awt/Window/MainKeyWindow/TestMainKeyWindow.java time-out on mac10.13 [v2] In-Reply-To: References: Message-ID: > Initially, this bug was filed because the test was run via jtreg without passing '-nativepath' option(the make file pass this option automatically). So we could just de-problem list the test, but on the macOS Catalina the "System Preferences.app" was moved so the test cannot run it. As a fix, I suggest running the java app via a separate process instead of "System Preferences.app". > > The test still fails before JDK-8194327, and passed after. 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 three additional commits since the last revision: - Merge branch 'master' into JDK-8213126 - Update TestMainKeyWindow.java - Initial fix ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/941/files - new: https://git.openjdk.java.net/jdk/pull/941/files/ef000fec..3a210c7a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=941&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=941&range=00-01 Stats: 412638 lines in 4609 files changed: 252284 ins; 111643 del; 48711 mod Patch: https://git.openjdk.java.net/jdk/pull/941.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/941/head:pull/941 PR: https://git.openjdk.java.net/jdk/pull/941 From serb at openjdk.java.net Thu Jan 7 03:40:29 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Thu, 7 Jan 2021 03:40:29 GMT Subject: RFR: 7194219: java/awt/Component/UpdatingBootTime/UpdatingBootTime.html fails on Linux [v2] In-Reply-To: <1puLRaS3bbjpiliy6h0OD3EDboP3pkFlfMUj7wrXfjw=.77372c28-e6a0-49a5-bfe3-863858f47392@github.com> References: <1puLRaS3bbjpiliy6h0OD3EDboP3pkFlfMUj7wrXfjw=.77372c28-e6a0-49a5-bfe3-863858f47392@github.com> Message-ID: > The test checks that the timestamp of the mouse event accurately represents the current time of the system, even if the time of the system is jumped to the past/future. > > On Unix in xawt we calculate the timstamp using this method: > reset_time_utc = System.currentTimeMillis() - getCurrentServerTime(); > timstamp = reset_time_utc + server_offset; > > (1.) Note that the "server_offset" - timstamp when the native event was generated, and we try to convert it to the UTC timestamp. Unfortunatly we callculate the "reset_time_utc" only once at the start of the application and then rarely update it. So if the time in the system is changed we still use the old one. > > The exactly the same bug described at (1.) was fixed on windows by the https://bugs.openjdk.java.net/browse/JDK-6461933 and for that bug the test in question was created. That bug was fixed by the "recalculation" system time more often. But it does not solve the general time issue and the code was reworked again by the https://bugs.openjdk.java.net/browse/JDK-8046495 > > I would like to fix the current bug in the same was as on windows, see link below: > https://bugs.openjdk.java.net/browse/JDK-8046495?focusedCommentId=13517205&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-13517205 > > After the fix we will use the same System.currentTimeMillis()/JVM_CurrentTimeMillis on all platforms. 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-7194219 - Initial fix ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/925/files - new: https://git.openjdk.java.net/jdk/pull/925/files/b9368a3a..1d33f93b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=925&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=925&range=00-01 Stats: 422884 lines in 4810 files changed: 258191 ins; 115055 del; 49638 mod Patch: https://git.openjdk.java.net/jdk/pull/925.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/925/head:pull/925 PR: https://git.openjdk.java.net/jdk/pull/925 From serb at openjdk.java.net Thu Jan 7 03:42:24 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Thu, 7 Jan 2021 03:42:24 GMT Subject: RFR: 6278172: TextComponent.getSelectedText() throws StringIndexOutOfBoundsException [v2] In-Reply-To: <5vcukZV00bZ1bAzji0LuUn5sTYIEVCyz3OzEOLeOMpM=.000ffc24-3aa7-481c-b7c8-3105867474e3@github.com> References: <5vcukZV00bZ1bAzji0LuUn5sTYIEVCyz3OzEOLeOMpM=.000ffc24-3aa7-481c-b7c8-3105867474e3@github.com> Message-ID: > The text components are implements as wrappers over the "native" peers. Most of the functionality is provided by the peers not wrappers like TextArea/TextField. The current bug occurs in the TextArea/TextField when the native peer was created yet. > > The steps to reproduce: > 1. Sets the long text to the component > 2. Select all text in the component > 3. Sets the short text to the component > 4. Request the selected text -> BOOM > > The bug on step 4 occurred because we request a long substring of the short text. To eliminate an exception we have two choices: > 1. Preserve the selection in the setText(), but limit it by the length of the current text. > 2. Resets the selection. > > I tried both solutions, the second caused some TCK tests to fail, so I selected the first one. 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 three additional commits since the last revision: - Merge branch 'master' into JDK-6278172 - Merge branch 'master' into JDK-6278172 - Initial fix ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1104/files - new: https://git.openjdk.java.net/jdk/pull/1104/files/a414f2df..5c99c3d4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1104&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1104&range=00-01 Stats: 360278 lines in 4004 files changed: 225151 ins; 88575 del; 46552 mod Patch: https://git.openjdk.java.net/jdk/pull/1104.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1104/head:pull/1104 PR: https://git.openjdk.java.net/jdk/pull/1104 From serb at openjdk.java.net Thu Jan 7 17:52:53 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Thu, 7 Jan 2021 17:52:53 GMT Subject: Integrated: 8213126: java/awt/Window/MainKeyWindow/TestMainKeyWindow.java time-out on mac10.13 In-Reply-To: References: Message-ID: <16nKpDj8lWB1RhWMGn86JegqYOdf58WycjfLZKBB_f8=.9eb15f44-beb5-4da8-8f8a-d75558972844@github.com> On Thu, 29 Oct 2020 18:42:58 GMT, Sergey Bylokhov wrote: > Initially, this bug was filed because the test was run via jtreg without passing '-nativepath' option(the make file pass this option automatically). So we could just de-problem list the test, but on the macOS Catalina the "System Preferences.app" was moved so the test cannot run it. As a fix, I suggest running the java app via a separate process instead of "System Preferences.app". > > The test still fails before JDK-8194327, and passed after. This pull request has now been integrated. Changeset: 2e99e28f Author: Sergey Bylokhov URL: https://git.openjdk.java.net/jdk/commit/2e99e28f Stats: 45 lines in 2 files changed: 23 ins; 11 del; 11 mod 8213126: java/awt/Window/MainKeyWindow/TestMainKeyWindow.java time-out on mac10.13 Reviewed-by: psadhukhan ------------- PR: https://git.openjdk.java.net/jdk/pull/941 From aivanov at openjdk.java.net Thu Jan 7 20:14:03 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Thu, 7 Jan 2021 20:14:03 GMT Subject: RFR: 6278172: TextComponent.getSelectedText() throws StringIndexOutOfBoundsException [v2] In-Reply-To: References: <5vcukZV00bZ1bAzji0LuUn5sTYIEVCyz3OzEOLeOMpM=.000ffc24-3aa7-481c-b7c8-3105867474e3@github.com> Message-ID: On Thu, 7 Jan 2021 03:42:24 GMT, Sergey Bylokhov wrote: >> The text components are implements as wrappers over the "native" peers. Most of the functionality is provided by the peers not wrappers like TextArea/TextField. The current bug occurs in the TextArea/TextField when the native peer was created yet. >> >> The steps to reproduce: >> 1. Sets the long text to the component >> 2. Select all text in the component >> 3. Sets the short text to the component >> 4. Request the selected text -> BOOM >> >> The bug on step 4 occurred because we request a long substring of the short text. To eliminate an exception we have two choices: >> 1. Preserve the selection in the setText(), but limit it by the length of the current text. >> 2. Resets the selection. >> >> I tried both solutions, the second caused some TCK tests to fail, so I selected the first one. > > 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 three additional commits since the last revision: > > - Merge branch 'master' into JDK-6278172 > - Merge branch 'master' into JDK-6278172 > - Initial fix Marked as reviewed by aivanov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1104 From aivanov at openjdk.java.net Thu Jan 7 20:14:07 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Thu, 7 Jan 2021 20:14:07 GMT Subject: RFR: 6278172: TextComponent.getSelectedText() throws StringIndexOutOfBoundsException [v2] In-Reply-To: References: <5vcukZV00bZ1bAzji0LuUn5sTYIEVCyz3OzEOLeOMpM=.000ffc24-3aa7-481c-b7c8-3105867474e3@github.com> Message-ID: On Thu, 7 Jan 2021 20:10:07 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 three additional commits since the last revision: >> >> - Merge branch 'master' into JDK-6278172 >> - Merge branch 'master' into JDK-6278172 >> - Initial fix > > Marked as reviewed by aivanov (Reviewer). I wonder how native text components behave: is the selection preserved when text is replaced? ------------- PR: https://git.openjdk.java.net/jdk/pull/1104 From jwilhelm at openjdk.java.net Thu Jan 7 20:45:15 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 7 Jan 2021 20:45:15 GMT Subject: RFR: Merge jdk16 Message-ID: <02vnbZrSN2O7CorWeOmmETnD8eNM9ebzDlkuVSO5HPs=.bf19f127-43d1-4e1f-85eb-3ffa97908b21@github.com> Forwardport JDK 16 -> JDK 17 ------------- Commit messages: - Merge - 8249633: doclint reports missing javadoc for JavaFX property methods that have a property description - 8251200: False positive messages about missing comments for serialization - 8259312: VerifyCACerts.java fails as soneraclass2ca cert will expire in 90 days - 8259075: Update the copyright notice in the files generated by CLDR Converter tool - 8259224: (ann) getAnnotatedReceiverType should not parameterize owner(s) of statically nested classes - 8258558: Revert changes for JDK-8252505 and related issues - 8259032: MappedMemorySegmentImpl#makeMappedSegment() ignores Unmapper#pagePosition - 8259007: This test printed a blank page - 8258989: JVM is failed to inline in jdk.internal.vm.vector.VectorSupport::convert - ... and 8 more: https://git.openjdk.java.net/jdk/compare/0e6de4eb...bbd6426f The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=1989&range=00.0 - jdk16: https://webrevs.openjdk.java.net/?repo=jdk&pr=1989&range=00.1 Changes: https://git.openjdk.java.net/jdk/pull/1989/files Stats: 2957 lines in 68 files changed: 751 ins; 2142 del; 64 mod Patch: https://git.openjdk.java.net/jdk/pull/1989.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1989/head:pull/1989 PR: https://git.openjdk.java.net/jdk/pull/1989 From jwilhelm at openjdk.java.net Thu Jan 7 21:21:57 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 7 Jan 2021 21:21:57 GMT Subject: Integrated: Merge jdk16 In-Reply-To: <02vnbZrSN2O7CorWeOmmETnD8eNM9ebzDlkuVSO5HPs=.bf19f127-43d1-4e1f-85eb-3ffa97908b21@github.com> References: <02vnbZrSN2O7CorWeOmmETnD8eNM9ebzDlkuVSO5HPs=.bf19f127-43d1-4e1f-85eb-3ffa97908b21@github.com> Message-ID: On Thu, 7 Jan 2021 20:40:49 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 16 -> JDK 17 This pull request has now been integrated. Changeset: 555641ed Author: Jesper Wilhelmsson URL: https://git.openjdk.java.net/jdk/commit/555641ed Stats: 2957 lines in 68 files changed: 751 ins; 2142 del; 64 mod Merge ------------- PR: https://git.openjdk.java.net/jdk/pull/1989 From serb at openjdk.java.net Fri Jan 8 00:34:55 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Fri, 8 Jan 2021 00:34:55 GMT Subject: RFR: 6278172: TextComponent.getSelectedText() throws StringIndexOutOfBoundsException [v2] In-Reply-To: References: <5vcukZV00bZ1bAzji0LuUn5sTYIEVCyz3OzEOLeOMpM=.000ffc24-3aa7-481c-b7c8-3105867474e3@github.com> Message-ID: On Thu, 7 Jan 2021 20:11:31 GMT, Alexey Ivanov wrote: > I wonder how native text components behave: is the selection preserved when text is replaced? On windows, the selection resets, on macOS and Linux it is preserved. But it works that way because we implemented it in a such way, actually did not pay attention to such use-case. > Do I get it right that if the new text is longer than the initial one, then only the portion will be left selected. For the case: 1. the user sets the short text 2. then selects the longer distance 3. then sets the longer text nothing is changed. The select() method at step 2 will trim passed parameters based on the short text at step 1. So only the portion of the text will be selected. > Won't it cause the issue if the scenario where the selectionStart is past the length of the new text. I mean the only "field" portion of "text field" is selected, and then the text in component is replaced with "text", thus the selectionStart points 1 character past the end of the new text. The new call to select() method should take care of that since the user as well can call it passing wrong parameters. ------------- PR: https://git.openjdk.java.net/jdk/pull/1104 From serb at openjdk.java.net Fri Jan 8 06:57:05 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Fri, 8 Jan 2021 06:57:05 GMT Subject: RFR: 8259439: Apply java.io.Serial annotations in java.datatransfer Message-ID: Please review the application of `@java.io.Serial` annotation (JDK-8202385) to types in the datatransfer module to enable stricter compile-time checking of serialization-related declarations. This annotation can be applied to these methods in the module: * private void writeObject(java.io.ObjectOutputStream stream) throws IOException * private void readObject(java.io.ObjectInputStream stream) throws IOException, ClassNotFoundException * private void readObjectNoData() throws ObjectStreamException * ANY-ACCESS-MODIFIER Object writeReplace() throws ObjectStreamException * ANY-ACCESS-MODIFIER Object readResolve() throws ObjectStreamException * private static final ObjectStreamField[] serialPersistentFields * private static final long serialVersionUID But only the `serialVersionUID` is updated since only this field is used in the datatransfer module. A similar fix was implemented for java.base module as well: http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-August/062046.html ------------- Commit messages: - Merge branch 'master' into JDK-8259439 - Initial fix Changes: https://git.openjdk.java.net/jdk/pull/1996/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1996&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259439 Stats: 31 lines in 5 files changed: 19 ins; 0 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/1996.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1996/head:pull/1996 PR: https://git.openjdk.java.net/jdk/pull/1996 From serb at openjdk.java.net Fri Jan 8 06:57:05 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Fri, 8 Jan 2021 06:57:05 GMT Subject: RFR: 8259439: Apply java.io.Serial annotations in java.datatransfer In-Reply-To: References: Message-ID: On Fri, 8 Jan 2021 04:51:50 GMT, Sergey Bylokhov wrote: > Please review the application of `@java.io.Serial` annotation (JDK-8202385) to types in the datatransfer module to enable stricter compile-time checking of serialization-related declarations. > > This annotation can be applied to these methods in the module: > * private void writeObject(java.io.ObjectOutputStream stream) throws IOException > * private void readObject(java.io.ObjectInputStream stream) throws IOException, ClassNotFoundException > * private void readObjectNoData() throws ObjectStreamException > * ANY-ACCESS-MODIFIER Object writeReplace() throws ObjectStreamException > * ANY-ACCESS-MODIFIER Object readResolve() throws ObjectStreamException > * private static final ObjectStreamField[] serialPersistentFields > * private static final long serialVersionUID > > But only the `serialVersionUID` is updated since only this field is used in the datatransfer module. > > A similar fix was implemented for java.base module as well: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-August/062046.html @jddarcy please take a look, as far as I understand we do not create a CSR for such changes. ------------- PR: https://git.openjdk.java.net/jdk/pull/1996 From aivanov at openjdk.java.net Fri Jan 8 22:07:54 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Fri, 8 Jan 2021 22:07:54 GMT Subject: RFR: 6278172: TextComponent.getSelectedText() throws StringIndexOutOfBoundsException [v2] In-Reply-To: References: <5vcukZV00bZ1bAzji0LuUn5sTYIEVCyz3OzEOLeOMpM=.000ffc24-3aa7-481c-b7c8-3105867474e3@github.com> Message-ID: On Fri, 8 Jan 2021 00:32:32 GMT, Sergey Bylokhov wrote: > The new call to select() method should take care of that since the user as well can call it passing wrong parameters. Thank you for clarification. Looks good. ------------- PR: https://git.openjdk.java.net/jdk/pull/1104 From aivanov at openjdk.java.net Fri Jan 8 22:54:54 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Fri, 8 Jan 2021 22:54:54 GMT Subject: RFR: 8259439: Apply java.io.Serial annotations in java.datatransfer In-Reply-To: References: Message-ID: On Fri, 8 Jan 2021 04:51:50 GMT, Sergey Bylokhov wrote: > Please review the application of `@java.io.Serial` annotation (JDK-8202385) to types in the datatransfer module to enable stricter compile-time checking of serialization-related declarations. > > This annotation can be applied to these methods in the module: > * private void writeObject(java.io.ObjectOutputStream stream) throws IOException > * private void readObject(java.io.ObjectInputStream stream) throws IOException, ClassNotFoundException > * private void readObjectNoData() throws ObjectStreamException > * ANY-ACCESS-MODIFIER Object writeReplace() throws ObjectStreamException > * ANY-ACCESS-MODIFIER Object readResolve() throws ObjectStreamException > * private static final ObjectStreamField[] serialPersistentFields > * private static final long serialVersionUID > > But only the `serialVersionUID` is updated since only this field is used in the datatransfer module. > > A similar fix was implemented for java.base module as well: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-August/062046.html Marked as reviewed by aivanov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1996 From prr at openjdk.java.net Sat Jan 9 01:33:02 2021 From: prr at openjdk.java.net (Phil Race) Date: Sat, 9 Jan 2021 01:33:02 GMT Subject: RFR: 8259343: [macOS] Update JNI error handling in Cocoa code. Message-ID: Proposed updates to JNI error handling. ------------- Commit messages: - 8259343: [macOS] Update JNI error handling in Cocoa code. - 8259343: [macOS] Update JNI error handling in Cocoa code. Changes: https://git.openjdk.java.net/jdk/pull/1967/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1967&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259343 Stats: 73 lines in 8 files changed: 58 ins; 1 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/1967.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1967/head:pull/1967 PR: https://git.openjdk.java.net/jdk/pull/1967 From serb at openjdk.java.net Sat Jan 9 01:33:03 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Sat, 9 Jan 2021 01:33:03 GMT Subject: RFR: 8259343: [macOS] Update JNI error handling in Cocoa code. In-Reply-To: References: Message-ID: On Wed, 6 Jan 2021 21:14:06 GMT, Phil Race wrote: > Proposed updates to JNI error handling. src/java.desktop/macosx/native/libosxapp/JNIUtilities.h line 180: > 178: * nature of the problem that has been detected and how survivable it is. > 179: */ > 180: #define CHECK_EXCEPTION() \ Since this macro does not try to return from the outer code we can change it to the method? src/java.desktop/macosx/native/libosxapp/JNIUtilities.h line 182: > 180: #define CHECK_EXCEPTION() \ > 181: if ((*env)->ExceptionOccurred(env) != NULL) { \ > 182: if ([NSThread isMainThread] == YES) { \ Isn't it is a similar code to the https://github.com/openjdk/jdk/blob/67c221148159d94142a3a6d9ddadce2dff8c858b/src/java.desktop/macosx/native/libosxapp/NSApplicationAWT.m#L334 Where we just catch an exception log it, and continue to run our infinite loop? Why do we need to do something specific here? I mean we cannot drop any try/catch blocks anyway since an nsexception may be generated by some external system code. src/java.desktop/macosx/native/libosxapp/JNIUtilities.h line 41: > 39: NSLog(@"%@",[NSThread callStackSymbols]); \ > 40: if ([NSThread isMainThread] == NO) { \ > 41: JNU_ThrowInternalError(env, "Bad JNI Lookup"); \ It will be possible that(most of the time) the JNU_ThrowInternalError will be called while we already have a raised java exception. ------------- PR: https://git.openjdk.java.net/jdk/pull/1967 From prr at openjdk.java.net Sat Jan 9 01:33:05 2021 From: prr at openjdk.java.net (Phil Race) Date: Sat, 9 Jan 2021 01:33:05 GMT Subject: RFR: 8259343: [macOS] Update JNI error handling in Cocoa code. In-Reply-To: References: Message-ID: On Thu, 7 Jan 2021 00:35:27 GMT, Sergey Bylokhov wrote: >> Proposed updates to JNI error handling. > > src/java.desktop/macosx/native/libosxapp/JNIUtilities.h line 180: > >> 178: * nature of the problem that has been detected and how survivable it is. >> 179: */ >> 180: #define CHECK_EXCEPTION() \ > > Since this macro does not try to return from the outer code we can change it to the method? But then "env" would need to be passed explicitly. I don't think the churn is worth it. And a method would then need a .m or .c file ... > src/java.desktop/macosx/native/libosxapp/JNIUtilities.h line 41: > >> 39: NSLog(@"%@",[NSThread callStackSymbols]); \ >> 40: if ([NSThread isMainThread] == NO) { \ >> 41: JNU_ThrowInternalError(env, "Bad JNI Lookup"); \ > > It will be possible that(most of the time) the JNU_ThrowInternalError will be called while we already have a raised java exception. I don't think "most" of the time is very likely. JNI lookup failures don't cause exceptions to be thrown. Is that what you are tihinking ? And separately, with either the current code of clearing exceptions or the change here to the practice of throwing NSException on seeing a Java Exception I think it very unlikely. > src/java.desktop/macosx/native/libosxapp/JNIUtilities.h line 182: > >> 180: #define CHECK_EXCEPTION() \ >> 181: if ((*env)->ExceptionOccurred(env) != NULL) { \ >> 182: if ([NSThread isMainThread] == YES) { \ > > Isn't it is a similar code to the > https://github.com/openjdk/jdk/blob/67c221148159d94142a3a6d9ddadce2dff8c858b/src/java.desktop/macosx/native/libosxapp/NSApplicationAWT.m#L334 > Where we just catch an exception log it, and continue to run our infinite loop? Why do we need to do something specific here? I mean we cannot drop any try/catch blocks anyway since an nsexception may be generated by some external system code. In my testing that code does not get called. The new code does. So the old code could probably be deleted as useless but it is also harmless and just maybe it'll catch something else, even if it isn't doing anything that I can see. ------------- PR: https://git.openjdk.java.net/jdk/pull/1967 From serb at openjdk.java.net Sat Jan 9 01:33:06 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Sat, 9 Jan 2021 01:33:06 GMT Subject: RFR: 8259343: [macOS] Update JNI error handling in Cocoa code. In-Reply-To: References: Message-ID: On Fri, 8 Jan 2021 02:40:58 GMT, Phil Race wrote: >> src/java.desktop/macosx/native/libosxapp/JNIUtilities.h line 41: >> >>> 39: NSLog(@"%@",[NSThread callStackSymbols]); \ >>> 40: if ([NSThread isMainThread] == NO) { \ >>> 41: JNU_ThrowInternalError(env, "Bad JNI Lookup"); \ >> >> It will be possible that(most of the time) the JNU_ThrowInternalError will be called while we already have a raised java exception. > > I don't think "most" of the time is very likely. JNI lookup failures don't cause exceptions to be thrown. > Is that what you are tihinking ? > > And separately, with either the current code of clearing exceptions or the change here to the practice of throwing NSException on seeing a Java Exception I think it very unlikely. Then how we get NoSuchMethodError here? https://bugs.openjdk.java.net/browse/JDK-8259232? https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions.html#GetMethodID Calling Instance Methods: GetMethodID RETURNS: Returns a method ID, or NULL if the specified method cannot be found. THROWS: NoSuchMethodError: if the specified method cannot be found. ExceptionInInitializerError: if the class initializer fails due to an exception. OutOfMemoryError: if the system runs out of memory. Same for fields: https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions.html#GetFieldID >> src/java.desktop/macosx/native/libosxapp/JNIUtilities.h line 180: >> >>> 178: * nature of the problem that has been detected and how survivable it is. >>> 179: */ >>> 180: #define CHECK_EXCEPTION() \ >> >> Since this macro does not try to return from the outer code we can change it to the method? > > But then "env" would need to be passed explicitly. I don't think the churn is worth it. > And a method would then need a .m or .c file ... But that could be merged to the CallXXXMethod and placed somewhere in the libosxapp >> src/java.desktop/macosx/native/libosxapp/JNIUtilities.h line 182: >> >>> 180: #define CHECK_EXCEPTION() \ >>> 181: if ((*env)->ExceptionOccurred(env) != NULL) { \ >>> 182: if ([NSThread isMainThread] == YES) { \ >> >> Isn't it is a similar code to the >> https://github.com/openjdk/jdk/blob/67c221148159d94142a3a6d9ddadce2dff8c858b/src/java.desktop/macosx/native/libosxapp/NSApplicationAWT.m#L334 >> Where we just catch an exception log it, and continue to run our infinite loop? Why do we need to do something specific here? I mean we cannot drop any try/catch blocks anyway since an nsexception may be generated by some external system code. > > In my testing that code does not get called. The new code does. So the old code could probably be deleted as useless but it is also harmless and just maybe it'll catch something else, even if it isn't doing anything that I can see. That code for sure should be called, it is even improved recently by JDK-8255681 I'll check how it was intended to work. ------------- PR: https://git.openjdk.java.net/jdk/pull/1967 From prr at openjdk.java.net Sat Jan 9 01:33:06 2021 From: prr at openjdk.java.net (Phil Race) Date: Sat, 9 Jan 2021 01:33:06 GMT Subject: RFR: 8259343: [macOS] Update JNI error handling in Cocoa code. In-Reply-To: References: Message-ID: <2MhWS44-i0zX8lt6BUh_dpOxsEQdYnifCB8dcqO_25E=.319e2c92-6bf1-40fa-86a6-5d9df8c6c27e@github.com> On Fri, 8 Jan 2021 04:40:36 GMT, Sergey Bylokhov wrote: >> But then "env" would need to be passed explicitly. I don't think the churn is worth it. >> And a method would then need a .m or .c file ... > > But that could be merged to the CallXXXMethod and placed somewhere in the libosxapp You mean those methods or macros that we already discussed and I explained why I do not want to do that ? This is a small update for error checking not revisiting everything done before. >> I don't think "most" of the time is very likely. JNI lookup failures don't cause exceptions to be thrown. >> Is that what you are tihinking ? >> >> And separately, with either the current code of clearing exceptions or the change here to the practice of throwing NSException on seeing a Java Exception I think it very unlikely. > > Then how we get NoSuchMethodError here? https://bugs.openjdk.java.net/browse/JDK-8259232? > https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions.html#GetMethodID > Calling Instance Methods: GetMethodID > RETURNS: > Returns a method ID, or NULL if the specified method cannot be found. > THROWS: > NoSuchMethodError: if the specified method cannot be found. > ExceptionInInitializerError: if the class initializer fails due to an exception. > OutOfMemoryError: if the system runs out of memory. > > Same for fields: > https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions.html#GetFieldID Ok. I will only create my own if none is pending. >> In my testing that code does not get called. The new code does. So the old code could probably be deleted as useless but it is also harmless and just maybe it'll catch something else, even if it isn't doing anything that I can see. > > That code for sure should be called, it is even improved recently by JDK-8255681 > I'll check how it was intended to work. I hadn't noticed that line - and definintely not realised it was recent. I suppose he must have had a way to trigger it. But I don't think it hurts to have both. ------------- PR: https://git.openjdk.java.net/jdk/pull/1967 From prr at openjdk.java.net Sat Jan 9 01:33:07 2021 From: prr at openjdk.java.net (Phil Race) Date: Sat, 9 Jan 2021 01:33:07 GMT Subject: RFR: 8259343: [macOS] Update JNI error handling in Cocoa code. In-Reply-To: References: Message-ID: On Wed, 6 Jan 2021 21:14:06 GMT, Phil Race wrote: > Proposed updates to JNI error handling. src/java.desktop/macosx/native/libosxapp/JNIUtilities.h line 46: > 44: if ((*env)->ExceptionOccurred(env) != NULL) { \ > 45: (*env)->ExceptionDescribe(env); \ > 46: } \ So the update here is that if we are not on the appkit thread, make sure a java exception is thrown. If we are on the appkit thread, clear any java exception since it isn't going anywhere but do it using describe which prints it. ------------- PR: https://git.openjdk.java.net/jdk/pull/1967 From serb at openjdk.java.net Sat Jan 9 07:25:59 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Sat, 9 Jan 2021 07:25:59 GMT Subject: Integrated: 6278172: TextComponent.getSelectedText() throws StringIndexOutOfBoundsException In-Reply-To: <5vcukZV00bZ1bAzji0LuUn5sTYIEVCyz3OzEOLeOMpM=.000ffc24-3aa7-481c-b7c8-3105867474e3@github.com> References: <5vcukZV00bZ1bAzji0LuUn5sTYIEVCyz3OzEOLeOMpM=.000ffc24-3aa7-481c-b7c8-3105867474e3@github.com> Message-ID: On Sat, 7 Nov 2020 00:14:19 GMT, Sergey Bylokhov wrote: > The text components are implements as wrappers over the "native" peers. Most of the functionality is provided by the peers not wrappers like TextArea/TextField. The current bug occurs in the TextArea/TextField when the native peer was created yet. > > The steps to reproduce: > 1. Sets the long text to the component > 2. Select all text in the component > 3. Sets the short text to the component > 4. Request the selected text -> BOOM > > The bug on step 4 occurred because we request a long substring of the short text. To eliminate an exception we have two choices: > 1. Preserve the selection in the setText(), but limit it by the length of the current text. > 2. Resets the selection. > > I tried both solutions, the second caused some TCK tests to fail, so I selected the first one. This pull request has now been integrated. Changeset: 6472104e Author: Sergey Bylokhov URL: https://git.openjdk.java.net/jdk/commit/6472104e Stats: 119 lines in 2 files changed: 107 ins; 3 del; 9 mod 6278172: TextComponent.getSelectedText() throws StringIndexOutOfBoundsException Reviewed-by: aivanov ------------- PR: https://git.openjdk.java.net/jdk/pull/1104 From pbansal at openjdk.java.net Sat Jan 9 12:53:11 2021 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Sat, 9 Jan 2021 12:53:11 GMT Subject: [jdk16] RFR: 8259237: Demo selection changes with left/right arrow key. No need to press space for selection. Message-ID: Please review a fix for jdk16 Issue: In SwingSet2, if the user navigates through the demos, the demo gets selected/starts on pressing left/right key only. There is no need to press the "space" key. Earlier, on pressing the left/right key, only demo icon used to get focused and user needed to press the "space" to actually select a demo. Cause: The SwingSet2 has JToggleButtons added to a ButtonGroup. Each JToggleButton has an AbstractAction set on it, which loads the demo. Earlier, when the user pressed Left/Right button, only the selected button used to change. The Action set on JToggleButton used to perform only on pressing the "Space" button. Now, the Action is performed on navigating the JToggleButtons using Left/Right keys without the need to press the "space" key. This issue is a side effect of fix done for https://bugs.openjdk.java.net/browse/JDK-8249548. The issues fixed in JDK-8249548 were not present in JRadioButton as there was code available to handle it in AquaButtonRadioUI and BasicRadioButtonUI. The fix done for JDK-8249548 moved duplicate code from AquaButtonRadioUI and BasicRadioButtonUI and moved it to BasicButtonUI, so this code is available for JToggleButton and JRadioButton for all L&Fs. This was wrong as there is a difference in behaviour for JRadioButtons added to ButtonGroup for AquaL&F and other L&Fs. In AquaL&F, the AbstractAction set on JRadioButton is not performed on button selection and user has to press "space". In other L&Fs, the AbstractAction is performed on selection of Button itself without the need to press "space". Fix: The current change fixes the issue in present bug and keeps the fixes done in JDK-8249548. Following is the behaviour of JToggleButton and JRadioButton for different L&Fs before JDK-8249548 fix, after JDK-8249548 fix and after current fix. Before fix for JDK-8249548 JToggleButton: For all L&Fs, user can not navigate/select the buttons added to ButtonGroup properly as mentioned in the JDK-8249548. JRadioButton: For Synth L&F (Nimbus L&F), user can not navigate/select the buttons added to ButtonGroup. For AquaL&F, user can select the buttons added to ButtonGroup by pressing left/right key and needs to press the "space" to perform the set Action. For Other L&Fs, user can select/navigate the buttons and the set Action is also performed without pressing "space" After fix for JDK-8249548 JToggleButton: For all L&Fs, user can navigate/select the buttons added to ButtonGroups and the AbstractAction set is performed without the need to press "space". JRadioButton: For all L&Fs, user can navigate/select the buttons added to ButtonGroups and the AbstractAction set is performed without the need to press "space". After current fix: JToggleButton: For all L&Fs, user can navigate/select the buttons added to ButtonGroups. User needs to press "space" to perform the set AbstractAction. JRadioButton: For AquaL&F, the behaviour before JDK-8249548 is restored, so user needs to press the "space" to perform the set Action. For all other L&Fs (including Synth L&F), the behaviour is same. User can navigate/select the buttons added to ButtonGroups and set Action is performed without pressing "space" I have run mach5 jobs with full jtreg/jck and all looks good. Links in JBS. The test TestButtonGroupFocusTraversal.java is modified such that it fails without current fix and passes after the fix. The fix also should be verified by running SwingSet2. ------------- Commit messages: - 8259237: Demo selection changes with left/right arrow key. No need to press space for selection. Changes: https://git.openjdk.java.net/jdk16/pull/99/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=99&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259237 Stats: 375 lines in 4 files changed: 350 ins; 20 del; 5 mod Patch: https://git.openjdk.java.net/jdk16/pull/99.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/99/head:pull/99 PR: https://git.openjdk.java.net/jdk16/pull/99 From serb at openjdk.java.net Sun Jan 10 07:07:06 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Sun, 10 Jan 2021 07:07:06 GMT Subject: RFR: 8259519: The java.awt.datatransfer.DataFlavor#ioInputStreamClass field is redundant Message-ID: A long time ago in the pre-1.0 era, this field was initialized via reflection since the "InputStream" class was optional. This was changed since then and a separate field to refer the "InputStream.class" is not needed. ------------- Commit messages: - Initial fix Changes: https://git.openjdk.java.net/jdk/pull/2016/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2016&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259519 Stats: 54 lines in 2 files changed: 50 ins; 1 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/2016.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2016/head:pull/2016 PR: https://git.openjdk.java.net/jdk/pull/2016 From pbansal at openjdk.java.net Sun Jan 10 13:01:54 2021 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Sun, 10 Jan 2021 13:01:54 GMT Subject: RFR: 8259439: Apply java.io.Serial annotations in java.datatransfer In-Reply-To: References: Message-ID: On Fri, 8 Jan 2021 04:51:50 GMT, Sergey Bylokhov wrote: > Please review the application of `@java.io.Serial` annotation (JDK-8202385) to types in the datatransfer module to enable stricter compile-time checking of serialization-related declarations. > > This annotation can be applied to these methods in the module: > * private void writeObject(java.io.ObjectOutputStream stream) throws IOException > * private void readObject(java.io.ObjectInputStream stream) throws IOException, ClassNotFoundException > * private void readObjectNoData() throws ObjectStreamException > * ANY-ACCESS-MODIFIER Object writeReplace() throws ObjectStreamException > * ANY-ACCESS-MODIFIER Object readResolve() throws ObjectStreamException > * private static final ObjectStreamField[] serialPersistentFields > * private static final long serialVersionUID > > But only the `serialVersionUID` is updated since only this field is used in the datatransfer module. > > A similar fix was implemented for java.base module as well: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-August/062046.html Marked as reviewed by pbansal (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1996 From attila at openjdk.java.net Sun Jan 10 19:57:57 2021 From: attila at openjdk.java.net (Attila Szegedi) Date: Sun, 10 Jan 2021 19:57:57 GMT Subject: RFR: 8259519: The java.awt.datatransfer.DataFlavor#ioInputStreamClass field is redundant In-Reply-To: References: Message-ID: On Sun, 10 Jan 2021 03:57:42 GMT, Sergey Bylokhov wrote: > A long time ago in the pre-1.0 era, this field was initialized via reflection since the "InputStream" class was optional. This was changed since then and a separate field to refer the "InputStream.class" is not needed. Changes requested by attila (Reviewer). src/java.datatransfer/share/classes/java/awt/datatransfer/DataFlavor.java line 1141: > 1139: */ > 1140: public final Class getDefaultRepresentationClass() { > 1141: return java.io.InputStream.class; Suggestion: return InputStream.class; The class is already imported on line 32. src/java.datatransfer/share/classes/java/awt/datatransfer/DataFlavor.java line 1160: > 1158: */ > 1159: public boolean isRepresentationClassInputStream() { > 1160: return java.io.InputStream.class.isAssignableFrom(representationClass); Suggestion: return InputStream.class.isAssignableFrom(representationClass); The class is already imported on line 32. ------------- PR: https://git.openjdk.java.net/jdk/pull/2016 From serb at openjdk.java.net Mon Jan 11 00:14:57 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Mon, 11 Jan 2021 00:14:57 GMT Subject: RFR: 8259519: The java.awt.datatransfer.DataFlavor#ioInputStreamClass field is redundant In-Reply-To: References: Message-ID: On Sun, 10 Jan 2021 19:55:02 GMT, Attila Szegedi wrote: >> A long time ago in the pre-1.0 era, this field was initialized via reflection since the "InputStream" class was optional. This was changed since then and a separate field to refer the "InputStream.class" is not needed. > > src/java.datatransfer/share/classes/java/awt/datatransfer/DataFlavor.java line 1160: > >> 1158: */ >> 1159: public boolean isRepresentationClassInputStream() { >> 1160: return java.io.InputStream.class.isAssignableFrom(representationClass); > > Suggestion: > > return InputStream.class.isAssignableFrom(representationClass); > The class is already imported on line 32. This is the style used by the various methods in this class to highlight an exact used type. ------------- PR: https://git.openjdk.java.net/jdk/pull/2016 From herrick at openjdk.java.net Mon Jan 11 01:56:56 2021 From: herrick at openjdk.java.net (Andy Herrick) Date: Mon, 11 Jan 2021 01:56:56 GMT Subject: Withdrawn: JDK-8189198: Add "forRemoval = true" to Applet APIs In-Reply-To: References: Message-ID: On Mon, 9 Nov 2020 13:56:33 GMT, Andy Herrick wrote: > JDK-8189198: Add "forRemoval = true" to Applet APIs This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/1127 From trebari at openjdk.java.net Mon Jan 11 05:22:53 2021 From: trebari at openjdk.java.net (Tejpal Rebari) Date: Mon, 11 Jan 2021 05:22:53 GMT Subject: RFR: 8259439: Apply java.io.Serial annotations in java.datatransfer In-Reply-To: References: Message-ID: On Fri, 8 Jan 2021 04:51:50 GMT, Sergey Bylokhov wrote: > Please review the application of `@java.io.Serial` annotation (JDK-8202385) to types in the datatransfer module to enable stricter compile-time checking of serialization-related declarations. > > This annotation can be applied to these methods in the module: > * private void writeObject(java.io.ObjectOutputStream stream) throws IOException > * private void readObject(java.io.ObjectInputStream stream) throws IOException, ClassNotFoundException > * private void readObjectNoData() throws ObjectStreamException > * ANY-ACCESS-MODIFIER Object writeReplace() throws ObjectStreamException > * ANY-ACCESS-MODIFIER Object readResolve() throws ObjectStreamException > * private static final ObjectStreamField[] serialPersistentFields > * private static final long serialVersionUID > > But only the `serialVersionUID` is updated since only this field is used in the datatransfer module. > > A similar fix was implemented for java.base module as well: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-August/062046.html Marked as reviewed by trebari (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1996 From serb at openjdk.java.net Mon Jan 11 06:07:59 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Mon, 11 Jan 2021 06:07:59 GMT Subject: RFR: 8259343: [macOS] Update JNI error handling in Cocoa code. In-Reply-To: References: Message-ID: <7RahvO2lHhxOAhcIdk2_pqtsbqdelLHRSXeAin2ZnQY=.0aaa2356-c382-46e7-83be-99ec143ee8ff@github.com> On Fri, 8 Jan 2021 19:05:09 GMT, Phil Race wrote: >> Proposed updates to JNI error handling. > > src/java.desktop/macosx/native/libosxapp/JNIUtilities.h line 46: > >> 44: if ((*env)->ExceptionOccurred(env) != NULL) { \ >> 45: (*env)->ExceptionDescribe(env); \ >> 46: } \ > > So the update here is that if we are not on the appkit thread, make sure a java exception is thrown. > If we are on the appkit thread, clear any java exception since it isn't going anywhere but do it using > describe which prints it. I read the logic of the method differently, probably the wrong indents? - If we are not on the toolkit thread then - Check ExceptionOccurred -> throw JNU_ThrowInternalError if needed or check exception again ->call ExceptionDescribe - NSException raise at the end. ------------- PR: https://git.openjdk.java.net/jdk/pull/1967 From serb at openjdk.java.net Mon Jan 11 06:07:57 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Mon, 11 Jan 2021 06:07:57 GMT Subject: RFR: 8259343: [macOS] Update JNI error handling in Cocoa code. In-Reply-To: References: Message-ID: On Wed, 6 Jan 2021 21:14:06 GMT, Phil Race wrote: > Proposed updates to JNI error handling. src/java.desktop/macosx/native/libosxapp/JNIUtilities.h line 41: > 39: NSLog(@"%@",[NSThread callStackSymbols]); \ > 40: if ([NSThread isMainThread] == NO) { \ > 41: if ((*env)->ExceptionOccurred(env) == NULL) { \ Not sure that the check for ExceptionOccurred is needed, in all other places where we check the ref to methods/field we only check the return value, and if it is null then return immediately assuming that an exception is rased already, for example : https://github.com/openjdk/jdk/blob/b72de3c5fc99f365e9fb25114ddd28eceddfa6e8/src/java.desktop/windows/native/libawt/windows/awt_Button.cpp#L357 Note that the exception in the static initializer is fatal for the application. ------------- PR: https://git.openjdk.java.net/jdk/pull/1967 From serb at openjdk.java.net Mon Jan 11 06:08:00 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Mon, 11 Jan 2021 06:08:00 GMT Subject: RFR: 8259343: [macOS] Update JNI error handling in Cocoa code. In-Reply-To: <2MhWS44-i0zX8lt6BUh_dpOxsEQdYnifCB8dcqO_25E=.319e2c92-6bf1-40fa-86a6-5d9df8c6c27e@github.com> References: <2MhWS44-i0zX8lt6BUh_dpOxsEQdYnifCB8dcqO_25E=.319e2c92-6bf1-40fa-86a6-5d9df8c6c27e@github.com> Message-ID: On Fri, 8 Jan 2021 19:17:17 GMT, Phil Race wrote: >> That code for sure should be called, it is even improved recently by JDK-8255681 >> I'll check how it was intended to work. > > I hadn't noticed that line - and definintely not realised it was recent. > I suppose he must have had a way to trigger it. > But I don't think it hurts to have both. I just tried to understand why we need to complicate this, to me, it is unclear why handling the same errors in the NSApplicationAWT.m does not work. ------------- PR: https://git.openjdk.java.net/jdk/pull/1967 From serb at openjdk.java.net Mon Jan 11 08:19:19 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Mon, 11 Jan 2021 08:19:19 GMT Subject: RFR: 8259522: Apply java.io.Serial annotations in java.desktop Message-ID: Please review the application of @java.io.Serial annotation (JDK-8202385) to types in the desktop module to enable stricter compile-time checking of serialization-related declarations. This annotation can be applied to these methods in the module: private void writeObject(java.io.ObjectOutputStream stream) throws IOException private void readObject(java.io.ObjectInputStream stream) throws IOException, ClassNotFoundException private void readObjectNoData() throws ObjectStreamException ANY-ACCESS-MODIFIER Object writeReplace() throws ObjectStreamException ANY-ACCESS-MODIFIER Object readResolve() throws ObjectStreamException private static final ObjectStreamField[] serialPersistentFields private static final long serialVersionUID Notes: - I have tried to update the comments for serialVersionUID as accurately as possible, but mostly based on the source code history and bugs in JBS where that field was added - Some of the readObject/writeObject methods in the javax.swing package does not have a spec, because this package and some others are excluded from the serialization specification. A similar fix was implemented for java.base module as well: http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-August/062046.html ------------- Commit messages: - Update TextAttribute.java - Update readResolve - Update writeReplace - Update readObject - Update writeObject - Update serialPersistentFields - Update serialVersionUID Changes: https://git.openjdk.java.net/jdk/pull/2020/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2020&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259522 Stats: 3426 lines in 343 files changed: 2268 ins; 287 del; 871 mod Patch: https://git.openjdk.java.net/jdk/pull/2020.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2020/head:pull/2020 PR: https://git.openjdk.java.net/jdk/pull/2020 From psadhukhan at openjdk.java.net Mon Jan 11 08:22:59 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Mon, 11 Jan 2021 08:22:59 GMT Subject: [jdk16] RFR: 8259237: Demo selection changes with left/right arrow key. No need to press space for selection. In-Reply-To: References: Message-ID: On Sat, 9 Jan 2021 12:47:48 GMT, Pankaj Bansal wrote: > Please review a fix for jdk16 > > Issue: In SwingSet2, if the user navigates through the demos, the demo gets selected/starts on pressing left/right key only. There is no need to press the "space" key. Earlier, on pressing the left/right key, only demo icon used to get focused and user needed to press the "space" to actually select a demo. > > Cause: The SwingSet2 has JToggleButtons added to a ButtonGroup. Each JToggleButton has an AbstractAction set on it, which loads the demo. Earlier, when the user pressed Left/Right button, only the selected button used to change. The Action set on JToggleButton used to perform only on pressing the "Space" button. Now, the Action is performed on navigating the JToggleButtons using Left/Right keys without the need to press the "space" key. > > This issue is a side effect of fix done for https://bugs.openjdk.java.net/browse/JDK-8249548. The issues fixed in JDK-8249548 were not present in JRadioButton as there was code available to handle it in AquaButtonRadioUI and BasicRadioButtonUI. The fix done for JDK-8249548 moved duplicate code from AquaButtonRadioUI and BasicRadioButtonUI and moved it to BasicButtonUI, so this code is available for JToggleButton and JRadioButton for all L&Fs. This was wrong as there is a difference in behaviour for JRadioButtons added to ButtonGroup for AquaL&F and other L&Fs. In AquaL&F, the AbstractAction set on JRadioButton is not performed on button selection and user has to press "space". In other L&Fs, the AbstractAction is performed on selection of Button itself without the need to press "space". > > Fix: The current change fixes the issue in present bug and keeps the fixes done in JDK-8249548. Following is the behaviour of JToggleButton and JRadioButton for different L&Fs before JDK-8249548 fix, after JDK-8249548 fix and after current fix. > > Before fix for JDK-8249548 > JToggleButton: > For all L&Fs, user can not navigate/select the buttons added to ButtonGroup properly as mentioned in the JDK-8249548. > JRadioButton: > For Synth L&F (Nimbus L&F), user can not navigate/select the buttons added to ButtonGroup. > For AquaL&F, user can select the buttons added to ButtonGroup by pressing left/right key and needs to press the "space" to perform the set Action. > For Other L&Fs, user can select/navigate the buttons and the set Action is also performed without pressing "space" > > After fix for JDK-8249548 > JToggleButton: > For all L&Fs, user can navigate/select the buttons added to ButtonGroups and the AbstractAction set is performed without the need to press "space". > JRadioButton: > For all L&Fs, user can navigate/select the buttons added to ButtonGroups and the AbstractAction set is performed without the need to press "space". > > After current fix: > JToggleButton: > For all L&Fs, user can navigate/select the buttons added to ButtonGroups. User needs to press "space" to perform the set AbstractAction. > JRadioButton: > For AquaL&F, the behaviour before JDK-8249548 is restored, so user needs to press the "space" to perform the set Action. > For all other L&Fs (including Synth L&F), the behaviour is same. User can navigate/select the buttons added to ButtonGroups and set Action is performed without pressing "space" > > I have run mach5 jobs with full jtreg/jck and all looks good. Links in JBS. The test TestButtonGroupFocusTraversal.java is modified such that it fails without current fix and passes after the fix. The fix also should be verified by running SwingSet2. I guess you did not run jtreg job with latest problemlist as it did not run javax/swing/JRadioButton/ButtonGroupFocus/ButtonGroupFocusTest.java javax/swing/JRadioButton/8075609/bug8075609.java javax/swing/JRadioButton/8033699/bug8033699.java Please see this test pass with your change as some of them used to fail after JDK-8226892 which was reworked by fix of JDK-8249548 src/java.desktop/macosx/classes/com/apple/laf/AquaButtonUI.java line 228: > 226: if (listener != null) { > 227: b.removeMouseListener(listener); > 228: b.removeMouseListener(listener); Why are we removing same listener twice? ------------- PR: https://git.openjdk.java.net/jdk16/pull/99 From pbansal at openjdk.java.net Mon Jan 11 08:37:57 2021 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Mon, 11 Jan 2021 08:37:57 GMT Subject: [jdk16] RFR: 8259237: Demo selection changes with left/right arrow key. No need to press space for selection. In-Reply-To: References: Message-ID: On Mon, 11 Jan 2021 08:05:21 GMT, Prasanta Sadhukhan wrote: >> Please review a fix for jdk16 >> >> Issue: In SwingSet2, if the user navigates through the demos, the demo gets selected/starts on pressing left/right key only. There is no need to press the "space" key. Earlier, on pressing the left/right key, only demo icon used to get focused and user needed to press the "space" to actually select a demo. >> >> Cause: The SwingSet2 has JToggleButtons added to a ButtonGroup. Each JToggleButton has an AbstractAction set on it, which loads the demo. Earlier, when the user pressed Left/Right button, only the selected button used to change. The Action set on JToggleButton used to perform only on pressing the "Space" button. Now, the Action is performed on navigating the JToggleButtons using Left/Right keys without the need to press the "space" key. >> >> This issue is a side effect of fix done for https://bugs.openjdk.java.net/browse/JDK-8249548. The issues fixed in JDK-8249548 were not present in JRadioButton as there was code available to handle it in AquaButtonRadioUI and BasicRadioButtonUI. The fix done for JDK-8249548 moved duplicate code from AquaButtonRadioUI and BasicRadioButtonUI and moved it to BasicButtonUI, so this code is available for JToggleButton and JRadioButton for all L&Fs. This was wrong as there is a difference in behaviour for JRadioButtons added to ButtonGroup for AquaL&F and other L&Fs. In AquaL&F, the AbstractAction set on JRadioButton is not performed on button selection and user has to press "space". In other L&Fs, the AbstractAction is performed on selection of Button itself without the need to press "space". >> >> Fix: The current change fixes the issue in present bug and keeps the fixes done in JDK-8249548. Following is the behaviour of JToggleButton and JRadioButton for different L&Fs before JDK-8249548 fix, after JDK-8249548 fix and after current fix. >> >> Before fix for JDK-8249548 >> JToggleButton: >> For all L&Fs, user can not navigate/select the buttons added to ButtonGroup properly as mentioned in the JDK-8249548. >> JRadioButton: >> For Synth L&F (Nimbus L&F), user can not navigate/select the buttons added to ButtonGroup. >> For AquaL&F, user can select the buttons added to ButtonGroup by pressing left/right key and needs to press the "space" to perform the set Action. >> For Other L&Fs, user can select/navigate the buttons and the set Action is also performed without pressing "space" >> >> After fix for JDK-8249548 >> JToggleButton: >> For all L&Fs, user can navigate/select the buttons added to ButtonGroups and the AbstractAction set is performed without the need to press "space". >> JRadioButton: >> For all L&Fs, user can navigate/select the buttons added to ButtonGroups and the AbstractAction set is performed without the need to press "space". >> >> After current fix: >> JToggleButton: >> For all L&Fs, user can navigate/select the buttons added to ButtonGroups. User needs to press "space" to perform the set AbstractAction. >> JRadioButton: >> For AquaL&F, the behaviour before JDK-8249548 is restored, so user needs to press the "space" to perform the set Action. >> For all other L&Fs (including Synth L&F), the behaviour is same. User can navigate/select the buttons added to ButtonGroups and set Action is performed without pressing "space" >> >> I have run mach5 jobs with full jtreg/jck and all looks good. Links in JBS. The test TestButtonGroupFocusTraversal.java is modified such that it fails without current fix and passes after the fix. The fix also should be verified by running SwingSet2. > > src/java.desktop/macosx/classes/com/apple/laf/AquaButtonUI.java line 228: > >> 226: if (listener != null) { >> 227: b.removeMouseListener(listener); >> 228: b.removeMouseListener(listener); > > Why are we removing same listener twice? I just rolled back the changes I did in this file in JDK-8249548. Looks like this was has been there for some time. See the file in commit made in this file before JDK-8249548 https://github.com/openjdk/jdk/blob/c18080fef714949221c8ddabc4e23d409575c3d3/src/java.desktop/macosx/classes/com/apple/laf/AquaButtonUI.java. But yes, it should not be done and I will remove it and update the PR. ------------- PR: https://git.openjdk.java.net/jdk16/pull/99 From pbansal at openjdk.java.net Mon Jan 11 09:52:18 2021 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Mon, 11 Jan 2021 09:52:18 GMT Subject: [jdk16] RFR: 8259237: Demo selection changes with left/right arrow key. No need to press space for selection. [v2] In-Reply-To: References: Message-ID: > Please review a fix for jdk16 > > Issue: In SwingSet2, if the user navigates through the demos, the demo gets selected/starts on pressing left/right key only. There is no need to press the "space" key. Earlier, on pressing the left/right key, only demo icon used to get focused and user needed to press the "space" to actually select a demo. > > Cause: The SwingSet2 has JToggleButtons added to a ButtonGroup. Each JToggleButton has an AbstractAction set on it, which loads the demo. Earlier, when the user pressed Left/Right button, only the selected button used to change. The Action set on JToggleButton used to perform only on pressing the "Space" button. Now, the Action is performed on navigating the JToggleButtons using Left/Right keys without the need to press the "space" key. > > This issue is a side effect of fix done for https://bugs.openjdk.java.net/browse/JDK-8249548. The issues fixed in JDK-8249548 were not present in JRadioButton as there was code available to handle it in AquaButtonRadioUI and BasicRadioButtonUI. The fix done for JDK-8249548 moved duplicate code from AquaButtonRadioUI and BasicRadioButtonUI and moved it to BasicButtonUI, so this code is available for JToggleButton and JRadioButton for all L&Fs. This was wrong as there is a difference in behaviour for JRadioButtons added to ButtonGroup for AquaL&F and other L&Fs. In AquaL&F, the AbstractAction set on JRadioButton is not performed on button selection and user has to press "space". In other L&Fs, the AbstractAction is performed on selection of Button itself without the need to press "space". > > Fix: The current change fixes the issue in present bug and keeps the fixes done in JDK-8249548. Following is the behaviour of JToggleButton and JRadioButton for different L&Fs before JDK-8249548 fix, after JDK-8249548 fix and after current fix. > > Before fix for JDK-8249548 > JToggleButton: > For all L&Fs, user can not navigate/select the buttons added to ButtonGroup properly as mentioned in the JDK-8249548. > JRadioButton: > For Synth L&F (Nimbus L&F), user can not navigate/select the buttons added to ButtonGroup. > For AquaL&F, user can select the buttons added to ButtonGroup by pressing left/right key and needs to press the "space" to perform the set Action. > For Other L&Fs, user can select/navigate the buttons and the set Action is also performed without pressing "space" > > After fix for JDK-8249548 > JToggleButton: > For all L&Fs, user can navigate/select the buttons added to ButtonGroups and the AbstractAction set is performed without the need to press "space". > JRadioButton: > For all L&Fs, user can navigate/select the buttons added to ButtonGroups and the AbstractAction set is performed without the need to press "space". > > After current fix: > JToggleButton: > For all L&Fs, user can navigate/select the buttons added to ButtonGroups. User needs to press "space" to perform the set AbstractAction. > JRadioButton: > For AquaL&F, the behaviour before JDK-8249548 is restored, so user needs to press the "space" to perform the set Action. > For all other L&Fs (including Synth L&F), the behaviour is same. User can navigate/select the buttons added to ButtonGroups and set Action is performed without pressing "space" > > I have run mach5 jobs with full jtreg/jck and all looks good. Links in JBS. The test TestButtonGroupFocusTraversal.java is modified such that it fails without current fix and passes after the fix. The fix also should be verified by running SwingSet2. Pankaj Bansal has updated the pull request incrementally with one additional commit since the last revision: Remove duplicate call to remove listener ------------- Changes: - all: https://git.openjdk.java.net/jdk16/pull/99/files - new: https://git.openjdk.java.net/jdk16/pull/99/files/903ffcbd..724f5999 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk16&pr=99&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk16&pr=99&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk16/pull/99.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/99/head:pull/99 PR: https://git.openjdk.java.net/jdk16/pull/99 From kizune at openjdk.java.net Mon Jan 11 11:19:04 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Mon, 11 Jan 2021 11:19:04 GMT Subject: [jdk16] RFR: 8259237: Demo selection changes with left/right arrow key. No need to press space for selection. [v2] In-Reply-To: References: Message-ID: On Mon, 11 Jan 2021 08:20:39 GMT, Prasanta Sadhukhan wrote: >> Pankaj Bansal has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove duplicate call to remove listener > > I guess you did not run jtreg job with latest problemlist as it did not run > javax/swing/JRadioButton/ButtonGroupFocus/ButtonGroupFocusTest.java > javax/swing/JRadioButton/8075609/bug8075609.java > javax/swing/JRadioButton/8033699/bug8033699.java > Please see this test pass with your change as some of them used to fail after JDK-8226892 which was reworked by fix of JDK-8249548 Quick question: why we special casing JRadioButton case? Is there any reason we should call the action on them? ------------- PR: https://git.openjdk.java.net/jdk16/pull/99 From pbansal at openjdk.java.net Mon Jan 11 12:01:04 2021 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Mon, 11 Jan 2021 12:01:04 GMT Subject: [jdk16] RFR: 8259237: Demo selection changes with left/right arrow key. No need to press space for selection. [v2] In-Reply-To: References: Message-ID: On Mon, 11 Jan 2021 11:16:02 GMT, Alexander Zuev wrote: > Quick question: why we special casing JRadioButton case? Is there any reason we should call the action on them? This was the behaviour which was there before JDK-8249548 for JRadioButton and I am just reverting to it. As explained in the PR description, the behaviour before JDK-8249548 was as below Before fix for JDK-8249548 JToggleButton: For all L&Fs, user can not navigate/select the buttons added to ButtonGroup properly as mentioned in the JDK-8249548. JRadioButton: For Synth L&F (Nimbus L&F), user can not navigate/select the buttons added to ButtonGroup. For AquaL&F, user can select the buttons added to ButtonGroup by pressing left/right key and needs to press the "space" to perform the set Action. For Other L&Fs, user can select/navigate the buttons and the set Action is also performed without pressing "space" ------------- PR: https://git.openjdk.java.net/jdk16/pull/99 From aivanov at openjdk.java.net Mon Jan 11 17:22:05 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Mon, 11 Jan 2021 17:22:05 GMT Subject: RFR: 7194219: java/awt/Component/UpdatingBootTime/UpdatingBootTime.html fails on Linux [v2] In-Reply-To: References: <1puLRaS3bbjpiliy6h0OD3EDboP3pkFlfMUj7wrXfjw=.77372c28-e6a0-49a5-bfe3-863858f47392@github.com> Message-ID: On Thu, 7 Jan 2021 03:40:29 GMT, Sergey Bylokhov wrote: >> The test checks that the timestamp of the mouse event accurately represents the current time of the system, even if the time of the system is jumped to the past/future. >> >> On Unix in xawt we calculate the timstamp using this method: >> reset_time_utc = System.currentTimeMillis() - getCurrentServerTime(); >> timstamp = reset_time_utc + server_offset; >> >> (1.) Note that the "server_offset" - timstamp when the native event was generated, and we try to convert it to the UTC timestamp. Unfortunatly we callculate the "reset_time_utc" only once at the start of the application and then rarely update it. So if the time in the system is changed we still use the old one. >> >> The exactly the same bug described at (1.) was fixed on windows by the https://bugs.openjdk.java.net/browse/JDK-6461933 and for that bug the test in question was created. That bug was fixed by the "recalculation" system time more often. But it does not solve the general time issue and the code was reworked again by the https://bugs.openjdk.java.net/browse/JDK-8046495 >> >> I would like to fix the current bug in the same was as on windows, see link below: >> https://bugs.openjdk.java.net/browse/JDK-8046495?focusedCommentId=13517205&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-13517205 >> >> After the fix we will use the same System.currentTimeMillis()/JVM_CurrentTimeMillis on all platforms. > > 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-7194219 > - Initial fix Marked as reviewed by aivanov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/925 From darcy at openjdk.java.net Mon Jan 11 17:52:03 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 11 Jan 2021 17:52:03 GMT Subject: RFR: 8259439: Apply java.io.Serial annotations in java.datatransfer In-Reply-To: References: Message-ID: On Fri, 8 Jan 2021 04:51:50 GMT, Sergey Bylokhov wrote: > Please review the application of `@java.io.Serial` annotation (JDK-8202385) to types in the datatransfer module to enable stricter compile-time checking of serialization-related declarations. > > This annotation can be applied to these methods in the module: > * private void writeObject(java.io.ObjectOutputStream stream) throws IOException > * private void readObject(java.io.ObjectInputStream stream) throws IOException, ClassNotFoundException > * private void readObjectNoData() throws ObjectStreamException > * ANY-ACCESS-MODIFIER Object writeReplace() throws ObjectStreamException > * ANY-ACCESS-MODIFIER Object readResolve() throws ObjectStreamException > * private static final ObjectStreamField[] serialPersistentFields > * private static final long serialVersionUID > > But only the `serialVersionUID` is updated since only this field is used in the datatransfer module. > > A similar fix was implemented for java.base module as well: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-August/062046.html Looks fine. ------------- Marked as reviewed by darcy (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1996 From prr at openjdk.java.net Mon Jan 11 17:52:19 2021 From: prr at openjdk.java.net (Phil Race) Date: Mon, 11 Jan 2021 17:52:19 GMT Subject: RFR: 8259343: [macOS] Update JNI error handling in Cocoa code. [v2] In-Reply-To: References: Message-ID: <5fPXj8SlcJcjfD9bwylmTZ7bR7Gia8CIDUFADlpcPAU=.6c25ea7c-89b8-4e70-8269-1cdb1bedb8d3@github.com> > Proposed updates to JNI error handling. Phil Race has updated the pull request incrementally with one additional commit since the last revision: 8259343: [macOS] Update JNI error handling in Cocoa code. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1967/files - new: https://git.openjdk.java.net/jdk/pull/1967/files/0e745aa6..08a41150 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1967&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1967&range=00-01 Stats: 3 lines in 1 file changed: 1 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1967.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1967/head:pull/1967 PR: https://git.openjdk.java.net/jdk/pull/1967 From prr at openjdk.java.net Mon Jan 11 17:52:19 2021 From: prr at openjdk.java.net (Phil Race) Date: Mon, 11 Jan 2021 17:52:19 GMT Subject: RFR: 8259343: [macOS] Update JNI error handling in Cocoa code. [v2] In-Reply-To: References: Message-ID: <1-5L0YWqNPmuzpu1O1Q1chv5l1dGr55oEdQj4r9wyRg=.1addab94-3655-417d-8e03-1a621164502a@github.com> On Mon, 11 Jan 2021 05:52:02 GMT, Sergey Bylokhov wrote: > Not sure that the check for ExceptionOccurred is needed, It may not be needed in practice but if the code path is never taken no harm ... in all other places where we check the ref to methods/field we only check the return value, and if it is null then return immediately assuming that an exception is rased already, for example : > > https://github.com/openjdk/jdk/blob/b72de3c5fc99f365e9fb25114ddd28eceddfa6e8/src/java.desktop/windows/native/libawt/windows/awt_Button.cpp#L357 > > Note that the exception in the static initializer is fatal for the application. Nothing new here. ------------- PR: https://git.openjdk.java.net/jdk/pull/1967 From prr at openjdk.java.net Mon Jan 11 17:52:20 2021 From: prr at openjdk.java.net (Phil Race) Date: Mon, 11 Jan 2021 17:52:20 GMT Subject: RFR: 8259343: [macOS] Update JNI error handling in Cocoa code. [v2] In-Reply-To: <7RahvO2lHhxOAhcIdk2_pqtsbqdelLHRSXeAin2ZnQY=.0aaa2356-c382-46e7-83be-99ec143ee8ff@github.com> References: <7RahvO2lHhxOAhcIdk2_pqtsbqdelLHRSXeAin2ZnQY=.0aaa2356-c382-46e7-83be-99ec143ee8ff@github.com> Message-ID: On Mon, 11 Jan 2021 05:58:28 GMT, Sergey Bylokhov wrote: >> src/java.desktop/macosx/native/libosxapp/JNIUtilities.h line 46: >> >>> 44: if ((*env)->ExceptionOccurred(env) != NULL) { \ >>> 45: (*env)->ExceptionDescribe(env); \ >>> 46: } \ >> >> So the update here is that if we are not on the appkit thread, make sure a java exception is thrown. >> If we are on the appkit thread, clear any java exception since it isn't going anywhere but do it using >> describe which prints it. > > I read the logic of the method differently, probably the wrong indents? > - If we are not on the toolkit thread then > - Check ExceptionOccurred -> throw JNU_ThrowInternalError if needed or check exception again ->call ExceptionDescribe > - NSException raise at the end. I have a paren in the wrong place ! I've pushed an update. ------------- PR: https://git.openjdk.java.net/jdk/pull/1967 From prr at openjdk.java.net Mon Jan 11 17:52:20 2021 From: prr at openjdk.java.net (Phil Race) Date: Mon, 11 Jan 2021 17:52:20 GMT Subject: RFR: 8259343: [macOS] Update JNI error handling in Cocoa code. [v2] In-Reply-To: References: <2MhWS44-i0zX8lt6BUh_dpOxsEQdYnifCB8dcqO_25E=.319e2c92-6bf1-40fa-86a6-5d9df8c6c27e@github.com> Message-ID: <3jqvTyJ_wKIDMURTmYQSbTCwUMcVRRvzvVekjS9Eem0=.866999d7-3542-4f3f-9e93-d6955b05a657@github.com> On Mon, 11 Jan 2021 06:01:36 GMT, Sergey Bylokhov wrote: >> I hadn't noticed that line - and definintely not realised it was recent. >> I suppose he must have had a way to trigger it. >> But I don't think it hurts to have both. > > I just tried to understand why we need to complicate this, to me, it is unclear why handling the same errors in the NSApplicationAWT.m does not work. Because of the reason I've said before. That logging in NSApplication AWT is not being seen. Something is swallowing it. So I'd say if anything remove that logging and keep the new one but as I also said it isn't harmful to have provision in case it also logs some case we aren't catching. ------------- PR: https://git.openjdk.java.net/jdk/pull/1967 From erikj at openjdk.java.net Mon Jan 11 18:59:03 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 11 Jan 2021 18:59:03 GMT Subject: RFR: 8259343: [macOS] Update JNI error handling in Cocoa code. [v2] In-Reply-To: <5fPXj8SlcJcjfD9bwylmTZ7bR7Gia8CIDUFADlpcPAU=.6c25ea7c-89b8-4e70-8269-1cdb1bedb8d3@github.com> References: <5fPXj8SlcJcjfD9bwylmTZ7bR7Gia8CIDUFADlpcPAU=.6c25ea7c-89b8-4e70-8269-1cdb1bedb8d3@github.com> Message-ID: On Mon, 11 Jan 2021 17:52:19 GMT, Phil Race wrote: >> Proposed updates to JNI error handling. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8259343: [macOS] Update JNI error handling in Cocoa code. make/modules/java.desktop/Lib.gmk line 96: > 94: $(call SET_SHARED_LIBRARY_ORIGIN), \ > 95: LIBS := \ > 96: -ljava \ There should be a dependency declaration added too. Something like this right after the SetupJdkLibrary macro call: $(BUILD_LIBOSXAPP): $(call FindLib, java.base, java) ------------- PR: https://git.openjdk.java.net/jdk/pull/1967 From prr at openjdk.java.net Mon Jan 11 19:27:12 2021 From: prr at openjdk.java.net (Phil Race) Date: Mon, 11 Jan 2021 19:27:12 GMT Subject: RFR: 8259343: [macOS] Update JNI error handling in Cocoa code. [v3] In-Reply-To: References: Message-ID: > Proposed updates to JNI error handling. Phil Race has updated the pull request incrementally with one additional commit since the last revision: 8259343: [macOS] Update JNI error handling in Cocoa code. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1967/files - new: https://git.openjdk.java.net/jdk/pull/1967/files/08a41150..913b37c2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1967&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1967&range=01-02 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1967.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1967/head:pull/1967 PR: https://git.openjdk.java.net/jdk/pull/1967 From prr at openjdk.java.net Mon Jan 11 19:27:12 2021 From: prr at openjdk.java.net (Phil Race) Date: Mon, 11 Jan 2021 19:27:12 GMT Subject: RFR: 8259343: [macOS] Update JNI error handling in Cocoa code. [v2] In-Reply-To: References: <5fPXj8SlcJcjfD9bwylmTZ7bR7Gia8CIDUFADlpcPAU=.6c25ea7c-89b8-4e70-8269-1cdb1bedb8d3@github.com> Message-ID: On Mon, 11 Jan 2021 18:56:38 GMT, Erik Joelsson wrote: > There should be a dependency declaration added too. Something like this right after the SetupJdkLibrary macro call: > > $(BUILD_LIBOSXAPP): $(call FindLib, java.base, java) Fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/1967 From erikj at openjdk.java.net Mon Jan 11 20:22:58 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 11 Jan 2021 20:22:58 GMT Subject: RFR: 8259343: [macOS] Update JNI error handling in Cocoa code. [v3] In-Reply-To: References: Message-ID: <9q6B-ZySWhc8qPfcn728cCehk_SSer-qtIhCJdI3sXg=.dce6e806-9858-481b-96a7-f27ed7d2bdb3@github.com> On Mon, 11 Jan 2021 19:27:12 GMT, Phil Race wrote: >> Proposed updates to JNI error handling. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8259343: [macOS] Update JNI error handling in Cocoa code. Build changes look good. ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1967 From kizune at openjdk.java.net Mon Jan 11 20:52:06 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Mon, 11 Jan 2021 20:52:06 GMT Subject: RFR: 8259585: Accessible actions do not work on mac os x Message-ID: 8259585: Accessible actions do not work on mac os x ------------- Commit messages: - 8259585: Accessible actions do not work on mac os x - Merge pull request #7 from openjdk/master - Merge pull request #6 from openjdk/master - Merge pull request #5 from openjdk/master - Merge pull request #4 from openjdk/master - Merge pull request #3 from openjdk/master - Merge pull request #2 from openjdk/master - Merge pull request #1 from openjdk/master Changes: https://git.openjdk.java.net/jdk/pull/2038/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2038&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259585 Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/2038.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2038/head:pull/2038 PR: https://git.openjdk.java.net/jdk/pull/2038 From avoitylov at openjdk.java.net Mon Jan 11 22:01:58 2021 From: avoitylov at openjdk.java.net (Aleksei Voitylov) Date: Mon, 11 Jan 2021 22:01:58 GMT Subject: RFR: 8252015: [macos11] java.awt.TrayIcon requires updates for template images [v2] In-Reply-To: References: Message-ID: <1XSYfXSB-8s1DjR4SIWnrj9NGkSKJLKa7BZ5Ecov0J8=.a9dfae37-1f81-4467-a89d-9bdb697c9fec@github.com> On Sun, 3 Jan 2021 08:48:26 GMT, Sergey Bylokhov wrote: >> Peter Zhelezniakov has updated the pull request incrementally with two additional commits since the last revision: >> >> - 8252015: fixed failing tests; renamed system property >> - 8252015: Added property description to TrayIcon javadoc > > Marked as reviewed by serb (Reviewer). @mrserb thank you for the review of the issue. Could you review the associated JDK-8255597 CSR as well? ------------- PR: https://git.openjdk.java.net/jdk/pull/481 From serb at openjdk.java.net Mon Jan 11 23:17:57 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Mon, 11 Jan 2021 23:17:57 GMT Subject: Integrated: 8259439: Apply java.io.Serial annotations in java.datatransfer In-Reply-To: References: Message-ID: On Fri, 8 Jan 2021 04:51:50 GMT, Sergey Bylokhov wrote: > Please review the application of `@java.io.Serial` annotation (JDK-8202385) to types in the datatransfer module to enable stricter compile-time checking of serialization-related declarations. > > This annotation can be applied to these methods in the module: > * private void writeObject(java.io.ObjectOutputStream stream) throws IOException > * private void readObject(java.io.ObjectInputStream stream) throws IOException, ClassNotFoundException > * private void readObjectNoData() throws ObjectStreamException > * ANY-ACCESS-MODIFIER Object writeReplace() throws ObjectStreamException > * ANY-ACCESS-MODIFIER Object readResolve() throws ObjectStreamException > * private static final ObjectStreamField[] serialPersistentFields > * private static final long serialVersionUID > > But only the `serialVersionUID` is updated since only this field is used in the datatransfer module. > > A similar fix was implemented for java.base module as well: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-August/062046.html This pull request has now been integrated. Changeset: ff54b77b Author: Sergey Bylokhov URL: https://git.openjdk.java.net/jdk/commit/ff54b77b Stats: 31 lines in 5 files changed: 19 ins; 0 del; 12 mod 8259439: Apply java.io.Serial annotations in java.datatransfer Reviewed-by: aivanov, pbansal, trebari, darcy ------------- PR: https://git.openjdk.java.net/jdk/pull/1996 From serb at openjdk.java.net Tue Jan 12 00:25:03 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Tue, 12 Jan 2021 00:25:03 GMT Subject: RFR: 8259585: Accessible actions do not work on mac os x In-Reply-To: References: Message-ID: On Mon, 11 Jan 2021 20:46:48 GMT, Alexander Zuev wrote: > 8259585: Accessible actions do not work on mac os x Marked as reviewed by serb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2038 From kizune at openjdk.java.net Tue Jan 12 00:32:00 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Tue, 12 Jan 2021 00:32:00 GMT Subject: Integrated: 8259585: Accessible actions do not work on mac os x In-Reply-To: References: Message-ID: On Mon, 11 Jan 2021 20:46:48 GMT, Alexander Zuev wrote: > 8259585: Accessible actions do not work on mac os x This pull request has now been integrated. Changeset: b6d51e15 Author: Alexander Zuev URL: https://git.openjdk.java.net/jdk/commit/b6d51e15 Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod 8259585: Accessible actions do not work on mac os x Reviewed-by: serb ------------- PR: https://git.openjdk.java.net/jdk/pull/2038 From serb at openjdk.java.net Tue Jan 12 02:34:58 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Tue, 12 Jan 2021 02:34:58 GMT Subject: RFR: 8259343: [macOS] Update JNI error handling in Cocoa code. [v3] In-Reply-To: References: Message-ID: On Mon, 11 Jan 2021 19:27:12 GMT, Phil Race wrote: >> Proposed updates to JNI error handling. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8259343: [macOS] Update JNI error handling in Cocoa code. src/java.desktop/macosx/native/libosxapp/JNIUtilities.h line 197: > 195: } \ > 196: if (getenv("JNU_NO_COCOA_EXCEPTION") == NULL) { \ > 197: [NSException raise:NSGenericException format:@"Java Exception"]; \ How did you check that the logging in the NSApplication was swallowing? Both macro will throw the NSException on the toolkit thread now, does it mean that in both cases the logging in the NSApplication will be ignored/no output? ------------- PR: https://git.openjdk.java.net/jdk/pull/1967 From serb at openjdk.java.net Tue Jan 12 02:41:00 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Tue, 12 Jan 2021 02:41:00 GMT Subject: RFR: 8259343: [macOS] Update JNI error handling in Cocoa code. [v3] In-Reply-To: <1-5L0YWqNPmuzpu1O1Q1chv5l1dGr55oEdQj4r9wyRg=.1addab94-3655-417d-8e03-1a621164502a@github.com> References: <1-5L0YWqNPmuzpu1O1Q1chv5l1dGr55oEdQj4r9wyRg=.1addab94-3655-417d-8e03-1a621164502a@github.com> Message-ID: On Mon, 11 Jan 2021 17:09:14 GMT, Phil Race wrote: >> src/java.desktop/macosx/native/libosxapp/JNIUtilities.h line 41: >> >>> 39: NSLog(@"%@",[NSThread callStackSymbols]); \ >>> 40: if ([NSThread isMainThread] == NO) { \ >>> 41: if ((*env)->ExceptionOccurred(env) == NULL) { \ >> >> Not sure that the check for ExceptionOccurred is needed, in all other places where we check the ref to methods/field we only check the return value, and if it is null then return immediately assuming that an exception is rased already, for example : >> https://github.com/openjdk/jdk/blob/b72de3c5fc99f365e9fb25114ddd28eceddfa6e8/src/java.desktop/windows/native/libawt/windows/awt_Button.cpp#L357 >> >> Note that the exception in the static initializer is fatal for the application. > >> Not sure that the check for ExceptionOccurred is needed, > It may not be needed in practice but if the code path is never taken no harm ... > > in all other places where we check the ref to methods/field we only check the return value, and if it is null then return immediately assuming that an exception is rased already, for example : >> >> https://github.com/openjdk/jdk/blob/b72de3c5fc99f365e9fb25114ddd28eceddfa6e8/src/java.desktop/windows/native/libawt/windows/awt_Button.cpp#L357 >> >> Note that the exception in the static initializer is fatal for the application. > > Nothing new here. The new thing here is that you check the result of the ExceptionOccurred if NULL is returned from the GetMethodID/etc, we usually never do it. If such checks are necessary then I'll create a separate bug to update other similar use cases. ------------- PR: https://git.openjdk.java.net/jdk/pull/1967 From kizune at openjdk.java.net Tue Jan 12 05:45:10 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Tue, 12 Jan 2021 05:45:10 GMT Subject: RFR: 8256109: Create implementation for NSAccessibilityButton protocol [v3] In-Reply-To: References: Message-ID: > Creating a native peer for pushbutton accessibility role on Max OS X. > The process of choosing of what peer to initialize is clunky so > might be addressed in the future. Alexander Zuev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: - Merge branch 'master' into JDK-8256109 - Merge branch 'openjdk-master' into master - Merge branch 'master' of https://github.com/openjdk/jdk into openjdk-master - Merge pull request #7 from openjdk/master Merge - Merge pull request #6 from openjdk/master Merge - Moved the new components implementations to the separate files. Changed the iitialization procedure to a class function with dictionary of role to class name relation. This pr is still intermittent since it uses the old style JNF java call syntacsis. Once fix for JDK-8257853 is integrated the calls needs to be converted to the new style but that is a minor change. - JDK-8256109: Create implementation for NSAccessibilityButton protocol Initial implementation. In future the accessibilityLabel function might be moved to a common component accessibility level if during implementation i will not find any corner cases when this function should behave radically different. - Merge pull request #5 from openjdk/master Merge - Merge pull request #4 from openjdk/master Merge - Merge pull request #3 from openjdk/master Merge - ... and 2 more: https://git.openjdk.java.net/jdk/compare/77f62909...d9d6f754 ------------- Changes: https://git.openjdk.java.net/jdk/pull/1549/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1549&range=02 Stats: 211 lines in 4 files changed: 211 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1549.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1549/head:pull/1549 PR: https://git.openjdk.java.net/jdk/pull/1549 From kizune at openjdk.java.net Tue Jan 12 05:58:22 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Tue, 12 Jan 2021 05:58:22 GMT Subject: RFR: 8256109: Create implementation for NSAccessibilityButton protocol [v4] In-Reply-To: References: Message-ID: > Creating a native peer for pushbutton accessibility role on Max OS X. > The process of choosing of what peer to initialize is clunky so > might be addressed in the future. Alexander Zuev has updated the pull request incrementally with two additional commits since the last revision: - Fixed year in .h files - Update code to use new style JNI ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1549/files - new: https://git.openjdk.java.net/jdk/pull/1549/files/d9d6f754..38d54d04 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1549&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1549&range=02-03 Stats: 95 lines in 5 files changed: 26 ins; 47 del; 22 mod Patch: https://git.openjdk.java.net/jdk/pull/1549.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1549/head:pull/1549 PR: https://git.openjdk.java.net/jdk/pull/1549 From kizune at openjdk.java.net Tue Jan 12 06:08:10 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Tue, 12 Jan 2021 06:08:10 GMT Subject: RFR: 8256109: Create implementation for NSAccessibilityButton protocol [v5] In-Reply-To: References: Message-ID: > Creating a native peer for pushbutton accessibility role on Max OS X. > The process of choosing of what peer to initialize is clunky so > might be addressed in the future. Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: Replaced #include with #import for consistency ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1549/files - new: https://git.openjdk.java.net/jdk/pull/1549/files/38d54d04..22fe7535 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1549&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1549&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1549.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1549/head:pull/1549 PR: https://git.openjdk.java.net/jdk/pull/1549 From kizune at openjdk.java.net Tue Jan 12 06:08:11 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Tue, 12 Jan 2021 06:08:11 GMT Subject: RFR: 8256109: Create implementation for NSAccessibilityButton protocol [v2] In-Reply-To: References: Message-ID: On Fri, 18 Dec 2020 00:19:59 GMT, Sergey Bylokhov wrote: >> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: >> >> Moved the new components implementations to the separate files. >> Changed the iitialization procedure to a class function with >> dictionary of role to class name relation. >> >> This pr is still intermittent since it uses the old style >> JNF java call syntacsis. Once fix for JDK-8257853 is integrated >> the calls needs to be converted to the new style but that is a minor >> change. > > src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ButtonAccessibility.m line 26: > >> 24: */ >> 25: >> 26: #include "ButtonAccessibility.h" > > I guess we should be consistent in the usage of import vs include. You are not wrong. Fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/1549 From kizune at openjdk.java.net Tue Jan 12 06:08:12 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Tue, 12 Jan 2021 06:08:12 GMT Subject: RFR: 8256109: Create implementation for NSAccessibilityButton protocol [v2] In-Reply-To: References: Message-ID: <4hh_0Cb2OCzihLw6M1u3yGFTaDgJzDLeCIzfLqmTL6E=.24bee0fa-43d8-46d5-9b45-ccdf9d6485bd@github.com> On Thu, 17 Dec 2020 08:18:26 GMT, Pankaj Bansal wrote: >> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: >> >> Moved the new components implementations to the separate files. >> Changed the iitialization procedure to a class function with >> dictionary of role to class name relation. >> >> This pr is still intermittent since it uses the old style >> JNF java call syntacsis. Once fix for JDK-8257853 is integrated >> the calls needs to be converted to the new style but that is a minor >> change. > > src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ButtonAccessibility.h line 25: > >> 23: * questions. >> 24: */ >> 25: > > There are no header guard here. Is it left intentionally? Yes, since the CommonComponentAccessibility being imported from the base class sometimes it causes compilation glitches - guess ObjC is not a big fan of forward-declaration. Adding header guard helps. And since i'm not planning to include sub-component header files in the base classes the ifdef guard is not required. ------------- PR: https://git.openjdk.java.net/jdk/pull/1549 From serb at openjdk.java.net Tue Jan 12 06:57:57 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Tue, 12 Jan 2021 06:57:57 GMT Subject: Integrated: 7194219: java/awt/Component/UpdatingBootTime/UpdatingBootTime.html fails on Linux In-Reply-To: <1puLRaS3bbjpiliy6h0OD3EDboP3pkFlfMUj7wrXfjw=.77372c28-e6a0-49a5-bfe3-863858f47392@github.com> References: <1puLRaS3bbjpiliy6h0OD3EDboP3pkFlfMUj7wrXfjw=.77372c28-e6a0-49a5-bfe3-863858f47392@github.com> Message-ID: <4KQVkG-r4MOZXhTOhwOYWBdyHv22kC-METfm5lLDyiw=.ff573518-6406-432b-8018-dade15316387@github.com> On Thu, 29 Oct 2020 08:41:04 GMT, Sergey Bylokhov wrote: > The test checks that the timestamp of the mouse event accurately represents the current time of the system, even if the time of the system is jumped to the past/future. > > On Unix in xawt we calculate the timstamp using this method: > reset_time_utc = System.currentTimeMillis() - getCurrentServerTime(); > timstamp = reset_time_utc + server_offset; > > (1.) Note that the "server_offset" - timstamp when the native event was generated, and we try to convert it to the UTC timestamp. Unfortunatly we callculate the "reset_time_utc" only once at the start of the application and then rarely update it. So if the time in the system is changed we still use the old one. > > The exactly the same bug described at (1.) was fixed on windows by the https://bugs.openjdk.java.net/browse/JDK-6461933 and for that bug the test in question was created. That bug was fixed by the "recalculation" system time more often. But it does not solve the general time issue and the code was reworked again by the https://bugs.openjdk.java.net/browse/JDK-8046495 > > I would like to fix the current bug in the same was as on windows, see link below: > https://bugs.openjdk.java.net/browse/JDK-8046495?focusedCommentId=13517205&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-13517205 > > After the fix we will use the same System.currentTimeMillis()/JVM_CurrentTimeMillis on all platforms. This pull request has now been integrated. Changeset: 61c5b95b Author: Sergey Bylokhov URL: https://git.openjdk.java.net/jdk/commit/61c5b95b Stats: 45 lines in 5 files changed: 0 ins; 38 del; 7 mod 7194219: java/awt/Component/UpdatingBootTime/UpdatingBootTime.html fails on Linux Reviewed-by: aivanov ------------- PR: https://git.openjdk.java.net/jdk/pull/925 From kizune at openjdk.java.net Tue Jan 12 07:21:08 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Tue, 12 Jan 2021 07:21:08 GMT Subject: RFR: 8256109: Create implementation for NSAccessibilityButton protocol [v2] In-Reply-To: <7xPXbUZEdBRbS6NitTQZU27jMlJ7ReltbKPRe-50_B4=.41ab5bd9-1084-41b9-8c10-1beb0dd7ed4f@github.com> References: <7xPXbUZEdBRbS6NitTQZU27jMlJ7ReltbKPRe-50_B4=.41ab5bd9-1084-41b9-8c10-1beb0dd7ed4f@github.com> Message-ID: On Thu, 17 Dec 2020 07:50:08 GMT, Pankaj Bansal wrote: >> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: >> >> Moved the new components implementations to the separate files. >> Changed the iitialization procedure to a class function with >> dictionary of role to class name relation. >> >> This pr is still intermittent since it uses the old style >> JNF java call syntacsis. Once fix for JDK-8257853 is integrated >> the calls needs to be converted to the new style but that is a minor >> change. > > src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CommonComponentAccessibility.h line 41: > >> 39: @end >> 40: >> 41: #endif > > I see a warning for missing newline at end of this file. For some reason all .h files are marked with this warning. Not sure why - there are no new line after the last statements in other .h files in the project. ------------- PR: https://git.openjdk.java.net/jdk/pull/1549 From peterz at openjdk.java.net Tue Jan 12 11:53:00 2021 From: peterz at openjdk.java.net (Peter Zhelezniakov) Date: Tue, 12 Jan 2021 11:53:00 GMT Subject: Integrated: 8252015: [macos11] java.awt.TrayIcon requires updates for template images In-Reply-To: References: Message-ID: On Fri, 2 Oct 2020 11:08:23 GMT, Peter Zhelezniakov wrote: > [JDK-8252015: [macos11] java.awt.TrayIcon requires updates for template images](https://bugs.openjdk.java.net/browse/JDK-8252015) > > ### Problem > According to Apple's human interface guidelines, developers should use template images for tray icons. This way icons look good when desktop theme or wallpaper change. On the API level, this means setting the `NSImage::isTemplate` flag. Currently there's no way in Java to set this flag. Even if one uses a template (black and transparent pixels only) image, MacOS will treat it as regular image. As a result, the image will not be visible when using dark theme. > > ### Solution: > * Add a new system property, `java.awt.enableTemplateImages`, to indicate that template images are being used by tray icons.When this property is set, all tray icon images are treated as templates. It's the developers' responsibility to ensure their images are indeed templates. This property allows us to avoid new API and accidental behavior changes > * Value of this property is passed from Java into `NSImage::setTemplate` > * We need the tray icon image rendered by MacOS, so we use a button (rather than a view) to host the image > > To do after CSR approval: > - [ ] Rename property `java.awt.` > - [ ] Add `TrayIcon` javadoc, use `@systemProperty` tag there This pull request has now been integrated. Changeset: 400dc76f Author: Peter Zhelezniakov Committer: Alexander Scherbatiy URL: https://git.openjdk.java.net/jdk/commit/400dc76f Stats: 56 lines in 4 files changed: 17 ins; 28 del; 11 mod 8252015: [macos11] java.awt.TrayIcon requires updates for template images Co-authored-by: Tres Finocchiaro Co-authored-by: Peter Zhelezniakov Reviewed-by: serb ------------- PR: https://git.openjdk.java.net/jdk/pull/481 From prr at openjdk.java.net Tue Jan 12 17:28:58 2021 From: prr at openjdk.java.net (Phil Race) Date: Tue, 12 Jan 2021 17:28:58 GMT Subject: RFR: 8259343: [macOS] Update JNI error handling in Cocoa code. [v3] In-Reply-To: References: <1-5L0YWqNPmuzpu1O1Q1chv5l1dGr55oEdQj4r9wyRg=.1addab94-3655-417d-8e03-1a621164502a@github.com> Message-ID: On Tue, 12 Jan 2021 02:38:11 GMT, Sergey Bylokhov wrote: >>> Not sure that the check for ExceptionOccurred is needed, >> It may not be needed in practice but if the code path is never taken no harm ... >> >> in all other places where we check the ref to methods/field we only check the return value, and if it is null then return immediately assuming that an exception is rased already, for example : >>> >>> https://github.com/openjdk/jdk/blob/b72de3c5fc99f365e9fb25114ddd28eceddfa6e8/src/java.desktop/windows/native/libawt/windows/awt_Button.cpp#L357 >>> >>> Note that the exception in the static initializer is fatal for the application. >> >> Nothing new here. > > The new thing here is that you check the result of the ExceptionOccurred if NULL is returned from the GetMethodID/etc, we usually never do it. If such checks are necessary then I'll create a separate bug to update other similar use cases. Here I don't have immediate control over why this is being called. So we could have null but no pending exception depending on what the caller did. It won't be executed except in the rare case there's a problem so it certainly isn't causing overhead so what is the problem ? I don't see a need to change other code unless there's a really good reason. ------------- PR: https://git.openjdk.java.net/jdk/pull/1967 From prr at openjdk.java.net Tue Jan 12 17:24:57 2021 From: prr at openjdk.java.net (Phil Race) Date: Tue, 12 Jan 2021 17:24:57 GMT Subject: RFR: 8259343: [macOS] Update JNI error handling in Cocoa code. [v3] In-Reply-To: References: Message-ID: On Tue, 12 Jan 2021 02:31:56 GMT, Sergey Bylokhov wrote: >> Phil Race has updated the pull request incrementally with one additional commit since the last revision: >> >> 8259343: [macOS] Update JNI error handling in Cocoa code. > > src/java.desktop/macosx/native/libosxapp/JNIUtilities.h line 197: > >> 195: } \ >> 196: if (getenv("JNU_NO_COCOA_EXCEPTION") == NULL) { \ >> 197: [NSException raise:NSGenericException format:@"Java Exception"]; \ > > How did you check that the logging in the NSApplication was swallowing? Both macro will throw the NSException on the toolkit thread now, does it mean that in both cases the logging in the NSApplication will be ignored/no output? See the bug assigned to you that I filed last month : https://bugs.openjdk.java.net/browse/JDK-8258797 This error should have been logged by that NSApplicationAWT code but was not (and I mean in JDK 16 as well before I started on this) and in JDK 17 it was seen only when adding the new logging. ------------- PR: https://git.openjdk.java.net/jdk/pull/1967 From serb at openjdk.java.net Tue Jan 12 20:06:59 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Tue, 12 Jan 2021 20:06:59 GMT Subject: RFR: 8259343: [macOS] Update JNI error handling in Cocoa code. [v3] In-Reply-To: References: Message-ID: On Tue, 12 Jan 2021 17:21:53 GMT, Phil Race wrote: >> src/java.desktop/macosx/native/libosxapp/JNIUtilities.h line 197: >> >>> 195: } \ >>> 196: if (getenv("JNU_NO_COCOA_EXCEPTION") == NULL) { \ >>> 197: [NSException raise:NSGenericException format:@"Java Exception"]; \ >> >> How did you check that the logging in the NSApplication was swallowing? Both macro will throw the NSException on the toolkit thread now, does it mean that in both cases the logging in the NSApplication will be ignored/no output? > > See the bug assigned to you that I filed last month : https://bugs.openjdk.java.net/browse/JDK-8258797 > This error should have been logged by that NSApplicationAWT code but was not (and I mean in JDK 16 as well before I started on this) and in JDK 17 it was seen only when adding the new logging. I have found it down to the absence of NSApplication#reportException() method and logging in it. Ok will update that code later in the separate update. ------------- PR: https://git.openjdk.java.net/jdk/pull/1967 From serb at openjdk.java.net Tue Jan 12 20:06:57 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Tue, 12 Jan 2021 20:06:57 GMT Subject: RFR: 8259343: [macOS] Update JNI error handling in Cocoa code. [v3] In-Reply-To: References: Message-ID: <9L-Z-lva8-afVWdri9YjO0wIM0nQ6H7IUOcruvNUToY=.33f942e9-23cb-43e7-a07d-b1fe64df4974@github.com> On Mon, 11 Jan 2021 19:27:12 GMT, Phil Race wrote: >> Proposed updates to JNI error handling. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8259343: [macOS] Update JNI error handling in Cocoa code. Marked as reviewed by serb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1967 From prr at openjdk.java.net Tue Jan 12 20:22:57 2021 From: prr at openjdk.java.net (Phil Race) Date: Tue, 12 Jan 2021 20:22:57 GMT Subject: Integrated: 8259343: [macOS] Update JNI error handling in Cocoa code. In-Reply-To: References: Message-ID: On Wed, 6 Jan 2021 21:14:06 GMT, Phil Race wrote: > Proposed updates to JNI error handling. This pull request has now been integrated. Changeset: d6a2105b Author: Phil Race URL: https://git.openjdk.java.net/jdk/commit/d6a2105b Stats: 75 lines in 8 files changed: 60 ins; 1 del; 14 mod 8259343: [macOS] Update JNI error handling in Cocoa code. Reviewed-by: erikj, serb ------------- PR: https://git.openjdk.java.net/jdk/pull/1967 From aivanov at openjdk.java.net Tue Jan 12 20:25:56 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Tue, 12 Jan 2021 20:25:56 GMT Subject: RFR: 8259522: Apply java.io.Serial annotations in java.desktop In-Reply-To: References: Message-ID: On Mon, 11 Jan 2021 06:21:52 GMT, Sergey Bylokhov wrote: > Please review the application of @java.io.Serial annotation (JDK-8202385) to types in the desktop module to enable stricter compile-time checking of serialization-related declarations. > > This annotation can be applied to these methods in the module: > > private void writeObject(java.io.ObjectOutputStream stream) throws IOException > private void readObject(java.io.ObjectInputStream stream) throws IOException, ClassNotFoundException > private void readObjectNoData() throws ObjectStreamException > ANY-ACCESS-MODIFIER Object writeReplace() throws ObjectStreamException > ANY-ACCESS-MODIFIER Object readResolve() throws ObjectStreamException > private static final ObjectStreamField[] serialPersistentFields > private static final long serialVersionUID > > Notes: > - I have tried to update the comments for serialVersionUID as accurately as possible, but mostly based on the source code history and bugs in JBS where that field was added > - Some of the readObject/writeObject methods in the javax.swing package does not have a spec, because this package and some others are excluded from the serialization specification. > > A similar fix was implemented for java.base module as well: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-August/062046.html Marked as reviewed by aivanov (Reviewer). src/java.desktop/share/classes/com/sun/media/sound/InvalidDataException.java line 42: > 40: */ > 41: @Serial > 42: private static final long serialVersionUID = 1L; This is the standard wording, yet should it mention the serialization is between the same versions only because the value of serialVersionUID is not unique? src/java.desktop/share/classes/java/awt/image/RasterFormatException.java line 28: > 26: package java.awt.image; > 27: > 28: Suggestion: In the majority of classes, there's only one empty line between package declaration and the first import statement. src/java.desktop/share/classes/java/awt/image/ImagingOpException.java line 28: > 26: package java.awt.image; > 27: > 28: Suggestion: ------------- PR: https://git.openjdk.java.net/jdk/pull/2020 From aivanov at openjdk.java.net Tue Jan 12 20:35:55 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Tue, 12 Jan 2021 20:35:55 GMT Subject: RFR: 8259519: The java.awt.datatransfer.DataFlavor#ioInputStreamClass field is redundant In-Reply-To: References: Message-ID: On Sun, 10 Jan 2021 03:57:42 GMT, Sergey Bylokhov wrote: > A long time ago in the pre-1.0 era, this field was initialized via reflection since the "InputStream" class was optional. This was changed since then and a separate field to refer the "InputStream.class" is not needed. Marked as reviewed by aivanov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2016 From serb at openjdk.java.net Tue Jan 12 20:42:18 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Tue, 12 Jan 2021 20:42:18 GMT Subject: RFR: 8259522: Apply java.io.Serial annotations in java.desktop [v2] In-Reply-To: References: Message-ID: <7X46pwNuTDGbEN3-jFa2QY2qUtMCK2dAu-BiPdoMK14=.19bc926b-62ba-4f79-8f32-be27898077a8@github.com> > Please review the application of @java.io.Serial annotation (JDK-8202385) to types in the desktop module to enable stricter compile-time checking of serialization-related declarations. > > This annotation can be applied to these methods in the module: > > private void writeObject(java.io.ObjectOutputStream stream) throws IOException > private void readObject(java.io.ObjectInputStream stream) throws IOException, ClassNotFoundException > private void readObjectNoData() throws ObjectStreamException > ANY-ACCESS-MODIFIER Object writeReplace() throws ObjectStreamException > ANY-ACCESS-MODIFIER Object readResolve() throws ObjectStreamException > private static final ObjectStreamField[] serialPersistentFields > private static final long serialVersionUID > > Notes: > - I have tried to update the comments for serialVersionUID as accurately as possible, but mostly based on the source code history and bugs in JBS where that field was added > - Some of the readObject/writeObject methods in the javax.swing package does not have a spec, because this package and some others are excluded from the serialization specification. > > A similar fix was implemented for java.base module as well: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-August/062046.html Sergey Bylokhov has updated the pull request incrementally with two additional commits since the last revision: - Update src/java.desktop/share/classes/java/awt/image/ImagingOpException.java Co-authored-by: Aleksei Ivanov <70774172+aivanov-jdk at users.noreply.github.com> - Update src/java.desktop/share/classes/java/awt/image/RasterFormatException.java Co-authored-by: Aleksei Ivanov <70774172+aivanov-jdk at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2020/files - new: https://git.openjdk.java.net/jdk/pull/2020/files/2e50a258..502c1a40 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2020&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2020&range=00-01 Stats: 4 lines in 2 files changed: 0 ins; 4 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2020.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2020/head:pull/2020 PR: https://git.openjdk.java.net/jdk/pull/2020 From serb at openjdk.java.net Tue Jan 12 20:42:19 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Tue, 12 Jan 2021 20:42:19 GMT Subject: RFR: 8259522: Apply java.io.Serial annotations in java.desktop [v2] In-Reply-To: References: Message-ID: On Tue, 12 Jan 2021 11:29:24 GMT, Alexey Ivanov wrote: >> Sergey Bylokhov has updated the pull request incrementally with two additional commits since the last revision: >> >> - Update src/java.desktop/share/classes/java/awt/image/ImagingOpException.java >> >> Co-authored-by: Aleksei Ivanov <70774172+aivanov-jdk at users.noreply.github.com> >> - Update src/java.desktop/share/classes/java/awt/image/RasterFormatException.java >> >> Co-authored-by: Aleksei Ivanov <70774172+aivanov-jdk at users.noreply.github.com> > > src/java.desktop/share/classes/com/sun/media/sound/InvalidDataException.java line 42: > >> 40: */ >> 41: @Serial >> 42: private static final long serialVersionUID = 1L; > > This is the standard wording, yet should it mention the serialization is between the same versions only because the value of serialVersionUID is not unique? I think it is "quite" unique, the "1L" is used from the beginning. It is just different from the value which could be generated by the "serialver" but still should work fine. ------------- PR: https://git.openjdk.java.net/jdk/pull/2020 From aivanov at openjdk.java.net Tue Jan 12 21:58:14 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Tue, 12 Jan 2021 21:58:14 GMT Subject: RFR: 8259522: Apply java.io.Serial annotations in java.desktop [v2] In-Reply-To: References: Message-ID: On Tue, 12 Jan 2021 20:36:21 GMT, Sergey Bylokhov wrote: >> src/java.desktop/share/classes/com/sun/media/sound/InvalidDataException.java line 42: >> >>> 40: */ >>> 41: @Serial >>> 42: private static final long serialVersionUID = 1L; >> >> This is the standard wording, yet should it mention the serialization is between the same versions only because the value of serialVersionUID is not unique? > > I think it is "quite" unique, the "1L" is used from the beginning. It is just different from the value which could be generated by the "serialver" but still should work fine. Okay. There are several classes which extend this one, all of them use the same 1L value which makes it not "quite" unique. Changing the values at this time presents more risks than benefits. ------------- PR: https://git.openjdk.java.net/jdk/pull/2020 From omikhaltcova at openjdk.java.net Wed Jan 13 00:20:57 2021 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Wed, 13 Jan 2021 00:20:57 GMT Subject: RFR: 8257414: Drag n Drop target area is wrong on high DPI systems In-Reply-To: References: Message-ID: On Mon, 4 Jan 2021 08:39:10 GMT, Sergey Bylokhov wrote: >> Please, review this small fix for drag-n-drop on Linux with HiDPI turned on! >> >> This bug is due to the following reason: while scaling Java recalculates resolution (W x H) according to sun.java2d.uiScale (W/SCALE x H/SCALE) and works inside these new coordinates but at the same time the events, that come from the system, continue reporting positions in the old coordinates (W x H). >> >> The idea of the suggested fix is in division of coordinates on the scale when they come from the system to Java and multiplying them on the scale when they go back from Java to the system. It is similar to processing events from mouse and buttons. >> >> Testing is quite complicated because for reproducing this bug the following conditions should be met: >> 1. HiDPI is turned on >> 2. sun.java2d.uiScale.enabled = true and sun.java2d.uiScale != 100% >> 3. the source of drag-n-drop is non-java application >> >> The step-by-step guide how to reproduce this bug is added to https://bugs.openjdk.java.net/browse/JDK-8257414. > > src/java.desktop/unix/classes/sun/awt/X11/XDnDDropTargetProtocol.java line 616: > >> 614: /* Translate mouse position from root coordinates >> 615: to the target window coordinates. */ >> 616: Point p = xwindow.toLocal(xwindow.scaleDown(x), xwindow.scaleDown(y)); > > I guess some clarification here is required. It is unclear what the coordinate system is used by the x/y above. Looks like before the fix the device space was always used, and after the fix the mix of device/user's space will be used. > If the user's space should always be used(the scaled version of the device), then I suggest to scale these coordinates here: > x = (int)(xclient.get_data(2) >> 16); > y = (int)(xclient.get_data(2) & 0xFFFF); > But you will need to check that all usage of the new coordinate system will be valid across the method. Sergey, thank you! Could you give me a hint please concerning some use case of drag-and-drop to meet the (xwindow == 0) condition in XDnDDropTargetProtocol::processXdndPosition(..)? I'm unable to do it by means of the tests' apps I have. ------------- PR: https://git.openjdk.java.net/jdk/pull/1907 From prr at openjdk.java.net Wed Jan 13 01:35:07 2021 From: prr at openjdk.java.net (Phil Race) Date: Wed, 13 Jan 2021 01:35:07 GMT Subject: RFR: 8259651: [macOS] Replace JNF_COCOA_ENTER/EXIT macros Message-ID: Most of the changes here are simply JNF_COCOA_ENTER -> JNI_COCOA_ENTER JNF_COCOA_EXIT -> JNI_COCOA_EXIT These new macros are defined in JNIUtilities.h and handle the auto release and on exit catch any NSException. Unlike the JNF code, JNI exceptions don't have to be extracted from the NSException. So calls to JNFException are also removed and in most cases they are just directly using one of the JNU_* defined exceptions since we are in a native nethod and can return control directly to Java. JNIUtilities has just two macros for cases where we need to accompany it with an NSException because we aren't in the immediate body of a JNI method. JNIUtilities also has a macro JNI_COCOA_EXIT_WITH_ACTION This is used by a macro in QuartzSurfaceData.m to re-implement a pre-existing macro JNF_COCOA_RENDERER_EXIT as JNI_COCOA_RENDERER_EXIT. This is used in a few places to ensure that we call FinishSurface on the Quartz surface. This already passed all our automated tests, although I'm re-running since I needed to merge to the current repo state. ------------- Commit messages: - 8259651: [macOS] Replace JNF_COCOA_ENTER/EXIT macros - 8259651: [macOS] Replace JNF_COCOA_ENTER/EXIT macros Changes: https://git.openjdk.java.net/jdk/pull/2056/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2056&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259651 Stats: 602 lines in 48 files changed: 58 ins; 17 del; 527 mod Patch: https://git.openjdk.java.net/jdk/pull/2056.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2056/head:pull/2056 PR: https://git.openjdk.java.net/jdk/pull/2056 From serb at openjdk.java.net Wed Jan 13 02:17:56 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Wed, 13 Jan 2021 02:17:56 GMT Subject: RFR: 8259651: [macOS] Replace JNF_COCOA_ENTER/EXIT macros In-Reply-To: References: Message-ID: On Tue, 12 Jan 2021 21:39:02 GMT, Phil Race wrote: > Most of the changes here are simply > JNF_COCOA_ENTER -> JNI_COCOA_ENTER > JNF_COCOA_EXIT -> JNI_COCOA_EXIT > > These new macros are defined in JNIUtilities.h and handle the auto release and on exit catch any NSException. > Unlike the JNF code, JNI exceptions don't have to be extracted from the NSException. > > So calls to JNFException are also removed and in most cases they are just directly using one of the JNU_* > defined exceptions since we are in a native nethod and can return control directly to Java. > > JNIUtilities has just two macros for cases where we need to accompany it with an NSException because > we aren't in the immediate body of a JNI method. > > JNIUtilities also has a macro JNI_COCOA_EXIT_WITH_ACTION > This is used by a macro in QuartzSurfaceData.m to re-implement a pre-existing macro > JNF_COCOA_RENDERER_EXIT as JNI_COCOA_RENDERER_EXIT. > This is used in a few places to ensure that we call FinishSurface on the Quartz surface. > > This already passed all our automated tests, although I'm re-running since I needed to merge to the > current repo state. src/java.desktop/macosx/native/libosxapp/JNIUtilities.h line 245: > 243: > 244: #define JNI_COCOA_THROW_RUNTIME_EXCEPTION(env, msg) \ > 245: JNU_ThrowByName(env, "java/lang/RuntimeException", msg); \ Can we guarantee that before the next java code executed later we clean this exception? BTW I still think the exceptions wrapping will be a better thing. If it will be caught by our catch block like in JNI_COCOA_EXIT we can unwrap it, otherwise, the java code could be executed safely since we clear an exception during wrapping. ------------- PR: https://git.openjdk.java.net/jdk/pull/2056 From serb at openjdk.java.net Wed Jan 13 02:33:57 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Wed, 13 Jan 2021 02:33:57 GMT Subject: Integrated: 8259519: The java.awt.datatransfer.DataFlavor#ioInputStreamClass field is redundant In-Reply-To: References: Message-ID: On Sun, 10 Jan 2021 03:57:42 GMT, Sergey Bylokhov wrote: > A long time ago in the pre-1.0 era, this field was initialized via reflection since the "InputStream" class was optional. This was changed since then and a separate field to refer the "InputStream.class" is not needed. This pull request has now been integrated. Changeset: 0957d9eb Author: Sergey Bylokhov URL: https://git.openjdk.java.net/jdk/commit/0957d9eb Stats: 53 lines in 2 files changed: 50 ins; 1 del; 2 mod 8259519: The java.awt.datatransfer.DataFlavor#ioInputStreamClass field is redundant Reviewed-by: aivanov ------------- PR: https://git.openjdk.java.net/jdk/pull/2016 From prr at openjdk.java.net Wed Jan 13 02:36:58 2021 From: prr at openjdk.java.net (Phil Race) Date: Wed, 13 Jan 2021 02:36:58 GMT Subject: RFR: 8259651: [macOS] Replace JNF_COCOA_ENTER/EXIT macros In-Reply-To: References: Message-ID: On Wed, 13 Jan 2021 02:15:22 GMT, Sergey Bylokhov wrote: >> Most of the changes here are simply >> JNF_COCOA_ENTER -> JNI_COCOA_ENTER >> JNF_COCOA_EXIT -> JNI_COCOA_EXIT >> >> These new macros are defined in JNIUtilities.h and handle the auto release and on exit catch any NSException. >> Unlike the JNF code, JNI exceptions don't have to be extracted from the NSException. >> >> So calls to JNFException are also removed and in most cases they are just directly using one of the JNU_* >> defined exceptions since we are in a native nethod and can return control directly to Java. >> >> JNIUtilities has just two macros for cases where we need to accompany it with an NSException because >> we aren't in the immediate body of a JNI method. >> >> JNIUtilities also has a macro JNI_COCOA_EXIT_WITH_ACTION >> This is used by a macro in QuartzSurfaceData.m to re-implement a pre-existing macro >> JNF_COCOA_RENDERER_EXIT as JNI_COCOA_RENDERER_EXIT. >> This is used in a few places to ensure that we call FinishSurface on the Quartz surface. >> >> This already passed all our automated tests, although I'm re-running since I needed to merge to the >> current repo state. > > src/java.desktop/macosx/native/libosxapp/JNIUtilities.h line 245: > >> 243: >> 244: #define JNI_COCOA_THROW_RUNTIME_EXCEPTION(env, msg) \ >> 245: JNU_ThrowByName(env, "java/lang/RuntimeException", msg); \ > > Can we guarantee that before the next java code executed later we clean this exception? > > BTW I still think the exceptions wrapping will be a better thing. If it will be caught by our catch block like in JNI_COCOA_EXIT we can unwrap it, otherwise, the java code could be executed safely since we clear an exception during wrapping. Since the next line throws NSException everything before this change and after this change should cause control to reach the COCOA_EXIT macro. I am not aware of anything in between. So this should be OK. The previous JNF code (as I discussed in some earlier review / thread) seems to be *internally* responsible for not doing things properly as I had found that its exception handling code actually made calls that aren't allowed with the exception pending. And this should not happen any more. ------------- PR: https://git.openjdk.java.net/jdk/pull/2056 From serb at openjdk.java.net Wed Jan 13 03:04:57 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Wed, 13 Jan 2021 03:04:57 GMT Subject: RFR: 8256109: Create implementation for NSAccessibilityButton protocol [v2] In-Reply-To: <4hh_0Cb2OCzihLw6M1u3yGFTaDgJzDLeCIzfLqmTL6E=.24bee0fa-43d8-46d5-9b45-ccdf9d6485bd@github.com> References: <4hh_0Cb2OCzihLw6M1u3yGFTaDgJzDLeCIzfLqmTL6E=.24bee0fa-43d8-46d5-9b45-ccdf9d6485bd@github.com> Message-ID: On Tue, 12 Jan 2021 06:04:32 GMT, Alexander Zuev wrote: >> src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ButtonAccessibility.h line 25: >> >>> 23: * questions. >>> 24: */ >>> 25: >> >> There are no header guard here. Is it left intentionally? > > Yes, since the CommonComponentAccessibility being imported from the base class sometimes it causes compilation glitches - guess ObjC is not a big fan of forward-declaration. Adding header guard helps. And since i'm not planning to include sub-component header files in the base classes the ifdef guard is not required. The headers in the obj-c usually do not have guards because they are included via "#import" ------------- PR: https://git.openjdk.java.net/jdk/pull/1549 From kizune at openjdk.java.net Wed Jan 13 06:06:02 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Wed, 13 Jan 2021 06:06:02 GMT Subject: RFR: 8256109: Create implementation for NSAccessibilityButton protocol [v2] In-Reply-To: References: <4hh_0Cb2OCzihLw6M1u3yGFTaDgJzDLeCIzfLqmTL6E=.24bee0fa-43d8-46d5-9b45-ccdf9d6485bd@github.com> Message-ID: On Wed, 13 Jan 2021 03:02:04 GMT, Sergey Bylokhov wrote: >> Yes, since the CommonComponentAccessibility being imported from the base class sometimes it causes compilation glitches - guess ObjC is not a big fan of forward-declaration. Adding header guard helps. And since i'm not planning to include sub-component header files in the base classes the ifdef guard is not required. > > The headers in the obj-c usually do not have guards because they are included via "#import" I know. But in this case that was not enough - that still caused weird compilation glitches like full compilation works but incremental calculation gives compilation error about usage of non-initialized variables. Guards helped. ------------- PR: https://git.openjdk.java.net/jdk/pull/1549 From psadhukhan at openjdk.java.net Wed Jan 13 06:13:57 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Wed, 13 Jan 2021 06:13:57 GMT Subject: RFR: 8259522: Apply java.io.Serial annotations in java.desktop [v2] In-Reply-To: <7X46pwNuTDGbEN3-jFa2QY2qUtMCK2dAu-BiPdoMK14=.19bc926b-62ba-4f79-8f32-be27898077a8@github.com> References: <7X46pwNuTDGbEN3-jFa2QY2qUtMCK2dAu-BiPdoMK14=.19bc926b-62ba-4f79-8f32-be27898077a8@github.com> Message-ID: <0BeCSRlVfit-78buTvO8-tci6rZDhwsML4JXKzujLM8=.ff5ba622-5c99-4925-b690-5b348d0d0e18@github.com> On Tue, 12 Jan 2021 20:42:18 GMT, Sergey Bylokhov wrote: >> Please review the application of @java.io.Serial annotation (JDK-8202385) to types in the desktop module to enable stricter compile-time checking of serialization-related declarations. >> >> This annotation can be applied to these methods in the module: >> >> private void writeObject(java.io.ObjectOutputStream stream) throws IOException >> private void readObject(java.io.ObjectInputStream stream) throws IOException, ClassNotFoundException >> private void readObjectNoData() throws ObjectStreamException >> ANY-ACCESS-MODIFIER Object writeReplace() throws ObjectStreamException >> ANY-ACCESS-MODIFIER Object readResolve() throws ObjectStreamException >> private static final ObjectStreamField[] serialPersistentFields >> private static final long serialVersionUID >> >> Notes: >> - I have tried to update the comments for serialVersionUID as accurately as possible, but mostly based on the source code history and bugs in JBS where that field was added >> - Some of the readObject/writeObject methods in the javax.swing package does not have a spec, because this package and some others are excluded from the serialization specification. >> >> A similar fix was implemented for java.base module as well: >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-August/062046.html > > Sergey Bylokhov has updated the pull request incrementally with two additional commits since the last revision: > > - Update src/java.desktop/share/classes/java/awt/image/ImagingOpException.java > > Co-authored-by: Aleksei Ivanov <70774172+aivanov-jdk at users.noreply.github.com> > - Update src/java.desktop/share/classes/java/awt/image/RasterFormatException.java > > Co-authored-by: Aleksei Ivanov <70774172+aivanov-jdk at users.noreply.github.com> Why do we add serialVersionUID in some classes like DefaultMutableTreeNode.java but not in other swing classes? Also, if this change is for stricter compile-time checking, shouldn't we remove @SuppressWarnings("serial") check? ------------- PR: https://git.openjdk.java.net/jdk/pull/2020 From serb at openjdk.java.net Wed Jan 13 06:35:57 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Wed, 13 Jan 2021 06:35:57 GMT Subject: RFR: 8256109: Create implementation for NSAccessibilityButton protocol [v2] In-Reply-To: References: <4hh_0Cb2OCzihLw6M1u3yGFTaDgJzDLeCIzfLqmTL6E=.24bee0fa-43d8-46d5-9b45-ccdf9d6485bd@github.com> Message-ID: On Wed, 13 Jan 2021 06:03:09 GMT, Alexander Zuev wrote: >> The headers in the obj-c usually do not have guards because they are included via "#import" > > I know. But in this case that was not enough - that still caused weird compilation glitches like full compilation works but incremental calculation gives compilation error about usage of non-initialized variables. Guards helped. I missed where the guards have helped, there are no guards in this file. Same question about why did you add guards to the "CommonComponentAccessibility.h"? ------------- PR: https://git.openjdk.java.net/jdk/pull/1549 From serb at openjdk.java.net Wed Jan 13 06:40:57 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Wed, 13 Jan 2021 06:40:57 GMT Subject: RFR: 8259651: [macOS] Replace JNF_COCOA_ENTER/EXIT macros In-Reply-To: References: Message-ID: On Wed, 13 Jan 2021 02:34:37 GMT, Phil Race wrote: > Since the next line throws NSException everything before this change and after this change should cause control to reach the COCOA_EXIT macro. It does not, the JNI_COCOA_EXIT macro is executed on a different thread than JNI_COCOA_THROW_RUNTIME_EXCEPTION (in both times where this macro is used) ------------- PR: https://git.openjdk.java.net/jdk/pull/2056 From serb at openjdk.java.net Wed Jan 13 07:07:54 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Wed, 13 Jan 2021 07:07:54 GMT Subject: RFR: 8259522: Apply java.io.Serial annotations in java.desktop [v2] In-Reply-To: <0BeCSRlVfit-78buTvO8-tci6rZDhwsML4JXKzujLM8=.ff5ba622-5c99-4925-b690-5b348d0d0e18@github.com> References: <7X46pwNuTDGbEN3-jFa2QY2qUtMCK2dAu-BiPdoMK14=.19bc926b-62ba-4f79-8f32-be27898077a8@github.com> <0BeCSRlVfit-78buTvO8-tci6rZDhwsML4JXKzujLM8=.ff5ba622-5c99-4925-b690-5b348d0d0e18@github.com> Message-ID: On Wed, 13 Jan 2021 06:10:53 GMT, Prasanta Sadhukhan wrote: > Why do we add serialVersionUID in some classes like DefaultMutableTreeNode.java but not in other swing classes? Most Swing classes are marked by the specific "Warning" that "Same-version serialization only" is supported. (I think such a warning is missed in a few classes). So generally the serialVersionUID field is not needed in such classes, but if present this provides a small benefit -> this UID is not generated at runtime. For example, the DefaultMutableTreeNode was updated by the JDK-5017904 fix, which was unrelated to serialization but was targeted for the performance issue. > Also, if this change is for stricter compile-time checking, shouldn't we remove @SuppressWarnings("serial") check? At some point, we probably can remove it but will need to fix all serialization warnings which were disabled. ------------- PR: https://git.openjdk.java.net/jdk/pull/2020 From psadhukhan at openjdk.java.net Wed Jan 13 07:34:56 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Wed, 13 Jan 2021 07:34:56 GMT Subject: RFR: 8259522: Apply java.io.Serial annotations in java.desktop [v2] In-Reply-To: <7X46pwNuTDGbEN3-jFa2QY2qUtMCK2dAu-BiPdoMK14=.19bc926b-62ba-4f79-8f32-be27898077a8@github.com> References: <7X46pwNuTDGbEN3-jFa2QY2qUtMCK2dAu-BiPdoMK14=.19bc926b-62ba-4f79-8f32-be27898077a8@github.com> Message-ID: On Tue, 12 Jan 2021 20:42:18 GMT, Sergey Bylokhov wrote: >> Please review the application of @java.io.Serial annotation (JDK-8202385) to types in the desktop module to enable stricter compile-time checking of serialization-related declarations. >> >> This annotation can be applied to these methods in the module: >> >> private void writeObject(java.io.ObjectOutputStream stream) throws IOException >> private void readObject(java.io.ObjectInputStream stream) throws IOException, ClassNotFoundException >> private void readObjectNoData() throws ObjectStreamException >> ANY-ACCESS-MODIFIER Object writeReplace() throws ObjectStreamException >> ANY-ACCESS-MODIFIER Object readResolve() throws ObjectStreamException >> private static final ObjectStreamField[] serialPersistentFields >> private static final long serialVersionUID >> >> Notes: >> - I have tried to update the comments for serialVersionUID as accurately as possible, but mostly based on the source code history and bugs in JBS where that field was added >> - Some of the readObject/writeObject methods in the javax.swing package does not have a spec, because this package and some others are excluded from the serialization specification. >> >> A similar fix was implemented for java.base module as well: >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-August/062046.html > > Sergey Bylokhov has updated the pull request incrementally with two additional commits since the last revision: > > - Update src/java.desktop/share/classes/java/awt/image/ImagingOpException.java > > Co-authored-by: Aleksei Ivanov <70774172+aivanov-jdk at users.noreply.github.com> > - Update src/java.desktop/share/classes/java/awt/image/RasterFormatException.java > > Co-authored-by: Aleksei Ivanov <70774172+aivanov-jdk at users.noreply.github.com> Marked as reviewed by psadhukhan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2020 From kizune at openjdk.java.net Wed Jan 13 08:08:57 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Wed, 13 Jan 2021 08:08:57 GMT Subject: RFR: 8256109: Create implementation for NSAccessibilityButton protocol [v2] In-Reply-To: References: <4hh_0Cb2OCzihLw6M1u3yGFTaDgJzDLeCIzfLqmTL6E=.24bee0fa-43d8-46d5-9b45-ccdf9d6485bd@github.com> Message-ID: On Wed, 13 Jan 2021 06:33:19 GMT, Sergey Bylokhov wrote: >> I know. But in this case that was not enough - that still caused weird compilation glitches like full compilation works but incremental calculation gives compilation error about usage of non-initialized variables. Guards helped. > > I missed where the guards have helped, there are no guards in this file. > Same question about why did you add guards to the "CommonComponentAccessibility.h"? I added guards into CommonComponentAccessibility.h because without them importing them into JavaComponentAccessibility from which CommonComponentAccessibility is inherited creates intermittent build failures. I used ifdef guards and the problem was gone so i kept them. I do not include any of the implementing classes headers down the inheritance three so i decided not to add guards there. ------------- PR: https://git.openjdk.java.net/jdk/pull/1549 From dcubed at openjdk.java.net Wed Jan 13 17:34:11 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 13 Jan 2021 17:34:11 GMT Subject: [jdk16] RFR: 8259720: ProblemList java/awt/Focus/AppletInitialFocusTest/AppletInitialFocusTest1.java on Windows Message-ID: <8KkQ2H3yzwK5bQuUb_6S3CDUIiLqvkepFwJOiZ345r0=.67bbc9a6-fa92-4423-9b49-bdf73e02b6eb@github.com> This is a trivial fix to ProblemList java/awt/Focus/AppletInitialFocusTest/AppletInitialFocusTest1.java on Windows in order to reduce the noise in the JDK16 CI. ------------- Commit messages: - 8259720: ProblemList java/awt/Focus/AppletInitialFocusTest/AppletInitialFocusTest1.java on Windows Changes: https://git.openjdk.java.net/jdk16/pull/117/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=117&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259720 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk16/pull/117.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/117/head:pull/117 PR: https://git.openjdk.java.net/jdk16/pull/117 From kizune at openjdk.java.net Wed Jan 13 18:00:08 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Wed, 13 Jan 2021 18:00:08 GMT Subject: [jdk16] RFR: 8259720: ProblemList java/awt/Focus/AppletInitialFocusTest/AppletInitialFocusTest1.java on Windows In-Reply-To: <8KkQ2H3yzwK5bQuUb_6S3CDUIiLqvkepFwJOiZ345r0=.67bbc9a6-fa92-4423-9b49-bdf73e02b6eb@github.com> References: <8KkQ2H3yzwK5bQuUb_6S3CDUIiLqvkepFwJOiZ345r0=.67bbc9a6-fa92-4423-9b49-bdf73e02b6eb@github.com> Message-ID: On Wed, 13 Jan 2021 17:29:09 GMT, Daniel D. Daugherty wrote: > This is a trivial fix to ProblemList java/awt/Focus/AppletInitialFocusTest/AppletInitialFocusTest1.java > on Windows in order to reduce the noise in the JDK16 CI. Marked as reviewed by kizune (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk16/pull/117 From dcubed at openjdk.java.net Wed Jan 13 18:15:09 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 13 Jan 2021 18:15:09 GMT Subject: [jdk16] RFR: 8259720: ProblemList java/awt/Focus/AppletInitialFocusTest/AppletInitialFocusTest1.java on Windows In-Reply-To: References: <8KkQ2H3yzwK5bQuUb_6S3CDUIiLqvkepFwJOiZ345r0=.67bbc9a6-fa92-4423-9b49-bdf73e02b6eb@github.com> Message-ID: On Wed, 13 Jan 2021 17:57:44 GMT, Alexander Zuev wrote: >> This is a trivial fix to ProblemList java/awt/Focus/AppletInitialFocusTest/AppletInitialFocusTest1.java >> on Windows in order to reduce the noise in the JDK16 CI. > > Marked as reviewed by kizune (Reviewer). @azuev-java - Thanks for the fast review! ------------- PR: https://git.openjdk.java.net/jdk16/pull/117 From pbansal at openjdk.java.net Wed Jan 13 18:21:03 2021 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Wed, 13 Jan 2021 18:21:03 GMT Subject: [jdk16] RFR: 8259720: ProblemList java/awt/Focus/AppletInitialFocusTest/AppletInitialFocusTest1.java on Windows In-Reply-To: <8KkQ2H3yzwK5bQuUb_6S3CDUIiLqvkepFwJOiZ345r0=.67bbc9a6-fa92-4423-9b49-bdf73e02b6eb@github.com> References: <8KkQ2H3yzwK5bQuUb_6S3CDUIiLqvkepFwJOiZ345r0=.67bbc9a6-fa92-4423-9b49-bdf73e02b6eb@github.com> Message-ID: On Wed, 13 Jan 2021 17:29:09 GMT, Daniel D. Daugherty wrote: > This is a trivial fix to ProblemList java/awt/Focus/AppletInitialFocusTest/AppletInitialFocusTest1.java > on Windows in order to reduce the noise in the JDK16 CI. Marked as reviewed by pbansal (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk16/pull/117 From dcubed at openjdk.java.net Wed Jan 13 18:27:07 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 13 Jan 2021 18:27:07 GMT Subject: [jdk16] Integrated: 8259720: ProblemList java/awt/Focus/AppletInitialFocusTest/AppletInitialFocusTest1.java on Windows In-Reply-To: <8KkQ2H3yzwK5bQuUb_6S3CDUIiLqvkepFwJOiZ345r0=.67bbc9a6-fa92-4423-9b49-bdf73e02b6eb@github.com> References: <8KkQ2H3yzwK5bQuUb_6S3CDUIiLqvkepFwJOiZ345r0=.67bbc9a6-fa92-4423-9b49-bdf73e02b6eb@github.com> Message-ID: <1iCekJV1mrLz8xNxLYBJ1goLz2ge2nDUBkD8ehK2DmA=.c9ad0430-2096-4964-8fd4-7d9a3b3bb311@github.com> On Wed, 13 Jan 2021 17:29:09 GMT, Daniel D. Daugherty wrote: > This is a trivial fix to ProblemList java/awt/Focus/AppletInitialFocusTest/AppletInitialFocusTest1.java > on Windows in order to reduce the noise in the JDK16 CI. This pull request has now been integrated. Changeset: 8abefdec Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk16/commit/8abefdec Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8259720: ProblemList java/awt/Focus/AppletInitialFocusTest/AppletInitialFocusTest1.java on Windows Reviewed-by: kizune, pbansal ------------- PR: https://git.openjdk.java.net/jdk16/pull/117 From prr at openjdk.java.net Wed Jan 13 20:41:09 2021 From: prr at openjdk.java.net (Phil Race) Date: Wed, 13 Jan 2021 20:41:09 GMT Subject: RFR: 8259729: Missed JNFInstanceOf -> IsInstanceOf conversion Message-ID: One line fix of a missed update ------------- Commit messages: - 8259729: Missed JNFInstanceOf -> IsInstanceOf conversion Changes: https://git.openjdk.java.net/jdk/pull/2066/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2066&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259729 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2066.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2066/head:pull/2066 PR: https://git.openjdk.java.net/jdk/pull/2066 From serb at openjdk.java.net Wed Jan 13 21:13:08 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Wed, 13 Jan 2021 21:13:08 GMT Subject: RFR: 8259729: Missed JNFInstanceOf -> IsInstanceOf conversion In-Reply-To: References: Message-ID: On Wed, 13 Jan 2021 20:35:55 GMT, Phil Race wrote: > One line fix of a missed update src/java.desktop/macosx/native/libawt_lwawt/awt/JavaComponentAccessibility.m line 1456: > 1454: > 1455: id value = nil; > 1456: if ((*env)->IsInstanceOf(env, jparent, jc_Container)) { Not sure, but do we need to check the jparent to NULL? "A NULL object can be cast to any class." ------------- PR: https://git.openjdk.java.net/jdk/pull/2066 From prr at openjdk.java.net Wed Jan 13 21:19:03 2021 From: prr at openjdk.java.net (Phil Race) Date: Wed, 13 Jan 2021 21:19:03 GMT Subject: RFR: 8259651: [macOS] Replace JNF_COCOA_ENTER/EXIT macros In-Reply-To: References: Message-ID: On Wed, 13 Jan 2021 06:38:13 GMT, Sergey Bylokhov wrote: >> Since the next line throws NSException everything before this change and after this change should cause control to reach the COCOA_EXIT macro. I am not aware of anything in between. So this should be OK. The previous JNF code (as I discussed in some earlier review / thread) seems to be *internally* responsible for not doing things properly as I had found that its exception handling code actually made calls that aren't allowed with the exception pending. And this should not happen any more. > >> Since the next line throws NSException everything before this change and after this change should cause control to reach the COCOA_EXIT macro. > > It does not, the JNI_COCOA_EXIT macro is executed on a different thread than JNI_COCOA_THROW_RUNTIME_EXCEPTION (in both times where this macro is used) You are correct. This is running in a performOnMainThreadWaiting:NO block. So the JNI call likely already returned to Java before that block gets run on the AppKit thread. But this seems to be the same as before and there was probably never any point to raising the JDK exception I think in this case maybe what I should is update the macro to skip throwing the Java Exception if it is being raised on the AppKit thread. No caller that I can see is expecting a RuntimeException for these failed actions so this seems to be very much an implementation decision. I am not even sure the code should be doing this. Rightly or wrongly GraphicsDevice.setFullScreenWindow(Window) declares no exceptions or possibility of failure. ------------- PR: https://git.openjdk.java.net/jdk/pull/2056 From prr at openjdk.java.net Wed Jan 13 21:28:03 2021 From: prr at openjdk.java.net (Phil Race) Date: Wed, 13 Jan 2021 21:28:03 GMT Subject: RFR: 8259729: Missed JNFInstanceOf -> IsInstanceOf conversion In-Reply-To: References: Message-ID: On Wed, 13 Jan 2021 21:10:46 GMT, Sergey Bylokhov wrote: >> One line fix of a missed update > > src/java.desktop/macosx/native/libawt_lwawt/awt/JavaComponentAccessibility.m line 1456: > >> 1454: >> 1455: id value = nil; >> 1456: if ((*env)->IsInstanceOf(env, jparent, jc_Container)) { > > Not sure, but do we need to check the jparent to NULL? "A NULL object can be cast to any class." Fair question but there was no NULL check there before so I assume it isn't expected to be NULL. I could add a NULL check but then we'd skip over the following code and maybe hide something that could be a problem. I don't mind either way. ------------- PR: https://git.openjdk.java.net/jdk/pull/2066 From serb at openjdk.java.net Wed Jan 13 21:33:04 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Wed, 13 Jan 2021 21:33:04 GMT Subject: RFR: 8259729: Missed JNFInstanceOf -> IsInstanceOf conversion In-Reply-To: References: Message-ID: On Wed, 13 Jan 2021 21:24:57 GMT, Phil Race wrote: >> src/java.desktop/macosx/native/libawt_lwawt/awt/JavaComponentAccessibility.m line 1456: >> >>> 1454: >>> 1455: id value = nil; >>> 1456: if ((*env)->IsInstanceOf(env, jparent, jc_Container)) { >> >> Not sure, but do we need to check the jparent to NULL? "A NULL object can be cast to any class." > > Fair question but there was no NULL check there before so I assume it isn't expected to be NULL. > I could add a NULL check but then we'd skip over the following code and maybe hide something that could be a problem. I don't mind either way. I do not know how exactly the JNFIsInstanceOf works for NULL parameters, will it return true or false? ------------- PR: https://git.openjdk.java.net/jdk/pull/2066 From prr at openjdk.java.net Wed Jan 13 22:04:03 2021 From: prr at openjdk.java.net (Phil Race) Date: Wed, 13 Jan 2021 22:04:03 GMT Subject: RFR: 8259729: Missed JNFInstanceOf -> IsInstanceOf conversion In-Reply-To: References: Message-ID: On Wed, 13 Jan 2021 21:30:24 GMT, Sergey Bylokhov wrote: >> Fair question but there was no NULL check there before so I assume it isn't expected to be NULL. >> I could add a NULL check but then we'd skip over the following code and maybe hide something that could be a problem. I don't mind either way. > > I do not know how exactly the JNFIsInstanceOf works for NULL parameters, will it return true or false? I just hacked a usage in A11Y in JDK 16 : printf("OBJ %d\n", JNFIsInstanceOf(env, NULL, &sjc_CAccessible)); it returns TRUE for NULL - same as JNI. ------------- PR: https://git.openjdk.java.net/jdk/pull/2066 From serb at openjdk.java.net Wed Jan 13 23:03:02 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Wed, 13 Jan 2021 23:03:02 GMT Subject: RFR: 8259729: Missed JNFInstanceOf -> IsInstanceOf conversion In-Reply-To: References: Message-ID: On Wed, 13 Jan 2021 20:35:55 GMT, Phil Race wrote: > One line fix of a missed update Marked as reviewed by serb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2066 From serb at openjdk.java.net Wed Jan 13 23:23:06 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Wed, 13 Jan 2021 23:23:06 GMT Subject: RFR: 8259651: [macOS] Replace JNF_COCOA_ENTER/EXIT macros In-Reply-To: References: Message-ID: On Wed, 13 Jan 2021 21:16:42 GMT, Phil Race wrote: >>> Since the next line throws NSException everything before this change and after this change should cause control to reach the COCOA_EXIT macro. >> >> It does not, the JNI_COCOA_EXIT macro is executed on a different thread than JNI_COCOA_THROW_RUNTIME_EXCEPTION (in both times where this macro is used) > > You are correct. This is running in a performOnMainThreadWaiting:NO block. > So the JNI call likely already returned to Java before that block gets run on the AppKit thread. > But this seems to be the same as before and there was probably never any point to raising the JDK exception > I think in this case maybe what I should is update the macro to skip throwing the Java Exception if > it is being raised on the AppKit thread. No caller that I can see is expecting a RuntimeException for these failed actions so this seems to be very much an implementation decision. I am not even sure the code should be doing this. Rightly or wrongly GraphicsDevice.setFullScreenWindow(Window) declares no exceptions or possibility of failure. It is always better to wrap the java exception and always clear after each callJavaMethod, so the next callJavaMethod will not be called when the java exception was raised. At the same time in the place where we catch the nsexception we can check does it have a java exception or not -> so we can unwrap and raise again the java exception just before return to the java code, or such exception in the NSApplication global catch block(including currently missing NSApplication#reportException). ------------- PR: https://git.openjdk.java.net/jdk/pull/2056 From prr at openjdk.java.net Thu Jan 14 00:18:02 2021 From: prr at openjdk.java.net (Phil Race) Date: Thu, 14 Jan 2021 00:18:02 GMT Subject: RFR: 8259651: [macOS] Replace JNF_COCOA_ENTER/EXIT macros In-Reply-To: References: Message-ID: On Wed, 13 Jan 2021 23:20:11 GMT, Sergey Bylokhov wrote: >> You are correct. This is running in a performOnMainThreadWaiting:NO block. >> So the JNI call likely already returned to Java before that block gets run on the AppKit thread. >> But this seems to be the same as before and there was probably never any point to raising the JDK exception >> I think in this case maybe what I should is update the macro to skip throwing the Java Exception if >> it is being raised on the AppKit thread. No caller that I can see is expecting a RuntimeException for these failed actions so this seems to be very much an implementation decision. I am not even sure the code should be doing this. Rightly or wrongly GraphicsDevice.setFullScreenWindow(Window) declares no exceptions or possibility of failure. > > It is always better to wrap the java exception and always clear after each callJavaMethod, so the next callJavaMethod will not be called when the java exception was raised. At the same time in the place where we catch the nsexception we can check does it have a java exception or not -> so we can unwrap and raise again the java exception just before return to the java code, or such exception in the NSApplication global catch block(including currently missing NSApplication#reportException). It is one way of doing it but it is much more heavyweight as it requires a carrier for the exception and so goes against the approach here which is to be very lightweight in the sense of avoiding creating classes - which so far as been the case. And there is no need to wrap it. If its there, it will be just be passed on up to Java without any work on our part. And as for clearing, that's what I was doing before and that made sense if the intention is to carry on. Since now we are always raising NSException there that next Java call shouldn't happen as we always should jump out. ------------- PR: https://git.openjdk.java.net/jdk/pull/2056 From serb at openjdk.java.net Thu Jan 14 00:21:05 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Thu, 14 Jan 2021 00:21:05 GMT Subject: RFR: 8256109: Create implementation for NSAccessibilityButton protocol [v5] In-Reply-To: References: Message-ID: On Tue, 12 Jan 2021 06:08:10 GMT, Alexander Zuev wrote: >> Creating a native peer for pushbutton accessibility role on Max OS X. >> The process of choosing of what peer to initialize is clunky so >> might be addressed in the future. > > Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: > > Replaced #include with #import for consistency src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CommonComponentAccessibility.m line 61: > 59: { > 60: if (rolesMap == nil) { > 61: [self initializeRolesMap]; Is it possible that this will be called on the different threads? Or it is always appkit(probably AWT_ASSERT_APPKIT_THREAD could be useful)? ------------- PR: https://git.openjdk.java.net/jdk/pull/1549 From kizune at openjdk.java.net Thu Jan 14 04:54:17 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Thu, 14 Jan 2021 04:54:17 GMT Subject: RFR: 8256109: Create implementation for NSAccessibilityButton protocol [v6] In-Reply-To: References: Message-ID: > Creating a native peer for pushbutton accessibility role on Max OS X. > The process of choosing of what peer to initialize is clunky so > might be addressed in the future. Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: Added AWT_ASSERT_APPKIT_THREAD ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1549/files - new: https://git.openjdk.java.net/jdk/pull/1549/files/22fe7535..0b208934 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1549&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1549&range=04-05 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1549.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1549/head:pull/1549 PR: https://git.openjdk.java.net/jdk/pull/1549 From kizune at openjdk.java.net Thu Jan 14 04:54:18 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Thu, 14 Jan 2021 04:54:18 GMT Subject: RFR: 8256109: Create implementation for NSAccessibilityButton protocol [v5] In-Reply-To: References: Message-ID: On Thu, 14 Jan 2021 00:17:57 GMT, Sergey Bylokhov wrote: >> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: >> >> Replaced #include with #import for consistency > > src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CommonComponentAccessibility.m line 61: > >> 59: { >> 60: if (rolesMap == nil) { >> 61: [self initializeRolesMap]; > > Is it possible that this will be called on the different threads? Or it is always appkit(probably AWT_ASSERT_APPKIT_THREAD could be useful)? Well, this method is being called from AppKit thread only but giving that it is static and public adding an assertion would be indeed wise. Fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/1549 From serb at openjdk.java.net Thu Jan 14 05:00:03 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Thu, 14 Jan 2021 05:00:03 GMT Subject: RFR: 8256109: Create implementation for NSAccessibilityButton protocol [v6] In-Reply-To: References: Message-ID: <7mT3eq9lLr-B4qCmYa9ul6qqsBVZeOnijon2-c4C6q8=.c766a0b0-ec42-4d35-8811-683cad9aba36@github.com> On Thu, 14 Jan 2021 04:54:17 GMT, Alexander Zuev wrote: >> Creating a native peer for pushbutton accessibility role on Max OS X. >> The process of choosing of what peer to initialize is clunky so >> might be addressed in the future. > > Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: > > Added AWT_ASSERT_APPKIT_THREAD Marked as reviewed by serb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1549 From kizune at openjdk.java.net Thu Jan 14 05:10:03 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Thu, 14 Jan 2021 05:10:03 GMT Subject: Integrated: 8256109: Create implementation for NSAccessibilityButton protocol In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 22:49:08 GMT, Alexander Zuev wrote: > Creating a native peer for pushbutton accessibility role on Max OS X. > The process of choosing of what peer to initialize is clunky so > might be addressed in the future. This pull request has now been integrated. Changeset: ae9187d7 Author: Alexander Zuev URL: https://git.openjdk.java.net/jdk/commit/ae9187d7 Stats: 295 lines in 5 files changed: 238 ins; 46 del; 11 mod 8256109: Create implementation for NSAccessibilityButton protocol Reviewed-by: prr, serb ------------- PR: https://git.openjdk.java.net/jdk/pull/1549 From pbansal at openjdk.java.net Thu Jan 14 14:11:14 2021 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Thu, 14 Jan 2021 14:11:14 GMT Subject: RFR: 8259779: Create implementation for NSAccessibilityStepper protocol Message-ID: <6nFRoyKpA_zZpJrYkqsxmVj1t7QDgmdm9jkJlcTQTGE=.9bf193ae-c687-4c7b-b184-06bbf77b9ec5@github.com> Creating a native peer for stepper/spinner accessibility role on Max OS X. ------------- Commit messages: - Resolve some whitespaces issues - 8259779: Create implementation for NSAccessibilityStepper protocol Changes: https://git.openjdk.java.net/jdk/pull/2081/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2081&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259779 Stats: 115 lines in 3 files changed: 114 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2081.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2081/head:pull/2081 PR: https://git.openjdk.java.net/jdk/pull/2081 From pbansal at openjdk.java.net Thu Jan 14 18:19:59 2021 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Thu, 14 Jan 2021 18:19:59 GMT Subject: Withdrawn: 8259779: Create implementation for NSAccessibilityStepper protocol In-Reply-To: <6nFRoyKpA_zZpJrYkqsxmVj1t7QDgmdm9jkJlcTQTGE=.9bf193ae-c687-4c7b-b184-06bbf77b9ec5@github.com> References: <6nFRoyKpA_zZpJrYkqsxmVj1t7QDgmdm9jkJlcTQTGE=.9bf193ae-c687-4c7b-b184-06bbf77b9ec5@github.com> Message-ID: On Thu, 14 Jan 2021 13:46:17 GMT, Pankaj Bansal wrote: > Creating a native peer for stepper/spinner accessibility role on Max OS X. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/2081 From prr at openjdk.java.net Thu Jan 14 21:41:21 2021 From: prr at openjdk.java.net (Phil Race) Date: Thu, 14 Jan 2021 21:41:21 GMT Subject: RFR: 8259651: [macOS] Replace JNF_COCOA_ENTER/EXIT macros [v2] In-Reply-To: References: Message-ID: > Most of the changes here are simply > JNF_COCOA_ENTER -> JNI_COCOA_ENTER > JNF_COCOA_EXIT -> JNI_COCOA_EXIT > > These new macros are defined in JNIUtilities.h and handle the auto release and on exit catch any NSException. > Unlike the JNF code, JNI exceptions don't have to be extracted from the NSException. > > So calls to JNFException are also removed and in most cases they are just directly using one of the JNU_* > defined exceptions since we are in a native nethod and can return control directly to Java. > > JNIUtilities has just two macros for cases where we need to accompany it with an NSException because > we aren't in the immediate body of a JNI method. > > JNIUtilities also has a macro JNI_COCOA_EXIT_WITH_ACTION > This is used by a macro in QuartzSurfaceData.m to re-implement a pre-existing macro > JNF_COCOA_RENDERER_EXIT as JNI_COCOA_RENDERER_EXIT. > This is used in a few places to ensure that we call FinishSurface on the Quartz surface. > > This already passed all our automated tests, although I'm re-running since I needed to merge to the > current repo state. Phil Race has updated the pull request incrementally with one additional commit since the last revision: 8259651: [macOS] Replace JNF_COCOA_ENTER/EXIT macros ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2056/files - new: https://git.openjdk.java.net/jdk/pull/2056/files/7dd3ec01..207ad745 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2056&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2056&range=00-01 Stats: 16 lines in 3 files changed: 6 ins; 8 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2056.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2056/head:pull/2056 PR: https://git.openjdk.java.net/jdk/pull/2056 From prr at openjdk.java.net Thu Jan 14 21:46:08 2021 From: prr at openjdk.java.net (Phil Race) Date: Thu, 14 Jan 2021 21:46:08 GMT Subject: RFR: 8259651: [macOS] Replace JNF_COCOA_ENTER/EXIT macros [v2] In-Reply-To: References: Message-ID: On Thu, 14 Jan 2021 21:41:21 GMT, Phil Race wrote: >> Most of the changes here are simply >> JNF_COCOA_ENTER -> JNI_COCOA_ENTER >> JNF_COCOA_EXIT -> JNI_COCOA_EXIT >> >> These new macros are defined in JNIUtilities.h and handle the auto release and on exit catch any NSException. >> Unlike the JNF code, JNI exceptions don't have to be extracted from the NSException. >> >> So calls to JNFException are also removed and in most cases they are just directly using one of the JNU_* >> defined exceptions since we are in a native nethod and can return control directly to Java. >> >> JNIUtilities has just two macros for cases where we need to accompany it with an NSException because >> we aren't in the immediate body of a JNI method. >> >> JNIUtilities also has a macro JNI_COCOA_EXIT_WITH_ACTION >> This is used by a macro in QuartzSurfaceData.m to re-implement a pre-existing macro >> JNF_COCOA_RENDERER_EXIT as JNI_COCOA_RENDERER_EXIT. >> This is used in a few places to ensure that we call FinishSurface on the Quartz surface. >> >> This already passed all our automated tests, although I'm re-running since I needed to merge to the >> current repo state. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8259651: [macOS] Replace JNF_COCOA_ENTER/EXIT macros src/java.desktop/macosx/native/libawt_lwawt/awt/AWTWindow.m line 1680: > 1678: [nsWindow setFrame:screenRect display:YES]; > 1679: } else { > 1680: [NSException raise:@"Java Exception" reason:@"Failed to enter full screen." userInfo:nil]; Since this code is lexically inside a block executed on the AppKit thread it makes no sense to raise a Java Exception. src/java.desktop/macosx/native/libawt_lwawt/awt/QuartzSurfaceData.m line 57: > 55: } \ > 56: [NSException raise:@"Java Exception" reason:@"Java OutOfMemoryException" userInfo:nil] > 57: This macro is needed only in this file. ------------- PR: https://git.openjdk.java.net/jdk/pull/2056 From serb at openjdk.java.net Fri Jan 15 00:31:01 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Fri, 15 Jan 2021 00:31:01 GMT Subject: Integrated: 8259522: Apply java.io.Serial annotations in java.desktop In-Reply-To: References: Message-ID: On Mon, 11 Jan 2021 06:21:52 GMT, Sergey Bylokhov wrote: > Please review the application of @java.io.Serial annotation (JDK-8202385) to types in the desktop module to enable stricter compile-time checking of serialization-related declarations. > > This annotation can be applied to these methods in the module: > > private void writeObject(java.io.ObjectOutputStream stream) throws IOException > private void readObject(java.io.ObjectInputStream stream) throws IOException, ClassNotFoundException > private void readObjectNoData() throws ObjectStreamException > ANY-ACCESS-MODIFIER Object writeReplace() throws ObjectStreamException > ANY-ACCESS-MODIFIER Object readResolve() throws ObjectStreamException > private static final ObjectStreamField[] serialPersistentFields > private static final long serialVersionUID > > Notes: > - I have tried to update the comments for serialVersionUID as accurately as possible, but mostly based on the source code history and bugs in JBS where that field was added > - Some of the readObject/writeObject methods in the javax.swing package does not have a spec, because this package and some others are excluded from the serialization specification. > > A similar fix was implemented for java.base module as well: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-August/062046.html This pull request has now been integrated. Changeset: 978bed6c Author: Sergey Bylokhov URL: https://git.openjdk.java.net/jdk/commit/978bed6c Stats: 3424 lines in 343 files changed: 2264 ins; 287 del; 873 mod 8259522: Apply java.io.Serial annotations in java.desktop Reviewed-by: aivanov, psadhukhan ------------- PR: https://git.openjdk.java.net/jdk/pull/2020 From psadhukhan at openjdk.java.net Fri Jan 15 05:40:02 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Fri, 15 Jan 2021 05:40:02 GMT Subject: RFR: 8259729: Missed JNFInstanceOf -> IsInstanceOf conversion In-Reply-To: References: Message-ID: On Wed, 13 Jan 2021 20:35:55 GMT, Phil Race wrote: > One line fix of a missed update Marked as reviewed by psadhukhan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2066 From kizune at openjdk.java.net Fri Jan 15 05:56:02 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Fri, 15 Jan 2021 05:56:02 GMT Subject: RFR: 8259729: Missed JNFInstanceOf -> IsInstanceOf conversion In-Reply-To: References: Message-ID: <9E6NS8W010aR5g8uja0jhCtKDF9bemCN6DNJWS8qRnM=.cf256b55-1e7c-416c-a161-596eb9592a7f@github.com> On Wed, 13 Jan 2021 20:35:55 GMT, Phil Race wrote: > One line fix of a missed update Marked as reviewed by kizune (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2066 From serb at openjdk.java.net Fri Jan 15 06:33:06 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Fri, 15 Jan 2021 06:33:06 GMT Subject: RFR: 8259651: [macOS] Replace JNF_COCOA_ENTER/EXIT macros [v2] In-Reply-To: References: Message-ID: <15TvCXuwUKVe19Ikw9lPHHB8XZQU4QwrCVRtHIetD6w=.f87d4b63-56f0-49b6-863e-0ee5660ba161@github.com> On Thu, 14 Jan 2021 21:41:21 GMT, Phil Race wrote: >> Most of the changes here are simply >> JNF_COCOA_ENTER -> JNI_COCOA_ENTER >> JNF_COCOA_EXIT -> JNI_COCOA_EXIT >> >> These new macros are defined in JNIUtilities.h and handle the auto release and on exit catch any NSException. >> Unlike the JNF code, JNI exceptions don't have to be extracted from the NSException. >> >> So calls to JNFException are also removed and in most cases they are just directly using one of the JNU_* >> defined exceptions since we are in a native nethod and can return control directly to Java. >> >> JNIUtilities has just two macros for cases where we need to accompany it with an NSException because >> we aren't in the immediate body of a JNI method. >> >> JNIUtilities also has a macro JNI_COCOA_EXIT_WITH_ACTION >> This is used by a macro in QuartzSurfaceData.m to re-implement a pre-existing macro >> JNF_COCOA_RENDERER_EXIT as JNI_COCOA_RENDERER_EXIT. >> This is used in a few places to ensure that we call FinishSurface on the Quartz surface. >> >> This already passed all our automated tests, although I'm re-running since I needed to merge to the >> current repo state. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8259651: [macOS] Replace JNF_COCOA_ENTER/EXIT macros Marked as reviewed by serb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2056 From kizune at openjdk.java.net Fri Jan 15 06:40:11 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Fri, 15 Jan 2021 06:40:11 GMT Subject: RFR: 8256110: Create implementation for NSAccessibilityStepper protocol Message-ID: <8a94jkv3VvrOpmV9m-VNfv5cfnKBgDOT0B0arBb64gI=.83861c0c-a8ff-452d-9fa1-9ae126042616@github.com> 8256110: Create implementation for NSAccessibilityStepper protocol ------------- Commit messages: - Fixed small glitch in new code. - 8256110: Create implementation for NSAccessibilityStepper protocol - Merge remote-tracking branch 'upstream/master' into master - Merge branch 'openjdk-master' into master - Merge branch 'master' of https://github.com/openjdk/jdk into openjdk-master - Merge pull request #7 from openjdk/master - Merge pull request #6 from openjdk/master - Merge pull request #5 from openjdk/master - Merge pull request #4 from openjdk/master - Merge pull request #3 from openjdk/master - ... and 2 more: https://git.openjdk.java.net/jdk/compare/bf28f925...43b4ef01 Changes: https://git.openjdk.java.net/jdk/pull/2092/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2092&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256110 Stats: 127 lines in 5 files changed: 114 ins; 11 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2092.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2092/head:pull/2092 PR: https://git.openjdk.java.net/jdk/pull/2092 From pbansal at openjdk.java.net Fri Jan 15 06:46:06 2021 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Fri, 15 Jan 2021 06:46:06 GMT Subject: RFR: 8256110: Create implementation for NSAccessibilityStepper protocol In-Reply-To: <8a94jkv3VvrOpmV9m-VNfv5cfnKBgDOT0B0arBb64gI=.83861c0c-a8ff-452d-9fa1-9ae126042616@github.com> References: <8a94jkv3VvrOpmV9m-VNfv5cfnKBgDOT0B0arBb64gI=.83861c0c-a8ff-452d-9fa1-9ae126042616@github.com> Message-ID: On Fri, 15 Jan 2021 06:34:22 GMT, Alexander Zuev wrote: > 8256110: Create implementation for NSAccessibilityStepper protocol Marked as reviewed by pbansal (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2092 From serb at openjdk.java.net Fri Jan 15 07:43:08 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Fri, 15 Jan 2021 07:43:08 GMT Subject: RFR: 8256110: Create implementation for NSAccessibilityStepper protocol In-Reply-To: <8a94jkv3VvrOpmV9m-VNfv5cfnKBgDOT0B0arBb64gI=.83861c0c-a8ff-452d-9fa1-9ae126042616@github.com> References: <8a94jkv3VvrOpmV9m-VNfv5cfnKBgDOT0B0arBb64gI=.83861c0c-a8ff-452d-9fa1-9ae126042616@github.com> Message-ID: <48p7EQeSf_9FRSQJTkzPQXBVM6jMvtbfQDwpkcuQ9UE=.27754dd2-7ee5-435e-b4ff-2e611fb52cd6@github.com> On Fri, 15 Jan 2021 06:34:22 GMT, Alexander Zuev wrote: > 8256110: Create implementation for NSAccessibilityStepper protocol src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ButtonAccessibility.m line 43: > 41: - (BOOL)accessibilityPerformPress > 42: { > 43: return [self performAccessibleAction:0]; I guess you need to remove the static "jclass sjc_CAccessibility = NULL;" above as well? ------------- PR: https://git.openjdk.java.net/jdk/pull/2092 From pbansal at openjdk.java.net Fri Jan 15 08:35:20 2021 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Fri, 15 Jan 2021 08:35:20 GMT Subject: RFR: 8256126: Create implementation for NSAccessibilityImage protocol peer Message-ID: Create implementation for NSAccessibilityImage protocol peer ------------- Commit messages: - 8256126: Create implementation for NSAccessibilityImage protocol peer Changes: https://git.openjdk.java.net/jdk/pull/2096/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2096&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256126 Stats: 42 lines in 3 files changed: 39 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2096.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2096/head:pull/2096 PR: https://git.openjdk.java.net/jdk/pull/2096 From kizune at openjdk.java.net Fri Jan 15 08:46:24 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Fri, 15 Jan 2021 08:46:24 GMT Subject: RFR: 8256110: Create implementation for NSAccessibilityStepper protocol [v2] In-Reply-To: <8a94jkv3VvrOpmV9m-VNfv5cfnKBgDOT0B0arBb64gI=.83861c0c-a8ff-452d-9fa1-9ae126042616@github.com> References: <8a94jkv3VvrOpmV9m-VNfv5cfnKBgDOT0B0arBb64gI=.83861c0c-a8ff-452d-9fa1-9ae126042616@github.com> Message-ID: > 8256110: Create implementation for NSAccessibilityStepper protocol Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: Code cleanup ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2092/files - new: https://git.openjdk.java.net/jdk/pull/2092/files/43b4ef01..ebb4bb20 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2092&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2092&range=00-01 Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2092.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2092/head:pull/2092 PR: https://git.openjdk.java.net/jdk/pull/2092 From kizune at openjdk.java.net Fri Jan 15 08:46:25 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Fri, 15 Jan 2021 08:46:25 GMT Subject: RFR: 8256110: Create implementation for NSAccessibilityStepper protocol [v2] In-Reply-To: <48p7EQeSf_9FRSQJTkzPQXBVM6jMvtbfQDwpkcuQ9UE=.27754dd2-7ee5-435e-b4ff-2e611fb52cd6@github.com> References: <8a94jkv3VvrOpmV9m-VNfv5cfnKBgDOT0B0arBb64gI=.83861c0c-a8ff-452d-9fa1-9ae126042616@github.com> <48p7EQeSf_9FRSQJTkzPQXBVM6jMvtbfQDwpkcuQ9UE=.27754dd2-7ee5-435e-b4ff-2e611fb52cd6@github.com> Message-ID: On Fri, 15 Jan 2021 07:40:23 GMT, Sergey Bylokhov wrote: >> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: >> >> Code cleanup > > src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ButtonAccessibility.m line 43: > >> 41: - (BOOL)accessibilityPerformPress >> 42: { >> 43: return [self performAccessibleAction:0]; > > I guess you need to remove the static "jclass sjc_CAccessibility = NULL;" above as well? And unneeded imports too. Remnants of the code that is gone. Fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/2092 From kizune at openjdk.java.net Fri Jan 15 08:54:04 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Fri, 15 Jan 2021 08:54:04 GMT Subject: RFR: 8256126: Create implementation for NSAccessibilityImage protocol peer In-Reply-To: References: Message-ID: <8v7tHPQZ0wxwfHSVxUg2dhVZc3ZXykWWfChx0alfE04=.20528076-69d1-4dd3-8d56-2da639bfb6ce@github.com> On Fri, 15 Jan 2021 08:29:44 GMT, Pankaj Bansal wrote: > Create implementation for NSAccessibilityImage protocol peer Marked as reviewed by kizune (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2096 From prr at openjdk.java.net Fri Jan 15 17:08:07 2021 From: prr at openjdk.java.net (Phil Race) Date: Fri, 15 Jan 2021 17:08:07 GMT Subject: Integrated: 8259651: [macOS] Replace JNF_COCOA_ENTER/EXIT macros In-Reply-To: References: Message-ID: On Tue, 12 Jan 2021 21:39:02 GMT, Phil Race wrote: > Most of the changes here are simply > JNF_COCOA_ENTER -> JNI_COCOA_ENTER > JNF_COCOA_EXIT -> JNI_COCOA_EXIT > > These new macros are defined in JNIUtilities.h and handle the auto release and on exit catch any NSException. > Unlike the JNF code, JNI exceptions don't have to be extracted from the NSException. > > So calls to JNFException are also removed and in most cases they are just directly using one of the JNU_* > defined exceptions since we are in a native nethod and can return control directly to Java. > > JNIUtilities has just two macros for cases where we need to accompany it with an NSException because > we aren't in the immediate body of a JNI method. > > JNIUtilities also has a macro JNI_COCOA_EXIT_WITH_ACTION > This is used by a macro in QuartzSurfaceData.m to re-implement a pre-existing macro > JNF_COCOA_RENDERER_EXIT as JNI_COCOA_RENDERER_EXIT. > This is used in a few places to ensure that we call FinishSurface on the Quartz surface. > > This already passed all our automated tests, although I'm re-running since I needed to merge to the > current repo state. This pull request has now been integrated. Changeset: 5855d52a Author: Phil Race URL: https://git.openjdk.java.net/jdk/commit/5855d52a Stats: 600 lines in 48 files changed: 56 ins; 17 del; 527 mod 8259651: [macOS] Replace JNF_COCOA_ENTER/EXIT macros Reviewed-by: serb ------------- PR: https://git.openjdk.java.net/jdk/pull/2056 From serb at openjdk.java.net Sat Jan 16 00:42:02 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Sat, 16 Jan 2021 00:42:02 GMT Subject: RFR: 8256126: Create implementation for NSAccessibilityImage protocol peer In-Reply-To: References: Message-ID: On Fri, 15 Jan 2021 08:29:44 GMT, Pankaj Bansal wrote: > Create implementation for NSAccessibilityImage protocol peer @pankaj-bansal please provide some steps to test that a11y for the image works. ------------- PR: https://git.openjdk.java.net/jdk/pull/2096 From serb at openjdk.java.net Sat Jan 16 00:51:04 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Sat, 16 Jan 2021 00:51:04 GMT Subject: RFR: 8257414: Drag n Drop target area is wrong on high DPI systems In-Reply-To: References: Message-ID: <81gphZwW6IcxQKRHJkvL-3OFSTELCi7qPX32WCKj7Qg=.21bbd517-5771-41bd-87a7-802a6e78b989@github.com> On Wed, 13 Jan 2021 00:17:45 GMT, Olga Mikhaltsova wrote: > Sergey, thank you! Could you give me a hint please concerning some use case of drag-and-drop to meet the (xwindow == 0) condition in XDnDDropTargetProtocol::processXdndPosition(..)? I'm unable to do it by means of the tests' apps I have. I think it is somehow related to the embedded frame when the event comes from some native window that is not registered as a java peer(but some external native app/window) ------------- PR: https://git.openjdk.java.net/jdk/pull/1907 From kizune at openjdk.java.net Sat Jan 16 02:08:21 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Sat, 16 Jan 2021 02:08:21 GMT Subject: RFR: 8256126: Create implementation for NSAccessibilityImage protocol peer In-Reply-To: References: Message-ID: On Fri, 15 Jan 2021 08:29:44 GMT, Pankaj Bansal wrote: > Create implementation for NSAccessibilityImage protocol peer > @pankaj-bansal please provide some steps to test that a11y for the image works. I use the simple code snippet like this:
import java.awt.*;
import java.net.MalformedURLException;
import java.net.URL;
import javax.swing.*;

public class AccessibleImageTest {
    public static void main(String[] args) throws MalformedURLException {
        new AccessibleImageTest().test();
    }

    public void test() throws MalformedURLException {
        JFrame frame = new JFrame("Test frame");
        frame.setLayout(new BorderLayout());
        ImageIcon imageIcon = new ImageIcon(new URL("https://www.oracle.com/a/ocom/img/i-code-java-300x352-3854596.png"));
        JLabel label = new JLabel(imageIcon);
        label.getAccessibleContext().setAccessibleDescription("I code Java");
        frame.add(label, BorderLayout.CENTER);
        frame.add(new JButton("Top button"), BorderLayout.NORTH);
        frame.add(new JButton("Bottom button"), BorderLayout.SOUTH);
        frame.setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE);
        frame.pack();
        frame.setVisible(true);
    }
}
After compiling and running the code you should see frame with two buttons on top and bottom and image in the middle. Now if you turn on VoiceOver with `` the accessibility cursor should be on one of the buttons. By using `