From psadhukhan at openjdk.org Thu Aug 1 03:38:40 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 1 Aug 2024 03:38:40 GMT Subject: Integrated: 8337457: Redundant Math.round call in AquaProgressBarUI#getStringPlacement In-Reply-To: <19pO_6uB0XN1R849SUo0-rytPb4YNs8AqyfxBYn6ElM=.c1ebaa7e-2334-4d75-9b95-2e8f74d8cb6c@github.com> References: <19pO_6uB0XN1R849SUo0-rytPb4YNs8AqyfxBYn6ElM=.c1ebaa7e-2334-4d75-9b95-2e8f74d8cb6c@github.com> Message-ID: <7RauOPN35uaaewKsBw8cm_3uNnjiwIlKXXxHUKOJlgQ=.ce4729a1-d65f-421f-b5fa-002dab159278@github.com> On Wed, 31 Jul 2024 07:12:35 GMT, Prasanta Sadhukhan wrote: > Since Math.round with integer argument returns the same value, and also since all arguments and calculations in the AquaProgressBarUI#getStringPlacement are integer arithmetic, Math.round is redundant and can be removed This pull request has now been integrated. Changeset: 65646b5f Author: Prasanta Sadhukhan URL: https://git.openjdk.org/jdk/commit/65646b5f81279a7fcef3ea04ef9894cf66f77a5a Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8337457: Redundant Math.round call in AquaProgressBarUI#getStringPlacement Reviewed-by: azvegint ------------- PR: https://git.openjdk.org/jdk/pull/20400 From psadhukhan at openjdk.org Thu Aug 1 03:43:06 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 1 Aug 2024 03:43:06 GMT Subject: RFR: 8337344: Redundant javadoc at RasterPrinterJob.isCancelled [v3] In-Reply-To: References: Message-ID: > RasterPrinterJob.isCancelled cites > `is a print job is ongoing but will be cancelled and the next opportunity` > > "and" -> "at" is fixed and more clarification added.. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Add override ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20375/files - new: https://git.openjdk.org/jdk/pull/20375/files/f0158b45..e5693b83 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20375&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20375&range=01-02 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20375.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20375/head:pull/20375 PR: https://git.openjdk.org/jdk/pull/20375 From abhiscxk at openjdk.org Thu Aug 1 04:45:31 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Thu, 1 Aug 2024 04:45:31 GMT Subject: RFR: 6318027: BasicScrollBarUI does not disable timer when enclosing frame is disabled. In-Reply-To: References: Message-ID: On Fri, 26 Jul 2024 06:03:28 GMT, Prasanta Sadhukhan wrote: > Issue is > BasicScrollBarUI.ArrowButtonListener starts a timer in mousePressed(), and stops it in mouseReleased(). If the frame containing the scrollbar is disabled between the MOUSE_PRESSED and the MOUSE_RELEASED events, the mouseReleased() method is never called. If the frame is then re-enabled, the still-running timer causes it to scroll all the way to the end. > Fix is to check if [ArrowButtonListener.handledEvent](https://github.com/openjdk/jdk/blame/ee839b7f0ebe471d3877cddd2c87019ccb8ee5ae/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicScrollBarUI.java#L1567) is still set when ActionEvent is processed then stop the timer and reset this variable. > > CI testing is green and also SwingSet2 JScrollPane scrolling with this modification.. test/jdk/javax/swing/JScrollBar/DisableFrameFromScrollBar.java line 87: > 85: frame.setSize(150, 150); > 86: frame.setLocationRelativeTo(null); > 87: frame.setVisible(true); Can be pushed to a helper method. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20346#discussion_r1699411655 From abhiscxk at openjdk.org Thu Aug 1 05:11:34 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Thu, 1 Aug 2024 05:11:34 GMT Subject: RFR: 6318027: BasicScrollBarUI does not disable timer when enclosing frame is disabled. In-Reply-To: References: Message-ID: <_g5SYdkcap5xfK58rwbdm3ZRCcLsOefVKhiSYLtk8Ow=.ea12bbde-7f7e-45af-ad56-571bd0f041af@github.com> On Fri, 26 Jul 2024 06:03:28 GMT, Prasanta Sadhukhan wrote: > Issue is > BasicScrollBarUI.ArrowButtonListener starts a timer in mousePressed(), and stops it in mouseReleased(). If the frame containing the scrollbar is disabled between the MOUSE_PRESSED and the MOUSE_RELEASED events, the mouseReleased() method is never called. If the frame is then re-enabled, the still-running timer causes it to scroll all the way to the end. > Fix is to check if [ArrowButtonListener.handledEvent](https://github.com/openjdk/jdk/blame/ee839b7f0ebe471d3877cddd2c87019ccb8ee5ae/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicScrollBarUI.java#L1567) is still set when ActionEvent is processed then stop the timer and reset this variable. > > CI testing is green and also SwingSet2 JScrollPane scrolling with this modification.. src/java.desktop/share/classes/javax/swing/plaf/basic/BasicScrollBarUI.java line 1614: > 1612: // mouseReleased is not called after mousePressed when > 1613: // this AcionEvent is being processed > 1614: if (buttonListener.handledEvent) { Since the fix is added in BasicScrollBarUI, will it affect Aqua ScrollBar also? test/jdk/javax/swing/JScrollBar/DisableFrameFromScrollBar.java line 81: > 79: bar.getModel().addChangeListener(new DisableChangeListener(frame)); > 80: frame.getContentPane().setLayout(new FlowLayout()); > 81: frame.getContentPane().add(bar); I guess `getContentPane` may be removed. test/jdk/javax/swing/JScrollBar/DisableFrameFromScrollBar.java line 85: > 83: frame.pack(); > 84: frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); > 85: frame.setSize(150, 150); setting frame size explicitly after calling `frame.pack()` looks redundant. test/jdk/javax/swing/JScrollBar/DisableFrameFromScrollBar.java line 138: > 136: Point p = bar.getLocationOnScreen(); > 137: Rectangle rect = bar.getBounds(); > 138: result[0] = new Point((int) (p.x + rect.width/2), Suggestion: result[0] = new Point((int) (p.x + rect.width / 2), test/jdk/javax/swing/JScrollBar/DisableFrameFromScrollBar.java line 149: > 147: public static class DisableChangeListener implements ChangeListener { > 148: private final JFrame m_frame; > 149: private boolean m_done = false; default value for a boolean is `false`, no need to set it explicitly. test/jdk/javax/swing/JScrollBar/DisableFrameFromScrollBar.java line 156: > 154: > 155: public void stateChanged(ChangeEvent p_e) { > 156: if (! m_done) { Suggestion: if (!m_done) { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20346#discussion_r1699418618 PR Review Comment: https://git.openjdk.org/jdk/pull/20346#discussion_r1699424368 PR Review Comment: https://git.openjdk.org/jdk/pull/20346#discussion_r1699425151 PR Review Comment: https://git.openjdk.org/jdk/pull/20346#discussion_r1699426454 PR Review Comment: https://git.openjdk.org/jdk/pull/20346#discussion_r1699427400 PR Review Comment: https://git.openjdk.org/jdk/pull/20346#discussion_r1699427872 From psadhukhan at openjdk.org Thu Aug 1 05:12:51 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 1 Aug 2024 05:12:51 GMT Subject: RFR: 8335231: [macos] Test java/awt/print/PrinterJob/Cancel/PrinterJobCancel.java failed on macOS because the case didn't get the expected PrintAbortException [v3] In-Reply-To: References: Message-ID: <1w-vJq4R769dS3TunRyONDDTvpRbBJV_OClh3Hz2nHk=.efb94e40-fce7-40ca-a351-9e9d00af2f3f@github.com> > When a printjob is cancelled midway, `PrinterAbortException `was not thrown in macos. because > firstly,` cancelCheck` invokes` LWCToolkit.invokeLater` with null as parameter causing it to fail with NPE and > secondly PrinterAbortException was consumed silently when `printLoop` throws any exception > which is rectified to throw the PrinterAbortException when encountered.. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Restore invokeLater and throw PrinterAbortException from native ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20027/files - new: https://git.openjdk.org/jdk/pull/20027/files/6c495ea1..c4c7f9d7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20027&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20027&range=01-02 Stats: 22 lines in 2 files changed: 18 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/20027.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20027/head:pull/20027 PR: https://git.openjdk.org/jdk/pull/20027 From psadhukhan at openjdk.org Thu Aug 1 05:15:30 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 1 Aug 2024 05:15:30 GMT Subject: RFR: 8335231: [macos] Test java/awt/print/PrinterJob/Cancel/PrinterJobCancel.java failed on macOS because the case didn't get the expected PrintAbortException [v3] In-Reply-To: References: <8E9aYUKvZccuNwo2_izseqFVsB60ozQVPmXqTnOkzJw=.63becc7a-0e69-4f2d-8291-c1b0680cb91f@github.com> <9lV9YHNZQ14JNgbhkLh3owJZQCvepHNaocKB6mK6gZI=.9b5ebf6a-7443-4fb4-bb48-e979754ec34f@github.com> Message-ID: On Wed, 31 Jul 2024 18:48:01 GMT, Phil Race wrote: >> I dont see any deadlock in my testing so I am using `isCancelled` . >> How do you normally "cancel" ongoing printing in macosx? I tried clicking on "x" in "Print Centre" when the specific print job is shown in the printer spooler and I dont see any deadlock for long printing tests like PrintAllFonts etc.. > > plugin mode is no longer a concern. > > So it seems to me that the worry is that some other thread holds the lock on the PrinterJob, and > is waiting for a print loop to return from native code running on the AppKit thread, which then up-calls to here and then needs to synchronize on the PrinterJob. > Other cases that I see aren't from native so aren't a problem. > > "Coming to your question, I guess if there is a deadlock, calling cancelDoc directly will also face the same" > > Yes whereas In the existing code it is run on the AppKit thread to avoid it ... > It seems safest to restore the invokeLater. Ok..Restore invokeLater and handled/thrown PrinterAbortException in native.. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20027#discussion_r1699431986 From abhiscxk at openjdk.org Thu Aug 1 06:09:31 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Thu, 1 Aug 2024 06:09:31 GMT Subject: RFR: 8329471: Remove GTK2 [v5] In-Reply-To: References: Message-ID: On Wed, 31 Jul 2024 19:17:05 GMT, Alexander Zvegintsev wrote: >> GTK2 support for Swing/AWT was deprecated for removal in JDK 21. >> >> It's being removed because no platform that supports the JDK needs it. >> >> Manual and automated testing is green. > > Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: > > more removal of is3() Changes looks good to me. Hope you have run all the tests with latest changes. ------------- Marked as reviewed by abhiscxk (Committer). PR Review: https://git.openjdk.org/jdk/pull/20378#pullrequestreview-2211709762 From aivanov at openjdk.org Thu Aug 1 10:27:32 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 1 Aug 2024 10:27:32 GMT Subject: RFR: 8337344: Redundant javadoc at RasterPrinterJob.isCancelled [v3] In-Reply-To: References: Message-ID: On Thu, 1 Aug 2024 03:43:06 GMT, Prasanta Sadhukhan wrote: >> RasterPrinterJob.isCancelled cites >> `is a print job is ongoing but will be cancelled and the next opportunity` >> >> "and" -> "at" is fixed and more clarification added.. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Add override Looks good to me. ------------- Marked as reviewed by aivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20375#pullrequestreview-2212344718 From kbarrett at openjdk.org Thu Aug 1 15:05:33 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 1 Aug 2024 15:05:33 GMT Subject: RFR: 8336289: Obliterate most references to _snprintf in the Windows JDK In-Reply-To: References: Message-ID: On Sat, 13 Jul 2024 05:34:00 GMT, Julian Waters wrote: >> snprintf has been available for all officially and unofficially supported compilers for Windows, Visual Studio since version 2015 and gcc since, well, forever. snprintf is conforming to C99 since the start when compiling using gcc, and 2015 when using Visual Studio. Since it conforms to C99 and provides better semantics than _snprintf, and is not compiler specific, we should use it in most places where we currently use _snprintf. This makes JDK code where this is used more robust due to the null terminating guarantee of snprintf. Since most of the changes are extremely simple, I've included all of them hoping to get this all done in one shot. The only places _snprintf is not replaced is places where I'm not sure whether the code is ours or not (As in, imported source code for external libraries). Note that the existing checks in place for the size of the characters written still work, as the return value of snprintf works mostly the same as _snprintf. The only difference is the nu ll terminating character at the end and the returning of the number of written characters if the buffer was terminated early, as seen here: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170 >> >> Reviews Required: 2 for HotSpot, jdk.hotspot.agent, and jdk.jdwp.agent, 1 for awt and jdk.accessibility, 1 for java.base, 1 for security, 1 for jdk.management(?) > > I would add a FORBID_C_FUNCTION for _snprintf for Windows, but unfortunately that would be completely useless since there's no way to restrict methods on Visual Studio @TheShermanTanker - this seems to have been forgotten? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20153#issuecomment-2263298973 From jwaters at openjdk.org Thu Aug 1 15:11:31 2024 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 1 Aug 2024 15:11:31 GMT Subject: RFR: 8336289: Obliterate most references to _snprintf in the Windows JDK [v3] In-Reply-To: References: Message-ID: On Tue, 16 Jul 2024 08:59:20 GMT, Julian Waters wrote: >> snprintf has been available for all officially and unofficially supported compilers for Windows, Visual Studio since version 2015 and gcc since, well, forever. snprintf is conforming to C99 since the start when compiling using gcc, and 2015 when using Visual Studio. Since it conforms to C99 and provides better semantics than _snprintf, and is not compiler specific, we should use it in most places where we currently use _snprintf. This makes JDK code where this is used more robust due to the null terminating guarantee of snprintf. Since most of the changes are extremely simple, I've included all of them hoping to get this all done in one shot. The only places _snprintf is not replaced is places where I'm not sure whether the code is ours or not (As in, imported source code for external libraries). Note that the existing checks in place for the size of the characters written still work, as the return value of snprintf works mostly the same as _snprintf. The only difference is the nu ll terminating character at the end and the returning of the number of written characters if the buffer was terminated early, as seen here: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170 >> >> Reviews Required: 2 for HotSpot, jdk.hotspot.agent, and jdk.jdwp.agent, 1 for awt and jdk.accessibility, 1 for java.base, 1 for security, 1 for jdk.management(?) > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > Revert Standard Integer type rewrite Yeah, I do unfortunately need reviewers for the sections that haven't been approved yet. Taking this reminder as an opportunity to bump this Pull Request :) ------------- PR Comment: https://git.openjdk.org/jdk/pull/20153#issuecomment-2263315060 From djgredler at gmail.com Thu Aug 1 17:08:23 2024 From: djgredler at gmail.com (Daniel Gredler) Date: Thu, 1 Aug 2024 19:08:23 +0200 Subject: PNG image writing: memory inefficiency? In-Reply-To: References: Message-ID: Thanks for the confirmation! I went ahead and made some measurements, and the improvement possibilities really are quite good -- in a local test PNGImageWriter.write( ) and callees were initially showing up as an allocation hotspot (~400k objects / ~65 MB allocated), but after some optimizations I'm seeing much better numbers (~400 objects / ~740 KB allocated). I also spent some time creating regression tests for different combinations of alpha pre-multiplied vs. not, BufferedImage vs. other image types, untiled vs. single-tile vs. multi-tile, custom source bands vs. none, etc. I've filed a bug (internal review ID 9077379), but do not have a bug number yet. Once I have a bug number I'll submit a PR for review. Take care, Daniel On Wed, Jul 31, 2024 at 8:13?PM Philip Race wrote: > I think yes. > Whereas JPG grabs the raster for the whole image whereas as you noted, > PNG is looping row by row, > so there might need to be some updates in the handling of the child > raster needed. > > -phil. > > > On 7/31/24 10:02 AM, Daniel Gredler wrote: > > Hi all, > > > > I'd like a quick sanity check on a possible memory inefficiency in > > PNGImageWriter. > > > > Some of the other image writers, like JPEGImageWriter, do their best > > to avoid duplicating the image raster + data buffer [1]... although it > > doesn't look like this was always the case [2]. > > > > The PNGImageWriter, on the other hand, always makes a new raster + > > data buffer copy for each row [3]. It *is* per-row, so the data isn't > > all duplicated in one go, but even on a row-by-row basis, it ends up > > being quite a bit of unnecessary allocation and subsequent garbage > > collection. > > > > Can somebody confirm if I'm reading things right, and whether > > PNGImageWriter would benefit from a similar BufferedImage + single > > tile check, such as already exists in JPEGImageWriter? > > > > Thanks! > > > > Daniel > > > > [1] > > > https://github.com/openjdk/jdk/blob/e4c7850c177899a5da6f5050cb0647a6e1a75d31/src/java.desktop/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageWriter.java#L415 > > [2] https://bugs.openjdk.org/browse/JDK-6266748 > > [3] > > > https://github.com/openjdk/jdk/blob/e4c7850c177899a5da6f5050cb0647a6e1a75d31/src/java.desktop/share/classes/com/sun/imageio/plugins/png/PNGImageWriter.java#L923 > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Thu Aug 1 17:57:50 2024 From: philip.race at oracle.com (Phil Race) Date: Thu, 1 Aug 2024 10:57:50 -0700 Subject: PNG image writing: memory inefficiency? In-Reply-To: References: Message-ID: <51911aa2-567b-44cb-9cf8-50eeb1129646@oracle.com> https://bugs.openjdk.org/browse/JDK-8337681 -phil. On 8/1/2024 10:08, Daniel Gredler wrote: > Thanks for the confirmation! > > I went ahead and made some measurements, and the improvement > possibilities really are quite good -- in a local test > PNGImageWriter.write( ) and callees were initially showing up as an > allocation hotspot (~400k objects / ~65 MB allocated), but after some > optimizations I'm seeing much better numbers (~400 objects / ~740 KB > allocated). > > I also spent some time creating regression tests for different > combinations of alpha pre-multiplied vs. not, BufferedImage vs. other > image types, untiled vs. single-tile vs. multi-tile, custom source > bands vs. none, etc. > > I've filed a bug (internal review ID 9077379), but do not have a bug > number yet. Once I have a bug number I'll submit a PR for review. > > Take care, > > Daniel > > > On Wed, Jul 31, 2024 at 8:13?PM Philip Race > wrote: > > I think yes. > Whereas JPG grabs the raster for the whole image whereas as you > noted, > PNG is looping row by row, > so there might need to be some updates in the handling of the child > raster needed. > > -phil. > > > On 7/31/24 10:02 AM, Daniel Gredler wrote: > > Hi all, > > > > I'd like a quick sanity check on a possible memory inefficiency in > > PNGImageWriter. > > > > Some of the other image writers, like JPEGImageWriter, do their > best > > to avoid duplicating the image raster + data buffer [1]... > although it > > doesn't look like this was always the case [2]. > > > > The PNGImageWriter, on the other hand, always makes a new raster + > > data buffer copy for each row [3]. It *is* per-row, so the data > isn't > > all duplicated in one go, but even on a row-by-row basis, it > ends up > > being quite a bit of unnecessary allocation and subsequent garbage > > collection. > > > > Can somebody confirm if I'm reading things right, and whether > > PNGImageWriter would benefit from a similar BufferedImage + single > > tile check, such as already exists in JPEGImageWriter? > > > > Thanks! > > > > Daniel > > > > [1] > > > https://github.com/openjdk/jdk/blob/e4c7850c177899a5da6f5050cb0647a6e1a75d31/src/java.desktop/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageWriter.java#L415 > > [2] https://bugs.openjdk.org/browse/JDK-6266748 > > [3] > > > https://github.com/openjdk/jdk/blob/e4c7850c177899a5da6f5050cb0647a6e1a75d31/src/java.desktop/share/classes/com/sun/imageio/plugins/png/PNGImageWriter.java#L923 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prr at openjdk.org Thu Aug 1 18:17:34 2024 From: prr at openjdk.org (Phil Race) Date: Thu, 1 Aug 2024 18:17:34 GMT Subject: RFR: 8337344: Redundant javadoc at RasterPrinterJob.isCancelled [v3] In-Reply-To: References: Message-ID: On Thu, 1 Aug 2024 03:43:06 GMT, Prasanta Sadhukhan wrote: >> RasterPrinterJob.isCancelled cites >> `is a print job is ongoing but will be cancelled and the next opportunity` >> >> "and" -> "at" is fixed and more clarification added.. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Add override Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20375#pullrequestreview-2213546295 From prr at openjdk.org Thu Aug 1 18:29:31 2024 From: prr at openjdk.org (Phil Race) Date: Thu, 1 Aug 2024 18:29:31 GMT Subject: RFR: 8335231: [macos] Test java/awt/print/PrinterJob/Cancel/PrinterJobCancel.java failed on macOS because the case didn't get the expected PrintAbortException [v3] In-Reply-To: <1w-vJq4R769dS3TunRyONDDTvpRbBJV_OClh3Hz2nHk=.efb94e40-fce7-40ca-a351-9e9d00af2f3f@github.com> References: <1w-vJq4R769dS3TunRyONDDTvpRbBJV_OClh3Hz2nHk=.efb94e40-fce7-40ca-a351-9e9d00af2f3f@github.com> Message-ID: On Thu, 1 Aug 2024 05:12:51 GMT, Prasanta Sadhukhan wrote: >> When a printjob is cancelled midway, `PrinterAbortException `was not thrown in macos. because >> firstly,` cancelCheck` invokes` LWCToolkit.invokeLater` with null as parameter causing it to fail with NPE and >> secondly PrinterAbortException was consumed silently when `printLoop` throws any exception >> which is rectified to throw the PrinterAbortException when encountered.. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Restore invokeLater and throw PrinterAbortException from native src/java.desktop/macosx/classes/sun/lwawt/macosx/CPrinterJob.java line 764: > 762: } > 763: }}, null); > 764: } catch (NullPointerException ex) { I'm confused. I thought you were going to do something about the null ? Unless you don't this code won't work. Restoring using invokeLater isn't the same thing as restoring the bug. Look at the code that you are calling - it won't run the Runnable if there's an NPE. "new Component()" instead of null for example. FWIW I do not understand why this code uses LWCToolkit.invokeLater() Seems unnecessary. Why don't it use EventQueue.invokeLater() directly ? That'll solve a couple of problems - simpler code, no null check because no Component arg needed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20027#discussion_r1700633061 From duke at openjdk.org Thu Aug 1 18:47:40 2024 From: duke at openjdk.org (duke) Date: Thu, 1 Aug 2024 18:47:40 GMT Subject: Withdrawn: 8315113: Print request Chromaticity.MONOCHROME attribute does not work on macOS In-Reply-To: References: Message-ID: <5SzsaX2ycHIiRbaSPvMD9OJXmFV8Wr5R3ViXFc-VgOc=.ecb4ab40-cb56-4a3a-856a-f27d36cd8432@github.com> On Mon, 11 Mar 2024 13:54:02 GMT, Alexander Scherbatiy wrote: > The fix provides ability to print Black & White pages on macOS. > > Cocoa API has [PMSetColorMode](https://developer.apple.com/documentation/applicationservices/core_printing/1805783-pmsetcolormode) function but it is marked as deprecated and really does nothing. > > There is no replacement; this function was included to facilitate porting legacy applications to macOS, > but it serves no useful purpose. > > Dumping `NSPrintInfo` print settings which were set by the native print dialog on macOS shows that the keys and values used for Black & White printing depend on the used printer type. > For example, the tested > `HP Color LaserJet MFP M180n` printer uses `ColorModel` key and`Gray` value, and > `HP Ink Tank 110 series` uses `HPColorMode` key and `grayscale` value. > > Printing all `NSPrintInfo` presets shows that they do not contain key/value pairs for Black&White settings. > This is the code snippet used to print `NSPrintInfo` presets: > > PMPrinter pr; > PMPrintSession printSession = (PMPrintSession)[printInfo PMPrintSession]; > OSStatus status = PMSessionGetCurrentPrinter(printSession, &pr); > CFArrayRef presetsList = nil; > status = PMPrinterCopyPresets(pr, &presetsList); > CFIndex arrayCount = CFArrayGetCount(presetsList); > > for (CFIndex index = 0; index < arrayCount; index++) { > PMPreset preset = (PMPreset)CFArrayGetValueAtIndex(presetsList, index); > CFStringRef presetName = nil; > if (PMPresetCopyName(preset, &presetName) == noErr && CFStringGetLength(presetName) > 0) { > NSLog(@" presetName: '%@'", presetName); > NSDictionary* dict = nil; > if (PMPresetGetAttributes(preset, (CFDictionaryRef*)(&dict)) == noErr) { > // print preset dict > > > The idea of the proposed fix is to store printer dependent key/value pairs in the `/conf/printer.properties` property file. > > The property file has the format: > > print-attribute.print-attribute-value.key=value > > where `print-attribute` is the java print attribute, `print-attribute-value` is the corresponding attribute value, and `key` and `value` is the key/value pair used by a specific printer. > > For example, for `Chromaticity` attribute the property file could look like: > > Chromaticity.MONOCHROME.ColorModel=Gray > Chromaticity.COLOR.ColorModel=CMYK > Chromaticity.MONOCHROME.HPColorMode=grayscale > Chromaticity.COLOR.HPColorMode=color > > where `Chromaticity.MONOCHROME` key prefix corresponds to `Chromaticity.MONOCHOROME` print attribute constant with (... This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/18195 From duke at openjdk.org Thu Aug 1 19:12:05 2024 From: duke at openjdk.org (Daniel Gredler) Date: Thu, 1 Aug 2024 19:12:05 GMT Subject: RFR: JDK-8337681: PNGImageWriter uses more memory than necessary Message-ID: At some point the `JPEGImageWriter` was optimized to reduce duplication / copying of rasters and data buffers (see `JDK-6266748`). However, `PNGImageWriter` never received a similar optimization, and is making unnecessary copies of raster and data buffers whenever PNG images are written. Measurements: In a local test, `PNGImageWriter.write( )` and callees were initially showing up as an allocation hotspot (~400k objects / ~65 MB allocated), but after these optimizations I'm seeing much better numbers (~400 objects / ~740 KB allocated). ------------- Commit messages: - JDK-8337681: PNGImageWriter uses more memory than necessary Changes: https://git.openjdk.org/jdk/pull/20432/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20432&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8337681 Stats: 193 lines in 2 files changed: 188 ins; 1 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/20432.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20432/head:pull/20432 PR: https://git.openjdk.org/jdk/pull/20432 From djgredler at gmail.com Thu Aug 1 19:38:45 2024 From: djgredler at gmail.com (Daniel Gredler) Date: Thu, 1 Aug 2024 21:38:45 +0200 Subject: PNG image writing: memory inefficiency? In-Reply-To: <51911aa2-567b-44cb-9cf8-50eeb1129646@oracle.com> References: <51911aa2-567b-44cb-9cf8-50eeb1129646@oracle.com> Message-ID: Great! The PR is available here: https://github.com/openjdk/jdk/pull/20432 Do you have a few spare cycles to review / sponsor? Happy to make any adjustments, if I've overlooked something. Take care, Daniel On Thu, Aug 1, 2024 at 8:00?PM Phil Race wrote: > https://bugs.openjdk.org/browse/JDK-8337681 > > -phil. > On 8/1/2024 10:08, Daniel Gredler wrote: > > Thanks for the confirmation! > > I went ahead and made some measurements, and the improvement possibilities > really are quite good -- in a local test PNGImageWriter.write( ) and > callees were initially showing up as an allocation hotspot (~400k objects / > ~65 MB allocated), but after some optimizations I'm seeing much better > numbers (~400 objects / ~740 KB allocated). > > I also spent some time creating regression tests for different > combinations of alpha pre-multiplied vs. not, BufferedImage vs. other image > types, untiled vs. single-tile vs. multi-tile, custom source bands vs. > none, etc. > > I've filed a bug (internal review ID 9077379), but do not have a bug > number yet. Once I have a bug number I'll submit a PR for review. > > Take care, > > Daniel > > > On Wed, Jul 31, 2024 at 8:13?PM Philip Race > wrote: > >> I think yes. >> Whereas JPG grabs the raster for the whole image whereas as you noted, >> PNG is looping row by row, >> so there might need to be some updates in the handling of the child >> raster needed. >> >> -phil. >> >> >> On 7/31/24 10:02 AM, Daniel Gredler wrote: >> > Hi all, >> > >> > I'd like a quick sanity check on a possible memory inefficiency in >> > PNGImageWriter. >> > >> > Some of the other image writers, like JPEGImageWriter, do their best >> > to avoid duplicating the image raster + data buffer [1]... although it >> > doesn't look like this was always the case [2]. >> > >> > The PNGImageWriter, on the other hand, always makes a new raster + >> > data buffer copy for each row [3]. It *is* per-row, so the data isn't >> > all duplicated in one go, but even on a row-by-row basis, it ends up >> > being quite a bit of unnecessary allocation and subsequent garbage >> > collection. >> > >> > Can somebody confirm if I'm reading things right, and whether >> > PNGImageWriter would benefit from a similar BufferedImage + single >> > tile check, such as already exists in JPEGImageWriter? >> > >> > Thanks! >> > >> > Daniel >> > >> > [1] >> > >> https://github.com/openjdk/jdk/blob/e4c7850c177899a5da6f5050cb0647a6e1a75d31/src/java.desktop/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageWriter.java#L415 >> > [2] https://bugs.openjdk.org/browse/JDK-6266748 >> > [3] >> > >> https://github.com/openjdk/jdk/blob/e4c7850c177899a5da6f5050cb0647a6e1a75d31/src/java.desktop/share/classes/com/sun/imageio/plugins/png/PNGImageWriter.java#L923 >> > >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From prr at openjdk.org Thu Aug 1 21:01:30 2024 From: prr at openjdk.org (Phil Race) Date: Thu, 1 Aug 2024 21:01:30 GMT Subject: RFR: 8337681: PNGImageWriter uses much more memory than necessary In-Reply-To: References: Message-ID: On Thu, 1 Aug 2024 19:06:57 GMT, Daniel Gredler wrote: > At some point the `JPEGImageWriter` was optimized to reduce duplication / copying of rasters and data buffers (see `JDK-6266748`). However, `PNGImageWriter` never received a similar optimization, and is making unnecessary copies of raster and data buffers whenever PNG images are written. > > Measurements: In a local test, `PNGImageWriter.write( )` and callees were initially showing up as an allocation hotspot (~400k objects / ~65 MB allocated), but after these optimizations I'm seeing much better numbers (~400 objects / ~740 KB allocated). I'm going to put it through our internal test system. test/jdk/javax/imageio/plugins/png/RasterReuseWriteTest.java line 49: > 47: > 48: public static void main(String[] args) throws Exception { > 49: test(BufferedImage.TYPE_INT_ARGB); can you also test INT_RGB at least ? ------------- PR Review: https://git.openjdk.org/jdk/pull/20432#pullrequestreview-2213833024 PR Review Comment: https://git.openjdk.org/jdk/pull/20432#discussion_r1700787185 From duke at openjdk.org Thu Aug 1 21:51:04 2024 From: duke at openjdk.org (Daniel Gredler) Date: Thu, 1 Aug 2024 21:51:04 GMT Subject: RFR: 8337681: PNGImageWriter uses much more memory than necessary [v2] In-Reply-To: References: Message-ID: On Thu, 1 Aug 2024 20:11:51 GMT, Phil Race wrote: >> Daniel Gredler has updated the pull request incrementally with two additional commits since the last revision: >> >> - JDK-8337681: add tests for TYPE_4BYTE_ABGR >> - JDK-8337681: add tests for TYPE_INT_RGB > > test/jdk/javax/imageio/plugins/png/RasterReuseWriteTest.java line 49: > >> 47: >> 48: public static void main(String[] args) throws Exception { >> 49: test(BufferedImage.TYPE_INT_ARGB); > > can you also test INT_RGB at least ? No problem, I've added `TYPE_INT_RGB`, `TYPE_4BYTE_ABGR` and `TYPE_4BYTE_ABGR_PRE`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20432#discussion_r1700905718 From duke at openjdk.org Thu Aug 1 21:51:04 2024 From: duke at openjdk.org (Daniel Gredler) Date: Thu, 1 Aug 2024 21:51:04 GMT Subject: RFR: 8337681: PNGImageWriter uses much more memory than necessary [v2] In-Reply-To: References: Message-ID: <8ZstKFyu435jMQ9_44gJwjCtz1N1at3B_wqbsDi2msE=.aede545e-7d62-4af6-9f51-5682a5281ac3@github.com> > At some point the `JPEGImageWriter` was optimized to reduce duplication / copying of rasters and data buffers (see `JDK-6266748`). However, `PNGImageWriter` never received a similar optimization, and is making unnecessary copies of raster and data buffers whenever PNG images are written. > > Measurements: In a local test, `PNGImageWriter.write( )` and callees were initially showing up as an allocation hotspot (~400k objects / ~65 MB allocated), but after these optimizations I'm seeing much better numbers (~400 objects / ~740 KB allocated). Daniel Gredler has updated the pull request incrementally with two additional commits since the last revision: - JDK-8337681: add tests for TYPE_4BYTE_ABGR - JDK-8337681: add tests for TYPE_INT_RGB ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20432/files - new: https://git.openjdk.org/jdk/pull/20432/files/bf1632ac..9285d44c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20432&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20432&range=00-01 Stats: 9 lines in 1 file changed: 8 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20432.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20432/head:pull/20432 PR: https://git.openjdk.org/jdk/pull/20432 From prr at openjdk.org Thu Aug 1 22:34:34 2024 From: prr at openjdk.org (Phil Race) Date: Thu, 1 Aug 2024 22:34:34 GMT Subject: RFR: 8336289: Obliterate most references to _snprintf in the Windows JDK [v3] In-Reply-To: References: Message-ID: On Tue, 16 Jul 2024 08:59:20 GMT, Julian Waters wrote: >> snprintf has been available for all officially and unofficially supported compilers for Windows, Visual Studio since version 2015 and gcc since, well, forever. snprintf is conforming to C99 since the start when compiling using gcc, and 2015 when using Visual Studio. Since it conforms to C99 and provides better semantics than _snprintf, and is not compiler specific, we should use it in most places where we currently use _snprintf. This makes JDK code where this is used more robust due to the null terminating guarantee of snprintf. Since most of the changes are extremely simple, I've included all of them hoping to get this all done in one shot. The only places _snprintf is not replaced is places where I'm not sure whether the code is ours or not (As in, imported source code for external libraries). Note that the existing checks in place for the size of the characters written still work, as the return value of snprintf works mostly the same as _snprintf. The only difference is the nu ll terminating character at the end and the returning of the number of written characters if the buffer was terminated early, as seen here: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170 >> >> Reviews Required: 2 for HotSpot, jdk.hotspot.agent, and jdk.jdwp.agent, 1 for awt and jdk.accessibility, 1 for java.base, 1 for security, 1 for jdk.management(?) > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > Revert Standard Integer type rewrite AWT + A11Y ------------- Marked as reviewed by prr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20153#pullrequestreview-2214138343 From prr at openjdk.org Thu Aug 1 22:36:33 2024 From: prr at openjdk.org (Phil Race) Date: Thu, 1 Aug 2024 22:36:33 GMT Subject: RFR: 8329471: Remove GTK2 [v5] In-Reply-To: References: Message-ID: On Wed, 31 Jul 2024 19:17:05 GMT, Alexander Zvegintsev wrote: >> GTK2 support for Swing/AWT was deprecated for removal in JDK 21. >> >> It's being removed because no platform that supports the JDK needs it. >> >> Manual and automated testing is green. > > Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: > > more removal of is3() Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20378#pullrequestreview-2214142837 From achung at openjdk.org Thu Aug 1 23:54:03 2024 From: achung at openjdk.org (Alisen Chung) Date: Thu, 1 Aug 2024 23:54:03 GMT Subject: RFR: 8235404: [macos] JOptionPane blocks drawing string on another component Message-ID: Currently if you try to use graphics to draw a string on a frame using JOptionPane + JTextField with a listener as a prompt, the string will not draw. Adding a repaint after dialog.dispose in JOptionPane will cause the text to show after the dialog is closed. ------------- Commit messages: - update test - update test - add test - init commit Changes: https://git.openjdk.org/jdk/pull/20359/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20359&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8235404 Stats: 85 lines in 2 files changed: 84 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20359.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20359/head:pull/20359 PR: https://git.openjdk.org/jdk/pull/20359 From honkar at openjdk.org Thu Aug 1 23:54:03 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Thu, 1 Aug 2024 23:54:03 GMT Subject: RFR: 8235404: [macos] JOptionPane blocks drawing string on another component In-Reply-To: References: Message-ID: On Fri, 26 Jul 2024 16:52:44 GMT, Alisen Chung wrote: > Currently if you try to use graphics to draw a string on a frame using JOptionPane + JTextField with a listener as a prompt, the string will not draw. Adding a repaint after dialog.dispose in JOptionPane will cause the text to show after the dialog is closed. The test requires clean-up there are couple of commented lines. JBS issue does not seem to be linked, can you check by adding. `/issue add 8235404` Test summary in jtreg needs an update test/jdk/javax/swing/JOptionPane/OptionPaneInput.java line 86: > 84: f.setSize(300,100); > 85: PassFailJFrame.addTestWindow(f); > 86: PassFailJFrame.positionTestWindow(f, PassFailJFrame.Position.HORIZONTAL); The JOptionPane can be add as a split window using PassFailJFrame.splitUI() since currently it gets blocked by the testUI. test/jdk/javax/swing/JOptionPane/OptionPaneInput.java line 89: > 87: f.setVisible(true); > 88: > 89: JOptionPane.showMessageDialog(null, t); Since parentComponent of JOptionPane is null running into NPE. parentComponent.revalidate(); parentComponent.repaint(); ------------- Changes requested by honkar (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20359#pullrequestreview-2214212950 PR Review Comment: https://git.openjdk.org/jdk/pull/20359#discussion_r1700999612 PR Review Comment: https://git.openjdk.org/jdk/pull/20359#discussion_r1700994254 From abhiscxk at openjdk.org Thu Aug 1 23:54:04 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Thu, 1 Aug 2024 23:54:04 GMT Subject: RFR: 8235404: [macos] JOptionPane blocks drawing string on another component In-Reply-To: References: Message-ID: On Fri, 26 Jul 2024 16:52:44 GMT, Alisen Chung wrote: > Currently if you try to use graphics to draw a string on a frame using JOptionPane + JTextField with a listener as a prompt, the string will not draw. Adding a repaint after dialog.dispose in JOptionPane will cause the text to show after the dialog is closed. Could you please add a test case to validate the fix ? test/jdk/javax/swing/JOptionPane/OptionPaneInput.java line 41: > 39: * @test > 40: * @bug 8235404 > 41: * @summary temp Please update summary. test/jdk/javax/swing/JOptionPane/OptionPaneInput.java line 44: > 42: * @library /java/awt/regtesthelpers > 43: * @build PassFailJFrame > 44: * @run main OptionPaneInput Suggestion: * @run main/manual OptionPaneInput test/jdk/javax/swing/JOptionPane/OptionPaneInput.java line 58: > 56: > 57: public static void main(String[] args) throws Exception { > 58: // UIManager.setLookAndFeel("com.sun.java.swing.plaf.motif.MotifLookAndFeel"); Please remove commented lines. test/jdk/javax/swing/JOptionPane/OptionPaneInput.java line 73: > 71: > 72: // RepaintManager.currentManager(f).setDoubleBufferingEnabled(false); > 73: // RepaintManager.currentManager(c).setDoubleBufferingEnabled(false); Please remove commented lines. test/jdk/javax/swing/JOptionPane/OptionPaneInput.java line 100: > 98: // g2.setColor(Color.BLACK); > 99: // g2.drawString("Dialog Closed", 10, 25); > 100: // g2.dispose(); Please remove commented lines. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20359#issuecomment-2257719774 PR Review Comment: https://git.openjdk.org/jdk/pull/20359#discussion_r1697897139 PR Review Comment: https://git.openjdk.org/jdk/pull/20359#discussion_r1697897469 PR Review Comment: https://git.openjdk.org/jdk/pull/20359#discussion_r1697897717 PR Review Comment: https://git.openjdk.org/jdk/pull/20359#discussion_r1697897950 PR Review Comment: https://git.openjdk.org/jdk/pull/20359#discussion_r1697897827 From honkar at openjdk.org Fri Aug 2 00:26:31 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Fri, 2 Aug 2024 00:26:31 GMT Subject: RFR: 8235404: [macos] JOptionPane blocks drawing string on another component In-Reply-To: References: Message-ID: <0s6SZvTeJdFtKAwulwUfbs9GcR_ibe-TgD7TO0xc_9Y=.5041192e-6b13-474d-ab2d-0c430c693182@github.com> On Thu, 1 Aug 2024 23:19:35 GMT, Harshitha Onkar wrote: >> Currently if you try to use graphics to draw a string on a frame using JOptionPane + JTextField with a listener as a prompt, the string will not draw. Adding a repaint after dialog.dispose in JOptionPane will cause the text to show after the dialog is closed. > > test/jdk/javax/swing/JOptionPane/OptionPaneInput.java line 89: > >> 87: f.setVisible(true); >> 88: >> 89: JOptionPane.showMessageDialog(null, t); > > Since parentComponent of JOptionPane is null running into NPE. > > > parentComponent.revalidate(); > parentComponent.repaint(); The fix should handle both cases - when parentComponent is null and not null. With current fix, if there is a case when parentComponent is null, we will run into NPE. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20359#discussion_r1701040297 From psadhukhan at openjdk.org Fri Aug 2 03:45:37 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 2 Aug 2024 03:45:37 GMT Subject: RFR: 7188058: Background of TextComponents are not changing colors to the default disabled color when set to uneditable [v2] In-Reply-To: References: Message-ID: <77lt11qmN9Pift0gg2CmeN1v1CRSv4nP50d8hdNPynU=.f2f65d8a-293d-48c2-81d4-0b945cfcb158@github.com> On Thu, 25 Jul 2024 00:02:07 GMT, Alisen Chung wrote: >> Currently the bug described in the issue is that the colors of the TextComponents do not change when setting TextComponents to uneditable. The default uneditable color (SystemColor.control) happens to be the same as the default for the editable color for some L&Fs, so the fix may not be initially noticeable. However, the bug still exists where the the color is not being changed when changing between editable and uneditable. You can check by changing TextComponent.getBackground() code to return Color.GRAY on line 342 and you can see that TextComponents are not changing to a gray background when set to uneditable. >> >> This fix adds a private setBackground method in TextComponent so that TextArea and TextField can change the background color to the correct color (SystemColor.control) when set uneditable by overriding the TextComponent setEditable. You can verify the fix by changing this color to Color.GRAY and verifying the backgrounds change to gray when the TextComponents are disabled. > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > moved test to awt src/java.desktop/share/classes/java/awt/TextArea.java line 613: > 611: public synchronized void setEditable(boolean b) { > 612: super.setEditable(b); > 613: Color defaultBackground = UIManager.getColor("TextArea.background"); I am not sure if it is ok to use swing "UIManager" class in awt I guess long time back somebody maybe @prrace mentioned that we should avoid calling swing class from awt? I see we use AttributeSet in TextComponent for accessibility usage but am not sure if we can use without restriction? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19876#discussion_r1701169618 From psadhukhan at openjdk.org Fri Aug 2 04:37:32 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 2 Aug 2024 04:37:32 GMT Subject: RFR: 8335130: The test "javax/swing/plaf/synth/ComponentsOrientationSupport/5033822/bug5033822.java" fails because the background color of the tabs is displayed incorrectly. In-Reply-To: References: Message-ID: <6cL06n6igHaVpMiHoua_UcfhY7F8bUkFibFowzkW4Xk=.c2943cd8-d9da-413a-aae7-adc6e64164df@github.com> On Tue, 9 Jul 2024 06:13:15 GMT, Abhishek Kumar wrote: > Issue is due to the condition added for the opaque property of SynthTabbedPane in [JDK-8226990](https://bugs.openjdk.org/browse/JDK-8226990). The previous fix for GTK and Nimbus was handled commonly in `SynthTabbedPaneUI` class to render the tabs based on opaque property. Since the Synth package is responsible to create a custom L&F using user defined XML file. In this test the L&F is fetched through the XML file and when `SynthTabbedPaneUI` APIs are invoked for the tab rendering, it is not correctly rendered. Setting the opaque property to true also doesn't help as the selected tab is rendered incorrectly. The proposed fix is to move the fix to GTK and Nimbus specific class and that will not cause any impact on custom xml based L&F. src/java.desktop/share/classes/javax/swing/plaf/synth/SynthTabbedPaneUI.java line 656: > 654: } > 655: > 656: tabContext.getPainter().paintTabbedPaneTabBackground(tabContext, g, what about the check `tabPane.isOpaque()))` in l764, will it still be needed? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20091#discussion_r1687642165 From abhiscxk at openjdk.org Fri Aug 2 04:50:38 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Fri, 2 Aug 2024 04:50:38 GMT Subject: RFR: 8329756: [macos] "javax/swing/JTable/KeyBoardNavigation.java" fail because most combinations of navigational keys with the Ctrl key do not work [v3] In-Reply-To: <-_r00_X3CFOOeuP4FB_KRSceZJyswN1qnjwTY30mbpk=.30bb60f5-429d-4607-b428-764a1d88074e@github.com> References: <_EJU3BR9GXNSzKni34YlZjY4conL9GcS0dLyUO67L18=.5b26c6a9-c4f2-49e9-8ff6-e18e8cf088af@github.com> <-_r00_X3CFOOeuP4FB_KRSceZJyswN1qnjwTY30mbpk=.30bb60f5-429d-4607-b428-764a1d88074e@github.com> Message-ID: On Tue, 30 Jul 2024 05:05:22 GMT, Tejesh R wrote: > Yeah, it was missed from previous updates and initial test instructions. Will take it up separately, coz might have to update Linux action command based on native functionality. Ok... please check for linux and raise a bug if it is required. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20331#discussion_r1701252756 From psadhukhan at openjdk.org Fri Aug 2 04:51:13 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 2 Aug 2024 04:51:13 GMT Subject: RFR: 8335231: [macos] Test java/awt/print/PrinterJob/Cancel/PrinterJobCancel.java failed on macOS because the case didn't get the expected PrintAbortException [v4] In-Reply-To: References: Message-ID: > When a printjob is cancelled midway, `PrinterAbortException `was not thrown in macos. because > firstly,` cancelCheck` invokes` LWCToolkit.invokeLater` with null as parameter causing it to fail with NPE and > secondly PrinterAbortException was consumed silently when `printLoop` throws any exception > which is rectified to throw the PrinterAbortException when encountered.. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Use EventQueue.invokeLater ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20027/files - new: https://git.openjdk.org/jdk/pull/20027/files/c4c7f9d7..6750e51f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20027&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20027&range=02-03 Stats: 9 lines in 1 file changed: 0 ins; 3 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/20027.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20027/head:pull/20027 PR: https://git.openjdk.org/jdk/pull/20027 From psadhukhan at openjdk.org Fri Aug 2 04:57:34 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 2 Aug 2024 04:57:34 GMT Subject: RFR: 8335231: [macos] Test java/awt/print/PrinterJob/Cancel/PrinterJobCancel.java failed on macOS because the case didn't get the expected PrintAbortException [v3] In-Reply-To: References: <1w-vJq4R769dS3TunRyONDDTvpRbBJV_OClh3Hz2nHk=.efb94e40-fce7-40ca-a351-9e9d00af2f3f@github.com> Message-ID: On Thu, 1 Aug 2024 18:26:50 GMT, Phil Race wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: >> >> Restore invokeLater and throw PrinterAbortException from native > > src/java.desktop/macosx/classes/sun/lwawt/macosx/CPrinterJob.java line 764: > >> 762: } >> 763: }}, null); >> 764: } catch (NullPointerException ex) { > > I'm confused. I thought you were going to do something about the null ? > Unless you don't this code won't work. > Restoring using invokeLater isn't the same thing as restoring the bug. > > Look at the code that you are calling - it won't run the Runnable if there's an NPE. > "new Component()" instead of null for example. > FWIW I do not understand why this code uses LWCToolkit.invokeLater() > Seems unnecessary. > Why don't it use EventQueue.invokeLater() directly ? > That'll solve a couple of problems - simpler code, no null check because no Component arg needed. Yes, actually I wanted to avoid changing the common `LWCToolkit.invokeLater` (as it needs to use Toolkit.getToolkit if component is null as I was not sure if it is ok to pass any adhoc component via `new Component `in CPrinterJob) which is also used in [accessibility](https://github.com/openjdk/jdk/blob/d10afa26e5c59475e49b353ed34e8e85d0615d92/src/java.desktop/macosx/classes/sun/lwawt/macosx/CAccessibility.java#L148) and [InputMethod](https://github.com/openjdk/jdk/blob/d10afa26e5c59475e49b353ed34e8e85d0615d92/src/java.desktop/macosx/classes/sun/lwawt/macosx/CInputMethod.java#L499) which would have affected and require testing in those areas but yes, I didn't see having NPE will render invokeLater a no-op Changed to use EventQueue.invokeLater.. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20027#discussion_r1701258601 From abhiscxk at openjdk.org Fri Aug 2 06:17:39 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Fri, 2 Aug 2024 06:17:39 GMT Subject: RFR: 8335130: The test "javax/swing/plaf/synth/ComponentsOrientationSupport/5033822/bug5033822.java" fails because the background color of the tabs is displayed incorrectly. In-Reply-To: <6cL06n6igHaVpMiHoua_UcfhY7F8bUkFibFowzkW4Xk=.c2943cd8-d9da-413a-aae7-adc6e64164df@github.com> References: <6cL06n6igHaVpMiHoua_UcfhY7F8bUkFibFowzkW4Xk=.c2943cd8-d9da-413a-aae7-adc6e64164df@github.com> Message-ID: On Tue, 23 Jul 2024 08:23:50 GMT, Prasanta Sadhukhan wrote: >> Issue is due to the condition added for the opaque property of SynthTabbedPane in [JDK-8226990](https://bugs.openjdk.org/browse/JDK-8226990). The previous fix for GTK and Nimbus was handled commonly in `SynthTabbedPaneUI` class to render the tabs based on opaque property. Since the Synth package is responsible to create a custom L&F using user defined XML file. In this test the L&F is fetched through the XML file and when `SynthTabbedPaneUI` APIs are invoked for the tab rendering, it is not correctly rendered. Setting the opaque property to true also doesn't help as the selected tab is rendered incorrectly. The proposed fix is to move the fix to GTK and Nimbus specific class and that will not cause any impact on custom xml based L&F. > > src/java.desktop/share/classes/javax/swing/plaf/synth/SynthTabbedPaneUI.java line 656: > >> 654: } >> 655: >> 656: tabContext.getPainter().paintTabbedPaneTabBackground(tabContext, g, > > what about the check `tabPane.isOpaque()))` in l764, will it still be needed? Yeah, it is still needed. If `contentOpaque` property is set to `false` but tabPane opacity is set to `true`, then the content area needs to fill with the set graphics color. By default `tabPane.isOpaque()` return `false`, it depends on the contentOpaque property to have a effect on content area background filling. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20091#discussion_r1701333467 From abhiscxk at openjdk.org Fri Aug 2 07:33:34 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Fri, 2 Aug 2024 07:33:34 GMT Subject: RFR: 8329756: [macos] "javax/swing/JTable/KeyBoardNavigation.java" fail because most combinations of navigational keys with the Ctrl key do not work [v3] In-Reply-To: References: Message-ID: On Tue, 30 Jul 2024 05:17:12 GMT, Tejesh R wrote: >> Mismatch in key combinations, I have taken native macos Numbers application as reference to verify. Have added `Ctrl-Shift Left/Right` action keys similar to `Ctrl-Shift UP/DOWN` which would be expected functionality. I've removed those test instructions which are not applicable/implemented/not working in Macos keyboard navigation. > > Tejesh R has updated the pull request incrementally with one additional commit since the last revision: > > Review fix Changes look good to me. ------------- Marked as reviewed by abhiscxk (Committer). PR Review: https://git.openjdk.org/jdk/pull/20331#pullrequestreview-2214875484 From tr at openjdk.org Fri Aug 2 09:17:06 2024 From: tr at openjdk.org (Tejesh R) Date: Fri, 2 Aug 2024 09:17:06 GMT Subject: RFR: 8233068: HIDPI: Linux: AWT Checkbox check mark is unscaled Message-ID: The check mark had been transformed with default scale which is 1.0 and the same is used on click of checkbox. This was done while computing the layout and not updated while paint. Hence the scaling update is done on painting the check mark and CI testing is green after the update too. ------------- Commit messages: - Removed whitespace - Fix + Automated test Changes: https://git.openjdk.org/jdk/pull/20441/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20441&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8233068 Stats: 104 lines in 2 files changed: 102 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20441.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20441/head:pull/20441 PR: https://git.openjdk.org/jdk/pull/20441 From aivanov at openjdk.org Fri Aug 2 13:09:43 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 2 Aug 2024 13:09:43 GMT Subject: Integrated: 8337274: Remove repeated 'the' in StyleSheet.create{Small,Large}AttributeSet In-Reply-To: References: Message-ID: <01oC8Q11b1pPiQ04tuaycu_Rop1s8M8Rq94uCrh1NHo=.959f6b81-a55e-4c90-a2e2-672e353e264f@github.com> On Fri, 26 Jul 2024 14:10:59 GMT, Alexey Ivanov wrote: > A trivial fix which removes the repeated word ?the? from the parameter description for `StyleSheet.create{Small,Large}AttributeSet` methods. These methods are public API. > > Additionally, I dropped repeated ?then? from the description of a private method. This pull request has now been integrated. Changeset: 066db6eb Author: Alexey Ivanov URL: https://git.openjdk.org/jdk/commit/066db6eb21e9c9202857f9f6adfcd537a0b82160 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod 8337274: Remove repeated 'the' in StyleSheet.create{Small,Large}AttributeSet Reviewed-by: achung, honkar, prr ------------- PR: https://git.openjdk.org/jdk/pull/20352 From prr at openjdk.org Fri Aug 2 18:54:31 2024 From: prr at openjdk.org (Phil Race) Date: Fri, 2 Aug 2024 18:54:31 GMT Subject: RFR: 8337681: PNGImageWriter uses much more memory than necessary [v2] In-Reply-To: <8ZstKFyu435jMQ9_44gJwjCtz1N1at3B_wqbsDi2msE=.aede545e-7d62-4af6-9f51-5682a5281ac3@github.com> References: <8ZstKFyu435jMQ9_44gJwjCtz1N1at3B_wqbsDi2msE=.aede545e-7d62-4af6-9f51-5682a5281ac3@github.com> Message-ID: On Thu, 1 Aug 2024 21:51:04 GMT, Daniel Gredler wrote: >> At some point the `JPEGImageWriter` was optimized to reduce duplication / copying of rasters and data buffers (see `JDK-6266748`). However, `PNGImageWriter` never received a similar optimization, and is making unnecessary copies of raster and data buffers whenever PNG images are written. >> >> Measurements: In a local test, `PNGImageWriter.write( )` and callees were initially showing up as an allocation hotspot (~400k objects / ~65 MB allocated), but after these optimizations I'm seeing much better numbers (~400 objects / ~740 KB allocated). > > Daniel Gredler has updated the pull request incrementally with two additional commits since the last revision: > > - JDK-8337681: add tests for TYPE_4BYTE_ABGR > - JDK-8337681: add tests for TYPE_INT_RGB Marked as reviewed by prr (Reviewer). I've approved but we do require 2 approvals for client fixes. ------------- PR Review: https://git.openjdk.org/jdk/pull/20432#pullrequestreview-2216207549 PR Comment: https://git.openjdk.org/jdk/pull/20432#issuecomment-2265958401 From duke at openjdk.org Fri Aug 2 20:37:31 2024 From: duke at openjdk.org (Daniel Gredler) Date: Fri, 2 Aug 2024 20:37:31 GMT Subject: RFR: 8337681: PNGImageWriter uses much more memory than necessary [v2] In-Reply-To: References: <8ZstKFyu435jMQ9_44gJwjCtz1N1at3B_wqbsDi2msE=.aede545e-7d62-4af6-9f51-5682a5281ac3@github.com> Message-ID: On Fri, 2 Aug 2024 18:51:33 GMT, Phil Race wrote: >> Daniel Gredler has updated the pull request incrementally with two additional commits since the last revision: >> >> - JDK-8337681: add tests for TYPE_4BYTE_ABGR >> - JDK-8337681: add tests for TYPE_INT_RGB > > I've approved but we do require 2 approvals for client fixes. @prrace: Thanks! @Team: Could another reviewer take a look at this PR and provide feedback? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20432#issuecomment-2266113261 From honkar at openjdk.org Fri Aug 2 21:26:32 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Fri, 2 Aug 2024 21:26:32 GMT Subject: RFR: 8233068: HIDPI: Linux: AWT Checkbox check mark is unscaled In-Reply-To: References: Message-ID: On Fri, 2 Aug 2024 09:07:47 GMT, Tejesh R wrote: > The check mark had been transformed with default scale which is 1.0 and the same is used on click of checkbox. This was done while computing the layout and not updated while paint. Hence the scaling update is done on painting the check mark and CI testing is green after the update too. The fix looks good. I ran the reproducer and the test passed without the fix too (on external monitor). Maybe the test condition can be tweaked. test/jdk/java/awt/Checkbox/CheckboxCheckerScalingTest.java line 74: > 72: for (int i = 0; i < imageAfterChecked.getHeight(); i++) { > 73: for (int j = 0; j < imageAfterChecked.getWidth(); j++) { > 74: if (sampleRGB != imageAfterChecked.getRGB(i, j)) { Maybe check for the tick color (black) within the checkbox? ------------- Changes requested by honkar (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20441#pullrequestreview-2216417294 PR Review Comment: https://git.openjdk.org/jdk/pull/20441#discussion_r1702331172 From achung at openjdk.org Fri Aug 2 21:35:37 2024 From: achung at openjdk.org (Alisen Chung) Date: Fri, 2 Aug 2024 21:35:37 GMT Subject: RFR: 6318027: BasicScrollBarUI does not disable timer when enclosing frame is disabled. In-Reply-To: <_g5SYdkcap5xfK58rwbdm3ZRCcLsOefVKhiSYLtk8Ow=.ea12bbde-7f7e-45af-ad56-571bd0f041af@github.com> References: <_g5SYdkcap5xfK58rwbdm3ZRCcLsOefVKhiSYLtk8Ow=.ea12bbde-7f7e-45af-ad56-571bd0f041af@github.com> Message-ID: <4TML2eKsoCAd8McEefOMoAxEBFFom5423HsoorVtFuc=.617f22e2-fd42-44bb-9644-8de718112f8e@github.com> On Thu, 1 Aug 2024 04:53:14 GMT, Abhishek Kumar wrote: >> Issue is >> BasicScrollBarUI.ArrowButtonListener starts a timer in mousePressed(), and stops it in mouseReleased(). If the frame containing the scrollbar is disabled between the MOUSE_PRESSED and the MOUSE_RELEASED events, the mouseReleased() method is never called. If the frame is then re-enabled, the still-running timer causes it to scroll all the way to the end. >> Fix is to check if [ArrowButtonListener.handledEvent](https://github.com/openjdk/jdk/blame/ee839b7f0ebe471d3877cddd2c87019ccb8ee5ae/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicScrollBarUI.java#L1567) is still set when ActionEvent is processed then stop the timer and reset this variable. >> >> CI testing is green and also SwingSet2 JScrollPane scrolling with this modification.. > > src/java.desktop/share/classes/javax/swing/plaf/basic/BasicScrollBarUI.java line 1614: > >> 1612: // mouseReleased is not called after mousePressed when >> 1613: // this AcionEvent is being processed >> 1614: if (buttonListener.handledEvent) { > > Since the fix is added in BasicScrollBarUI, will it affect Aqua ScrollBar also? I think most L&F's ScrollBarUI classes are extending BasicScrollBarUI so it might be worth checking if this issue also occurs in those L&Fs too ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20346#discussion_r1702335812 From achung at openjdk.org Sat Aug 3 04:33:32 2024 From: achung at openjdk.org (Alisen Chung) Date: Sat, 3 Aug 2024 04:33:32 GMT Subject: RFR: 8233068: HIDPI: Linux: AWT Checkbox check mark is unscaled In-Reply-To: References: Message-ID: On Fri, 2 Aug 2024 09:07:47 GMT, Tejesh R wrote: > The check mark had been transformed with default scale which is 1.0 and the same is used on click of checkbox. This was done while computing the layout and not updated while paint. Hence the scaling update is done on painting the check mark and CI testing is green after the update too. src/java.desktop/unix/classes/sun/awt/X11/XCheckboxPeer.java line 1: > 1: /* update copyright year in this file ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20441#discussion_r1702456282 From lbourges at openjdk.org Sat Aug 3 10:30:32 2024 From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Sat, 3 Aug 2024 10:30:32 GMT Subject: RFR: 8337681: PNGImageWriter uses much more memory than necessary [v2] In-Reply-To: <8ZstKFyu435jMQ9_44gJwjCtz1N1at3B_wqbsDi2msE=.aede545e-7d62-4af6-9f51-5682a5281ac3@github.com> References: <8ZstKFyu435jMQ9_44gJwjCtz1N1at3B_wqbsDi2msE=.aede545e-7d62-4af6-9f51-5682a5281ac3@github.com> Message-ID: On Thu, 1 Aug 2024 21:51:04 GMT, Daniel Gredler wrote: >> At some point the `JPEGImageWriter` was optimized to reduce duplication / copying of rasters and data buffers (see `JDK-6266748`). However, `PNGImageWriter` never received a similar optimization, and is making unnecessary copies of raster and data buffers whenever PNG images are written. >> >> Measurements: In a local test, `PNGImageWriter.write( )` and callees were initially showing up as an allocation hotspot (~400k objects / ~65 MB allocated), but after these optimizations I'm seeing much better numbers (~400 objects / ~740 KB allocated). > > Daniel Gredler has updated the pull request incrementally with two additional commits since the last revision: > > - JDK-8337681: add tests for TYPE_4BYTE_ABGR > - JDK-8337681: add tests for TYPE_INT_RGB Lgtm, just an overall look to png writer changes I will have a look if nobody else ramps up... ------------- Marked as reviewed by lbourges (Committer). PR Review: https://git.openjdk.org/jdk/pull/20432#pullrequestreview-2217017106 PR Comment: https://git.openjdk.org/jdk/pull/20432#issuecomment-2266667599 From duke at openjdk.org Sat Aug 3 10:53:30 2024 From: duke at openjdk.org (duke) Date: Sat, 3 Aug 2024 10:53:30 GMT Subject: RFR: 8337681: PNGImageWriter uses much more memory than necessary [v2] In-Reply-To: <8ZstKFyu435jMQ9_44gJwjCtz1N1at3B_wqbsDi2msE=.aede545e-7d62-4af6-9f51-5682a5281ac3@github.com> References: <8ZstKFyu435jMQ9_44gJwjCtz1N1at3B_wqbsDi2msE=.aede545e-7d62-4af6-9f51-5682a5281ac3@github.com> Message-ID: On Thu, 1 Aug 2024 21:51:04 GMT, Daniel Gredler wrote: >> At some point the `JPEGImageWriter` was optimized to reduce duplication / copying of rasters and data buffers (see `JDK-6266748`). However, `PNGImageWriter` never received a similar optimization, and is making unnecessary copies of raster and data buffers whenever PNG images are written. >> >> Measurements: In a local test, `PNGImageWriter.write( )` and callees were initially showing up as an allocation hotspot (~400k objects / ~65 MB allocated), but after these optimizations I'm seeing much better numbers (~400 objects / ~740 KB allocated). > > Daniel Gredler has updated the pull request incrementally with two additional commits since the last revision: > > - JDK-8337681: add tests for TYPE_4BYTE_ABGR > - JDK-8337681: add tests for TYPE_INT_RGB @gredler Your change (at version 9285d44cc62233fce2283f4844dc055fa0720a5c) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20432#issuecomment-2266673962 From duke at openjdk.org Sat Aug 3 18:12:39 2024 From: duke at openjdk.org (lawrence.andrews) Date: Sat, 3 Aug 2024 18:12:39 GMT Subject: RFR: 8328553: Get rid of JApplet in test/jdk/sanity/client/lib/SwingSet2/src/DemoModule.java Message-ID: 1) Replaced JApplet with JPanel 2) Tests passed before and after fix ------------- Commit messages: - Left a blank line at the end of the file - 8328553: Get rid of JApplet in test/jdk/sanity/client/lib/SwingSet2/src/DemoModule.java Changes: https://git.openjdk.org/jdk/pull/20450/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20450&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8328553 Stats: 11 lines in 1 file changed: 1 ins; 7 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/20450.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20450/head:pull/20450 PR: https://git.openjdk.org/jdk/pull/20450 From javalists at cbfiddle.com Sun Aug 4 19:38:09 2024 From: javalists at cbfiddle.com (Alan Snyder) Date: Sun, 4 Aug 2024 12:38:09 -0700 Subject: suggested clarification Message-ID: <1DB54193-A592-4D90-BF01-E611453C5559@cbfiddle.com> The spec for javax.swing.text.View.viewToModel(float x, float y, Shape a, Position.Bias[] biasReturn) says: "The biasReturn argument will be filled in to indicate that the point given is closer to the next character in the model or the previous character in the model.? It looks like a non-null value is always stored and in the case where the point is equidistant the value is Forward. One could read the spec and not rule out a null being stored in the equidistant case. From prr at openjdk.org Sun Aug 4 21:47:34 2024 From: prr at openjdk.org (Phil Race) Date: Sun, 4 Aug 2024 21:47:34 GMT Subject: RFR: 8335231: [macos] Test java/awt/print/PrinterJob/Cancel/PrinterJobCancel.java failed on macOS because the case didn't get the expected PrintAbortException [v4] In-Reply-To: References: Message-ID: On Fri, 2 Aug 2024 04:51:13 GMT, Prasanta Sadhukhan wrote: >> When a printjob is cancelled midway, `PrinterAbortException `was not thrown in macos. because >> firstly,` cancelCheck` invokes` LWCToolkit.invokeLater` with null as parameter causing it to fail with NPE and >> secondly PrinterAbortException was consumed silently when `printLoop` throws any exception >> which is rectified to throw the PrinterAbortException when encountered.. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Use EventQueue.invokeLater I think we still have some things to look at here (1) The job still gets queued for printing - should it ? Ideally not if there's some thing we can do. (2) The "Error during printing" dialog I get after running the test is from macOS not us. Should it happen ? (3) There's also an NSException printed which is because a call to CHECK_EXCEPTION thinks the pending Java Exception is an error from an upcall made after terminating the print loop. Here is the NSException printed for (3) : 2024-08-02 13:34:54.360 java[50622:37988054] Java Exception 2024-08-02 13:34:54.360 java[50622:37988054] ( 0 CoreFoundation 0x00007ff8045ed11a __exceptionPreprocess + 242 1 libobjc.A.dylib 0x00007ff8041120b7 objc_exception_throw + 48 2 CoreFoundation 0x00007ff8045ecf80 +[NSException raise:format:] + 214 3 libawt_lwawt.dylib 0x0000000127355ed8 -[PrinterView complete:] + 552 4 libawt_lwawt.dylib 0x0000000127354050 -[PrintModel safePrintLoop:withEnv:] + 176 5 libawt_lwawt.dylib 0x00000001272f68ef Java_sun_lwawt_macosx_CPrinterJob_printLoop + 3871 6 ??? 0x000000011455ca87 0x0 + 4636134023 ) Note it is not a Java Exception, it is an NSException and we log this from JNI_COCOA_EXIT after we catch it. Perhaps we should only log this if a debugging flag is set .. but at least in this case it helped me see the problem (3). So what's going on with (3)? - I can partly help explain that. When we get an unexpected Java Exception from a JNI call and need to bail back up to Java we use NSException to do this. Unexpected exceptions mean bad method lookups, eg up calls that create an unexpected exception etc. If an NSException is raised Objective-C transfers control to the next "catch" - which is in this case JNI_COCOA_EXIT This particular NSException happens because after the printLoop we need to make an up-call from "complete" (*env)->CallVoidMethod(env, fPrinterJob, jf_completePrintLoop); CHECK_EXCEPTION(); But there's this PrinterAbortException already pending, which means we really should not be making the up-call without clearing it first, which is another issue (#4, or still part of #3 ?) After the upcall CHECK_EXCEPTION sees a pending Java Exception which it supposes is from a problem during the upcall and raises the NSException to "bail" up to the JNI_COCOA_EXIT where we catch it and log it as seen above. So the NSExceptions do not escape to Java and the Java Exception is seen by Java - which is OK so far as it goes. BUT we've jumped over a lot of printer job clean up which might contribute to (1) and (2) above but probably isn't the whole story. So how can we get that PrinterAbortException back up to Java without causing problems for subsequent upcalls? If we just remove the CHECK_EXCEPTION then that would probably do it, but really we should have that check. If we don't make the call at all with a pending exception what does that do ? Some special handling of this whole case seems likely to be needed but I don't have time to look into this deeply enough to test a solution. Perhaps we could (1) grab the exception (2) clear it from the current thread, but we still have a ref - it is just a Java object ! (3) store it in some field of the CPrinterJob (4) then check for it and re-throw when we reach Java code. \ Don't forget about (1) - the job being queued. I'm also unclear if the NSException is detected by the macOS printing code and plays a role in the popup. Hmm, perhaps not, since I still get it if I comment that out. Perhaps this something else we are skipping past that has nothing to do with the NSException ------------- PR Comment: https://git.openjdk.org/jdk/pull/20027#issuecomment-2267725000 From rgupta at openjdk.org Mon Aug 5 04:46:47 2024 From: rgupta at openjdk.org (Ravi Gupta) Date: Mon, 5 Aug 2024 04:46:47 GMT Subject: RFR: 8333403: Write a test to check various components events are triggered properly [v7] In-Reply-To: References: Message-ID: > This testcase checks for the following assertions for Component events: > > 1. When components are resized, moved, hidden and shown the respective events are triggered. > 2. When the components are hidden/disabled also,the component events like resized/moved are triggered. > 3. When a hidden component is hidden again, or a visible component is shown again, the events should not be fired. > 4. When a window is minimized/restored then hidden and shown component events should be triggered. > > Testing: > Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass. Ravi Gupta has updated the pull request incrementally with one additional commit since the last revision: 8333403: Review comments fixed ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19521/files - new: https://git.openjdk.org/jdk/pull/19521/files/eb2a4741..b367175a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19521&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19521&range=05-06 Stats: 23 lines in 1 file changed: 4 ins; 4 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/19521.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19521/head:pull/19521 PR: https://git.openjdk.org/jdk/pull/19521 From jwaters at openjdk.org Mon Aug 5 05:15:39 2024 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 5 Aug 2024 05:15:39 GMT Subject: RFR: 8334599: Improve code from JDK-8302671 [v3] In-Reply-To: <2r08GrKTlRfZn1a66BQweJMBalfbaVX_3mGOgCxbg2I=.ef1d0d3e-d1e1-4831-9673-b5127e79aba9@github.com> References: <2r08GrKTlRfZn1a66BQweJMBalfbaVX_3mGOgCxbg2I=.ef1d0d3e-d1e1-4831-9673-b5127e79aba9@github.com> Message-ID: On Thu, 11 Jul 2024 08:41:28 GMT, Julian Waters wrote: >> In [JDK-8302671](https://bugs.openjdk.org/browse/JDK-8302671) I fixed a memmove decay bug by rewriting a sizeof on an array to an explicit size of 256, but this is a bit of a band aid fix. It's come to my attention that in C++, one can pass an array by reference, which causes sizeof to work correctly on an array and has the added bonus of enforcing an array of that size on the arguments passed to that method. I've reverted my change from 8302671 and instead explicitly made kstate an array reference so that sizeof works on the array as expected, and that the array size can be explicitly set in the array brackets >> >> Verification: https://godbolt.org/z/Ezj76eWWY and GitHub Actions > > Julian Waters has updated the pull request incrementally with two additional commits since the last revision: > > - Revert Formatting in awt_Component.cpp > - Update src/java.desktop/windows/native/libawt/windows/awt_Component.cpp > > Co-authored-by: Alexey Ivanov I guess Phil forgot about this. Seems like it's good to go, though ------------- PR Comment: https://git.openjdk.org/jdk/pull/19798#issuecomment-2268187102 From jwaters at openjdk.org Mon Aug 5 05:15:41 2024 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 5 Aug 2024 05:15:41 GMT Subject: RFR: 8336289: Obliterate most references to _snprintf in the Windows JDK [v3] In-Reply-To: References: Message-ID: On Tue, 16 Jul 2024 08:59:20 GMT, Julian Waters wrote: >> snprintf has been available for all officially and unofficially supported compilers for Windows, Visual Studio since version 2015 and gcc since, well, forever. snprintf is conforming to C99 since the start when compiling using gcc, and 2015 when using Visual Studio. Since it conforms to C99 and provides better semantics than _snprintf, and is not compiler specific, we should use it in most places where we currently use _snprintf. This makes JDK code where this is used more robust due to the null terminating guarantee of snprintf. Since most of the changes are extremely simple, I've included all of them hoping to get this all done in one shot. The only places _snprintf is not replaced is places where I'm not sure whether the code is ours or not (As in, imported source code for external libraries). Note that the existing checks in place for the size of the characters written still work, as the return value of snprintf works mostly the same as _snprintf. The only difference is the nu ll terminating character at the end and the returning of the number of written characters if the buffer was terminated early, as seen here: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170 >> >> Reviews Required: 2 for HotSpot, jdk.hotspot.agent, and jdk.jdwp.agent, 1 for awt and jdk.accessibility, 1 for java.base, 1 for security, 1 for jdk.management(?) > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > Revert Standard Integer type rewrite Alright! Just need approval for java.base and security, then we should be good to go ------------- PR Comment: https://git.openjdk.org/jdk/pull/20153#issuecomment-2268188595 From jwaters at openjdk.org Mon Aug 5 05:15:40 2024 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 5 Aug 2024 05:15:40 GMT Subject: Integrated: 8334599: Improve code from JDK-8302671 In-Reply-To: References: Message-ID: <2A_c5nrfyE43Nx8k45XS_lzxmXMZY_in4V9yElVZsRE=.246182cb-ee36-4a95-aae4-8e199f8b1c8c@github.com> On Thu, 20 Jun 2024 08:29:39 GMT, Julian Waters wrote: > In [JDK-8302671](https://bugs.openjdk.org/browse/JDK-8302671) I fixed a memmove decay bug by rewriting a sizeof on an array to an explicit size of 256, but this is a bit of a band aid fix. It's come to my attention that in C++, one can pass an array by reference, which causes sizeof to work correctly on an array and has the added bonus of enforcing an array of that size on the arguments passed to that method. I've reverted my change from 8302671 and instead explicitly made kstate an array reference so that sizeof works on the array as expected, and that the array size can be explicitly set in the array brackets > > Verification: https://godbolt.org/z/Ezj76eWWY and GitHub Actions This pull request has now been integrated. Changeset: dabdae6b Author: Julian Waters URL: https://git.openjdk.org/jdk/commit/dabdae6b355b3e7a2795f6b01ba475652d483288 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod 8334599: Improve code from JDK-8302671 Reviewed-by: aivanov, stuefe, prr ------------- PR: https://git.openjdk.org/jdk/pull/19798 From jpai at openjdk.org Mon Aug 5 05:57:32 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 5 Aug 2024 05:57:32 GMT Subject: RFR: 8336289: Obliterate most references to _snprintf in the Windows JDK [v3] In-Reply-To: References: Message-ID: On Tue, 16 Jul 2024 08:59:20 GMT, Julian Waters wrote: >> snprintf has been available for all officially and unofficially supported compilers for Windows, Visual Studio since version 2015 and gcc since, well, forever. snprintf is conforming to C99 since the start when compiling using gcc, and 2015 when using Visual Studio. Since it conforms to C99 and provides better semantics than _snprintf, and is not compiler specific, we should use it in most places where we currently use _snprintf. This makes JDK code where this is used more robust due to the null terminating guarantee of snprintf. Since most of the changes are extremely simple, I've included all of them hoping to get this all done in one shot. The only places _snprintf is not replaced is places where I'm not sure whether the code is ours or not (As in, imported source code for external libraries). Note that the existing checks in place for the size of the characters written still work, as the return value of snprintf works mostly the same as _snprintf. The only difference is the nu ll terminating character at the end and the returning of the number of written characters if the buffer was terminated early, as seen here: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170 >> >> Reviews Required: 2 for HotSpot, jdk.hotspot.agent, and jdk.jdwp.agent, 1 for awt and jdk.accessibility, 1 for java.base, 1 for security, 1 for jdk.management(?) > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > Revert Standard Integer type rewrite Hello Julian, > Just need approval for java.base and security Daniel has approved this PR and I think that should take care of java.base review. In any case, I had a look at the java.base change and it looks OK to me. A several of these files will need a copyright year change. Could you update those files to use 2024? ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20153#pullrequestreview-2218070566 From tr at openjdk.org Mon Aug 5 08:59:14 2024 From: tr at openjdk.org (Tejesh R) Date: Mon, 5 Aug 2024 08:59:14 GMT Subject: RFR: 8233068: HIDPI: Linux: AWT Checkbox check mark is unscaled [v2] In-Reply-To: References: Message-ID: > The check mark had been transformed with default scale which is 1.0 and the same is used on click of checkbox. This was done while computing the layout and not updated while paint. Hence the scaling update is done on painting the check mark and CI testing is green after the update too. Tejesh R has updated the pull request incrementally with two additional commits since the last revision: - Color updation - Test condition updated + Copyright year ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20441/files - new: https://git.openjdk.org/jdk/pull/20441/files/f9b5fb2f..59bb3562 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20441&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20441&range=00-01 Stats: 10 lines in 2 files changed: 3 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/20441.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20441/head:pull/20441 PR: https://git.openjdk.org/jdk/pull/20441 From tr at openjdk.org Mon Aug 5 08:59:14 2024 From: tr at openjdk.org (Tejesh R) Date: Mon, 5 Aug 2024 08:59:14 GMT Subject: RFR: 8233068: HIDPI: Linux: AWT Checkbox check mark is unscaled [v2] In-Reply-To: References: Message-ID: On Fri, 2 Aug 2024 21:23:54 GMT, Harshitha Onkar wrote: >> Tejesh R has updated the pull request incrementally with two additional commits since the last revision: >> >> - Color updation >> - Test condition updated + Copyright year > > test/jdk/java/awt/Checkbox/CheckboxCheckerScalingTest.java line 74: > >> 72: for (int i = 0; i < imageAfterChecked.getHeight(); i++) { >> 73: for (int j = 0; j < imageAfterChecked.getWidth(); j++) { >> 74: if (sampleRGB != imageAfterChecked.getRGB(i, j)) { > > Maybe check for the tick color (black) within the checkbox? Yes, updated. This seems to be better than checking for unmatched case. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20441#discussion_r1703774247 From reto.merz at abacus.ch Mon Aug 5 09:23:23 2024 From: reto.merz at abacus.ch (Reto Merz) Date: Mon, 5 Aug 2024 09:23:23 +0000 Subject: Status on JDK-8305479 (+ info to reproduce it) Message-ID: Hello, Our customers are using Drag & Drop functionality more and more and reports are increasing that our application is haning. It starts to escalate since the only workaround is to restart the app right now. The problem is already reported with JDK-8305479 [1] Is there any way to increase the priority of that issue or is a developer here we can hire to search for a fix (and create a pull request)? Btw, the bug is much easier to reproduce: 1) Start the demo app (see [1]) 2) try to drop a document (eg: pdf file) from the windows desktop into the textfield Repeat step 2 if necessary. For me after 1-2 try this will cause the hang. If not, move the JFrame to another position and repeat step 2 again. Tested with latest JDK: java version "22.0.2" 2024-07-16 Java(TM) SE Runtime Environment (build 22.0.2+9-70) Java HotSpot(TM) 64-Bit Server VM (build 22.0.2+9-70, mixed mode, sharing) OS MS Windows: Microsoft Windows [Version 10.0.17763.5458] Regards Reto Merz [1] https://bugs.openjdk.org/browse/JDK-8305479 From psadhukhan at openjdk.org Mon Aug 5 10:09:06 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 5 Aug 2024 10:09:06 GMT Subject: RFR: 8335231: [macos] Test java/awt/print/PrinterJob/Cancel/PrinterJobCancel.java failed on macOS because the case didn't get the expected PrintAbortException [v5] In-Reply-To: References: Message-ID: <6BItk2St1IQ4QKZkY3M7fT02GV_vJTb3WRP0lVq8FWU=.0c4a6ff0-65c3-4186-b56a-7d6fea72046a@github.com> > When a printjob is cancelled midway, `PrinterAbortException `was not thrown in macos. because > firstly,` cancelCheck` invokes` LWCToolkit.invokeLater` with null as parameter causing it to fail with NPE and > secondly PrinterAbortException was consumed silently when `printLoop` throws any exception > which is rectified to throw the PrinterAbortException when encountered.. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Dont call completePrintLoop if cancelDoc is called as both exits PrintingLoop ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20027/files - new: https://git.openjdk.org/jdk/pull/20027/files/6750e51f..3ff67eb2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20027&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20027&range=03-04 Stats: 10 lines in 1 file changed: 6 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/20027.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20027/head:pull/20027 PR: https://git.openjdk.org/jdk/pull/20027 From psadhukhan at openjdk.org Mon Aug 5 10:09:07 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 5 Aug 2024 10:09:07 GMT Subject: RFR: 8335231: [macos] Test java/awt/print/PrinterJob/Cancel/PrinterJobCancel.java failed on macOS because the case didn't get the expected PrintAbortException [v4] In-Reply-To: References: Message-ID: <2Cr2XgHtfVK8ZuEt587nPSm-HkXCS8GlPJPyl4tFor0=.fa52d1b9-846a-422e-8b95-efd84751d7c8@github.com> On Sun, 4 Aug 2024 21:44:33 GMT, Phil Race wrote: > (1) The job still gets queued for printing - should it ? Ideally not if there's some thing we can do. I guess you are testing via your standalone `PJC.java` or jtreg's `PrinterJobCancel.java` which starts the print job and after 5sec does call `PrinterJob.cancel` so I guess it should start/queue the printjob..The printjob is supposed to print **6 pages** if it doesn't get cancelled I see it prints the 1st page and then it aborts in normal run with the above testcase... Are you not seeing that or am I misunderstanding your statement? > (2) The "Error during printing" dialog I get after running the test is from macOS not us. Should it happen ? I suspected it might be because of `abortDoc `native call but even after commenting `cancelDoc`, this dialog is coming. > (3) There's also an NSException printed I thought it is because of this line in `CHECK_EXCEPTION `macro `[NSException raise:NSGenericException format:@"Java Exception"]; ` which was added by you in [JDK-8259343:[macOS] Update JNI error handling in Cocoa code.](https://bugs.openjdk.org/browse/JDK-8259343) I found one issue where I see that `cancelDoc` exits the printingLoop and so does `completePrintLoop` called from `PrinterView.m#complete` so I think we should not be calling completePrintLoop from complete when cancelDoc is called to abort the printjob. Also, I think we should not check the CHECK_EXCEPTION also in that case I modified the PR to do that which stops the NSException being thrown so that should solve (3) but (2) is still an enigma.. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20027#issuecomment-2268693037 From jdv at openjdk.org Mon Aug 5 10:30:34 2024 From: jdv at openjdk.org (Jayathirth D V) Date: Mon, 5 Aug 2024 10:30:34 GMT Subject: RFR: 8233068: HIDPI: Linux: AWT Checkbox check mark is unscaled [v2] In-Reply-To: References: Message-ID: On Mon, 5 Aug 2024 08:59:14 GMT, Tejesh R wrote: >> The check mark had been transformed with default scale which is 1.0 and the same is used on click of checkbox. This was done while computing the layout and not updated while paint. Hence the scaling update is done on painting the check mark and CI testing is green after the update too. > > Tejesh R has updated the pull request incrementally with two additional commits since the last revision: > > - Color updation > - Test condition updated + Copyright year Apart from the comment i have added. Code change looks good to me. test/jdk/java/awt/Checkbox/CheckboxCheckerScalingTest.java line 86: > 84: if (!checkmarkFound) { > 85: try { > 86: ImageIO.write(imageAfterChecked, "png", Do we need to write this 8*8 image when this test fails? How useful will it be? This looks like a very simply scenario where the tests will fail if nothing is filled in the checkbox. May be we can write whole checkbox/Frame into an image, but then also i don't see how this failure image will be helpful for debugging. If possible we should avoid writing into an image. ------------- Marked as reviewed by jdv (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20441#pullrequestreview-2218635710 PR Review Comment: https://git.openjdk.org/jdk/pull/20441#discussion_r1703902410 From rkannathpari at openjdk.org Mon Aug 5 11:01:04 2024 From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad) Date: Mon, 5 Aug 2024 11:01:04 GMT Subject: RFR: 8290501 : Typo Found In The javax.swing Interface BoundedRangeModel Documentation Message-ID: Documentation updated ------------- Commit messages: - JDK-8290501 : Typo Found In The javax.swing Interface BoundedRangeModel Documentation Changes: https://git.openjdk.org/jdk/pull/20465/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20465&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290501 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20465.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20465/head:pull/20465 PR: https://git.openjdk.org/jdk/pull/20465 From rgupta at openjdk.org Mon Aug 5 11:57:40 2024 From: rgupta at openjdk.org (Ravi Gupta) Date: Mon, 5 Aug 2024 11:57:40 GMT Subject: RFR: 8333403: Write a test to check various components events are triggered properly [v6] In-Reply-To: References: Message-ID: On Wed, 24 Jul 2024 19:14:00 GMT, Alexey Ivanov wrote: >> Ravi Gupta has updated the pull request incrementally with one additional commit since the last revision: >> >> 8333403: Review commnets fixed > > test/jdk/java/awt/event/ComponentEvent/ComponentEventTest.java line 191: > >> 189: >> 190: robot.delay(DELAY); >> 191: if (componentShown || componentHidden) { > > Is it possible that any other event is triggered? Or do you expect other events? > > When you inconify the frame, you verify of all the event flags but you verify only two flags here. Here we expect events should not triggered. When inconify i expect all events should not triggered , but when form Frame.ICONIFIED to Frame.NORMAL componentMoved and componentResized events are triggered , Events order on Windows and Mac are different. Order of the events for Frame from Frame.ICONIFIED to Frame.NORMAL On Windows Component Shown Frame is Visible with ExtendedState as ICONIFIED Component Moved Component Resized Frame is Visible with ExtendedState as NORMAL On MAC Component Moved Component Resized Component Shown Frame is Visible with ExtendedState as ICONIFIED Frame is Visible with ExtendedState as NORMAL ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19521#discussion_r1703998938 From tr at openjdk.org Mon Aug 5 12:23:35 2024 From: tr at openjdk.org (Tejesh R) Date: Mon, 5 Aug 2024 12:23:35 GMT Subject: RFR: 8233068: HIDPI: Linux: AWT Checkbox check mark is unscaled [v2] In-Reply-To: References: Message-ID: <7XFsqvd2pf5Nx3RBtA1bmWE8vvDsm7jlVh8iT5P34Lg=.fe2b1373-0241-4563-9e79-b1c13558dd3d@github.com> On Mon, 5 Aug 2024 10:27:17 GMT, Jayathirth D V wrote: >> Tejesh R has updated the pull request incrementally with two additional commits since the last revision: >> >> - Color updation >> - Test condition updated + Copyright year > > test/jdk/java/awt/Checkbox/CheckboxCheckerScalingTest.java line 86: > >> 84: if (!checkmarkFound) { >> 85: try { >> 86: ImageIO.write(imageAfterChecked, "png", > > Do we need to write this 8*8 image when this test fails? How useful will it be? > This looks like a very simply scenario where the tests will fail if nothing is filled in the checkbox. > > May be we can write whole checkbox/Frame into an image, but then also i don't see how this failure image will be helpful for debugging. If possible we should avoid writing into an image. I'll be used on intermittent failure cases, yeah probably writing whole checkbox/frame will be useful. Anyhow we can add on failure cases whenever required too. Will remove it as of now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20441#discussion_r1704028983 From tr at openjdk.org Mon Aug 5 12:28:09 2024 From: tr at openjdk.org (Tejesh R) Date: Mon, 5 Aug 2024 12:28:09 GMT Subject: RFR: 8233068: HIDPI: Linux: AWT Checkbox check mark is unscaled [v3] In-Reply-To: References: Message-ID: > The check mark had been transformed with default scale which is 1.0 and the same is used on click of checkbox. This was done while computing the layout and not updated while paint. Hence the scaling update is done on painting the check mark and CI testing is green after the update too. Tejesh R has updated the pull request incrementally with one additional commit since the last revision: Remove image writing ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20441/files - new: https://git.openjdk.org/jdk/pull/20441/files/59bb3562..362f88b4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20441&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20441&range=01-02 Stats: 9 lines in 1 file changed: 0 ins; 9 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20441.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20441/head:pull/20441 PR: https://git.openjdk.org/jdk/pull/20441 From ihse at openjdk.org Mon Aug 5 15:41:35 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 5 Aug 2024 15:41:35 GMT Subject: RFR: 8329471: Remove GTK2 [v5] In-Reply-To: References: Message-ID: On Wed, 31 Jul 2024 19:17:05 GMT, Alexander Zvegintsev wrote: >> GTK2 support for Swing/AWT was deprecated for removal in JDK 21. >> >> It's being removed because no platform that supports the JDK needs it. >> >> Manual and automated testing is green. > > Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: > > more removal of is3() Build changes are trivially fine. ------------- Marked as reviewed by ihse (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20378#pullrequestreview-2219324329 From duke at openjdk.org Mon Aug 5 16:55:51 2024 From: duke at openjdk.org (duke) Date: Mon, 5 Aug 2024 16:55:51 GMT Subject: Withdrawn: 8233177: Remove testcase for JDK-8001470 as fix has been reverted In-Reply-To: References: Message-ID: On Tue, 23 Jan 2024 08:18:33 GMT, Prasanta Sadhukhan wrote: > Existing regression test is failing because textfield height is not as per test's expectation..Seems like the indic character being tried to render is not being loaded (probably because of missing glyphs) leading to 0 preferredSpan from [BoxView](https://github.com/openjdk/jdk/blame/5a74c2a67ebcb47e51732f03c4be694bdf920469/src/java.desktop/share/classes/javax/swing/text/BoxView.java#L545-L552) which is superclass for `i18nFieldVIew`, the field view for Indic characters. > Tried block character in the test which is now being loaded properly leading to correct height.. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/17528 From achung at openjdk.org Mon Aug 5 17:02:36 2024 From: achung at openjdk.org (Alisen Chung) Date: Mon, 5 Aug 2024 17:02:36 GMT Subject: RFR: 7188058: Background of TextComponents are not changing colors to the default disabled color when set to uneditable [v2] In-Reply-To: <77lt11qmN9Pift0gg2CmeN1v1CRSv4nP50d8hdNPynU=.f2f65d8a-293d-48c2-81d4-0b945cfcb158@github.com> References: <77lt11qmN9Pift0gg2CmeN1v1CRSv4nP50d8hdNPynU=.f2f65d8a-293d-48c2-81d4-0b945cfcb158@github.com> Message-ID: On Fri, 2 Aug 2024 03:42:51 GMT, Prasanta Sadhukhan wrote: >> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: >> >> moved test to awt > > src/java.desktop/share/classes/java/awt/TextArea.java line 613: > >> 611: public synchronized void setEditable(boolean b) { >> 612: super.setEditable(b); >> 613: Color defaultBackground = UIManager.getColor("TextArea.background"); > > I am not sure if it is ok to use swing "UIManager" class in awt > I guess long time back somebody maybe @prrace mentioned that we should avoid calling swing class from awt? > I see we use AttributeSet in TextComponent for accessibility usage but am not sure if we can use without restriction? This call is only to get the default background of TextArea. Is there another way to grab the default color without using UIManager? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19876#discussion_r1704404236 From achung at openjdk.org Mon Aug 5 17:01:16 2024 From: achung at openjdk.org (Alisen Chung) Date: Mon, 5 Aug 2024 17:01:16 GMT Subject: RFR: 8235404: [macos] JOptionPane blocks drawing string on another component [v2] In-Reply-To: References: Message-ID: > Currently if you try to use graphics to draw a string on a frame using JOptionPane + JTextField with a listener as a prompt, the string will not draw. Adding a repaint after dialog.dispose in JOptionPane will cause the text to show after the dialog is closed. Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: check for null ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20359/files - new: https://git.openjdk.org/jdk/pull/20359/files/50fd274b..84d62d5e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20359&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20359&range=00-01 Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20359.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20359/head:pull/20359 PR: https://git.openjdk.org/jdk/pull/20359 From achung at openjdk.org Mon Aug 5 17:32:32 2024 From: achung at openjdk.org (Alisen Chung) Date: Mon, 5 Aug 2024 17:32:32 GMT Subject: RFR: 8235404: [macos] JOptionPane blocks drawing string on another component In-Reply-To: References: Message-ID: <__Nl6wVftlCz-WJxYldrA02iXVXuH6GqjRpMRIgCysE=.c214b8f5-4468-4a7f-a27d-c1fb30edf030@github.com> On Tue, 30 Jul 2024 08:00:58 GMT, Abhishek Kumar wrote: >> Currently if you try to use graphics to draw a string on a frame using JOptionPane + JTextField with a listener as a prompt, the string will not draw. Adding a repaint after dialog.dispose in JOptionPane will cause the text to show after the dialog is closed. > > Could you please add a test case to validate the fix ? @kumarabhi006 I've updated the test from your feedback. Could you re-review the changes? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20359#issuecomment-2269563582 From achung at openjdk.org Mon Aug 5 17:32:33 2024 From: achung at openjdk.org (Alisen Chung) Date: Mon, 5 Aug 2024 17:32:33 GMT Subject: RFR: 8235404: [macos] JOptionPane blocks drawing string on another component [v2] In-Reply-To: References: Message-ID: <9R3UOq-1Fex7UFvZ32yRZ5--wJUJXlBG0tEbd_SYn7o=.99e0df9b-a8ee-4931-b8a1-5a8943d46b4d@github.com> On Thu, 1 Aug 2024 23:28:19 GMT, Harshitha Onkar wrote: >> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: >> >> check for null > > test/jdk/javax/swing/JOptionPane/OptionPaneInput.java line 86: > >> 84: f.setSize(300,100); >> 85: PassFailJFrame.addTestWindow(f); >> 86: PassFailJFrame.positionTestWindow(f, PassFailJFrame.Position.HORIZONTAL); > > The JOptionPane can be add as a split window using PassFailJFrame.splitUI() since currently it gets blocked by the testUI. There's no way to use the builder here since JOptionPane.showMessageDialog must be called after the testUI is set visible to reproduce the bug. The JOptionPane dialog is supposed to be covering the testUI because it?s a dialog so I think the test is fine as is ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20359#discussion_r1704431425 From achung at openjdk.org Mon Aug 5 17:32:35 2024 From: achung at openjdk.org (Alisen Chung) Date: Mon, 5 Aug 2024 17:32:35 GMT Subject: RFR: 8235404: [macos] JOptionPane blocks drawing string on another component [v2] In-Reply-To: <0s6SZvTeJdFtKAwulwUfbs9GcR_ibe-TgD7TO0xc_9Y=.5041192e-6b13-474d-ab2d-0c430c693182@github.com> References: <0s6SZvTeJdFtKAwulwUfbs9GcR_ibe-TgD7TO0xc_9Y=.5041192e-6b13-474d-ab2d-0c430c693182@github.com> Message-ID: <6D6Jn1w2AI0sQfj8_Y4Tddo6IeExDun03rHHtr74IOM=.beb7dc8a-f725-4103-ba50-650ebae3360f@github.com> On Fri, 2 Aug 2024 00:22:00 GMT, Harshitha Onkar wrote: >> test/jdk/javax/swing/JOptionPane/OptionPaneInput.java line 89: >> >>> 87: f.setVisible(true); >>> 88: >>> 89: JOptionPane.showMessageDialog(null, t); >> >> Since parentComponent of JOptionPane is null running into NPE. >> >> >> parentComponent.revalidate(); >> parentComponent.repaint(); > > The fix should handle both cases - when parentComponent is null and not null. With current fix, if there is a case when parentComponent is null, we will run into NPE. added null check ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20359#discussion_r1704431617 From honkar at openjdk.org Mon Aug 5 17:41:33 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Mon, 5 Aug 2024 17:41:33 GMT Subject: RFR: 8233068: HIDPI: Linux: AWT Checkbox check mark is unscaled [v3] In-Reply-To: References: Message-ID: On Mon, 5 Aug 2024 12:28:09 GMT, Tejesh R wrote: >> The check mark had been transformed with default scale which is 1.0 and the same is used on click of checkbox. This was done while computing the layout and not updated while paint. Hence the scaling update is done on painting the check mark and CI testing is green after the update too. > > Tejesh R has updated the pull request incrementally with one additional commit since the last revision: > > Remove image writing Updated changes looks good. ------------- Marked as reviewed by honkar (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20441#pullrequestreview-2219544640 From honkar at openjdk.org Mon Aug 5 17:59:33 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Mon, 5 Aug 2024 17:59:33 GMT Subject: RFR: 8235404: [macos] JOptionPane blocks drawing string on another component [v2] In-Reply-To: <6D6Jn1w2AI0sQfj8_Y4Tddo6IeExDun03rHHtr74IOM=.beb7dc8a-f725-4103-ba50-650ebae3360f@github.com> References: <0s6SZvTeJdFtKAwulwUfbs9GcR_ibe-TgD7TO0xc_9Y=.5041192e-6b13-474d-ab2d-0c430c693182@github.com> <6D6Jn1w2AI0sQfj8_Y4Tddo6IeExDun03rHHtr74IOM=.beb7dc8a-f725-4103-ba50-650ebae3360f@github.com> Message-ID: On Mon, 5 Aug 2024 17:28:00 GMT, Alisen Chung wrote: >> The fix should handle both cases - when parentComponent is null and not null. With current fix, if there is a case when parentComponent is null, we will run into NPE. > > added null check @alisenchung Shouldn't both cases be handled here? when parentComponent is null - JOptionPane.showMessageDialog(null, t), it does not work in this case. when parentComponent is NOT null - JOptionPane.showMessageDialog(f, t) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20359#discussion_r1704459558 From honkar at openjdk.org Mon Aug 5 19:23:32 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Mon, 5 Aug 2024 19:23:32 GMT Subject: RFR: 8235404: [macos] JOptionPane blocks drawing string on another component [v2] In-Reply-To: References: <0s6SZvTeJdFtKAwulwUfbs9GcR_ibe-TgD7TO0xc_9Y=.5041192e-6b13-474d-ab2d-0c430c693182@github.com> <6D6Jn1w2AI0sQfj8_Y4Tddo6IeExDun03rHHtr74IOM=.beb7dc8a-f725-4103-ba50-650ebae3360f@github.com> Message-ID: On Mon, 5 Aug 2024 17:56:41 GMT, Harshitha Onkar wrote: >> added null check > > @alisenchung > > Shouldn't both cases be handled here? > when parentComponent is null - JOptionPane.showMessageDialog(null, t), it does not work in this case. > when parentComponent is NOT null - JOptionPane.showMessageDialog(f, t) I looked into the JOptionPane code so when parentComponent is null, for some cases [getRootFrame()](https://github.com/openjdk/jdk/blob/e2c07d5044587476fc0fff14260e2b73816d2062/src/java.desktop/share/classes/javax/swing/JOptionPane.java#L1692) is used, this returns a hidden frame (in case nothing is set as RootFrame) and thus the test case is not applicable here. Hence "when parentComponent is null" is not valid case here. The fix looks good. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20359#discussion_r1704537952 From honkar at openjdk.org Mon Aug 5 21:05:35 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Mon, 5 Aug 2024 21:05:35 GMT Subject: RFR: 8235404: [macos] JOptionPane blocks drawing string on another component [v2] In-Reply-To: References: Message-ID: On Mon, 5 Aug 2024 17:01:16 GMT, Alisen Chung wrote: >> Currently if you try to use graphics to draw a string on a frame using JOptionPane + JTextField with a listener as a prompt, the string will not draw. Adding a repaint after dialog.dispose in JOptionPane will cause the text to show after the dialog is closed. > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > check for null Fix looks good except for minor spacing issues. test/jdk/javax/swing/JOptionPane/OptionPaneInput.java line 66: > 64: f.add(c); > 65: > 66: t.addActionListener(e->{ Suggestion: t.addActionListener(e -> { test/jdk/javax/swing/JOptionPane/OptionPaneInput.java line 82: > 80: JOptionPane.showMessageDialog(f, t); > 81: } > 82: } EOF newline misisng ------------- Marked as reviewed by honkar (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20359#pullrequestreview-2219705742 PR Review Comment: https://git.openjdk.org/jdk/pull/20359#discussion_r1704539024 PR Review Comment: https://git.openjdk.org/jdk/pull/20359#discussion_r1704539596 From achung at openjdk.org Tue Aug 6 00:41:53 2024 From: achung at openjdk.org (Alisen Chung) Date: Tue, 6 Aug 2024 00:41:53 GMT Subject: RFR: 8235404: [macos] JOptionPane blocks drawing string on another component [v3] In-Reply-To: References: Message-ID: > Currently if you try to use graphics to draw a string on a frame using JOptionPane + JTextField with a listener as a prompt, the string will not draw. Adding a repaint after dialog.dispose in JOptionPane will cause the text to show after the dialog is closed. Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: fix spacing ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20359/files - new: https://git.openjdk.org/jdk/pull/20359/files/84d62d5e..935e9884 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20359&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20359&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20359.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20359/head:pull/20359 PR: https://git.openjdk.org/jdk/pull/20359 From dnguyen at openjdk.org Tue Aug 6 00:41:53 2024 From: dnguyen at openjdk.org (Damon Nguyen) Date: Tue, 6 Aug 2024 00:41:53 GMT Subject: RFR: 8235404: [macos] JOptionPane blocks drawing string on another component [v2] In-Reply-To: References: Message-ID: On Mon, 5 Aug 2024 17:01:16 GMT, Alisen Chung wrote: >> Currently if you try to use graphics to draw a string on a frame using JOptionPane + JTextField with a listener as a prompt, the string will not draw. Adding a repaint after dialog.dispose in JOptionPane will cause the text to show after the dialog is closed. > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > check for null Fix itself looks like it's working fine now. I agree to handle the small comment Harshitha left already, but otherwise lgtm. ------------- Marked as reviewed by dnguyen (Committer). PR Review: https://git.openjdk.org/jdk/pull/20359#pullrequestreview-2220050246 From honkar at openjdk.org Tue Aug 6 00:41:53 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Tue, 6 Aug 2024 00:41:53 GMT Subject: RFR: 8235404: [macos] JOptionPane blocks drawing string on another component [v3] In-Reply-To: References: Message-ID: On Tue, 6 Aug 2024 00:38:40 GMT, Alisen Chung wrote: >> Currently if you try to use graphics to draw a string on a frame using JOptionPane + JTextField with a listener as a prompt, the string will not draw. Adding a repaint after dialog.dispose in JOptionPane will cause the text to show after the dialog is closed. > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > fix spacing Marked as reviewed by honkar (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20359#pullrequestreview-2220052345 From duke at openjdk.org Tue Aug 6 05:55:57 2024 From: duke at openjdk.org (toshiogata) Date: Tue, 6 Aug 2024 05:55:57 GMT Subject: RFR: 8337851: Some tests have name which confuse jtreg Message-ID: Rename the tests to prevent unexpected deletion of result files when `-retain` jtreg option is specified. Testing: modified tests ------------- Commit messages: - Merge branch 'master' into 8337851 - 8337851: Some tests have name which confuse jtreg Changes: https://git.openjdk.org/jdk/pull/20475/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20475&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8337851 Stats: 0 lines in 4 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20475.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20475/head:pull/20475 PR: https://git.openjdk.org/jdk/pull/20475 From abhiscxk at openjdk.org Tue Aug 6 07:21:34 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Tue, 6 Aug 2024 07:21:34 GMT Subject: RFR: 8233068: HIDPI: Linux: AWT Checkbox check mark is unscaled [v3] In-Reply-To: References: Message-ID: On Mon, 5 Aug 2024 12:28:09 GMT, Tejesh R wrote: >> The check mark had been transformed with default scale which is 1.0 and the same is used on click of checkbox. This was done while computing the layout and not updated while paint. Hence the scaling update is done on painting the check mark and CI testing is green after the update too. > > Tejesh R has updated the pull request incrementally with one additional commit since the last revision: > > Remove image writing src/java.desktop/unix/classes/sun/awt/X11/XCheckboxPeer.java line 1: > 1: /* You may expand wild imports. test/jdk/java/awt/Checkbox/CheckboxCheckerScalingTest.java line 28: > 26: import java.awt.Frame; > 27: import java.awt.Rectangle; > 28: import java.awt.Point; sort the imports Suggestion: import java.awt.Point; import java.awt.Rectangle; test/jdk/java/awt/Checkbox/CheckboxCheckerScalingTest.java line 82: > 80: > 81: if (!checkmarkFound) { > 82: throw new RuntimeException(" Checkmark not scaled"); minor spacing Suggestion: throw new RuntimeException("Checkmark not scaled"); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20441#discussion_r1705007690 PR Review Comment: https://git.openjdk.org/jdk/pull/20441#discussion_r1705008392 PR Review Comment: https://git.openjdk.org/jdk/pull/20441#discussion_r1705033710 From tr at openjdk.org Tue Aug 6 07:56:11 2024 From: tr at openjdk.org (Tejesh R) Date: Tue, 6 Aug 2024 07:56:11 GMT Subject: RFR: 8233068: HIDPI: Linux: AWT Checkbox check mark is unscaled [v3] In-Reply-To: References: Message-ID: On Tue, 6 Aug 2024 06:55:46 GMT, Abhishek Kumar wrote: >> Tejesh R has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove image writing > > src/java.desktop/unix/classes/sun/awt/X11/XCheckboxPeer.java line 1: > >> 1: /* > > You may expand wild imports. Having issue with intellij settings, so will skip it now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20441#discussion_r1705075019 From tr at openjdk.org Tue Aug 6 07:56:11 2024 From: tr at openjdk.org (Tejesh R) Date: Tue, 6 Aug 2024 07:56:11 GMT Subject: RFR: 8233068: HIDPI: Linux: AWT Checkbox check mark is unscaled [v4] In-Reply-To: References: Message-ID: > The check mark had been transformed with default scale which is 1.0 and the same is used on click of checkbox. This was done while computing the layout and not updated while paint. Hence the scaling update is done on painting the check mark and CI testing is green after the update too. Tejesh R has updated the pull request incrementally with one additional commit since the last revision: Review updates ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20441/files - new: https://git.openjdk.org/jdk/pull/20441/files/362f88b4..a59323f0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20441&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20441&range=02-03 Stats: 3 lines in 1 file changed: 1 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20441.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20441/head:pull/20441 PR: https://git.openjdk.org/jdk/pull/20441 From abhiscxk at openjdk.org Tue Aug 6 07:59:34 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Tue, 6 Aug 2024 07:59:34 GMT Subject: RFR: 8233068: HIDPI: Linux: AWT Checkbox check mark is unscaled [v3] In-Reply-To: References: Message-ID: On Mon, 5 Aug 2024 12:28:09 GMT, Tejesh R wrote: >> The check mark had been transformed with default scale which is 1.0 and the same is used on click of checkbox. This was done while computing the layout and not updated while paint. Hence the scaling update is done on painting the check mark and CI testing is green after the update too. > > Tejesh R has updated the pull request incrementally with one additional commit since the last revision: > > Remove image writing test/jdk/java/awt/Checkbox/CheckboxCheckerScalingTest.java line 53: > 51: Robot robot = new Robot(); > 52: try { > 53: SwingUtilities.invokeAndWait(() -> { I think `EventQueue.invokeAndWait()` should be used instead of `SwingUtilities.invokeAndWait()` for AWT test. test/jdk/java/awt/Checkbox/CheckboxCheckerScalingTest.java line 54: > 52: try { > 53: SwingUtilities.invokeAndWait(() -> { > 54: frame = new Frame("ComboBox checker scaling test"); Is it possible to render the checkbox into the buffered image directly and then do the testing? This way, you can avoid creating the frame, adding component to it, using robot for screen capture. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20441#discussion_r1705077572 PR Review Comment: https://git.openjdk.org/jdk/pull/20441#discussion_r1705082559 From psadhukhan at openjdk.org Tue Aug 6 08:38:33 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 6 Aug 2024 08:38:33 GMT Subject: RFR: 8335130: The test "javax/swing/plaf/synth/ComponentsOrientationSupport/5033822/bug5033822.java" fails because the background color of the tabs is displayed incorrectly. In-Reply-To: References: Message-ID: On Tue, 9 Jul 2024 06:13:15 GMT, Abhishek Kumar wrote: > Issue is due to the condition added for the opaque property of SynthTabbedPane in [JDK-8226990](https://bugs.openjdk.org/browse/JDK-8226990). The previous fix for GTK and Nimbus was handled commonly in `SynthTabbedPaneUI` class to render the tabs based on opaque property. Since the Synth package is responsible to create a custom L&F using user defined XML file. In this test the L&F is fetched through the XML file and when `SynthTabbedPaneUI` APIs are invoked for the tab rendering, it is not correctly rendered. Setting the opaque property to true also doesn't help as the selected tab is rendered incorrectly. The proposed fix is to move the fix to GTK and Nimbus specific class and that will not cause any impact on custom xml based L&F. Is it not possible to opensource the test along with this fix? This bugid needs to be added in the tag.. ------------- PR Review: https://git.openjdk.org/jdk/pull/20091#pullrequestreview-2220646095 From aturbanov at openjdk.org Tue Aug 6 08:41:36 2024 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Tue, 6 Aug 2024 08:41:36 GMT Subject: RFR: 8235404: [macos] JOptionPane blocks drawing string on another component [v3] In-Reply-To: References: Message-ID: On Tue, 6 Aug 2024 00:41:53 GMT, Alisen Chung wrote: >> Currently if you try to use graphics to draw a string on a frame using JOptionPane + JTextField with a listener as a prompt, the string will not draw. Adding a repaint after dialog.dispose in JOptionPane will cause the text to show after the dialog is closed. > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > fix spacing test/jdk/javax/swing/JOptionPane/OptionPaneInput.java line 75: > 73: }); > 74: > 75: f.setSize(300,100); Suggestion: f.setSize(300, 100); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20359#discussion_r1705142048 From abhiscxk at openjdk.org Tue Aug 6 08:50:36 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Tue, 6 Aug 2024 08:50:36 GMT Subject: RFR: 8335130: The test "javax/swing/plaf/synth/ComponentsOrientationSupport/5033822/bug5033822.java" fails because the background color of the tabs is displayed incorrectly. In-Reply-To: References: Message-ID: On Tue, 6 Aug 2024 08:35:50 GMT, Prasanta Sadhukhan wrote: > Is it not possible to opensource the test along with this fix? This bugid needs to be added in the tag.. There are few png images associated with the test and most probably it can be open sourced but I am not sure. > This bugid needs to be added in the tag.. ok. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20091#issuecomment-2270729259 From abhiscxk at openjdk.org Tue Aug 6 09:02:36 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Tue, 6 Aug 2024 09:02:36 GMT Subject: RFR: 8335130: The test "javax/swing/plaf/synth/ComponentsOrientationSupport/5033822/bug5033822.java" fails because the background color of the tabs is displayed incorrectly. In-Reply-To: References: Message-ID: On Tue, 6 Aug 2024 08:35:50 GMT, Prasanta Sadhukhan wrote: >> Issue is due to the condition added for the opaque property of SynthTabbedPane in [JDK-8226990](https://bugs.openjdk.org/browse/JDK-8226990). The previous fix for GTK and Nimbus was handled commonly in `SynthTabbedPaneUI` class to render the tabs based on opaque property. Since the Synth package is responsible to create a custom L&F using user defined XML file. In this test the L&F is fetched through the XML file and when `SynthTabbedPaneUI` APIs are invoked for the tab rendering, it is not correctly rendered. Setting the opaque property to true also doesn't help as the selected tab is rendered incorrectly. The proposed fix is to move the fix to GTK and Nimbus specific class and that will not cause any impact on custom xml based L&F. > > Is it not possible to opensource the test along with this fix? > This bugid needs to be added in the tag.. @prsadhuk bugid updated in the tag. What do you suggest about moving the test to open? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20091#issuecomment-2270753974 From psadhukhan at openjdk.org Tue Aug 6 09:06:34 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 6 Aug 2024 09:06:34 GMT Subject: RFR: 8335130: The test "javax/swing/plaf/synth/ComponentsOrientationSupport/5033822/bug5033822.java" fails because the background color of the tabs is displayed incorrectly. In-Reply-To: References: Message-ID: On Tue, 9 Jul 2024 06:13:15 GMT, Abhishek Kumar wrote: > Issue is due to the condition added for the opaque property of SynthTabbedPane in [JDK-8226990](https://bugs.openjdk.org/browse/JDK-8226990). The previous fix for GTK and Nimbus was handled commonly in `SynthTabbedPaneUI` class to render the tabs based on opaque property. Since the Synth package is responsible to create a custom L&F using user defined XML file. In this test the L&F is fetched through the XML file and when `SynthTabbedPaneUI` APIs are invoked for the tab rendering, it is not correctly rendered. Setting the opaque property to true also doesn't help as the selected tab is rendered incorrectly. The proposed fix is to move the fix to GTK and Nimbus specific class and that will not cause any impact on custom xml based L&F. Marked as reviewed by psadhukhan (Reviewer). Seems like the image files are being used in xml file and not in java where probably we could have used some bufferedimage.. png headers doesn't show any copyright as far I could see but still not sure if those images can be opensourced.. Ok for now to be in closed.. ------------- PR Review: https://git.openjdk.org/jdk/pull/20091#pullrequestreview-2220714392 PR Comment: https://git.openjdk.org/jdk/pull/20091#issuecomment-2270764529 From abhiscxk at openjdk.org Tue Aug 6 09:09:31 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Tue, 6 Aug 2024 09:09:31 GMT Subject: RFR: 8335130: The test "javax/swing/plaf/synth/ComponentsOrientationSupport/5033822/bug5033822.java" fails because the background color of the tabs is displayed incorrectly. In-Reply-To: References: Message-ID: On Tue, 6 Aug 2024 09:03:08 GMT, Prasanta Sadhukhan wrote: > Seems like the image files are being used in xml file and not in java where probably we could have used some bufferedimage.. png headers doesn't show any copyright as far I could see but still not sure if those images can be opensourced.. Ok for now to be in closed.. ok. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20091#issuecomment-2270771903 From psadhukhan at openjdk.org Tue Aug 6 09:28:34 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 6 Aug 2024 09:28:34 GMT Subject: RFR: 7188058: Background of TextComponents are not changing colors to the default disabled color when set to uneditable [v2] In-Reply-To: References: <77lt11qmN9Pift0gg2CmeN1v1CRSv4nP50d8hdNPynU=.f2f65d8a-293d-48c2-81d4-0b945cfcb158@github.com> Message-ID: On Mon, 5 Aug 2024 16:59:50 GMT, Alisen Chung wrote: >> src/java.desktop/share/classes/java/awt/TextArea.java line 613: >> >>> 611: public synchronized void setEditable(boolean b) { >>> 612: super.setEditable(b); >>> 613: Color defaultBackground = UIManager.getColor("TextArea.background"); >> >> I am not sure if it is ok to use swing "UIManager" class in awt >> I guess long time back somebody maybe @prrace mentioned that we should avoid calling swing class from awt? >> I see we use AttributeSet in TextComponent for accessibility usage but am not sure if we can use without restriction? > > This call is only to get the default background of TextArea. Is there another way to grab the default color without using UIManager? Yes, but as far I could see `TextArea.background` property is being set in `AquaLookAndFeel.java, MotifLookAndFeel.java, BasicLookAndFeel.java, XAWTLookAndFeel.java and WindowsLookAndFeel.java` and this L&F will not be set in AWT environment, if I am not wrong so you will either get garbage or wrong default color if you use UIManager.getColor..so I guess you need to use `TextComponent.getBackground()` which returns SystemColor.control if nothing is set ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19876#discussion_r1705216392 From psadhukhan at openjdk.org Tue Aug 6 09:40:36 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 6 Aug 2024 09:40:36 GMT Subject: Integrated: 8337344: Redundant javadoc at RasterPrinterJob.isCancelled In-Reply-To: References: Message-ID: <3LLCYYugyEx6Ho9bw-veKkvrSEiGzNbLkdK21s9TWmo=.c5f9a5bd-5e02-45b3-970e-a4ebce47d28e@github.com> On Mon, 29 Jul 2024 12:47:28 GMT, Prasanta Sadhukhan wrote: > RasterPrinterJob.isCancelled cites > `is a print job is ongoing but will be cancelled and the next opportunity` > > "and" -> "at" is fixed and more clarification added.. This pull request has now been integrated. Changeset: a117945d Author: Prasanta Sadhukhan URL: https://git.openjdk.org/jdk/commit/a117945d5a704781944ae15c852c31d090f03adb Stats: 5 lines in 1 file changed: 0 ins; 4 del; 1 mod 8337344: Redundant javadoc at RasterPrinterJob.isCancelled Reviewed-by: aivanov, prr ------------- PR: https://git.openjdk.org/jdk/pull/20375 From tr at openjdk.org Tue Aug 6 11:04:34 2024 From: tr at openjdk.org (Tejesh R) Date: Tue, 6 Aug 2024 11:04:34 GMT Subject: RFR: 8233068: HIDPI: Linux: AWT Checkbox check mark is unscaled [v3] In-Reply-To: References: Message-ID: On Tue, 6 Aug 2024 07:52:49 GMT, Abhishek Kumar wrote: >> Tejesh R has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove image writing > > test/jdk/java/awt/Checkbox/CheckboxCheckerScalingTest.java line 53: > >> 51: Robot robot = new Robot(); >> 52: try { >> 53: SwingUtilities.invokeAndWait(() -> { > > I think `EventQueue.invokeAndWait()` should be used instead of `SwingUtilities.invokeAndWait()` for AWT test. Why? > test/jdk/java/awt/Checkbox/CheckboxCheckerScalingTest.java line 54: > >> 52: try { >> 53: SwingUtilities.invokeAndWait(() -> { >> 54: frame = new Frame("ComboBox checker scaling test"); > > Is it possible to render the checkbox into the buffered image directly and then do the testing? > > This way, you can avoid creating the frame, adding component to it, using robot for screen capture. I guess it can be done, anyhow will try it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20441#discussion_r1705338940 PR Review Comment: https://git.openjdk.org/jdk/pull/20441#discussion_r1705339386 From abhiscxk at openjdk.org Tue Aug 6 12:59:39 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Tue, 6 Aug 2024 12:59:39 GMT Subject: RFR: 8233068: HIDPI: Linux: AWT Checkbox check mark is unscaled [v3] In-Reply-To: References: Message-ID: On Tue, 6 Aug 2024 11:01:26 GMT, Tejesh R wrote: >> test/jdk/java/awt/Checkbox/CheckboxCheckerScalingTest.java line 53: >> >>> 51: Robot robot = new Robot(); >>> 52: try { >>> 53: SwingUtilities.invokeAndWait(() -> { >> >> I think `EventQueue.invokeAndWait()` should be used instead of `SwingUtilities.invokeAndWait()` for AWT test. > > Why? I remember it was advised to use "EventQueue.invokeAndWait() for AWT tests and SwingUtilities.invokeAndWait for swing tests and we should avoid calling swing class from awt. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20441#discussion_r1705490446 From ihse at openjdk.org Tue Aug 6 16:19:31 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 6 Aug 2024 16:19:31 GMT Subject: RFR: 8337851: Some tests have name which confuse jtreg In-Reply-To: References: Message-ID: On Tue, 6 Aug 2024 05:51:35 GMT, toshiogata wrote: > Rename the tests to prevent unexpected deletion of result files when `-retain` jtreg option is specified. > Testing: modified tests @jonathan-gibbons Is this a bug in jtreg, or where these files actually improperly named? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20475#issuecomment-2271665937 From jjg at openjdk.org Tue Aug 6 17:27:32 2024 From: jjg at openjdk.org (Jonathan Gibbons) Date: Tue, 6 Aug 2024 17:27:32 GMT Subject: RFR: 8337851: Some tests have name which confuse jtreg In-Reply-To: References: Message-ID: <3Td2vLLcPueF_vnXvGXF637nREXWsZsvT5gHOFRNNdE=.c703c4ce-0fae-42e3-989a-2821798eefad@github.com> On Tue, 6 Aug 2024 16:17:07 GMT, Magnus Ihse Bursie wrote: > @jonathan-gibbons Is this a bug in jtreg, or where these files actually improperly named? Not a bug as such, but maybe a little-known misfeature. `jtreg` has always had problems with filenames that could cause confusion, and the general sense has generally been, "if it hurts, don't do it!". That being said, our overall library API and infrastructure is way better these days than in times past, and it might be reasonable to file an Enhancement for `jtreg` to have a utility/check/test to detect these anomalous situations. In the meantime, renaming the files to avoid the problem is the recommended solution. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20475#issuecomment-2271784061 From honkar at openjdk.org Tue Aug 6 17:48:33 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Tue, 6 Aug 2024 17:48:33 GMT Subject: RFR: 8233068: HIDPI: Linux: AWT Checkbox check mark is unscaled [v3] In-Reply-To: References: Message-ID: <4wKiZaPRCVqLvmi7g-CSnxL0dr5bh39qZ0q5tV3e7-M=.cdbe73d1-4542-44a9-b9bd-fc3776638417@github.com> On Tue, 6 Aug 2024 12:57:00 GMT, Abhishek Kumar wrote: >> Why? > > I remember it was advised to use "EventQueue.invokeAndWait() for AWT tests and SwingUtilities.invokeAndWait for swing tests and we should avoid calling swing class from awt. Yes, this is correct. I have seen many AWT tests use `EventQueue.invokeAndWait()` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20441#discussion_r1705907990 From honkar at openjdk.org Tue Aug 6 17:56:31 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Tue, 6 Aug 2024 17:56:31 GMT Subject: RFR: 8290501 : Typo Found In The javax.swing Interface BoundedRangeModel Documentation In-Reply-To: References: Message-ID: On Mon, 5 Aug 2024 10:56:49 GMT, Renjith Kannath Pariyangad wrote: > Documentation updated src/java.desktop/share/classes/javax/swing/BoundedRangeModel.java line 43: > 41: * must lie within the outer one, i.e. value must be > 42: * less than or equal to maximum and value+extent > 43: * must be greater than or equal to minimum, and maximum Since you are already updating the doc, we could also consider updating `...` to use the newer format `{@code ...}` in this file. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20465#discussion_r1705916252 From achung at openjdk.org Tue Aug 6 18:28:09 2024 From: achung at openjdk.org (Alisen Chung) Date: Tue, 6 Aug 2024 18:28:09 GMT Subject: RFR: 8235404: [macos] JOptionPane blocks drawing string on another component [v4] In-Reply-To: References: Message-ID: > Currently if you try to use graphics to draw a string on a frame using JOptionPane + JTextField with a listener as a prompt, the string will not draw. Adding a repaint after dialog.dispose in JOptionPane will cause the text to show after the dialog is closed. Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: space ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20359/files - new: https://git.openjdk.org/jdk/pull/20359/files/935e9884..21696aad Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20359&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20359&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20359.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20359/head:pull/20359 PR: https://git.openjdk.org/jdk/pull/20359 From honkar at openjdk.org Tue Aug 6 18:35:30 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Tue, 6 Aug 2024 18:35:30 GMT Subject: RFR: 8328553: Get rid of JApplet in test/jdk/sanity/client/lib/SwingSet2/src/DemoModule.java In-Reply-To: References: Message-ID: <9i7ceg_lrISZD8CrT4XuW3LpYO-Aiw4tT8hcZz9d0Ag=.6bd5939f-626d-46a9-9c0d-5f81a8f0650f@github.com> On Sat, 3 Aug 2024 18:07:16 GMT, lawrence.andrews wrote: > 1) Replaced JApplet with JPanel > 2) Tests passed before and after fix Changes look good. Not related to the fix, but when you click on File > About, following exception is seen due to missing image (resources/images/About.jpg). Maybe this option is not required for the sanity test in which case it can be disabled. ![image](https://github.com/user-attachments/assets/04307a44-4fd9-41bd-bac6-5f8f7ae7a293) About.jpg is available jfc/SwingSet2/ demo version. Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException: Cannot invoke "java.net.URL.toExternalForm()" because "location" is null at java.desktop/javax.swing.ImageIcon.(ImageIcon.java:232) at SwingSet2.createImageIcon(SwingSet2.java:783) at SwingSet2$AboutPanel.(SwingSet2.java:1161) ------------- PR Comment: https://git.openjdk.org/jdk/pull/20450#issuecomment-2271904762 From honkar at openjdk.org Tue Aug 6 18:54:34 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Tue, 6 Aug 2024 18:54:34 GMT Subject: RFR: 8235404: [macos] JOptionPane blocks drawing string on another component [v4] In-Reply-To: References: Message-ID: On Tue, 6 Aug 2024 18:28:09 GMT, Alisen Chung wrote: >> Currently if you try to use graphics to draw a string on a frame using JOptionPane + JTextField with a listener as a prompt, the string will not draw. Adding a repaint after dialog.dispose in JOptionPane will cause the text to show after the dialog is closed. > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > space Changes requested by honkar (Reviewer). test/jdk/javax/swing/JOptionPane/OptionPaneInput.java line 9: > 7: * published by the Free Software Foundation. Oracle designates this > 8: * particular file as subject to the "Classpath" exception as provided > 9: * by Oracle in the LICENSE file that accompanied this code. Isn't the "Classpath" exception header only applicable to source code files? Can you please verify with other test file copyright header. ------------- PR Review: https://git.openjdk.org/jdk/pull/20359#pullrequestreview-2222021004 PR Review Comment: https://git.openjdk.org/jdk/pull/20359#discussion_r1705976247 From achung at openjdk.org Tue Aug 6 20:51:50 2024 From: achung at openjdk.org (Alisen Chung) Date: Tue, 6 Aug 2024 20:51:50 GMT Subject: RFR: 8235404: [macos] JOptionPane blocks drawing string on another component [v5] In-Reply-To: References: Message-ID: <19lQrZL2vXGW01lYsVm8mhouxFqRkaKPC_tzimBRkWk=.a34d929d-e6df-4f64-8291-5ca7b178b815@github.com> > Currently if you try to use graphics to draw a string on a frame using JOptionPane + JTextField with a listener as a prompt, the string will not draw. Adding a repaint after dialog.dispose in JOptionPane will cause the text to show after the dialog is closed. Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: remove classpath from copyright ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20359/files - new: https://git.openjdk.org/jdk/pull/20359/files/21696aad..930bb81e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20359&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20359&range=03-04 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20359.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20359/head:pull/20359 PR: https://git.openjdk.org/jdk/pull/20359 From achung at openjdk.org Tue Aug 6 20:51:51 2024 From: achung at openjdk.org (Alisen Chung) Date: Tue, 6 Aug 2024 20:51:51 GMT Subject: RFR: 8235404: [macos] JOptionPane blocks drawing string on another component [v4] In-Reply-To: References: Message-ID: On Tue, 6 Aug 2024 18:49:56 GMT, Harshitha Onkar wrote: >> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: >> >> space > > test/jdk/javax/swing/JOptionPane/OptionPaneInput.java line 9: > >> 7: * published by the Free Software Foundation. Oracle designates this >> 8: * particular file as subject to the "Classpath" exception as provided >> 9: * by Oracle in the LICENSE file that accompanied this code. > > Isn't the "Classpath" exception header only applicable to source code files? > Can you please verify with other test file copyright header. Good catch, I've removed the classpath portion of the copyright. Can you check over the copyright again to make sure it's correct? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20359#discussion_r1706096195 From honkar at openjdk.org Tue Aug 6 21:09:40 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Tue, 6 Aug 2024 21:09:40 GMT Subject: RFR: 8235404: [macos] JOptionPane blocks drawing string on another component [v5] In-Reply-To: <19lQrZL2vXGW01lYsVm8mhouxFqRkaKPC_tzimBRkWk=.a34d929d-e6df-4f64-8291-5ca7b178b815@github.com> References: <19lQrZL2vXGW01lYsVm8mhouxFqRkaKPC_tzimBRkWk=.a34d929d-e6df-4f64-8291-5ca7b178b815@github.com> Message-ID: On Tue, 6 Aug 2024 20:51:50 GMT, Alisen Chung wrote: >> Currently if you try to use graphics to draw a string on a frame using JOptionPane + JTextField with a listener as a prompt, the string will not draw. Adding a repaint after dialog.dispose in JOptionPane will cause the text to show after the dialog is closed. > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > remove classpath from copyright LGTM ------------- Marked as reviewed by honkar (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20359#pullrequestreview-2222244585 From achung at openjdk.org Tue Aug 6 21:12:38 2024 From: achung at openjdk.org (Alisen Chung) Date: Tue, 6 Aug 2024 21:12:38 GMT Subject: Integrated: 8235404: [macos] JOptionPane blocks drawing string on another component In-Reply-To: References: Message-ID: On Fri, 26 Jul 2024 16:52:44 GMT, Alisen Chung wrote: > Currently if you try to use graphics to draw a string on a frame using JOptionPane + JTextField with a listener as a prompt, the string will not draw. Adding a repaint after dialog.dispose in JOptionPane will cause the text to show after the dialog is closed. This pull request has now been integrated. Changeset: fc652d2a Author: Alisen Chung URL: https://git.openjdk.org/jdk/commit/fc652d2a58bfd99b05011c051e5710d1dac049ab Stats: 86 lines in 2 files changed: 85 ins; 0 del; 1 mod 8235404: [macos] JOptionPane blocks drawing string on another component Reviewed-by: honkar, dnguyen ------------- PR: https://git.openjdk.org/jdk/pull/20359 From achung at openjdk.org Tue Aug 6 21:36:15 2024 From: achung at openjdk.org (Alisen Chung) Date: Tue, 6 Aug 2024 21:36:15 GMT Subject: RFR: 7188058: Background of TextComponents are not changing colors to the default disabled color when set to uneditable [v3] In-Reply-To: References: Message-ID: > Currently the bug described in the issue is that the colors of the TextComponents do not change when setting TextComponents to uneditable. The default uneditable color (SystemColor.control) happens to be the same as the default for the editable color for some L&Fs, so the fix may not be initially noticeable. However, the bug still exists where the the color is not being changed when changing between editable and uneditable. You can check by changing TextComponent.getBackground() code to return Color.GRAY on line 342 and you can see that TextComponents are not changing to a gray background when set to uneditable. > > This fix adds a private setBackground method in TextComponent so that TextArea and TextField can change the background color to the correct color (SystemColor.control) when set uneditable by overriding the TextComponent setEditable. You can verify the fix by changing this color to Color.GRAY and verifying the backgrounds change to gray when the TextComponents are disabled. Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: use getbackground ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19876/files - new: https://git.openjdk.org/jdk/pull/19876/files/0b0f049c..e83c29fe Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19876&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19876&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/19876.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19876/head:pull/19876 PR: https://git.openjdk.org/jdk/pull/19876 From achung at openjdk.org Tue Aug 6 21:48:38 2024 From: achung at openjdk.org (Alisen Chung) Date: Tue, 6 Aug 2024 21:48:38 GMT Subject: RFR: 8233068: HIDPI: Linux: AWT Checkbox check mark is unscaled [v4] In-Reply-To: References: Message-ID: On Tue, 6 Aug 2024 07:56:11 GMT, Tejesh R wrote: >> The check mark had been transformed with default scale which is 1.0 and the same is used on click of checkbox. This was done while computing the layout and not updated while paint. Hence the scaling update is done on painting the check mark and CI testing is green after the update too. > > Tejesh R has updated the pull request incrementally with one additional commit since the last revision: > > Review updates test/jdk/java/awt/Checkbox/CheckboxCheckerScalingTest.java line 39: > 37: * @bug 8233068 > 38: * @summary Tests checkbox checker on scaling > 39: * @requires (os.family == "linux") can this test also be run on different platforms? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20441#discussion_r1706147120 From dnguyen at openjdk.org Tue Aug 6 23:17:42 2024 From: dnguyen at openjdk.org (Damon Nguyen) Date: Tue, 6 Aug 2024 23:17:42 GMT Subject: RFR: 8321140: Doc change to note difference in Metal's JButton margins Message-ID: Previously in [JDK-8282772](https://bugs.openjdk.org/browse/JDK-8282772), there was a fix for JButtons with HTML content alignment for non-MacOS L&Fs. This fix was to make other L&Fs in line with the Aqua fix found in [JDK-8015854](https://bugs.openjdk.org/browse/JDK-8015854). However, the non-MacOS L&F fix caused a regression and the details and original discussion can be found in [JDK-8318590](https://bugs.openjdk.org/browse/JDK-8318590). This non-MacOS L&F fix was backed out and the current behavior for JButtons with HTML content for these L&Fs was deemed to be correct as is. Through discussion, a note about Metal's different margin values should be added somewhere for future reference. Metal's horizontal margins are 14 where other L&Fs are zero or some small value. This discrepancy is what caused the original issue to be filed. This change is to add a comment to `MetalLookAndFeel.java` since there is no exact spot where these values are set for the margin. It's been added where other Metal components (CheckBox, RadioButton, etc.) have comments on margins as well. Here are some L&F values for reference/comparison: Metal's margins: [top=2,left=14,bottom=2,right=14] Aqua's margins: [top=0,left=2,bottom=0,right=2] Motif's margins: [top=2,left=4,bottom=2,right=4] Nimbus's margins: [top=0,left=0,bottom=0,right=0] ------------- Commit messages: - Initial commit Changes: https://git.openjdk.org/jdk/pull/20482/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20482&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8321140 Stats: 48 lines in 1 file changed: 36 ins; 9 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/20482.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20482/head:pull/20482 PR: https://git.openjdk.org/jdk/pull/20482 From honkar at openjdk.org Wed Aug 7 00:39:32 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Wed, 7 Aug 2024 00:39:32 GMT Subject: RFR: 8321140: Doc change to note difference in Metal's JButton margins In-Reply-To: References: Message-ID: <4A_H-zTNLfS_4IDTcWYX9vo4NuTEtlv_XGl0upo0inI=.cfa48fae-ed2e-4ce2-a0b7-bc1d9bd266dc@github.com> On Tue, 6 Aug 2024 23:12:44 GMT, Damon Nguyen wrote: > Previously in [JDK-8282772](https://bugs.openjdk.org/browse/JDK-8282772), there was a fix for JButtons with HTML content alignment for non-MacOS L&Fs. This fix was to make other L&Fs in line with the Aqua fix found in [JDK-8015854](https://bugs.openjdk.org/browse/JDK-8015854). > > However, the non-MacOS L&F fix caused a regression and the details and original discussion can be found in [JDK-8318590](https://bugs.openjdk.org/browse/JDK-8318590). This non-MacOS L&F fix was backed out and the current behavior for JButtons with HTML content for these L&Fs was deemed to be correct as is. > > Through discussion, a note about Metal's different margin values should be added somewhere for future reference. Metal's horizontal margins are 14 where other L&Fs are zero or some small value. This discrepancy is what caused the original issue to be filed. This change is to add a comment to `MetalLookAndFeel.java` since there is no exact spot where these values are set for the margin. It's been added where other Metal components (CheckBox, RadioButton, etc.) have comments on margins as well. > > Here are some L&F values for reference/comparison: > > Metal's margins: [top=2,left=14,bottom=2,right=14] > Aqua's margins: [top=0,left=2,bottom=0,right=2] > Motif's margins: [top=2,left=4,bottom=2,right=4] > Nimbus's margins: [top=0,left=0,bottom=0,right=0] In some L&Fs I see margin defaults set using `Button.margin`. Where does Metal LAF finally obtain these margin values from?`[top=2,left=14,bottom=2,right=14]`. Adding your margin comment will provide clarity & quick reference since these values are not evident. ------------- PR Review: https://git.openjdk.org/jdk/pull/20482#pullrequestreview-2222438374 From psadhukhan at openjdk.org Wed Aug 7 04:27:14 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 7 Aug 2024 04:27:14 GMT Subject: RFR: 8335231: [macos] Test java/awt/print/PrinterJob/Cancel/PrinterJobCancel.java failed on macOS because the case didn't get the expected PrintAbortException [v6] In-Reply-To: References: Message-ID: > When a printjob is cancelled midway, `PrinterAbortException `was not thrown in macos. because > firstly,` cancelCheck` invokes` LWCToolkit.invokeLater` with null as parameter causing it to fail with NPE and > secondly PrinterAbortException was consumed silently when `printLoop` throws any exception > which is rectified to throw the PrinterAbortException when encountered.. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Grab the exception, clear, store and then recheck in Javacode to avoid NSException log ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20027/files - new: https://git.openjdk.org/jdk/pull/20027/files/3ff67eb2..6a1c7ce5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20027&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20027&range=04-05 Stats: 19 lines in 2 files changed: 10 ins; 4 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/20027.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20027/head:pull/20027 PR: https://git.openjdk.org/jdk/pull/20027 From psadhukhan at openjdk.org Wed Aug 7 04:29:39 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 7 Aug 2024 04:29:39 GMT Subject: RFR: 8335231: [macos] Test java/awt/print/PrinterJob/Cancel/PrinterJobCancel.java failed on macOS because the case didn't get the expected PrintAbortException [v5] In-Reply-To: <6BItk2St1IQ4QKZkY3M7fT02GV_vJTb3WRP0lVq8FWU=.0c4a6ff0-65c3-4186-b56a-7d6fea72046a@github.com> References: <6BItk2St1IQ4QKZkY3M7fT02GV_vJTb3WRP0lVq8FWU=.0c4a6ff0-65c3-4186-b56a-7d6fea72046a@github.com> Message-ID: On Mon, 5 Aug 2024 10:09:06 GMT, Prasanta Sadhukhan wrote: >> When a printjob is cancelled midway, `PrinterAbortException `was not thrown in macos. because >> firstly,` cancelCheck` invokes` LWCToolkit.invokeLater` with null as parameter causing it to fail with NPE and >> secondly PrinterAbortException was consumed silently when `printLoop` throws any exception >> which is rectified to throw the PrinterAbortException when encountered.. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Dont call completePrintLoop if cancelDoc is called as both exits PrintingLoop I modified the PR to implement this (1) grab the exception (2) clear it from the current thread, but we still have a ref - it is just a Java object ! (3) store it in some field of the CPrinterJob (4) then check for it and re-throw when we reach Java code. which solves the (3) NSException log but (2) macos error popup is still there.. I guess it is because it prints 1st page but there is a blank 2nd page which seems to suggest macos printer driver spooled the page but failed to print as it was aborted so it threw the error popup.. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20027#issuecomment-2272592973 From tr at openjdk.org Wed Aug 7 04:31:39 2024 From: tr at openjdk.org (Tejesh R) Date: Wed, 7 Aug 2024 04:31:39 GMT Subject: RFR: 8233068: HIDPI: Linux: AWT Checkbox check mark is unscaled [v4] In-Reply-To: References: Message-ID: On Tue, 6 Aug 2024 21:45:50 GMT, Alisen Chung wrote: >> Tejesh R has updated the pull request incrementally with one additional commit since the last revision: >> >> Review updates > > test/jdk/java/awt/Checkbox/CheckboxCheckerScalingTest.java line 39: > >> 37: * @bug 8233068 >> 38: * @summary Tests checkbox checker on scaling >> 39: * @requires (os.family == "linux") > > can this test also be run on different platforms? Can be run, but in windows the scaling is not taken care yet. I guess in macos the scaling is handled. Since the fix is for linux alone, its better to restrict to linux now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20441#discussion_r1706364439 From tr at openjdk.org Wed Aug 7 04:57:31 2024 From: tr at openjdk.org (Tejesh R) Date: Wed, 7 Aug 2024 04:57:31 GMT Subject: RFR: 8233068: HIDPI: Linux: AWT Checkbox check mark is unscaled [v3] In-Reply-To: References: Message-ID: On Tue, 6 Aug 2024 11:01:52 GMT, Tejesh R wrote: >> test/jdk/java/awt/Checkbox/CheckboxCheckerScalingTest.java line 54: >> >>> 52: try { >>> 53: SwingUtilities.invokeAndWait(() -> { >>> 54: frame = new Frame("ComboBox checker scaling test"); >> >> Is it possible to render the checkbox into the buffered image directly and then do the testing? >> >> This way, you can avoid creating the frame, adding component to it, using robot for screen capture. > > I guess it can be done, anyhow will try it. Tried it, but not able to paint it to `bufferedImage` the way it does for swing components. I don't see any references also which does this, except for print/image. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20441#discussion_r1706379453 From tr at openjdk.org Wed Aug 7 05:08:53 2024 From: tr at openjdk.org (Tejesh R) Date: Wed, 7 Aug 2024 05:08:53 GMT Subject: RFR: 8233068: HIDPI: Linux: AWT Checkbox check mark is unscaled [v5] In-Reply-To: References: Message-ID: <3N2FvQpQDxJakEyEr0OH8v7DJj1ZmlpCg5OZU1EmMsc=.353d9acf-4333-4574-97da-ce0230f96774@github.com> > The check mark had been transformed with default scale which is 1.0 and the same is used on click of checkbox. This was done while computing the layout and not updated while paint. Hence the scaling update is done on painting the check mark and CI testing is green after the update too. Tejesh R has updated the pull request incrementally with one additional commit since the last revision: replaced with EventQueue ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20441/files - new: https://git.openjdk.org/jdk/pull/20441/files/a59323f0..ab1cd785 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20441&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20441&range=03-04 Stats: 6 lines in 1 file changed: 1 ins; 2 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/20441.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20441/head:pull/20441 PR: https://git.openjdk.org/jdk/pull/20441 From mvs at openjdk.org Wed Aug 7 06:59:59 2024 From: mvs at openjdk.org (Manukumar V S) Date: Wed, 7 Aug 2024 06:59:59 GMT Subject: RFR: 8337886: java/awt/Frame/MaximizeUndecoratedTest.java fails in OEL due to a slight color difference Message-ID: <2HljLuH3vumJyEMqhCWnGVnAWCJaMrbVbf0PgBO8ATg=.3bd94f6d-124b-4e4a-be15-ec319f552223@github.com> java/awt/Frame/MaximizeUndecoratedTest.java fails in OEL due to a slight color difference in the background color. This is currently reproduced only for Oracle Linux. The Color object I'm getting for each of these Point objects: new Point(maxBounds.x + OFFSET, maxBounds.y + OFFSET) --> java.awt.Color[r=0,g=255,b=0] new Point(maxBounds.width - OFFSET, maxBounds.y + OFFSET) --> java.awt.Color[r=0,g=207,b=0] new Point(maxBounds.width - OFFSET, maxBounds.height - OFFSET) --> java.awt.Color[r=0,g=255,b=0] new Point(maxBounds.x + OFFSET, maxBounds.height - OFFSET) --> java.awt.Color[r=0,g=255,b=0] So, the issue occurs for the second Point object --> new Point(maxBounds.width - OFFSET, maxBounds.y + OFFSET) - java.awt.Color[r=0,g=207,b=0] Fix: When the offset is increased from 2 to 3, it works fine in all the platforms. Testing: Tested using mach5 in all the available platforms and it works fine everywhere(results attached in bug). Tested manually in OEL 8 and it works fine there also. ------------- Commit messages: - 8337886: java/awt/Frame/MaximizeUndecoratedTest.java fails in OEL due to a slight color difference Changes: https://git.openjdk.org/jdk/pull/20486/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20486&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8337886 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20486.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20486/head:pull/20486 PR: https://git.openjdk.org/jdk/pull/20486 From psadhukhan at openjdk.org Wed Aug 7 07:56:15 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 7 Aug 2024 07:56:15 GMT Subject: RFR: 6318027: BasicScrollBarUI does not disable timer when enclosing frame is disabled. [v2] In-Reply-To: References: Message-ID: > Issue is > BasicScrollBarUI.ArrowButtonListener starts a timer in mousePressed(), and stops it in mouseReleased(). If the frame containing the scrollbar is disabled between the MOUSE_PRESSED and the MOUSE_RELEASED events, the mouseReleased() method is never called. If the frame is then re-enabled, the still-running timer causes it to scroll all the way to the end. > Fix is to check if [ArrowButtonListener.handledEvent](https://github.com/openjdk/jdk/blame/ee839b7f0ebe471d3877cddd2c87019ccb8ee5ae/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicScrollBarUI.java#L1567) is still set when ActionEvent is processed then stop the timer and reset this variable. > > CI testing is green and also SwingSet2 JScrollPane scrolling with this modification.. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Test update ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20346/files - new: https://git.openjdk.org/jdk/pull/20346/files/dfe4532a..53d6f32e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20346&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20346&range=00-01 Stats: 32 lines in 1 file changed: 17 ins; 11 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/20346.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20346/head:pull/20346 PR: https://git.openjdk.org/jdk/pull/20346 From psadhukhan at openjdk.org Wed Aug 7 07:59:31 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 7 Aug 2024 07:59:31 GMT Subject: RFR: 6318027: BasicScrollBarUI does not disable timer when enclosing frame is disabled. [v2] In-Reply-To: <4TML2eKsoCAd8McEefOMoAxEBFFom5423HsoorVtFuc=.617f22e2-fd42-44bb-9644-8de718112f8e@github.com> References: <_g5SYdkcap5xfK58rwbdm3ZRCcLsOefVKhiSYLtk8Ow=.ea12bbde-7f7e-45af-ad56-571bd0f041af@github.com> <4TML2eKsoCAd8McEefOMoAxEBFFom5423HsoorVtFuc=.617f22e2-fd42-44bb-9644-8de718112f8e@github.com> Message-ID: On Fri, 2 Aug 2024 21:32:02 GMT, Alisen Chung wrote: >> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicScrollBarUI.java line 1614: >> >>> 1612: // mouseReleased is not called after mousePressed when >>> 1613: // this AcionEvent is being processed >>> 1614: if (buttonListener.handledEvent) { >> >> Since the fix is added in BasicScrollBarUI, will it affect Aqua ScrollBar also? > > I think most L&F's ScrollBarUI classes are extending BasicScrollBarUI so it might be worth checking if this issue also occurs in those L&Fs too Aqua ScrollBar does not have arrowbutton so ArrowButtonListener, as mentioned in JBS, is not there but there is trackpad and there is similar issue with it but it cannot be handled with this "handledEvent" and needs to be handled separately so as of now AquaL&F is omitted from the testing..Other L&F are fine as per the testing.. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20346#discussion_r1706556828 From psadhukhan at openjdk.org Wed Aug 7 13:52:07 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 7 Aug 2024 13:52:07 GMT Subject: RFR: 6318027: BasicScrollBarUI does not disable timer when enclosing frame is disabled. [v3] In-Reply-To: References: Message-ID: > Issue is > BasicScrollBarUI.ArrowButtonListener starts a timer in mousePressed(), and stops it in mouseReleased(). If the frame containing the scrollbar is disabled between the MOUSE_PRESSED and the MOUSE_RELEASED events, the mouseReleased() method is never called. If the frame is then re-enabled, the still-running timer causes it to scroll all the way to the end. > Fix is to check if [ArrowButtonListener.handledEvent](https://github.com/openjdk/jdk/blame/ee839b7f0ebe471d3877cddd2c87019ccb8ee5ae/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicScrollBarUI.java#L1567) is still set when ActionEvent is processed then stop the timer and reset this variable. > > CI testing is green and also SwingSet2 JScrollPane scrolling with this modification.. Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision: - copyright - Restore AquaL&F testing ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20346/files - new: https://git.openjdk.org/jdk/pull/20346/files/53d6f32e..00fd5e58 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20346&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20346&range=01-02 Stats: 11 lines in 3 files changed: 6 ins; 3 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20346.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20346/head:pull/20346 PR: https://git.openjdk.org/jdk/pull/20346 From aivanov at openjdk.org Wed Aug 7 18:29:32 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 7 Aug 2024 18:29:32 GMT Subject: RFR: 8321140: Doc change to note difference in Metal's JButton margins In-Reply-To: References: Message-ID: On Tue, 6 Aug 2024 23:12:44 GMT, Damon Nguyen wrote: > Previously in [JDK-8282772](https://bugs.openjdk.org/browse/JDK-8282772), there was a fix for JButtons with HTML content alignment for non-MacOS L&Fs. This fix was to make other L&Fs in line with the Aqua fix found in [JDK-8015854](https://bugs.openjdk.org/browse/JDK-8015854). > > However, the non-MacOS L&F fix caused a regression and the details and original discussion can be found in [JDK-8318590](https://bugs.openjdk.org/browse/JDK-8318590). This non-MacOS L&F fix was backed out and the current behavior for JButtons with HTML content for these L&Fs was deemed to be correct as is. > > Through discussion, a note about Metal's different margin values should be added somewhere for future reference. Metal's horizontal margins are 14 where other L&Fs are zero or some small value. This discrepancy is what caused the original issue to be filed. This change is to add a comment to `MetalLookAndFeel.java` since there is no exact spot where these values are set for the margin. It's been added where other Metal components (CheckBox, RadioButton, etc.) have comments on margins as well. > > Here are some L&F values for reference/comparison: > > Metal's margins: [top=2,left=14,bottom=2,right=14] > Aqua's margins: [top=0,left=2,bottom=0,right=2] > Motif's margins: [top=2,left=4,bottom=2,right=4] > Nimbus's margins: [top=0,left=0,bottom=0,right=0] I've no objections from adding a comment in the code. However, the comment looks as if hanging in the air. There are `CheckBox.totalInsets` and `RadioButton.totalInsets` but there's no similar property for `Button`. As for me, *?Doc change?* implies javadoc, but it is not the case. You're add a regular code comment which no one sees, except for developers. The subject has be clearer in this respect. Like ?Comment about difference? or ?Note about difference??, to avoid any confusion. ------------- Changes requested by aivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20482#pullrequestreview-2225892906 From swinxythecat at gmail.com Wed Aug 7 20:16:46 2024 From: swinxythecat at gmail.com (SWinxy) Date: Wed, 7 Aug 2024 16:16:46 -0400 Subject: Status on JDK-8305479 (+ info to reproduce it) In-Reply-To: References: Message-ID: This appears to be a deadlock. I've been able to replicate it, but it's annoyingly finicky to get it to freeze. A thread gets stuck on WaitForSingleObject at awt_Toolkit.cpp#L3139 (in AwtToolkit::InvokeInputMethodFunction) waiting for an object to be signaled, but the signalling gets lost. And so it waits indefinitely. dmarkov, do you know more? A possible solution would be to change the timeout to be 1000ms, but that may have unintended effects. SWinxy On Mon, Aug 5, 2024 at 5:23?AM Reto Merz wrote: > Hello, > > Our customers are using Drag & Drop functionality more and more > and reports are increasing that our application is haning. > It starts to escalate since the only workaround is to restart the app > right now. > > The problem is already reported with JDK-8305479 [1] > > Is there any way to increase the priority of that issue > or is a developer here we can hire to search for a fix (and create a pull > request)? > > Btw, the bug is much easier to reproduce: > > 1) Start the demo app (see [1]) > 2) try to drop a document (eg: pdf file) from the windows desktop into the > textfield > > Repeat step 2 if necessary. For me after 1-2 try this will cause the hang. > If not, move the JFrame to another position and repeat step 2 again. > > Tested with latest JDK: > java version "22.0.2" 2024-07-16 > Java(TM) SE Runtime Environment (build 22.0.2+9-70) > Java HotSpot(TM) 64-Bit Server VM (build 22.0.2+9-70, mixed mode, > sharing) > > OS MS Windows: > Microsoft Windows [Version 10.0.17763.5458] > > Regards > Reto Merz > > [1] https://bugs.openjdk.org/browse/JDK-8305479 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dnguyen at openjdk.org Wed Aug 7 22:35:30 2024 From: dnguyen at openjdk.org (Damon Nguyen) Date: Wed, 7 Aug 2024 22:35:30 GMT Subject: RFR: 8321140: Add comment to note difference in Metal's JButton margins In-Reply-To: References: Message-ID: On Tue, 6 Aug 2024 23:12:44 GMT, Damon Nguyen wrote: > Previously in [JDK-8282772](https://bugs.openjdk.org/browse/JDK-8282772), there was a fix for JButtons with HTML content alignment for non-MacOS L&Fs. This fix was to make other L&Fs in line with the Aqua fix found in [JDK-8015854](https://bugs.openjdk.org/browse/JDK-8015854). > > However, the non-MacOS L&F fix caused a regression and the details and original discussion can be found in [JDK-8318590](https://bugs.openjdk.org/browse/JDK-8318590). This non-MacOS L&F fix was backed out and the current behavior for JButtons with HTML content for these L&Fs was deemed to be correct as is. > > Through discussion, a note about Metal's different margin values should be added somewhere for future reference. Metal's horizontal margins are 14 where other L&Fs are zero or some small value. This discrepancy is what caused the original issue to be filed. This change is to add a comment to `MetalLookAndFeel.java` since there is no exact spot where these values are set for the margin. It's been added where other Metal components (CheckBox, RadioButton, etc.) have comments on margins as well. > > Here are some L&F values for reference/comparison: > > Metal's margins: [top=2,left=14,bottom=2,right=14] > Aqua's margins: [top=0,left=2,bottom=0,right=2] > Motif's margins: [top=2,left=4,bottom=2,right=4] > Nimbus's margins: [top=0,left=0,bottom=0,right=0] > I've no objections from adding a comment in the code. However, the comment looks as if hanging in the air. There are `CheckBox.totalInsets` and `RadioButton.totalInsets` but there's no similar property for `Button`. > > As for me, _?Doc change?_ implies javadoc, but it is not the case. You're add a regular code comment which no one sees, except for developers. > > The subject has be clearer in this respect. Like ?Comment about difference? or ?Note about difference??, to avoid any confusion. Updated thanks. Originally this was meant to be a visible doc change when I created the issue long ago. But after looking thru the docs for Metal and any other appropriate APIs, I couldn't find a great spot to place it other than here. I agree that the comment seems to be out of place. Do you have any suggestions for where to place it otherwise? I'm currently looking into where the Metal margin defaults are set for @honkar-jdk comment. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20482#issuecomment-2274461508 From achung at openjdk.org Thu Aug 8 01:22:42 2024 From: achung at openjdk.org (Alisen Chung) Date: Thu, 8 Aug 2024 01:22:42 GMT Subject: RFR: 7188058: Background of TextComponents are not changing colors to the default disabled color when set to uneditable [v2] In-Reply-To: References: <77lt11qmN9Pift0gg2CmeN1v1CRSv4nP50d8hdNPynU=.f2f65d8a-293d-48c2-81d4-0b945cfcb158@github.com> Message-ID: On Tue, 6 Aug 2024 09:25:55 GMT, Prasanta Sadhukhan wrote: >> This call is only to get the default background of TextArea. Is there another way to grab the default color without using UIManager? > > Yes, but as far I could see `TextArea.background` property is being set in > `AquaLookAndFeel.java, MotifLookAndFeel.java, BasicLookAndFeel.java, XAWTLookAndFeel.java and WindowsLookAndFeel.java` > and this L&F will not be set in AWT environment, if I am not wrong so you will either get garbage or wrong default color if you use UIManager.getColor..so I guess you need to use `TextComponent.getBackground()` which returns SystemColor.control if nothing is set i've made the change to use TextComponent.getBackground() instead to get the correct background color ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19876#discussion_r1708330280 From abhiscxk at openjdk.org Thu Aug 8 04:31:32 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Thu, 8 Aug 2024 04:31:32 GMT Subject: RFR: 8233068: HIDPI: Linux: AWT Checkbox check mark is unscaled [v5] In-Reply-To: <3N2FvQpQDxJakEyEr0OH8v7DJj1ZmlpCg5OZU1EmMsc=.353d9acf-4333-4574-97da-ce0230f96774@github.com> References: <3N2FvQpQDxJakEyEr0OH8v7DJj1ZmlpCg5OZU1EmMsc=.353d9acf-4333-4574-97da-ce0230f96774@github.com> Message-ID: On Wed, 7 Aug 2024 05:08:53 GMT, Tejesh R wrote: >> The check mark had been transformed with default scale which is 1.0 and the same is used on click of checkbox. This was done while computing the layout and not updated while paint. Hence the scaling update is done on painting the check mark and CI testing is green after the update too. > > Tejesh R has updated the pull request incrementally with one additional commit since the last revision: > > replaced with EventQueue Looks good to me. ------------- Marked as reviewed by abhiscxk (Committer). PR Review: https://git.openjdk.org/jdk/pull/20441#pullrequestreview-2226836967 From jdv at openjdk.org Thu Aug 8 10:39:33 2024 From: jdv at openjdk.org (Jayathirth D V) Date: Thu, 8 Aug 2024 10:39:33 GMT Subject: RFR: 8233068: HIDPI: Linux: AWT Checkbox check mark is unscaled [v5] In-Reply-To: <3N2FvQpQDxJakEyEr0OH8v7DJj1ZmlpCg5OZU1EmMsc=.353d9acf-4333-4574-97da-ce0230f96774@github.com> References: <3N2FvQpQDxJakEyEr0OH8v7DJj1ZmlpCg5OZU1EmMsc=.353d9acf-4333-4574-97da-ce0230f96774@github.com> Message-ID: <4AXIKz6IGjFoMWgMDOZlMySOWsDKlSuPYy13rV3hveI=.339034fd-8238-4dda-bca1-6523e88c0dc4@github.com> On Wed, 7 Aug 2024 05:08:53 GMT, Tejesh R wrote: >> The check mark had been transformed with default scale which is 1.0 and the same is used on click of checkbox. This was done while computing the layout and not updated while paint. Hence the scaling update is done on painting the check mark and CI testing is green after the update too. > > Tejesh R has updated the pull request incrementally with one additional commit since the last revision: > > replaced with EventQueue Latest change looks good to me. Make sure to verify latest test in our CI test system before pushing the change. ------------- Marked as reviewed by jdv (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20441#pullrequestreview-2227493477 From tr at openjdk.org Thu Aug 8 10:43:40 2024 From: tr at openjdk.org (Tejesh R) Date: Thu, 8 Aug 2024 10:43:40 GMT Subject: Integrated: 8233068: HIDPI: Linux: AWT Checkbox check mark is unscaled In-Reply-To: References: Message-ID: On Fri, 2 Aug 2024 09:07:47 GMT, Tejesh R wrote: > The check mark had been transformed with default scale which is 1.0 and the same is used on click of checkbox. This was done while computing the layout and not updated while paint. Hence the scaling update is done on painting the check mark and CI testing is green after the update too. This pull request has now been integrated. Changeset: 3bc4a1ac Author: Tejesh R URL: https://git.openjdk.org/jdk/commit/3bc4a1acc4bb1885ddba69283b99bbe02f8e43b7 Stats: 98 lines in 2 files changed: 95 ins; 0 del; 3 mod 8233068: HIDPI: Linux: AWT Checkbox check mark is unscaled Reviewed-by: jdv, abhiscxk, honkar ------------- PR: https://git.openjdk.org/jdk/pull/20441 From azvegint at openjdk.org Thu Aug 8 10:54:40 2024 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Thu, 8 Aug 2024 10:54:40 GMT Subject: Integrated: 8329471: Remove GTK2 In-Reply-To: References: Message-ID: On Mon, 29 Jul 2024 14:55:07 GMT, Alexander Zvegintsev wrote: > GTK2 support for Swing/AWT was deprecated for removal in JDK 21. > > It's being removed because no platform that supports the JDK needs it. > > Manual and automated testing is green. This pull request has now been integrated. Changeset: 12c553f1 Author: Alexander Zvegintsev URL: https://git.openjdk.org/jdk/commit/12c553f12876b4095685676f800119c0e275bf44 Stats: 3352 lines in 17 files changed: 4 ins; 3298 del; 50 mod 8329471: Remove GTK2 Reviewed-by: abhiscxk, prr, ihse ------------- PR: https://git.openjdk.org/jdk/pull/20378 From azvegint at openjdk.org Thu Aug 8 10:54:40 2024 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Thu, 8 Aug 2024 10:54:40 GMT Subject: Integrated: 8335267: [XWayland] move screencast tokens from .awt to .java folder In-Reply-To: References: Message-ID: On Thu, 18 Jul 2024 14:08:35 GMT, Alexander Zvegintsev wrote: > Trivial fix to move the screencast token storage file from `~/.awt/robot/screencast-tokens.properties` to `~/.java/robot/screencast-tokens.properties`, where it should be. > Old location is still valid and will only be used if there is a file in the old location and the new location does not have it. > > Along with the fix `@SuppressWarnings("removal")` is moved to individual items as it was done in [JFX](https://github.com/openjdk/jfx/pull/1490). This pull request has now been integrated. Changeset: 088871ce Author: Alexander Zvegintsev URL: https://git.openjdk.org/jdk/commit/088871ce36f85fb30b24c49146f547bc8e2b0dcb Stats: 61 lines in 1 file changed: 23 ins; 8 del; 30 mod 8335267: [XWayland] move screencast tokens from .awt to .java folder Reviewed-by: prr, avu ------------- PR: https://git.openjdk.org/jdk/pull/20234 From azvegint at openjdk.org Thu Aug 8 10:56:35 2024 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Thu, 8 Aug 2024 10:56:35 GMT Subject: Integrated: 8337320: Update ProblemList.txt with tests known to fail on XWayland In-Reply-To: <0s0hzkhYPEDdMKqb60baTTX5DjM-TLADt8uDG3euGQQ=.c24f5055-0a6b-49a5-8eed-ed9caffdd433@github.com> References: <0s0hzkhYPEDdMKqb60baTTX5DjM-TLADt8uDG3euGQQ=.c24f5055-0a6b-49a5-8eed-ed9caffdd433@github.com> Message-ID: <88sv8h3M-rYjGRUYwZqKVlZISju3rGVLIiG_hJQ9_VQ=.a383e67a-241c-4966-bd51-19476e5e700f@github.com> On Tue, 30 Jul 2024 03:48:08 GMT, Alexander Zvegintsev wrote: > Adding tests failing on XWayland. > > The `java/awt/Focus/VetoableChangeListenerLoopTest.java` mentioned in the bug description no longer fails. This pull request has now been integrated. Changeset: ddbd7a78 Author: Alexander Zvegintsev URL: https://git.openjdk.org/jdk/commit/ddbd7a78f191462695ecbeeef7fd6312e322b15a Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod 8337320: Update ProblemList.txt with tests known to fail on XWayland Reviewed-by: prr ------------- PR: https://git.openjdk.org/jdk/pull/20384 From achung at openjdk.org Thu Aug 8 16:22:36 2024 From: achung at openjdk.org (Alisen Chung) Date: Thu, 8 Aug 2024 16:22:36 GMT Subject: RFR: 7188058: Background of TextComponents are not changing colors to the default disabled color when set to uneditable [v3] In-Reply-To: References: Message-ID: On Tue, 6 Aug 2024 21:36:15 GMT, Alisen Chung wrote: >> Currently the bug described in the issue is that the colors of the TextComponents do not change when setting TextComponents to uneditable. The default uneditable color (SystemColor.control) happens to be the same as the default for the editable color for some L&Fs, so the fix may not be initially noticeable. However, the bug still exists where the the color is not being changed when changing between editable and uneditable. You can check by changing TextComponent.getBackground() code to return Color.GRAY on line 342 and you can see that TextComponents are not changing to a gray background when set to uneditable. >> >> This fix adds a private setBackground method in TextComponent so that TextArea and TextField can change the background color to the correct color (SystemColor.control) when set uneditable by overriding the TextComponent setEditable. You can verify the fix by changing this color to Color.GRAY and verifying the backgrounds change to gray when the TextComponents are disabled. > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > use getbackground @prsadhuk @DamonGuy can you take a look at the latest changes? ------------- PR Comment: https://git.openjdk.org/jdk/pull/19876#issuecomment-2276206648 From dnguyen at openjdk.org Thu Aug 8 18:22:34 2024 From: dnguyen at openjdk.org (Damon Nguyen) Date: Thu, 8 Aug 2024 18:22:34 GMT Subject: RFR: 7188058: Background of TextComponents are not changing colors to the default disabled color when set to uneditable [v3] In-Reply-To: References: Message-ID: On Tue, 6 Aug 2024 21:36:15 GMT, Alisen Chung wrote: >> Currently the bug described in the issue is that the colors of the TextComponents do not change when setting TextComponents to uneditable. The default uneditable color (SystemColor.control) happens to be the same as the default for the editable color for some L&Fs, so the fix may not be initially noticeable. However, the bug still exists where the the color is not being changed when changing between editable and uneditable. You can check by changing TextComponent.getBackground() code to return Color.GRAY on line 342 and you can see that TextComponents are not changing to a gray background when set to uneditable. >> >> This fix adds a private setBackground method in TextComponent so that TextArea and TextField can change the background color to the correct color (SystemColor.control) when set uneditable by overriding the TextComponent setEditable. You can verify the fix by changing this color to Color.GRAY and verifying the backgrounds change to gray when the TextComponents are disabled. > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > use getbackground Updates since my last comment look good. ------------- Marked as reviewed by dnguyen (Committer). PR Review: https://git.openjdk.org/jdk/pull/19876#pullrequestreview-2228568682 From abhiscxk at openjdk.org Fri Aug 9 05:12:39 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Fri, 9 Aug 2024 05:12:39 GMT Subject: Integrated: 8335130: The test "javax/swing/plaf/synth/ComponentsOrientationSupport/5033822/bug5033822.java" fails because the background color of the tabs is displayed incorrectly. In-Reply-To: References: Message-ID: On Tue, 9 Jul 2024 06:13:15 GMT, Abhishek Kumar wrote: > Issue is due to the condition added for the opaque property of SynthTabbedPane in [JDK-8226990](https://bugs.openjdk.org/browse/JDK-8226990). The previous fix for GTK and Nimbus was handled commonly in `SynthTabbedPaneUI` class to render the tabs based on opaque property. Since the Synth package is responsible to create a custom L&F using user defined XML file. In this test the L&F is fetched through the XML file and when `SynthTabbedPaneUI` APIs are invoked for the tab rendering, it is not correctly rendered. Setting the opaque property to true also doesn't help as the selected tab is rendered incorrectly. The proposed fix is to move the fix to GTK and Nimbus specific class and that will not cause any impact on custom xml based L&F. This pull request has now been integrated. Changeset: 9ab8c6b9 Author: Abhishek Kumar URL: https://git.openjdk.org/jdk/commit/9ab8c6b9ba90ffd12600a250c8704571e9feb78d Stats: 49 lines in 3 files changed: 9 ins; 8 del; 32 mod 8335130: The test "javax/swing/plaf/synth/ComponentsOrientationSupport/5033822/bug5033822.java" fails because the background color of the tabs is displayed incorrectly. Reviewed-by: achung, psadhukhan ------------- PR: https://git.openjdk.org/jdk/pull/20091 From abhiscxk at openjdk.org Fri Aug 9 06:52:33 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Fri, 9 Aug 2024 06:52:33 GMT Subject: RFR: 6318027: BasicScrollBarUI does not disable timer when enclosing frame is disabled. [v3] In-Reply-To: References: Message-ID: On Wed, 7 Aug 2024 13:52:07 GMT, Prasanta Sadhukhan wrote: >> Issue is >> BasicScrollBarUI.ArrowButtonListener starts a timer in mousePressed(), and stops it in mouseReleased(). If the frame containing the scrollbar is disabled between the MOUSE_PRESSED and the MOUSE_RELEASED events, the mouseReleased() method is never called. If the frame is then re-enabled, the still-running timer causes it to scroll all the way to the end. >> Fix is to check if [ArrowButtonListener.handledEvent](https://github.com/openjdk/jdk/blame/ee839b7f0ebe471d3877cddd2c87019ccb8ee5ae/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicScrollBarUI.java#L1567) is still set when ActionEvent is processed then stop the timer and reset this variable. >> >> CI testing is green and also SwingSet2 JScrollPane scrolling with this modification.. > > Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision: > > - copyright > - Restore AquaL&F testing @prsadhuk I was verifying the test and for Aqua L&F looks like the timer is not stopped and scrollbar scrolls down to the end and it doesn't throw any exception also. Test ran fine for Metal, Nimbus and Motif L&Fs. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20346#issuecomment-2277262463 From abhiscxk at openjdk.org Fri Aug 9 06:57:31 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Fri, 9 Aug 2024 06:57:31 GMT Subject: RFR: 6318027: BasicScrollBarUI does not disable timer when enclosing frame is disabled. [v3] In-Reply-To: References: Message-ID: <5uXKFNbDuFqJQ8XtSS2CsvFDNv83NluVvYRl5Q20Yvs=.e1a16cd9-3236-4daf-bfeb-b4ca99661566@github.com> On Wed, 7 Aug 2024 13:52:07 GMT, Prasanta Sadhukhan wrote: >> Issue is >> BasicScrollBarUI.ArrowButtonListener starts a timer in mousePressed(), and stops it in mouseReleased(). If the frame containing the scrollbar is disabled between the MOUSE_PRESSED and the MOUSE_RELEASED events, the mouseReleased() method is never called. If the frame is then re-enabled, the still-running timer causes it to scroll all the way to the end. >> Fix is to check if [ArrowButtonListener.handledEvent](https://github.com/openjdk/jdk/blame/ee839b7f0ebe471d3877cddd2c87019ccb8ee5ae/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicScrollBarUI.java#L1567) is still set when ActionEvent is processed then stop the timer and reset this variable. >> >> CI testing is green and also SwingSet2 JScrollPane scrolling with this modification.. > > Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision: > > - copyright > - Restore AquaL&F testing src/java.desktop/macosx/classes/com/apple/laf/AquaScrollBarUI.java line 530: > 528: > 529: public void actionPerformed(final ActionEvent e) { > 530: if (fTrackHighlight != Hit.NONE && !fTrackListener.fStillInTrack) { `fTrackListener.fStillInTrack` value is `true` and here the condition is to check for negation which makes it to `false` and overall condition evaluates to `false` and that may be the reason that the timer is not stopped. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20346#discussion_r1710868013 From azvegint at openjdk.org Fri Aug 9 10:37:39 2024 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Fri, 9 Aug 2024 10:37:39 GMT Subject: RFR: 8338109: java/awt/Mouse/EnterExitEvents/ResizingFrameTest.java duplicate in ProblemList Message-ID: [JDK-8337320 ](https://bugs.openjdk.org/browse/JDK-8337320) introduced the second mention of the java/awt/Mouse/EnterExitEvents/ResizingFrameTest.java in problem list. This causes the test to fail on MacOS ------------- Commit messages: - 8338109: java/awt/Mouse/EnterExitEvents/ResizingFrameTest.java duplicate in ProblemList Changes: https://git.openjdk.org/jdk/pull/20521/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20521&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8338109 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20521.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20521/head:pull/20521 PR: https://git.openjdk.org/jdk/pull/20521 From aivanov at openjdk.org Fri Aug 9 11:31:39 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 9 Aug 2024 11:31:39 GMT Subject: RFR: 8338109: java/awt/Mouse/EnterExitEvents/ResizingFrameTest.java duplicate in ProblemList In-Reply-To: References: Message-ID: On Fri, 9 Aug 2024 10:33:13 GMT, Alexander Zvegintsev wrote: > [JDK-8337320 ](https://bugs.openjdk.org/browse/JDK-8337320) introduced the second mention of the java/awt/Mouse/EnterExitEvents/ResizingFrameTest.java in problem list. > > This causes the test to fail on MacOS Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20521#pullrequestreview-2229971313 From azvegint at openjdk.org Fri Aug 9 11:31:39 2024 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Fri, 9 Aug 2024 11:31:39 GMT Subject: Integrated: 8338109: java/awt/Mouse/EnterExitEvents/ResizingFrameTest.java duplicate in ProblemList In-Reply-To: References: Message-ID: On Fri, 9 Aug 2024 10:33:13 GMT, Alexander Zvegintsev wrote: > [JDK-8337320 ](https://bugs.openjdk.org/browse/JDK-8337320) introduced the second mention of the java/awt/Mouse/EnterExitEvents/ResizingFrameTest.java in problem list. > > This causes the test to fail on MacOS This pull request has now been integrated. Changeset: 2b5aec2a Author: Alexander Zvegintsev URL: https://git.openjdk.org/jdk/commit/2b5aec2aad3883d4d407ec3a572f78755d60190d Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod 8338109: java/awt/Mouse/EnterExitEvents/ResizingFrameTest.java duplicate in ProblemList Reviewed-by: aivanov ------------- PR: https://git.openjdk.org/jdk/pull/20521 From psadhukhan at openjdk.org Fri Aug 9 13:19:32 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 9 Aug 2024 13:19:32 GMT Subject: RFR: 7188058: Background of TextComponents are not changing colors to the default disabled color when set to uneditable [v3] In-Reply-To: References: Message-ID: On Tue, 6 Aug 2024 21:36:15 GMT, Alisen Chung wrote: >> Currently the bug described in the issue is that the colors of the TextComponents do not change when setting TextComponents to uneditable. The default uneditable color (SystemColor.control) happens to be the same as the default for the editable color for some L&Fs, so the fix may not be initially noticeable. However, the bug still exists where the the color is not being changed when changing between editable and uneditable. You can check by changing TextComponent.getBackground() code to return Color.GRAY on line 342 and you can see that TextComponents are not changing to a gray background when set to uneditable. >> >> This fix adds a private setBackground method in TextComponent so that TextArea and TextField can change the background color to the correct color (SystemColor.control) when set uneditable by overriding the TextComponent setEditable. You can verify the fix by changing this color to Color.GRAY and verifying the backgrounds change to gray when the TextComponents are disabled. > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > use getbackground src/java.desktop/share/classes/java/awt/TextField.java line 495: > 493: public synchronized void setEditable(boolean b) { > 494: super.setEditable(b); > 495: Color defaultBackground = UIManager.getColor("TextField.background"); It still uses UIManager.getColor here and this property is again set in L&Fs mentioned for`TextArea.background` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19876#discussion_r1711448046 From reto.merz at abacus.ch Fri Aug 9 14:40:10 2024 From: reto.merz at abacus.ch (Reto Merz) Date: Fri, 9 Aug 2024 14:40:10 +0000 Subject: AW: Status on JDK-8305479 (+ info to reproduce it) In-Reply-To: References: Message-ID: Hello SWinxy Thanks for looking at it. I have reproduced it with the demo code from JDK-8305479 on my machine and also on a virtuale machine. While I can reproduce it on my physical machine (Windows 2019 Server) very easily, it is much harder on the virtual machine (Windows 11). In our production application it is very easy to reproduce it in both environment, physical and on a virtual machine. Yes, the WaitForSingleObject is also what we have seen when we have looked at a dump with WinDbg and a Debugimage JDK. We have also found a solution to "detect" the freeze, but we have not found a way to unfreeze/release the lock. What we have try for example is to call 'endComposition' on the WInputMethod instance (the instance which cause the deadlock). Or to call 'finalize' method. At the moment we register a custom EventQueue which does not dispatch the WInputMethod event at all. Like this: @Override protected void dispatchEvent(AWTEvent event) { if (InvocationEvent.INVOCATION_DEFAULT == event.getID() && event.paramString().startsWith("INVOCATION_DEFAULT,runnable=sun.awt.windows.WInputMethod$")) { return; // do not dispatch ; https://mail.openjdk.org/pipermail/client-libs-dev/2024-August/021543.html } super.dispatchEvent(event); } We assume that our workaround will have some bad side effects for users with IME. But the freeze is much worse for our customers. And we assume the bug is a regression introdcued by JDK-8261231. Thanks Regards Reto Von: SWinxy Gesendet: Mittwoch, 7. August 2024 22:17 An: Reto Merz Cc: client-libs-dev at openjdk.org Betreff: Re: Status on JDK-8305479 (+ info to reproduce it) This appears to be a deadlock. I've been able to replicate it, but it's annoyingly finicky to get it to freeze. A thread gets stuck on WaitForSingleObject at awt_Toolkit.cpp#L3139 (in AwtToolkit::InvokeInputMethodFunction) waiting for an object to be signaled, but the signalling gets lost. And so it waits indefinitely. dmarkov, do you know more? A possible solution would be to change the timeout to be 1000ms, but that may have unintended effects. SWinxy On Mon, Aug 5, 2024 at 5:23?AM Reto Merz wrote: Hello, Our customers are using Drag & Drop functionality more and more and reports are increasing that our application is haning. It starts to escalate since the only workaround is to restart the app right now. The problem is already reported with JDK-8305479 [1] Is there any way to increase the priority of that issue or is a developer here we can hire to search for a fix (and create a pull request)? Btw, the bug is much easier to reproduce: 1) Start the demo app (see [1]) 2) try to drop a document (eg: pdf file) from the windows desktop into the textfield Repeat step 2 if necessary. For me after 1-2 try this will cause the hang. If not, move the JFrame to another position and repeat step 2 again. Tested with latest JDK: ? ? java version "22.0.2" 2024-07-16 ? ? Java(TM) SE Runtime Environment (build 22.0.2+9-70) ? ? Java HotSpot(TM) 64-Bit Server VM (build 22.0.2+9-70, mixed mode, sharing) OS MS Windows: ? ? Microsoft Windows [Version 10.0.17763.5458] Regards Reto Merz [1] https://bugs.openjdk.org/browse/JDK-8305479 From prr at openjdk.org Fri Aug 9 18:25:32 2024 From: prr at openjdk.org (Phil Race) Date: Fri, 9 Aug 2024 18:25:32 GMT Subject: RFR: 8290501 : Typo Found In The javax.swing Interface BoundedRangeModel Documentation In-Reply-To: References: Message-ID: On Tue, 6 Aug 2024 17:53:47 GMT, Harshitha Onkar wrote: >> Documentation updated > > src/java.desktop/share/classes/javax/swing/BoundedRangeModel.java line 43: > >> 41: * must lie within the outer one, i.e. value must be >> 42: * less than or equal to maximum and value+extent >> 43: * must be greater than or equal to minimum, and maximum > > Since you are already updating the doc, we could also consider updating `...` to use the newer format `{@code ...}` in this file. Actually, I wouldn't bother. That's a change that's about 100x the problem. What I would do, is look for other typos in this file. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20465#discussion_r1711954218 From mvs at openjdk.org Fri Aug 9 18:50:45 2024 From: mvs at openjdk.org (Manukumar V S) Date: Fri, 9 Aug 2024 18:50:45 GMT Subject: RFR: 8338103: Stabilize and open source a Swing OGL ButtonResizeTest Message-ID: <8--CxVHS_jclzzN2PWYkI0W3yr7w1al5PSqRdis-PUc=.2f57c378-49cc-40bc-b042-f6aa9bfed07d@github.com> This PR creates a new test by stabilising and open sourcing a closed test. This test verifies that the OpenGL pipeline does not create artifacts with swing components after window is zoomed to maximum size and then resized back to normal. This test is run twice, with and without the flags "-Dsun.java2d.opengl=True -Dsun.java2d.opengl.fbobject=false" . This is tested(15 times per platform) in all the available mach5 headful platforms and found to be stable. ------------- Commit messages: - 8338103: Stabilize and open source a Swing OGL ButtonResizeTest Changes: https://git.openjdk.org/jdk/pull/20532/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20532&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8338103 Stats: 312 lines in 1 file changed: 312 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20532.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20532/head:pull/20532 PR: https://git.openjdk.org/jdk/pull/20532 From achung at openjdk.org Fri Aug 9 21:58:45 2024 From: achung at openjdk.org (Alisen Chung) Date: Fri, 9 Aug 2024 21:58:45 GMT Subject: RFR: 8329756: [macos] "javax/swing/JTable/KeyBoardNavigation.java" fail because most combinations of navigational keys with the Ctrl key do not work [v3] In-Reply-To: References: Message-ID: On Tue, 30 Jul 2024 05:17:12 GMT, Tejesh R wrote: >> Mismatch in key combinations, I have taken native macos Numbers application as reference to verify. Have added `Ctrl-Shift Left/Right` action keys similar to `Ctrl-Shift UP/DOWN` which would be expected functionality. I've removed those test instructions which are not applicable/implemented/not working in Macos keyboard navigation. > > Tejesh R has updated the pull request incrementally with one additional commit since the last revision: > > Review fix test/jdk/javax/swing/JTable/KeyBoardNavigation.java line 1: > 1: /* When I run this test I need to expand the test window, might be better to explicitly set the size of the test frame to be larger ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20331#discussion_r1712252185 From dnguyen at openjdk.org Fri Aug 9 22:37:45 2024 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 9 Aug 2024 22:37:45 GMT Subject: RFR: 8321140: Add comment to note difference in Metal's JButton margins In-Reply-To: References: Message-ID: On Tue, 6 Aug 2024 23:12:44 GMT, Damon Nguyen wrote: > Previously in [JDK-8282772](https://bugs.openjdk.org/browse/JDK-8282772), there was a fix for JButtons with HTML content alignment for non-MacOS L&Fs. This fix was to make other L&Fs in line with the Aqua fix found in [JDK-8015854](https://bugs.openjdk.org/browse/JDK-8015854). > > However, the non-MacOS L&F fix caused a regression and the details and original discussion can be found in [JDK-8318590](https://bugs.openjdk.org/browse/JDK-8318590). This non-MacOS L&F fix was backed out and the current behavior for JButtons with HTML content for these L&Fs was deemed to be correct as is. > > Through discussion, a note about Metal's different margin values should be added somewhere for future reference. Metal's horizontal margins are 14 where other L&Fs are zero or some small value. This discrepancy is what caused the original issue to be filed. This change is to add a comment to `MetalLookAndFeel.java` since there is no exact spot where these values are set for the margin. It's been added where other Metal components (CheckBox, RadioButton, etc.) have comments on margins as well. > > Here are some L&F values for reference/comparison: > > Metal's margins: [top=2,left=14,bottom=2,right=14] > Aqua's margins: [top=0,left=2,bottom=0,right=2] > Motif's margins: [top=2,left=4,bottom=2,right=4] > Nimbus's margins: [top=0,left=0,bottom=0,right=0] I found the values to be set in `BasicLookAndFeel.java` which explains why other custom L&F's are also affected. Moving the doc to there and changing this back to a public doc change can be done instead. Otherwise, I can leave it as a comment note where the value is set. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20482#issuecomment-2278835514 From honkar at openjdk.org Sat Aug 10 00:17:30 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Sat, 10 Aug 2024 00:17:30 GMT Subject: RFR: 8321140: Add comment to note difference in Metal's JButton margins In-Reply-To: References: Message-ID: On Tue, 6 Aug 2024 23:12:44 GMT, Damon Nguyen wrote: > Previously in [JDK-8282772](https://bugs.openjdk.org/browse/JDK-8282772), there was a fix for JButtons with HTML content alignment for non-MacOS L&Fs. This fix was to make other L&Fs in line with the Aqua fix found in [JDK-8015854](https://bugs.openjdk.org/browse/JDK-8015854). > > However, the non-MacOS L&F fix caused a regression and the details and original discussion can be found in [JDK-8318590](https://bugs.openjdk.org/browse/JDK-8318590). This non-MacOS L&F fix was backed out and the current behavior for JButtons with HTML content for these L&Fs was deemed to be correct as is. > > Through discussion, a note about Metal's different margin values should be added somewhere for future reference. Metal's horizontal margins are 14 where other L&Fs are zero or some small value. This discrepancy is what caused the original issue to be filed. This change is to add a comment to `MetalLookAndFeel.java` since there is no exact spot where these values are set for the margin. It's been added where other Metal components (CheckBox, RadioButton, etc.) have comments on margins as well. > > Here are some L&F values for reference/comparison: > > Metal's margins: [top=2,left=14,bottom=2,right=14] > Aqua's margins: [top=0,left=2,bottom=0,right=2] > Motif's margins: [top=2,left=4,bottom=2,right=4] > Nimbus's margins: [top=0,left=0,bottom=0,right=0] LGTM ------------- Marked as reviewed by honkar (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20482#pullrequestreview-2231276880 From honkar at openjdk.org Sat Aug 10 00:17:31 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Sat, 10 Aug 2024 00:17:31 GMT Subject: RFR: 8321140: Add comment to note difference in Metal's JButton margins In-Reply-To: References: Message-ID: On Fri, 9 Aug 2024 22:35:06 GMT, Damon Nguyen wrote: > I found the values to be set in `BasicLookAndFeel.java` which explains why other custom L&F's are also affected. Moving the doc to there and changing this back to a public doc change can be done instead. Otherwise, I can leave it as a comment note where the value is set. It looks okay to me to have it has a comment in MetalLAF as it is now. > Moving the doc to there and changing this back to a public doc change can be done instead I think what @aivanov-jdk meant here is that since this is a comment, only the JBS title needs a change to reflect that it is a comment and not a javadoc change. Even if it is moved to BasicLAF, it would still be added as a comment, correct? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20482#issuecomment-2278900657 From honkar at openjdk.org Sat Aug 10 00:34:33 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Sat, 10 Aug 2024 00:34:33 GMT Subject: RFR: 8290501 : Typo Found In The javax.swing Interface BoundedRangeModel Documentation In-Reply-To: References: Message-ID: <3utD4oFciEgPNtbcImfgDM3kBmnYm5fDNoEVcSs3xY4=.556b0ba5-2391-4541-be3f-fb75d44fd5df@github.com> On Fri, 9 Aug 2024 18:22:27 GMT, Phil Race wrote: >> src/java.desktop/share/classes/javax/swing/BoundedRangeModel.java line 43: >> >>> 41: * must lie within the outer one, i.e. value must be >>> 42: * less than or equal to maximum and value+extent >>> 43: * must be greater than or equal to minimum, and maximum >> >> Since you are already updating the doc, we could also consider updating `...` to use the newer format `{@code ...}` in this file. > > Actually, I wouldn't bother. That's a change that's about 100x the problem. > What I would do, is look for other typos in this file. Agreed. @Renjithkannath Minor typo that can be addressed in this PR "an" can be removed from the following line For **an** example of specifying custom bounded range models used by sliders, ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20465#discussion_r1712424440 From prr at openjdk.org Sat Aug 10 01:16:41 2024 From: prr at openjdk.org (Phil Race) Date: Sat, 10 Aug 2024 01:16:41 GMT Subject: RFR: 8290501 : Typo Found In The javax.swing Interface BoundedRangeModel Documentation In-Reply-To: References: Message-ID: On Mon, 5 Aug 2024 10:56:49 GMT, Renjith Kannath Pariyangad wrote: > Documentation updated Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20465#pullrequestreview-2231289106 From prr at openjdk.org Sat Aug 10 01:16:41 2024 From: prr at openjdk.org (Phil Race) Date: Sat, 10 Aug 2024 01:16:41 GMT Subject: RFR: 8290501 : Typo Found In The javax.swing Interface BoundedRangeModel Documentation In-Reply-To: <3utD4oFciEgPNtbcImfgDM3kBmnYm5fDNoEVcSs3xY4=.556b0ba5-2391-4541-be3f-fb75d44fd5df@github.com> References: <3utD4oFciEgPNtbcImfgDM3kBmnYm5fDNoEVcSs3xY4=.556b0ba5-2391-4541-be3f-fb75d44fd5df@github.com> Message-ID: <88xF9vwGOj8gA9cpmQIGkexEJmkgSFLE69Fs8XGhdIU=.d39aa80c-ae1e-409e-b172-4e2a2f83081b@github.com> On Sat, 10 Aug 2024 00:31:57 GMT, Harshitha Onkar wrote: >> Actually, I wouldn't bother. That's a change that's about 100x the problem. >> What I would do, is look for other typos in this file. > > Agreed. > > @Renjithkannath Minor typo that can be addressed in this PR > "an" can be removed from the following line > For **an** example of specifying custom bounded range models used by sliders, No, that would be introducing incorrect grammar, not fixing a typo. Maybe we are just done here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20465#discussion_r1712449855 From duke at openjdk.org Sun Aug 11 00:46:30 2024 From: duke at openjdk.org (lawrence.andrews) Date: Sun, 11 Aug 2024 00:46:30 GMT Subject: RFR: 8328553: Get rid of JApplet in test/jdk/sanity/client/lib/SwingSet2/src/DemoModule.java In-Reply-To: References: Message-ID: <0rYS1eTGmWU9E8x2Sas18IXFBj33yAOswtIkUCCPmNM=.34120c77-d5ef-44e2-9dba-0f292d253cc5@github.com> On Sat, 3 Aug 2024 18:07:16 GMT, lawrence.andrews wrote: > 1) Replaced JApplet with JPanel > 2) Tests passed before and after fix I can file a new ticket and work on the NPE. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20450#issuecomment-2282331277 From dmitry.markov at oracle.com Sun Aug 11 14:34:32 2024 From: dmitry.markov at oracle.com (Dmitrii Markov) Date: Sun, 11 Aug 2024 14:34:32 +0000 Subject: Status on JDK-8305479 (+ info to reproduce it) In-Reply-To: References: Message-ID: According to the remark in InvokeInputMethodFunction we shouldn?t use async calls like PostMessage() if Drag?n?Drop operation is active. If I got it right in problem case we entered to Drag?nDrop operation right after we started waiting on the InputMethod event object in InvokeInputMethodFunction. I suspect some lack of synchronisation takes place. Perhaps we need to drop and reschedule the InputMethod events that are in progress before we enter Drag?n?Drop. Dmitrii On 7 Aug 2024, at 21:16, SWinxy wrote: This appears to be a deadlock. I've been able to replicate it, but it's annoyingly finicky to get it to freeze. A thread gets stuck on WaitForSingleObject at awt_Toolkit.cpp#L3139 (in AwtToolkit::InvokeInputMethodFunction) waiting for an object to be signaled, but the signalling gets lost. And so it waits indefinitely. dmarkov, do you know more? A possible solution would be to change the timeout to be 1000ms, but that may have unintended effects. SWinxy On Mon, Aug 5, 2024 at 5:23?AM Reto Merz > wrote: Hello, Our customers are using Drag & Drop functionality more and more and reports are increasing that our application is haning. It starts to escalate since the only workaround is to restart the app right now. The problem is already reported with JDK-8305479 [1] Is there any way to increase the priority of that issue or is a developer here we can hire to search for a fix (and create a pull request)? Btw, the bug is much easier to reproduce: 1) Start the demo app (see [1]) 2) try to drop a document (eg: pdf file) from the windows desktop into the textfield Repeat step 2 if necessary. For me after 1-2 try this will cause the hang. If not, move the JFrame to another position and repeat step 2 again. Tested with latest JDK: java version "22.0.2" 2024-07-16 Java(TM) SE Runtime Environment (build 22.0.2+9-70) Java HotSpot(TM) 64-Bit Server VM (build 22.0.2+9-70, mixed mode, sharing) OS MS Windows: Microsoft Windows [Version 10.0.17763.5458] Regards Reto Merz [1] https://bugs.openjdk.org/browse/JDK-8305479 -------------- next part -------------- An HTML attachment was scrubbed... URL: From aivanov at openjdk.org Mon Aug 12 09:55:34 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 12 Aug 2024 09:55:34 GMT Subject: RFR: 8321140: Add comment to note difference in Metal's JButton margins In-Reply-To: References: Message-ID: <0HSAjdsjToSftyZJVabjRAzdf0xc-Kye8c9CLk_-Lmo=.b807a5ec-3e4e-43fa-87e1-d92afa311f53@github.com> On Tue, 6 Aug 2024 23:12:44 GMT, Damon Nguyen wrote: > Previously in [JDK-8282772](https://bugs.openjdk.org/browse/JDK-8282772), there was a fix for JButtons with HTML content alignment for non-MacOS L&Fs. This fix was to make other L&Fs in line with the Aqua fix found in [JDK-8015854](https://bugs.openjdk.org/browse/JDK-8015854). > > However, the non-MacOS L&F fix caused a regression and the details and original discussion can be found in [JDK-8318590](https://bugs.openjdk.org/browse/JDK-8318590). This non-MacOS L&F fix was backed out and the current behavior for JButtons with HTML content for these L&Fs was deemed to be correct as is. > > Through discussion, a note about Metal's different margin values should be added somewhere for future reference. Metal's horizontal margins are 14 where other L&Fs are zero or some small value. This discrepancy is what caused the original issue to be filed. This change is to add a comment to `MetalLookAndFeel.java` since there is no exact spot where these values are set for the margin. It's been added where other Metal components (CheckBox, RadioButton, etc.) have comments on margins as well. > > Here are some L&F values for reference/comparison: > > Metal's margins: [top=2,left=14,bottom=2,right=14] > Aqua's margins: [top=0,left=2,bottom=0,right=2] > Motif's margins: [top=2,left=4,bottom=2,right=4] > Nimbus's margins: [top=0,left=0,bottom=0,right=0] I still don't quite understand where the margin comes from. A comment, like the one you have currently, which points to where the values come from would be good. Adding anything to public javadoc requires a CSR. Not sure if you want to go this way. It's not worth it. If developer can customise the border, it should not be specified in javadoc. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20482#issuecomment-2283541633 From aivanov at openjdk.org Mon Aug 12 10:11:31 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 12 Aug 2024 10:11:31 GMT Subject: RFR: 8290501 : Typo Found In The javax.swing Interface BoundedRangeModel Documentation In-Reply-To: References: Message-ID: On Mon, 5 Aug 2024 10:56:49 GMT, Renjith Kannath Pariyangad wrote: > Documentation updated Marked as reviewed by aivanov (Reviewer). src/java.desktop/share/classes/javax/swing/BoundedRangeModel.java line 1: > 1: /* Update the copyright year in the file, please. I also suggest expanding the imports to use single-class imports instead of wildcard. ------------- PR Review: https://git.openjdk.org/jdk/pull/20465#pullrequestreview-2232538206 PR Review Comment: https://git.openjdk.org/jdk/pull/20465#discussion_r1713470157 From aivanov at openjdk.org Mon Aug 12 10:11:32 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 12 Aug 2024 10:11:32 GMT Subject: RFR: 8290501 : Typo Found In The javax.swing Interface BoundedRangeModel Documentation In-Reply-To: <88xF9vwGOj8gA9cpmQIGkexEJmkgSFLE69Fs8XGhdIU=.d39aa80c-ae1e-409e-b172-4e2a2f83081b@github.com> References: <3utD4oFciEgPNtbcImfgDM3kBmnYm5fDNoEVcSs3xY4=.556b0ba5-2391-4541-be3f-fb75d44fd5df@github.com> <88xF9vwGOj8gA9cpmQIGkexEJmkgSFLE69Fs8XGhdIU=.d39aa80c-ae1e-409e-b172-4e2a2f83081b@github.com> Message-ID: On Sat, 10 Aug 2024 01:14:09 GMT, Phil Race wrote: >> Agreed. >> >> @Renjithkannath Minor typo that can be addressed in this PR >> "an" can be removed from the following line >> For **an** example of specifying custom bounded range models used by sliders, > > No, that would be introducing incorrect grammar, not fixing a typo. > > Maybe we are just done here. I agree it's not worth it. Yes, the javadoc comment can be improved further: - `JSlider` and `JProgressBar` could be marked up with `{@link}`; - All references to classes and methods could be marked up with `{@code}`; - `Slider` and `ScrollBar` should be referenced by prose, as they refer to component concepts rather than component classes, alternatively these can be changed to `JSlider` and `JScrollBar` correspondingly. The above changes don't make much difference and don't considerably improve the specification. > > For **an** example of specifying custom bounded range models used by sliders, > > No, that would be introducing incorrect grammar, not fixing a typo. No, *?an?* shouldn't be removed in this case. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20465#discussion_r1713478135 From aivanov at openjdk.org Mon Aug 12 10:42:33 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 12 Aug 2024 10:42:33 GMT Subject: RFR: 8290501 : Typo Found In The javax.swing Interface BoundedRangeModel Documentation In-Reply-To: References: Message-ID: <_Zzgu9GIM2c5rgJfecqUKt18GBixMp72tlTWTDxrKoM=.81c8b2de-754d-4d1e-a595-88d8b5faf7c8@github.com> On Mon, 5 Aug 2024 10:56:49 GMT, Renjith Kannath Pariyangad wrote: > Documentation updated IDE suggests simplifying the sentence at line 231 (for the `setRangeProperties` method). Consider using _?all the?_ (instead of _?all of the?_): This method sets *all of the model's*? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20465#issuecomment-2283627554 From duke at openjdk.org Mon Aug 12 12:05:33 2024 From: duke at openjdk.org (Daniel Gredler) Date: Mon, 12 Aug 2024 12:05:33 GMT Subject: RFR: 8337681: PNGImageWriter uses much more memory than necessary [v2] In-Reply-To: References: <8ZstKFyu435jMQ9_44gJwjCtz1N1at3B_wqbsDi2msE=.aede545e-7d62-4af6-9f51-5682a5281ac3@github.com> Message-ID: On Fri, 2 Aug 2024 18:51:33 GMT, Phil Race wrote: >> Daniel Gredler has updated the pull request incrementally with two additional commits since the last revision: >> >> - JDK-8337681: add tests for TYPE_4BYTE_ABGR >> - JDK-8337681: add tests for TYPE_INT_RGB > > I've approved but we do require 2 approvals for client fixes. @prrace I think this is ready to be merged. Could you have a look and sponsor the PR if everything still looks good to you? Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/20432#issuecomment-2283785510 From duke at openjdk.org Mon Aug 12 12:12:45 2024 From: duke at openjdk.org (Daniel Gredler) Date: Mon, 12 Aug 2024 12:12:45 GMT Subject: Integrated: 8337681: PNGImageWriter uses much more memory than necessary In-Reply-To: References: Message-ID: On Thu, 1 Aug 2024 19:06:57 GMT, Daniel Gredler wrote: > At some point the `JPEGImageWriter` was optimized to reduce duplication / copying of rasters and data buffers (see `JDK-6266748`). However, `PNGImageWriter` never received a similar optimization, and is making unnecessary copies of raster and data buffers whenever PNG images are written. > > Measurements: In a local test, `PNGImageWriter.write( )` and callees were initially showing up as an allocation hotspot (~400k objects / ~65 MB allocated), but after these optimizations I'm seeing much better numbers (~400 objects / ~740 KB allocated). This pull request has now been integrated. Changeset: 89a15f14 Author: Daniel Gredler Committer: Laurent Bourg?s URL: https://git.openjdk.org/jdk/commit/89a15f1414f89d2dd32eac791e9155fcb4207e56 Stats: 200 lines in 2 files changed: 195 ins; 1 del; 4 mod 8337681: PNGImageWriter uses much more memory than necessary Reviewed-by: prr, lbourges ------------- PR: https://git.openjdk.org/jdk/pull/20432 From achung at openjdk.org Mon Aug 12 16:30:48 2024 From: achung at openjdk.org (Alisen Chung) Date: Mon, 12 Aug 2024 16:30:48 GMT Subject: RFR: 7188058: Background of TextComponents are not changing colors to the default disabled color when set to uneditable [v4] In-Reply-To: References: Message-ID: > Currently the bug described in the issue is that the colors of the TextComponents do not change when setting TextComponents to uneditable. The default uneditable color (SystemColor.control) happens to be the same as the default for the editable color for some L&Fs, so the fix may not be initially noticeable. However, the bug still exists where the the color is not being changed when changing between editable and uneditable. You can check by changing TextComponent.getBackground() code to return Color.GRAY on line 342 and you can see that TextComponents are not changing to a gray background when set to uneditable. > > This fix adds a private setBackground method in TextComponent so that TextArea and TextField can change the background color to the correct color (SystemColor.control) when set uneditable by overriding the TextComponent setEditable. You can verify the fix by changing this color to Color.GRAY and verifying the backgrounds change to gray when the TextComponents are disabled. Alisen Chung has updated the pull request incrementally with two additional commits since the last revision: - remove import - remove uimanager from textfield ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19876/files - new: https://git.openjdk.org/jdk/pull/19876/files/e83c29fe..ccf63c8a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19876&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19876&range=02-03 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/19876.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19876/head:pull/19876 PR: https://git.openjdk.org/jdk/pull/19876 From achung at openjdk.org Mon Aug 12 16:30:48 2024 From: achung at openjdk.org (Alisen Chung) Date: Mon, 12 Aug 2024 16:30:48 GMT Subject: RFR: 7188058: Background of TextComponents are not changing colors to the default disabled color when set to uneditable [v3] In-Reply-To: References: Message-ID: On Fri, 9 Aug 2024 13:16:42 GMT, Prasanta Sadhukhan wrote: >> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: >> >> use getbackground > > src/java.desktop/share/classes/java/awt/TextField.java line 495: > >> 493: public synchronized void setEditable(boolean b) { >> 494: super.setEditable(b); >> 495: Color defaultBackground = UIManager.getColor("TextField.background"); > > It still uses UIManager.getColor here and this property is again set in L&Fs mentioned for`TextArea.background` UIManager removed from textfield as well now ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19876#discussion_r1714077988 From rkannathpari at openjdk.org Tue Aug 13 05:19:07 2024 From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad) Date: Tue, 13 Aug 2024 05:19:07 GMT Subject: RFR: 8290501 : Typo Found In The javax.swing Interface BoundedRangeModel Documentation [v2] In-Reply-To: References: Message-ID: > Documentation updated Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision: Updated copyright year ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20465/files - new: https://git.openjdk.org/jdk/pull/20465/files/438e8dc5..176230af Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20465&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20465&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20465.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20465/head:pull/20465 PR: https://git.openjdk.org/jdk/pull/20465 From rkannathpari at openjdk.org Tue Aug 13 05:19:08 2024 From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad) Date: Tue, 13 Aug 2024 05:19:08 GMT Subject: RFR: 8290501 : Typo Found In The javax.swing Interface BoundedRangeModel Documentation In-Reply-To: References: Message-ID: On Mon, 5 Aug 2024 10:56:49 GMT, Renjith Kannath Pariyangad wrote: > Documentation updated Thank you @honkar-jdk, @prrace and @aivanov-jdk for your time and review. I have updated copyright year and updated line 231 with ?all the? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20465#issuecomment-2285356476 From aivanov at openjdk.org Tue Aug 13 16:38:49 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 13 Aug 2024 16:38:49 GMT Subject: RFR: 8290501 : Typo in javax.swing.BoundedRangeModel documentation [v2] In-Reply-To: References: Message-ID: <3ABi1o0TkbiMwhir3ZROuF8a77lXQ3qwOgJFCPQIm5U=.92555ada-2dc0-4d5e-8177-51fd20a00da1@github.com> On Tue, 13 Aug 2024 05:19:07 GMT, Renjith Kannath Pariyangad wrote: >> Documentation updated > > Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision: > > Updated copyright year For what it's worth, expand the imports. import javax.swing.event.ChangeListener; Only one class is imported. ------------- Changes requested by aivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20465#pullrequestreview-2236055834 From dnguyen at openjdk.org Tue Aug 13 19:18:48 2024 From: dnguyen at openjdk.org (Damon Nguyen) Date: Tue, 13 Aug 2024 19:18:48 GMT Subject: RFR: 8321140: Add comment to note difference in Metal's JButton margins In-Reply-To: <0HSAjdsjToSftyZJVabjRAzdf0xc-Kye8c9CLk_-Lmo=.b807a5ec-3e4e-43fa-87e1-d92afa311f53@github.com> References: <0HSAjdsjToSftyZJVabjRAzdf0xc-Kye8c9CLk_-Lmo=.b807a5ec-3e4e-43fa-87e1-d92afa311f53@github.com> Message-ID: <_BRdmJ-aCVfns4cwu9sW3wa8XC0rfMSSHkyPtJtX2qA=.b3c16121-d815-4b4c-b0ff-152125c073a9@github.com> On Mon, 12 Aug 2024 09:53:10 GMT, Alexey Ivanov wrote: > I still don't quite understand where the margin comes from. > > A comment, like the one you have currently, which points to where the values come from would be good. > > Adding anything to public javadoc requires a CSR. Not sure if you want to go this way. It's not worth it. If developer can customise the border, it should not be specified in javadoc. Metal (and the custom L&Fs) seem to use BasicLookAndFeel's default value for `Button.margin` which is (2, 14, 2, 14). This can be found in `BasicLookAndFeel.java`. Other L&Fs have set values for `Button.margin` but Metal does not. For example, `AquaLookAndFeel` has a value of (0, 2, 0, 2) for `Button.margin`. I agree it's more difficult to add anything to public javadocs. I can add the note to `BasicLookAndFeel.java` instead and note that the default installed L&Fs have a vastly different horizontal margin compared to Basic's value minus Metal L&F. Not sure of the best way to phrase this yet, but this is where the margin values itself comes from. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20482#issuecomment-2286960656 From achung at openjdk.org Tue Aug 13 20:38:52 2024 From: achung at openjdk.org (Alisen Chung) Date: Tue, 13 Aug 2024 20:38:52 GMT Subject: RFR: 7188058: Background of TextComponents are not changing colors to the default disabled color when set to uneditable [v4] In-Reply-To: References: Message-ID: On Mon, 12 Aug 2024 16:30:48 GMT, Alisen Chung wrote: >> Currently the bug described in the issue is that the colors of the TextComponents do not change when setting TextComponents to uneditable. The default uneditable color (SystemColor.control) happens to be the same as the default for the editable color for some L&Fs, so the fix may not be initially noticeable. However, the bug still exists where the the color is not being changed when changing between editable and uneditable. You can check by changing TextComponent.getBackground() code to return Color.GRAY on line 342 and you can see that TextComponents are not changing to a gray background when set to uneditable. >> >> This fix adds a private setBackground method in TextComponent so that TextArea and TextField can change the background color to the correct color (SystemColor.control) when set uneditable by overriding the TextComponent setEditable. You can verify the fix by changing this color to Color.GRAY and verifying the backgrounds change to gray when the TextComponents are disabled. > > Alisen Chung has updated the pull request incrementally with two additional commits since the last revision: > > - remove import > - remove uimanager from textfield @prsadhuk can you take another look? ------------- PR Comment: https://git.openjdk.org/jdk/pull/19876#issuecomment-2287093888 From jdv at openjdk.org Wed Aug 14 09:06:52 2024 From: jdv at openjdk.org (Jayathirth D V) Date: Wed, 14 Aug 2024 09:06:52 GMT Subject: RFR: 8337237: Use FFM instead of Unsafe for Java 2D RenderBuffer class [v3] In-Reply-To: References: Message-ID: <-0VDi3f9VbGe-Pp6OO5x9VKQwloI02IU_rhkpS0g_Ck=.c15cc7c1-0b83-4f56-9b6b-e9dd7d2fd75b@github.com> On Mon, 29 Jul 2024 17:09:49 GMT, Phil Race wrote: >> Migrate from using Unsafe to FFM's MemorySegment API for allocating and setting native memory. >> This code is used by Metal, OpenGL and D3D, so I manually tested SwingSet2 and J2Demo as well as running all the usual tests. >> I also did some micro-benchmarking on the performance of Unsafe vs MemorySegment. >> The performance of either is more than sufficient for us .. ie they could be 10x slower and we wouldn't even notice. >> But they are in the same ballpark, and if one or the other is clearly faster it is the new FFM code. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8337237 There are no alignment issues while reading/writing into RenderBuffer, verified that by taking a look at individual Metal/OpenGL/D3D calls. Also as captured we should not worry about performance impact of these calls as these are minute computations compared to actual rendering logic. Latest change looks good to me. ------------- Marked as reviewed by jdv (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20339#pullrequestreview-2237576791 From prr at openjdk.org Wed Aug 14 18:00:55 2024 From: prr at openjdk.org (Phil Race) Date: Wed, 14 Aug 2024 18:00:55 GMT Subject: Integrated: 8337237: Use FFM instead of Unsafe for Java 2D RenderBuffer class In-Reply-To: References: Message-ID: On Thu, 25 Jul 2024 22:53:36 GMT, Phil Race wrote: > Migrate from using Unsafe to FFM's MemorySegment API for allocating and setting native memory. > This code is used by Metal, OpenGL and D3D, so I manually tested SwingSet2 and J2Demo as well as running all the usual tests. > I also did some micro-benchmarking on the performance of Unsafe vs MemorySegment. > The performance of either is more than sufficient for us .. ie they could be 10x slower and we wouldn't even notice. > But they are in the same ballpark, and if one or the other is clearly faster it is the new FFM code. This pull request has now been integrated. Changeset: c0384b6f Author: Phil Race URL: https://git.openjdk.org/jdk/commit/c0384b6f3584501fb3bd93854734eeacf6620a7e Stats: 78 lines in 1 file changed: 4 ins; 18 del; 56 mod 8337237: Use FFM instead of Unsafe for Java 2D RenderBuffer class Reviewed-by: jvernee, jdv ------------- PR: https://git.openjdk.org/jdk/pull/20339 From achung at openjdk.org Wed Aug 14 20:45:52 2024 From: achung at openjdk.org (Alisen Chung) Date: Wed, 14 Aug 2024 20:45:52 GMT Subject: RFR: 8321140: Add comment to note difference in Metal's JButton margins In-Reply-To: References: Message-ID: On Tue, 6 Aug 2024 23:12:44 GMT, Damon Nguyen wrote: > Previously in [JDK-8282772](https://bugs.openjdk.org/browse/JDK-8282772), there was a fix for JButtons with HTML content alignment for non-MacOS L&Fs. This fix was to make other L&Fs in line with the Aqua fix found in [JDK-8015854](https://bugs.openjdk.org/browse/JDK-8015854). > > However, the non-MacOS L&F fix caused a regression and the details and original discussion can be found in [JDK-8318590](https://bugs.openjdk.org/browse/JDK-8318590). This non-MacOS L&F fix was backed out and the current behavior for JButtons with HTML content for these L&Fs was deemed to be correct as is. > > Through discussion, a note about Metal's different margin values should be added somewhere for future reference. Metal's horizontal margins are 14 where other L&Fs are zero or some small value. This discrepancy is what caused the original issue to be filed. This change is to add a comment to `MetalLookAndFeel.java` since there is no exact spot where these values are set for the margin. It's been added where other Metal components (CheckBox, RadioButton, etc.) have comments on margins as well. > > Here are some L&F values for reference/comparison: > > Metal's margins: [top=2,left=14,bottom=2,right=14] > Aqua's margins: [top=0,left=2,bottom=0,right=2] > Motif's margins: [top=2,left=4,bottom=2,right=4] > Nimbus's margins: [top=0,left=0,bottom=0,right=0] src/java.desktop/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java line 810: > 808: "released SPACE", "released" > 809: }), > 810: // margin is (2, 14, 2, 14) which is vastly larger in horizontal I see below that there is another comment saying margin is 2 all the way around, what is the difference? how are these comments placed to indicate what margins they are referring to? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20482#discussion_r1717528282 From prr at openjdk.org Wed Aug 14 21:00:50 2024 From: prr at openjdk.org (Phil Race) Date: Wed, 14 Aug 2024 21:00:50 GMT Subject: RFR: 8328553: Get rid of JApplet in test/jdk/sanity/client/lib/SwingSet2/src/DemoModule.java In-Reply-To: References: Message-ID: On Sat, 3 Aug 2024 18:07:16 GMT, lawrence.andrews wrote: > 1) Replaced JApplet with JPanel > 2) Tests passed before and after fix test/jdk/sanity/client/lib/SwingSet2/src/DemoModule.java line 46: > 44: * A generic SwingSet2 demo module > 45: */ > 46: public class DemoModule extends JPanel { But you still import JApplet ! See line 34 above. > import javax.swing.JApplet; ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20450#discussion_r1717542948 From duke at openjdk.org Wed Aug 14 21:36:18 2024 From: duke at openjdk.org (lawrence.andrews) Date: Wed, 14 Aug 2024 21:36:18 GMT Subject: RFR: 8328553: Get rid of JApplet in test/jdk/sanity/client/lib/SwingSet2/src/DemoModule.java [v2] In-Reply-To: References: Message-ID: <2OSk0XPx_yss7rVX9cGt9CofcHzc32HJGEFgFr4scwQ=.24af7aac-1bf7-4c73-af32-1087ec367966@github.com> > 1) Replaced JApplet with JPanel > 2) Tests passed before and after fix lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision: Removed the JApplet import ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20450/files - new: https://git.openjdk.org/jdk/pull/20450/files/0e30b745..4a39ba80 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20450&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20450&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20450.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20450/head:pull/20450 PR: https://git.openjdk.org/jdk/pull/20450 From honkar at openjdk.org Wed Aug 14 21:41:51 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Wed, 14 Aug 2024 21:41:51 GMT Subject: RFR: 8328553: Get rid of JApplet in test/jdk/sanity/client/lib/SwingSet2/src/DemoModule.java [v2] In-Reply-To: <2OSk0XPx_yss7rVX9cGt9CofcHzc32HJGEFgFr4scwQ=.24af7aac-1bf7-4c73-af32-1087ec367966@github.com> References: <2OSk0XPx_yss7rVX9cGt9CofcHzc32HJGEFgFr4scwQ=.24af7aac-1bf7-4c73-af32-1087ec367966@github.com> Message-ID: <2WZoW52KH4CEA6YC8hUaDnihFo1xCkPG8y3z8Faz9kc=.6bb9a270-c41a-4bb7-95a6-b00184d5f3ca@github.com> On Wed, 14 Aug 2024 21:36:18 GMT, lawrence.andrews wrote: >> 1) Replaced JApplet with JPanel >> 2) Tests passed before and after fix > > lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision: > > Removed the JApplet import LGTM ------------- Marked as reviewed by honkar (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20450#pullrequestreview-2239242093 From honkar at openjdk.org Wed Aug 14 21:41:52 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Wed, 14 Aug 2024 21:41:52 GMT Subject: RFR: 8328553: Get rid of JApplet in test/jdk/sanity/client/lib/SwingSet2/src/DemoModule.java In-Reply-To: <0rYS1eTGmWU9E8x2Sas18IXFBj33yAOswtIkUCCPmNM=.34120c77-d5ef-44e2-9dba-0f292d253cc5@github.com> References: <0rYS1eTGmWU9E8x2Sas18IXFBj33yAOswtIkUCCPmNM=.34120c77-d5ef-44e2-9dba-0f292d253cc5@github.com> Message-ID: On Sun, 11 Aug 2024 00:44:12 GMT, lawrence.andrews wrote: > I can file a new ticket and work on the NPE. Ok. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20450#issuecomment-2289953316 From dnguyen at openjdk.org Wed Aug 14 21:51:48 2024 From: dnguyen at openjdk.org (Damon Nguyen) Date: Wed, 14 Aug 2024 21:51:48 GMT Subject: RFR: 8337886: java/awt/Frame/MaximizeUndecoratedTest.java fails in OEL due to a slight color difference In-Reply-To: <2HljLuH3vumJyEMqhCWnGVnAWCJaMrbVbf0PgBO8ATg=.3bd94f6d-124b-4e4a-be15-ec319f552223@github.com> References: <2HljLuH3vumJyEMqhCWnGVnAWCJaMrbVbf0PgBO8ATg=.3bd94f6d-124b-4e4a-be15-ec319f552223@github.com> Message-ID: On Wed, 7 Aug 2024 06:55:30 GMT, Manukumar V S wrote: > java/awt/Frame/MaximizeUndecoratedTest.java fails in OEL due to a slight color difference in the background color. This is currently reproduced only for Oracle Linux. > > The Color object I'm getting for each of these Point objects: > new Point(maxBounds.x + OFFSET, maxBounds.y + OFFSET) --> java.awt.Color[r=0,g=255,b=0] > new Point(maxBounds.width - OFFSET, maxBounds.y + OFFSET) --> java.awt.Color[r=0,g=207,b=0] > new Point(maxBounds.width - OFFSET, maxBounds.height - OFFSET) --> java.awt.Color[r=0,g=255,b=0] > new Point(maxBounds.x + OFFSET, maxBounds.height - OFFSET) --> java.awt.Color[r=0,g=255,b=0] > > So, the issue occurs for the second Point object --> new Point(maxBounds.width - OFFSET, maxBounds.y + OFFSET) - java.awt.Color[r=0,g=207,b=0] > > > Fix: > When the offset is increased from 2 to 3, it works fine in all the platforms. > > Testing: > Tested using mach5 in all the available platforms and it works fine everywhere(results attached in bug). > Tested manually in OEL 8 and it works fine there also. Is this due to anti-aliasing or something similar? And any idea why it's only Oracle Linux? Change itself looks simple enough, but odd that it's only for this scenario. ------------- PR Review: https://git.openjdk.org/jdk/pull/20486#pullrequestreview-2239254165 From prr at openjdk.org Wed Aug 14 22:41:49 2024 From: prr at openjdk.org (Phil Race) Date: Wed, 14 Aug 2024 22:41:49 GMT Subject: RFR: 8328553: Get rid of JApplet in test/jdk/sanity/client/lib/SwingSet2/src/DemoModule.java [v2] In-Reply-To: <2OSk0XPx_yss7rVX9cGt9CofcHzc32HJGEFgFr4scwQ=.24af7aac-1bf7-4c73-af32-1087ec367966@github.com> References: <2OSk0XPx_yss7rVX9cGt9CofcHzc32HJGEFgFr4scwQ=.24af7aac-1bf7-4c73-af32-1087ec367966@github.com> Message-ID: On Wed, 14 Aug 2024 21:36:18 GMT, lawrence.andrews wrote: >> 1) Replaced JApplet with JPanel >> 2) Tests passed before and after fix > > lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision: > > Removed the JApplet import Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20450#pullrequestreview-2239312726 From achung at openjdk.org Wed Aug 14 23:47:51 2024 From: achung at openjdk.org (Alisen Chung) Date: Wed, 14 Aug 2024 23:47:51 GMT Subject: RFR: 8337851: Some tests have name which confuse jtreg In-Reply-To: References: Message-ID: <9Ohvnc6MgnokscABDpbRhBYuXtjguHrcJd7eVRWSXYs=.cd938d32-de8b-4eb1-a601-421762f991f3@github.com> On Tue, 6 Aug 2024 05:51:35 GMT, toshiogata wrote: > Rename the tests to prevent unexpected deletion of result files when `-retain` jtreg option is specified. > Testing: modified tests test/langtools/tools/javac/generics/parametricException/ParametricException.java line 1: > 1: /* since you're renaming this file for jtreg testing anyway could you move the jtreg tags down below the imports and expand the wildcard import? test/langtools/tools/javac/warnings/Serial/Serial.java line 1: > 1: /* move jtreg tags below imports and add copyrights ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20475#discussion_r1717644293 PR Review Comment: https://git.openjdk.org/jdk/pull/20475#discussion_r1717644469 From duke at openjdk.org Thu Aug 15 00:25:50 2024 From: duke at openjdk.org (duke) Date: Thu, 15 Aug 2024 00:25:50 GMT Subject: RFR: 8328553: Get rid of JApplet in test/jdk/sanity/client/lib/SwingSet2/src/DemoModule.java [v2] In-Reply-To: <2OSk0XPx_yss7rVX9cGt9CofcHzc32HJGEFgFr4scwQ=.24af7aac-1bf7-4c73-af32-1087ec367966@github.com> References: <2OSk0XPx_yss7rVX9cGt9CofcHzc32HJGEFgFr4scwQ=.24af7aac-1bf7-4c73-af32-1087ec367966@github.com> Message-ID: On Wed, 14 Aug 2024 21:36:18 GMT, lawrence.andrews wrote: >> 1) Replaced JApplet with JPanel >> 2) Tests passed before and after fix > > lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision: > > Removed the JApplet import @lawrence-andrew Your change (at version 4a39ba80cd61284ea48ad6935c346fc161c1f1af) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20450#issuecomment-2290135491 From duke at openjdk.org Thu Aug 15 01:03:25 2024 From: duke at openjdk.org (lawrence.andrews) Date: Thu, 15 Aug 2024 01:03:25 GMT Subject: RFR: 8338425: java.lang.NullPointerException when About MenuItem is selected from SwingSet2DemoTest.java Message-ID: Added the missing jpg file & tested and NPE is not seen any more ------------- Commit messages: - 8338425: java.lang.NullPointerException when About MenuItem is selected from SwingSet2DemoTest.java Changes: https://git.openjdk.org/jdk/pull/20589/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20589&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8338425 Stats: 0 lines in 1 file changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20589.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20589/head:pull/20589 PR: https://git.openjdk.org/jdk/pull/20589 From psadhukhan at openjdk.org Thu Aug 15 07:26:28 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 15 Aug 2024 07:26:28 GMT Subject: RFR: 6318027: BasicScrollBarUI does not disable timer when enclosing frame is disabled. [v4] In-Reply-To: References: Message-ID: > Issue is > BasicScrollBarUI.ArrowButtonListener starts a timer in mousePressed(), and stops it in mouseReleased(). If the frame containing the scrollbar is disabled between the MOUSE_PRESSED and the MOUSE_RELEASED events, the mouseReleased() method is never called. If the frame is then re-enabled, the still-running timer causes it to scroll all the way to the end. > Fix is to check if [ArrowButtonListener.handledEvent](https://github.com/openjdk/jdk/blame/ee839b7f0ebe471d3877cddd2c87019ccb8ee5ae/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicScrollBarUI.java#L1567) is still set when ActionEvent is processed then stop the timer and reset this variable. > > CI testing is green and also SwingSet2 JScrollPane scrolling with this modification.. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Stop the timer if frame is disabled ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20346/files - new: https://git.openjdk.org/jdk/pull/20346/files/00fd5e58..526c6a17 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20346&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20346&range=02-03 Stats: 34 lines in 2 files changed: 19 ins; 0 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/20346.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20346/head:pull/20346 PR: https://git.openjdk.org/jdk/pull/20346 From psadhukhan at openjdk.org Thu Aug 15 07:26:28 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 15 Aug 2024 07:26:28 GMT Subject: RFR: 6318027: BasicScrollBarUI does not disable timer when enclosing frame is disabled. [v3] In-Reply-To: <5uXKFNbDuFqJQ8XtSS2CsvFDNv83NluVvYRl5Q20Yvs=.e1a16cd9-3236-4daf-bfeb-b4ca99661566@github.com> References: <5uXKFNbDuFqJQ8XtSS2CsvFDNv83NluVvYRl5Q20Yvs=.e1a16cd9-3236-4daf-bfeb-b4ca99661566@github.com> Message-ID: On Fri, 9 Aug 2024 06:54:27 GMT, Abhishek Kumar wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision: >> >> - copyright >> - Restore AquaL&F testing > > src/java.desktop/macosx/classes/com/apple/laf/AquaScrollBarUI.java line 530: > >> 528: >> 529: public void actionPerformed(final ActionEvent e) { >> 530: if (fTrackHighlight != Hit.NONE && !fTrackListener.fStillInTrack) { > > `fTrackListener.fStillInTrack` value is `true` and here the condition is to check for negation which makes it to `false` and overall condition evaluates to `false` and that may be the reason that the timer is not stopped. Yes thats the drawback of indirect checking....I have modified PR to check for frame disable directly and stop the timer.. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20346#discussion_r1718061735 From psadhukhan at openjdk.org Thu Aug 15 07:26:53 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 15 Aug 2024 07:26:53 GMT Subject: RFR: 7188058: Background of TextComponents are not changing colors to the default disabled color when set to uneditable [v4] In-Reply-To: References: Message-ID: On Mon, 12 Aug 2024 16:30:48 GMT, Alisen Chung wrote: >> Currently the bug described in the issue is that the colors of the TextComponents do not change when setting TextComponents to uneditable. The default uneditable color (SystemColor.control) happens to be the same as the default for the editable color for some L&Fs, so the fix may not be initially noticeable. However, the bug still exists where the the color is not being changed when changing between editable and uneditable. You can check by changing TextComponent.getBackground() code to return Color.GRAY on line 342 and you can see that TextComponents are not changing to a gray background when set to uneditable. >> >> This fix adds a private setBackground method in TextComponent so that TextArea and TextField can change the background color to the correct color (SystemColor.control) when set uneditable by overriding the TextComponent setEditable. You can verify the fix by changing this color to Color.GRAY and verifying the backgrounds change to gray when the TextComponents are disabled. > > Alisen Chung has updated the pull request incrementally with two additional commits since the last revision: > > - remove import > - remove uimanager from textfield src/java.desktop/share/classes/java/awt/TextArea.java line 38: > 36: import javax.accessibility.AccessibleState; > 37: import javax.accessibility.AccessibleStateSet; > 38: import javax.swing.UIManager; this import not needed.. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19876#discussion_r1718062278 From vdyakov at openjdk.org Thu Aug 15 15:07:48 2024 From: vdyakov at openjdk.org (Victor Dyakov) Date: Thu, 15 Aug 2024 15:07:48 GMT Subject: RFR: 8336873: BasicSplitPaneDivider:oneTouchExpandableChanged() should mention that implementation depends on SplitPane.supportsOneTouchButtons property [v2] In-Reply-To: <_qclrQho-hPrq6qT8ix-DEMP5I8pAFMKaSlBPdsfNyg=.6f817935-f665-44f3-b84d-5c764c32dea1@github.com> References: <4kkRV1pcjLKt4xgPWGrVfa0xTNHjjeEDEbp0e_buI7Q=.12d41a38-3f53-4dc3-b26a-9b265f0f54b3@github.com> <_qclrQho-hPrq6qT8ix-DEMP5I8pAFMKaSlBPdsfNyg=.6f817935-f665-44f3-b84d-5c764c32dea1@github.com> Message-ID: On Sun, 28 Jul 2024 23:14:03 GMT, Phil Race wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with three additional commits since the last revision: >> >> - typo >> - copyright year >> - L&F typo > > The only LAF I see that sets supportsOneTouchButtons is GTK and it sets it to false .. > so nothing anywhere sets it to true ! > And in the code being updated "true" is passed as the default value to DefaultLookup.getBoolean > > So this seems to imply that a Laf has to consciously opt-out of one touch .. which is surprising to me. i.e you have to know about this property in the first place to opt-out .. and I don't see where it is documented so how can anyone writing a LaF know about it ? > Is there not a central document about all of these ? @prrace could you please take a look? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20289#issuecomment-2291483466 From vdyakov at openjdk.org Thu Aug 15 15:16:53 2024 From: vdyakov at openjdk.org (Victor Dyakov) Date: Thu, 15 Aug 2024 15:16:53 GMT Subject: RFR: 8335231: [macos] Test java/awt/print/PrinterJob/Cancel/PrinterJobCancel.java failed on macOS because the case didn't get the expected PrintAbortException [v4] In-Reply-To: References: Message-ID: On Sun, 4 Aug 2024 21:44:33 GMT, Phil Race wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: >> >> Use EventQueue.invokeLater > > I think we still have some things to look at here > > (1) The job still gets queued for printing - should it ? Ideally not if there's some thing we can do. > (2) The "Error during printing" dialog I get after running the test is from macOS not us. Should it happen ? > (3) There's also an NSException printed which is because a call to CHECK_EXCEPTION thinks > the pending Java Exception is an error from an upcall made after terminating the print loop. > > Here is the NSException printed for (3) : > > 2024-08-02 13:34:54.360 java[50622:37988054] Java Exception > 2024-08-02 13:34:54.360 java[50622:37988054] ( > 0 CoreFoundation 0x00007ff8045ed11a __exceptionPreprocess + 242 > 1 libobjc.A.dylib 0x00007ff8041120b7 objc_exception_throw + 48 > 2 CoreFoundation 0x00007ff8045ecf80 +[NSException raise:format:] + 214 > 3 libawt_lwawt.dylib 0x0000000127355ed8 -[PrinterView complete:] + 552 > 4 libawt_lwawt.dylib 0x0000000127354050 -[PrintModel safePrintLoop:withEnv:] + 176 > 5 libawt_lwawt.dylib 0x00000001272f68ef Java_sun_lwawt_macosx_CPrinterJob_printLoop + 3871 > 6 ??? 0x000000011455ca87 0x0 + 4636134023 > ) > > Note it is not a Java Exception, it is an NSException and we log this from JNI_COCOA_EXIT after we catch it. > Perhaps we should only log this if a debugging flag is set .. but at least in this case it helped me see the problem (3). > > So what's going on with (3)? - I can partly help explain that. > When we get an unexpected Java Exception from a JNI call and need to bail back up to Java we use NSException to do this. > Unexpected exceptions mean bad method lookups, eg up calls that create an unexpected exception etc. > If an NSException is raised Objective-C transfers control to the next "catch" - which is in this case JNI_COCOA_EXIT > > This particular NSException happens because after the printLoop we need to make an up-call from "complete" > > (*env)->CallVoidMethod(env, fPrinterJob, jf_completePrintLoop); > CHECK_EXCEPTION(); > > But there's this PrinterAbortException already pending, which means we really should not be making the up-call without clearing it first, which is another issue (#4, or still part of #3 ?) > > After the upcall CHECK_EXCEPTION sees a pending Java Exception which it supposes is from a problem during the upcall and raises the NSException to "bail" up to the JNI_COCOA_EXIT where we catch it and l... @prrace please take a look ------------- PR Comment: https://git.openjdk.org/jdk/pull/20027#issuecomment-2291499751 From duke at openjdk.org Thu Aug 15 16:38:53 2024 From: duke at openjdk.org (lawrence.andrews) Date: Thu, 15 Aug 2024 16:38:53 GMT Subject: Integrated: 8328553: Get rid of JApplet in test/jdk/sanity/client/lib/SwingSet2/src/DemoModule.java In-Reply-To: References: Message-ID: <173gbttbYwRIRG3O2hp5u92h8khW7nbByEEyZu3nsVc=.61dcf974-c45e-4ac2-b0da-8b0bfb75b198@github.com> On Sat, 3 Aug 2024 18:07:16 GMT, lawrence.andrews wrote: > 1) Replaced JApplet with JPanel > 2) Tests passed before and after fix This pull request has now been integrated. Changeset: 7d1bbff0 Author: lawrence.andrews Committer: Harshitha Onkar URL: https://git.openjdk.org/jdk/commit/7d1bbff076c063d066951eedb21de7e694e588b3 Stats: 12 lines in 1 file changed: 1 ins; 8 del; 3 mod 8328553: Get rid of JApplet in test/jdk/sanity/client/lib/SwingSet2/src/DemoModule.java Reviewed-by: honkar, prr ------------- PR: https://git.openjdk.org/jdk/pull/20450 From honkar at openjdk.org Thu Aug 15 16:57:55 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Thu, 15 Aug 2024 16:57:55 GMT Subject: RFR: 8338425: java.lang.NullPointerException when About MenuItem is selected from SwingSet2DemoTest.java In-Reply-To: References: Message-ID: <-87ZJpOd69K_hggNLZnx8KH1SwVA8YiLcsDv8SwwMEE=.97dd3e20-8615-4487-bf85-23f5f7ae0211@github.com> On Thu, 15 Aug 2024 00:58:18 GMT, lawrence.andrews wrote: > Added the missing jpg file & tested and NPE is not seen any more The image needs to be added to this location too `test/jdk/sanity/client/lib/SwingSet2/src/resources/images`. The NPE observed here https://github.com/openjdk/jdk/pull/20450#issuecomment-2271904762 was on SwingSet2. ------------- Changes requested by honkar (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20589#pullrequestreview-2240864965 From honkar at openjdk.org Thu Aug 15 17:58:48 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Thu, 15 Aug 2024 17:58:48 GMT Subject: RFR: 8290501 : Typo in javax.swing.BoundedRangeModel documentation [v2] In-Reply-To: References: Message-ID: On Tue, 13 Aug 2024 05:19:07 GMT, Renjith Kannath Pariyangad wrote: >> Documentation updated > > Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision: > > Updated copyright year LGTM, please expand the import as suggested by @aivanov-jdk before integrating. ------------- Marked as reviewed by honkar (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20465#pullrequestreview-2241007884 From aivanov at openjdk.org Thu Aug 15 18:08:26 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 15 Aug 2024 18:08:26 GMT Subject: RFR: 8332901: Choice/SelectCurrentItemTest/SelectCurrentItemTest.java doesn't open popup on macOS Message-ID: I looked at `java/awt/Choice/SelectCurrentItemTest/SelectCurrentItemTest.java`, ran it and noticed that the test does not open the popup of the `Choice` component on macOS 14.x. If the popup does not open, the test does not verify anything ? it always passes. I refactored the test and added a mouse listener to the `Choice` component. If mouse click isn't registered, the test fails. The updated test fails for me locally on macOS Sonoma 14.5. This is likely the result of [JDK-8322653](https://bugs.openjdk.org/browse/JDK-8322653): _[macos14] : Mouse clicks are not received within 3 pixels of the window boundary_. The updated test passes on CI. ------------- Commit messages: - 8332901: Changes: https://git.openjdk.org/jdk/pull/20601/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20601&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8332901 Stats: 137 lines in 1 file changed: 62 ins; 38 del; 37 mod Patch: https://git.openjdk.org/jdk/pull/20601.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20601/head:pull/20601 PR: https://git.openjdk.org/jdk/pull/20601 From aivanov at openjdk.org Thu Aug 15 18:09:50 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 15 Aug 2024 18:09:50 GMT Subject: RFR: 8321140: Add comment to note difference in Metal's JButton margins In-Reply-To: References: Message-ID: On Wed, 14 Aug 2024 20:43:35 GMT, Alisen Chung wrote: >> Previously in [JDK-8282772](https://bugs.openjdk.org/browse/JDK-8282772), there was a fix for JButtons with HTML content alignment for non-MacOS L&Fs. This fix was to make other L&Fs in line with the Aqua fix found in [JDK-8015854](https://bugs.openjdk.org/browse/JDK-8015854). >> >> However, the non-MacOS L&F fix caused a regression and the details and original discussion can be found in [JDK-8318590](https://bugs.openjdk.org/browse/JDK-8318590). This non-MacOS L&F fix was backed out and the current behavior for JButtons with HTML content for these L&Fs was deemed to be correct as is. >> >> Through discussion, a note about Metal's different margin values should be added somewhere for future reference. Metal's horizontal margins are 14 where other L&Fs are zero or some small value. This discrepancy is what caused the original issue to be filed. This change is to add a comment to `MetalLookAndFeel.java` since there is no exact spot where these values are set for the margin. It's been added where other Metal components (CheckBox, RadioButton, etc.) have comments on margins as well. >> >> Here are some L&F values for reference/comparison: >> >> Metal's margins: [top=2,left=14,bottom=2,right=14] >> Aqua's margins: [top=0,left=2,bottom=0,right=2] >> Motif's margins: [top=2,left=4,bottom=2,right=4] >> Nimbus's margins: [top=0,left=0,bottom=0,right=0] > > src/java.desktop/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java line 810: > >> 808: "released SPACE", "released" >> 809: }), >> 810: // margin is (2, 14, 2, 14) which is vastly larger in horizontal > > I see below that there is another comment saying margin is 2 all the way around, what is the difference? how are these comments placed to indicate what margins they are referring to? The below comments apply to check box and radio button; this comment applies to regular push button. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20482#discussion_r1718800055 From aivanov at openjdk.org Thu Aug 15 18:34:49 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 15 Aug 2024 18:34:49 GMT Subject: RFR: 8321140: Add comment to note difference in Metal's JButton margins In-Reply-To: References: Message-ID: On Tue, 6 Aug 2024 23:12:44 GMT, Damon Nguyen wrote: > Previously in [JDK-8282772](https://bugs.openjdk.org/browse/JDK-8282772), there was a fix for JButtons with HTML content alignment for non-MacOS L&Fs. This fix was to make other L&Fs in line with the Aqua fix found in [JDK-8015854](https://bugs.openjdk.org/browse/JDK-8015854). > > However, the non-MacOS L&F fix caused a regression and the details and original discussion can be found in [JDK-8318590](https://bugs.openjdk.org/browse/JDK-8318590). This non-MacOS L&F fix was backed out and the current behavior for JButtons with HTML content for these L&Fs was deemed to be correct as is. > > Through discussion, a note about Metal's different margin values should be added somewhere for future reference. Metal's horizontal margins are 14 where other L&Fs are zero or some small value. This discrepancy is what caused the original issue to be filed. This change is to add a comment to `MetalLookAndFeel.java` since there is no exact spot where these values are set for the margin. It's been added where other Metal components (CheckBox, RadioButton, etc.) have comments on margins as well. > > Here are some L&F values for reference/comparison: > > Metal's margins: [top=2,left=14,bottom=2,right=14] > Aqua's margins: [top=0,left=2,bottom=0,right=2] > Motif's margins: [top=2,left=4,bottom=2,right=4] > Nimbus's margins: [top=0,left=0,bottom=0,right=0] Changes requested by aivanov (Reviewer). src/java.desktop/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java line 810: > 808: "released SPACE", "released" > 809: }), > 810: // margin is (2, 14, 2, 14) which is vastly larger in horizontal I still suggest adding a reference to `BasicBorder` class or `BasicLookAndFeel` where this border is defined. The borders for check boxes and radio buttons reference `BasicBorders.RadioButtonBorder` which helps to understand where the values are coming from. Specifically, `BasicLookAndFeel` defines `Button.margin` property: https://github.com/openjdk/jdk/blob/1cd488436880b00c55fa91f44c115999cf686afd/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicLookAndFeel.java#L729 It is set to the button in `installDefaults`: https://github.com/openjdk/jdk/blob/1cd488436880b00c55fa91f44c115999cf686afd/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicButtonUI.java#L158-L160 `BasicBorders.getButtonBorder` returns a border which defines colours and margins; the margins come from `MarginBorder` class which just returns the margins of a button component: https://github.com/openjdk/jdk/blob/1cd488436880b00c55fa91f44c115999cf686afd/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicBorders.java#L493-L495 ------------- PR Review: https://git.openjdk.org/jdk/pull/20482#pullrequestreview-2241072564 PR Review Comment: https://git.openjdk.org/jdk/pull/20482#discussion_r1718830042 From dnguyen at openjdk.org Thu Aug 15 19:06:49 2024 From: dnguyen at openjdk.org (Damon Nguyen) Date: Thu, 15 Aug 2024 19:06:49 GMT Subject: RFR: 8321140: Add comment to note difference in Metal's JButton margins In-Reply-To: References: Message-ID: On Thu, 15 Aug 2024 18:06:49 GMT, Alexey Ivanov wrote: >> src/java.desktop/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java line 810: >> >>> 808: "released SPACE", "released" >>> 809: }), >>> 810: // margin is (2, 14, 2, 14) which is vastly larger in horizontal >> >> I see below that there is another comment saying margin is 2 all the way around, what is the difference? how are these comments placed to indicate what margins they are referring to? > > The below comments apply to check box and radio button; this comment applies to regular push button. Yep. The issue is with regular buttons as Alexey mentioned. This caused a long discussion chain described in the linked issues. Nothing to do with CheckBox or RadioButton. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20482#discussion_r1718868474 From dnguyen at openjdk.org Thu Aug 15 19:15:21 2024 From: dnguyen at openjdk.org (Damon Nguyen) Date: Thu, 15 Aug 2024 19:15:21 GMT Subject: RFR: 8321140: Add comment to note difference in Metal's JButton margins [v2] In-Reply-To: References: Message-ID: On Thu, 15 Aug 2024 18:32:08 GMT, Alexey Ivanov wrote: >> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: >> >> Move note > > src/java.desktop/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java line 810: > >> 808: "released SPACE", "released" >> 809: }), >> 810: // margin is (2, 14, 2, 14) which is vastly larger in horizontal > > I still suggest adding a reference to `BasicBorder` class or `BasicLookAndFeel` where this border is defined. > > The borders for check boxes and radio buttons reference `BasicBorders.RadioButtonBorder` which helps to understand where the values are coming from. > > Specifically, `BasicLookAndFeel` defines `Button.margin` property: > > https://github.com/openjdk/jdk/blob/1cd488436880b00c55fa91f44c115999cf686afd/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicLookAndFeel.java#L729 > > It is set to the button in `installDefaults`: > > https://github.com/openjdk/jdk/blob/1cd488436880b00c55fa91f44c115999cf686afd/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicButtonUI.java#L158-L160 > > `BasicBorders.getButtonBorder` returns a border which defines colours and margins; the margins come from `MarginBorder` class which just returns the margins of a button component: > > https://github.com/openjdk/jdk/blob/1cd488436880b00c55fa91f44c115999cf686afd/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicBorders.java#L493-L495 Agreed. This is what I found as well. Had a bit of trouble figuring out how to phrase the note since the comment was meant to differentiate Metal from the other default installed LAFs. I moved it to `BasicLookAndFeel.java` since that's where the values are specifically defined. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20482#discussion_r1718876976 From dnguyen at openjdk.org Thu Aug 15 19:15:20 2024 From: dnguyen at openjdk.org (Damon Nguyen) Date: Thu, 15 Aug 2024 19:15:20 GMT Subject: RFR: 8321140: Add comment to note difference in Metal's JButton margins [v2] In-Reply-To: References: Message-ID: > Previously in [JDK-8282772](https://bugs.openjdk.org/browse/JDK-8282772), there was a fix for JButtons with HTML content alignment for non-MacOS L&Fs. This fix was to make other L&Fs in line with the Aqua fix found in [JDK-8015854](https://bugs.openjdk.org/browse/JDK-8015854). > > However, the non-MacOS L&F fix caused a regression and the details and original discussion can be found in [JDK-8318590](https://bugs.openjdk.org/browse/JDK-8318590). This non-MacOS L&F fix was backed out and the current behavior for JButtons with HTML content for these L&Fs was deemed to be correct as is. > > Through discussion, a note about Metal's different margin values should be added somewhere for future reference. Metal's horizontal margins are 14 where other L&Fs are zero or some small value. This discrepancy is what caused the original issue to be filed. This change is to add a comment to `MetalLookAndFeel.java` since there is no exact spot where these values are set for the margin. It's been added where other Metal components (CheckBox, RadioButton, etc.) have comments on margins as well. > > Here are some L&F values for reference/comparison: > > Metal's margins: [top=2,left=14,bottom=2,right=14] > Aqua's margins: [top=0,left=2,bottom=0,right=2] > Motif's margins: [top=2,left=4,bottom=2,right=4] > Nimbus's margins: [top=0,left=0,bottom=0,right=0] Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: Move note ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20482/files - new: https://git.openjdk.org/jdk/pull/20482/files/ba4a8327..e590b8dd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20482&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20482&range=00-01 Stats: 50 lines in 2 files changed: 11 ins; 35 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/20482.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20482/head:pull/20482 PR: https://git.openjdk.org/jdk/pull/20482 From honkar at openjdk.org Fri Aug 16 00:50:00 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Fri, 16 Aug 2024 00:50:00 GMT Subject: RFR: 8332901: Choice/SelectCurrentItemTest/SelectCurrentItemTest.java doesn't open popup on macOS In-Reply-To: References: Message-ID: <9ZRnKcd-AK9eugGg6jgzcqW15_-K5MIRcY9pyMreivw=.4f50b730-3fbb-4a60-b2ea-e68b441b49b5@github.com> On Thu, 15 Aug 2024 18:02:33 GMT, Alexey Ivanov wrote: > I looked at `java/awt/Choice/SelectCurrentItemTest/SelectCurrentItemTest.java`, ran it and noticed that the test does not open the popup of the `Choice` component on macOS 14.x. > > If the popup does not open, the test does not verify anything ? it always passes. > > I refactored the test and added a mouse listener to the `Choice` component. If mouse click isn't registered, the test fails. > > The updated test fails for me locally on macOS Sonoma 14.5. This is likely the result of [JDK-8322653](https://bugs.openjdk.org/browse/JDK-8322653): _[macos14] : Mouse clicks are not received within 3 pixels of the window boundary_. > > The updated test passes on CI. @aivanov-jdk As you mentioned earlier this test fails on macOS 14.5 due to [JDK-8322653](https://bugs.openjdk.org/browse/JDK-8322653), since it passes on 14.3 and 14.4 do we skip problemlisting the test for now ? ------------- PR Review: https://git.openjdk.org/jdk/pull/20601#pullrequestreview-2241577721 From honkar at openjdk.org Fri Aug 16 00:56:56 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Fri, 16 Aug 2024 00:56:56 GMT Subject: RFR: 8332901: Choice/SelectCurrentItemTest/SelectCurrentItemTest.java doesn't open popup on macOS In-Reply-To: References: Message-ID: On Thu, 15 Aug 2024 18:02:33 GMT, Alexey Ivanov wrote: > I looked at `java/awt/Choice/SelectCurrentItemTest/SelectCurrentItemTest.java`, ran it and noticed that the test does not open the popup of the `Choice` component on macOS 14.x. > > If the popup does not open, the test does not verify anything ? it always passes. > > I refactored the test and added a mouse listener to the `Choice` component. If mouse click isn't registered, the test fails. > > The updated test fails for me locally on macOS Sonoma 14.5. This is likely the result of [JDK-8322653](https://bugs.openjdk.org/browse/JDK-8322653): _[macos14] : Mouse clicks are not received within 3 pixels of the window boundary_. > > The updated test passes on CI. test/jdk/java/awt/Choice/SelectCurrentItemTest/SelectCurrentItemTest.java line 89: > 87: > 88: frame.setLocationRelativeTo(null); > 89: frame.pack(); When frame.setSize() is used, the mouse pointer on the choice drop-down button is no longer a resize indicator and the click event is received. But I guess you are planning to leave this as-is for now so as to not mask the external issue. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20601#discussion_r1719159917 From duke at openjdk.org Fri Aug 16 01:05:21 2024 From: duke at openjdk.org (toshiogata) Date: Fri, 16 Aug 2024 01:05:21 GMT Subject: RFR: 8337851: Some tests have name which confuse jtreg [v2] In-Reply-To: References: Message-ID: > Rename the tests to prevent unexpected deletion of result files when `-retain` jtreg option is specified. > Testing: modified tests toshiogata has updated the pull request incrementally with one additional commit since the last revision: Move jtreg tags and expand wildcard imports ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20475/files - new: https://git.openjdk.org/jdk/pull/20475/files/4f973c70..9b30df12 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20475&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20475&range=00-01 Stats: 11 lines in 2 files changed: 6 ins; 4 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20475.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20475/head:pull/20475 PR: https://git.openjdk.org/jdk/pull/20475 From duke at openjdk.org Fri Aug 16 01:05:22 2024 From: duke at openjdk.org (toshiogata) Date: Fri, 16 Aug 2024 01:05:22 GMT Subject: RFR: 8337851: Some tests have name which confuse jtreg [v2] In-Reply-To: <9Ohvnc6MgnokscABDpbRhBYuXtjguHrcJd7eVRWSXYs=.cd938d32-de8b-4eb1-a601-421762f991f3@github.com> References: <9Ohvnc6MgnokscABDpbRhBYuXtjguHrcJd7eVRWSXYs=.cd938d32-de8b-4eb1-a601-421762f991f3@github.com> Message-ID: On Wed, 14 Aug 2024 23:43:14 GMT, Alisen Chung wrote: >> toshiogata has updated the pull request incrementally with one additional commit since the last revision: >> >> Move jtreg tags and expand wildcard imports > > test/langtools/tools/javac/generics/parametricException/ParametricException.java line 1: > >> 1: /* > > since you're renaming this file for jtreg testing anyway could you move the jtreg tags down below the imports and expand the wildcard import? As you mentioned, it's a good time to make a minor improvement, so I modified the test. > test/langtools/tools/javac/warnings/Serial/Serial.java line 1: > >> 1: /* > > move jtreg tags below imports and add copyrights The copyright has been intentionally omitted as explained in https://bugs.openjdk.org/browse/JDK-8258525 I moved the jtreg tag. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20475#discussion_r1719166472 PR Review Comment: https://git.openjdk.org/jdk/pull/20475#discussion_r1719166674 From achung at openjdk.org Fri Aug 16 01:41:53 2024 From: achung at openjdk.org (Alisen Chung) Date: Fri, 16 Aug 2024 01:41:53 GMT Subject: RFR: 8337886: java/awt/Frame/MaximizeUndecoratedTest.java fails in OEL due to a slight color difference In-Reply-To: <2HljLuH3vumJyEMqhCWnGVnAWCJaMrbVbf0PgBO8ATg=.3bd94f6d-124b-4e4a-be15-ec319f552223@github.com> References: <2HljLuH3vumJyEMqhCWnGVnAWCJaMrbVbf0PgBO8ATg=.3bd94f6d-124b-4e4a-be15-ec319f552223@github.com> Message-ID: On Wed, 7 Aug 2024 06:55:30 GMT, Manukumar V S wrote: > java/awt/Frame/MaximizeUndecoratedTest.java fails in OEL due to a slight color difference in the background color. This is currently reproduced only for Oracle Linux. > > The Color object I'm getting for each of these Point objects: > new Point(maxBounds.x + OFFSET, maxBounds.y + OFFSET) --> java.awt.Color[r=0,g=255,b=0] > new Point(maxBounds.width - OFFSET, maxBounds.y + OFFSET) --> java.awt.Color[r=0,g=207,b=0] > new Point(maxBounds.width - OFFSET, maxBounds.height - OFFSET) --> java.awt.Color[r=0,g=255,b=0] > new Point(maxBounds.x + OFFSET, maxBounds.height - OFFSET) --> java.awt.Color[r=0,g=255,b=0] > > So, the issue occurs for the second Point object --> new Point(maxBounds.width - OFFSET, maxBounds.y + OFFSET) - java.awt.Color[r=0,g=207,b=0] > > > Fix: > When the offset is increased from 2 to 3, it works fine in all the platforms. > > Testing: > Tested using mach5 in all the available platforms and it works fine everywhere(results attached in bug). > Tested manually in OEL 8 and it works fine there also. test/jdk/java/awt/Frame/MaximizeUndecoratedTest.java line 1: > 1: /* It appears in the attached tests that one of the platforms (linux aarch64) was not run. Could you double check the mach5 test run? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20486#discussion_r1719186385 From tr at openjdk.org Fri Aug 16 04:13:50 2024 From: tr at openjdk.org (Tejesh R) Date: Fri, 16 Aug 2024 04:13:50 GMT Subject: RFR: 6318027: BasicScrollBarUI does not disable timer when enclosing frame is disabled. [v3] In-Reply-To: References: Message-ID: <95xzatBENO9qB53LI3LzQunZe77NP8wA-wuysDCJYTY=.eea62496-ee77-4464-a1c4-fde242159dc2@github.com> On Wed, 7 Aug 2024 13:52:07 GMT, Prasanta Sadhukhan wrote: >> Issue is >> BasicScrollBarUI.ArrowButtonListener starts a timer in mousePressed(), and stops it in mouseReleased(). If the frame containing the scrollbar is disabled between the MOUSE_PRESSED and the MOUSE_RELEASED events, the mouseReleased() method is never called. If the frame is then re-enabled, the still-running timer causes it to scroll all the way to the end. >> Fix is to check if [ArrowButtonListener.handledEvent](https://github.com/openjdk/jdk/blame/ee839b7f0ebe471d3877cddd2c87019ccb8ee5ae/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicScrollBarUI.java#L1567) is still set when ActionEvent is processed then stop the timer and reset this variable. >> >> CI testing is green and also SwingSet2 JScrollPane scrolling with this modification.. > > Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision: > > - copyright > - Restore AquaL&F testing test/jdk/javax/swing/JScrollBar/DisableFrameFromScrollBar.java line 52: > 50: private static JFrame frame; > 51: private static JScrollBar bar; > 52: private static Robot robot; `robot` can be local variable. test/jdk/javax/swing/JScrollBar/DisableFrameFromScrollBar.java line 120: > 118: } while(isAdjusting && !doCheck); > 119: if (bar.getValue() == (bar.getMaximum() - bar.getVisibleAmount())) { > 120: throw new RuntimeException("ScrollBar did't disable timer"); Suggestion: throw new RuntimeException("ScrollBar didn't disable timer"); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20346#discussion_r1717111311 PR Review Comment: https://git.openjdk.org/jdk/pull/20346#discussion_r1717104900 From mvs at openjdk.org Fri Aug 16 06:00:52 2024 From: mvs at openjdk.org (Manukumar V S) Date: Fri, 16 Aug 2024 06:00:52 GMT Subject: RFR: 8337886: java/awt/Frame/MaximizeUndecoratedTest.java fails in OEL due to a slight color difference In-Reply-To: References: <2HljLuH3vumJyEMqhCWnGVnAWCJaMrbVbf0PgBO8ATg=.3bd94f6d-124b-4e4a-be15-ec319f552223@github.com> Message-ID: On Fri, 16 Aug 2024 01:39:38 GMT, Alisen Chung wrote: >> java/awt/Frame/MaximizeUndecoratedTest.java fails in OEL due to a slight color difference in the background color. This is currently reproduced only for Oracle Linux. >> >> The Color object I'm getting for each of these Point objects: >> new Point(maxBounds.x + OFFSET, maxBounds.y + OFFSET) --> java.awt.Color[r=0,g=255,b=0] >> new Point(maxBounds.width - OFFSET, maxBounds.y + OFFSET) --> java.awt.Color[r=0,g=207,b=0] >> new Point(maxBounds.width - OFFSET, maxBounds.height - OFFSET) --> java.awt.Color[r=0,g=255,b=0] >> new Point(maxBounds.x + OFFSET, maxBounds.height - OFFSET) --> java.awt.Color[r=0,g=255,b=0] >> >> So, the issue occurs for the second Point object --> new Point(maxBounds.width - OFFSET, maxBounds.y + OFFSET) - java.awt.Color[r=0,g=207,b=0] >> >> >> Fix: >> When the offset is increased from 2 to 3, it works fine in all the platforms. >> >> Testing: >> Tested using mach5 in all the available platforms and it works fine everywhere(results attached in bug). >> Tested manually in OEL 8 and it works fine there also. > > test/jdk/java/awt/Frame/MaximizeUndecoratedTest.java line 1: > >> 1: /* > > It appears in the attached tests that one of the platforms (linux aarch64) was not run. Could you double check the mach5 test run? Yea thats true, there was no linux-aarch64 headful machines available in mach5, but I have run it manually and confirmed that its working fine in linux-aarch64 also. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20486#discussion_r1719370658 From mvs at openjdk.org Fri Aug 16 07:26:48 2024 From: mvs at openjdk.org (Manukumar V S) Date: Fri, 16 Aug 2024 07:26:48 GMT Subject: RFR: 8337886: java/awt/Frame/MaximizeUndecoratedTest.java fails in OEL due to a slight color difference In-Reply-To: References: <2HljLuH3vumJyEMqhCWnGVnAWCJaMrbVbf0PgBO8ATg=.3bd94f6d-124b-4e4a-be15-ec319f552223@github.com> Message-ID: On Wed, 14 Aug 2024 21:49:05 GMT, Damon Nguyen wrote: > Is this due to anti-aliasing or something similar? And any idea why it's only Oracle Linux? Change itself looks simple enough, but odd that it's only for this scenario. @DamonGuy I don't think this has any relationship with anti-aliasing or something similar as there is no font involved. This test verifies whether the frame is maximised or not by checking its four border points(by comparing it's colour with GREEN). But in OEL, the top left and top right borders are curved, so there is a possibility of error if we directly compare those points with GREEN colour, that's why an OFFSET is needed. But an OFFSET of 2 is not sufficient for OEL, and for safety I will change it to 5. I don't see this issue in Ubuntu as the borders as rectangular there, but not curved. I'm attaching the OEL screenshot for your reference. ![MaximizedFrame](https://github.com/user-attachments/assets/3086b093-68fd-42dc-8c7a-1342fada9003) ------------- PR Comment: https://git.openjdk.org/jdk/pull/20486#issuecomment-2292974424 From mvs at openjdk.org Fri Aug 16 07:36:01 2024 From: mvs at openjdk.org (Manukumar V S) Date: Fri, 16 Aug 2024 07:36:01 GMT Subject: RFR: 8337886: java/awt/Frame/MaximizeUndecoratedTest.java fails in OEL due to a slight color difference [v2] In-Reply-To: <2HljLuH3vumJyEMqhCWnGVnAWCJaMrbVbf0PgBO8ATg=.3bd94f6d-124b-4e4a-be15-ec319f552223@github.com> References: <2HljLuH3vumJyEMqhCWnGVnAWCJaMrbVbf0PgBO8ATg=.3bd94f6d-124b-4e4a-be15-ec319f552223@github.com> Message-ID: <1vVV9gF1wPCRLSRL8G50nWrriNzIaFfmuRDhW19rUSA=.f2a24bb3-9574-402d-b346-ab31737be122@github.com> > java/awt/Frame/MaximizeUndecoratedTest.java fails in OEL due to a slight color difference in the background color. This is currently reproduced only for Oracle Linux. > > The Color object I'm getting for each of these Point objects: > new Point(maxBounds.x + OFFSET, maxBounds.y + OFFSET) --> java.awt.Color[r=0,g=255,b=0] > new Point(maxBounds.width - OFFSET, maxBounds.y + OFFSET) --> java.awt.Color[r=0,g=207,b=0] > new Point(maxBounds.width - OFFSET, maxBounds.height - OFFSET) --> java.awt.Color[r=0,g=255,b=0] > new Point(maxBounds.x + OFFSET, maxBounds.height - OFFSET) --> java.awt.Color[r=0,g=255,b=0] > > So, the issue occurs for the second Point object --> new Point(maxBounds.width - OFFSET, maxBounds.y + OFFSET) - java.awt.Color[r=0,g=207,b=0] > > > Fix: > When the offset is increased from 2 to 5, it works fine in all the platforms. > > This test verifies whether the frame is maximised or not by checking its four border points(by comparing it's colour with GREEN). But in OEL, the top left and top right borders are curved, so there is a possibility of error if we directly compare those points with GREEN colour, that's why an OFFSET is needed. But an OFFSET of 2 is not sufficient for OEL, and for safety I will change it to 5. I don't see this issue in Ubuntu as the borders as rectangular there, but not curved. > > Testing: > Tested using mach5 in all the available platforms and it works fine everywhere(results attached in bug). > Tested manually in OEL 8 and 9(both x64 and aarch64) and it works fine there also. Manukumar V S has updated the pull request incrementally with one additional commit since the last revision: Changing the OFFSET to a safer value 5 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20486/files - new: https://git.openjdk.org/jdk/pull/20486/files/0f7f7161..26a74acb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20486&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20486&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20486.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20486/head:pull/20486 PR: https://git.openjdk.org/jdk/pull/20486 From tr at openjdk.org Fri Aug 16 07:45:08 2024 From: tr at openjdk.org (Tejesh R) Date: Fri, 16 Aug 2024 07:45:08 GMT Subject: RFR: 8338041: Keyborad Navigation of JTable, Ctrl Shift RIGHT/LEFT doesn't follow native action in GTK L&F Message-ID: <_kMMFJ9LnQOmUmp_3Ob1m3lj2xLKUo-ChL00Clw4xjs=.7e799f69-da05-44f4-9bf7-6e9e43b427b8@github.com> In JTable, keyboard navigation keys Ctrl Shift RIGHT/LEFT doesn't follow native actions of Linux. In native the actions are extended to end of selected columns cells either LEFT/RIGHT but in swing gtk look and feel the selection is extended to one cell to left/right. This might be taken as reference of Windows OS since the same is observed in Windows native. Hence I have update the actions for Ctrl Shift RIGHT & LEFT. Added automated test too. The fix is tested in CI and its fine. ------------- Commit messages: - Test updates - Key action modified + Automatic test added Changes: https://git.openjdk.org/jdk/pull/20608/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20608&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8338041 Stats: 140 lines in 2 files changed: 138 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20608.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20608/head:pull/20608 PR: https://git.openjdk.org/jdk/pull/20608 From rkannathpari at openjdk.org Fri Aug 16 10:00:22 2024 From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad) Date: Fri, 16 Aug 2024 10:00:22 GMT Subject: RFR: 8290501 : Typo in javax.swing.BoundedRangeModel documentation [v3] In-Reply-To: References: Message-ID: > Documentation updated Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision: Updated import ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20465/files - new: https://git.openjdk.org/jdk/pull/20465/files/176230af..097976f0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20465&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20465&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20465.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20465/head:pull/20465 PR: https://git.openjdk.org/jdk/pull/20465 From abhiscxk at openjdk.org Fri Aug 16 10:05:18 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Fri, 16 Aug 2024 10:05:18 GMT Subject: RFR: 4795384: GTK+ JFileChooser buttons should have mnemonics Message-ID: JFileChooser don't have the mnemonics for open and save button in GTK L&F. Fix is to add mnemonics for open and save button. Fix can be verified by Swingset2 demo application. Mnemonics in GTK L&F are visible once alt key is pressed. After running the SwingSet2 application, change the `L&F to GTK` and select` JFileChooser demo` from toolbar. Click on `Select Plain JFileChooser` button and then press alt key to verify the mnemonics. ------------- Commit messages: - add mnemonics for open and save button Changes: https://git.openjdk.org/jdk/pull/20612/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20612&range=00 Issue: https://bugs.openjdk.org/browse/JDK-4795384 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20612.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20612/head:pull/20612 PR: https://git.openjdk.org/jdk/pull/20612 From abhiscxk at openjdk.org Fri Aug 16 10:15:52 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Fri, 16 Aug 2024 10:15:52 GMT Subject: RFR: 8338041: Keyborad Navigation of JTable, Ctrl Shift RIGHT/LEFT doesn't follow native action in GTK L&F In-Reply-To: <_kMMFJ9LnQOmUmp_3Ob1m3lj2xLKUo-ChL00Clw4xjs=.7e799f69-da05-44f4-9bf7-6e9e43b427b8@github.com> References: <_kMMFJ9LnQOmUmp_3Ob1m3lj2xLKUo-ChL00Clw4xjs=.7e799f69-da05-44f4-9bf7-6e9e43b427b8@github.com> Message-ID: On Fri, 16 Aug 2024 07:39:44 GMT, Tejesh R wrote: > In JTable, keyboard navigation keys Ctrl Shift RIGHT/LEFT doesn't follow native actions of Linux. In native the actions are extended to end of selected columns cells either LEFT/RIGHT but in swing gtk look and feel the selection is extended to one cell to left/right. This might be taken as reference of Windows OS since the same is observed in Windows native. Hence I have update the actions for Ctrl Shift RIGHT & LEFT. > Added automated test too. The fix is tested in CI and its fine. test/jdk/javax/swing/plaf/gtk/JTableCtrlShiftRightLeftKeyTest.java line 75: > 73: robot.delay(100); > 74: > 75: testCtrlShift(KeyEvent.VK_RIGHT, SELECTED_COLUMN, table.getColumnCount()-1); Suggestion: testCtrlShift(KeyEvent.VK_RIGHT, SELECTED_COLUMN, table.getColumnCount() - 1); test/jdk/javax/swing/plaf/gtk/JTableCtrlShiftRightLeftKeyTest.java line 114: > 112: > 113: if (selectedColumnAfterKeyPress[0] != startCellCheck || > 114: selectedColumnAfterKeyPress[selectedColumnAfterKeyPress.length-1] != Suggestion: selectedColumnAfterKeyPress[selectedColumnAfterKeyPress.length - 1] != test/jdk/javax/swing/plaf/gtk/JTableCtrlShiftRightLeftKeyTest.java line 117: > 115: endCellCheck) { > 116: System.out.println("Selected Columns: "); > 117: for (int columnAfterTabPress : selectedColumnAfterKeyPress) { I don't think it is required to print the selected column.. If at all it is required for debugging I guess `columnAfterTabPress` should be renamed as columns are not selected after tab press. test/jdk/javax/swing/plaf/gtk/JTableCtrlShiftRightLeftKeyTest.java line 120: > 118: System.out.println(columnAfterTabPress); > 119: } > 120: String key = (keySelected == KeyEvent.VK_RIGHT)? "RIGHT" : "LEFT"; "RIGHT" or "LEFT" can be passed as an argument to this method. This check can be removed. test/jdk/javax/swing/plaf/gtk/JTableCtrlShiftRightLeftKeyTest.java line 122: > 120: String key = (keySelected == KeyEvent.VK_RIGHT)? "RIGHT" : "LEFT"; > 121: String failureMsg = "Test Failure. Failed to select cells for Ctrl" + > 122: " Shift "+key+" selection"; Suggestion: " Shift " + key + " selection"; test/jdk/javax/swing/plaf/gtk/JTableCtrlShiftRightLeftKeyTest.java line 128: > 126: > 127: private static void createAndShowUI() { > 128: frame = new JFrame("Test JTable Tab Press"); Title should be changed to something like `Test JTable Ctrl + Shift + Left / Right Key Press` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20608#discussion_r1719644278 PR Review Comment: https://git.openjdk.org/jdk/pull/20608#discussion_r1719645093 PR Review Comment: https://git.openjdk.org/jdk/pull/20608#discussion_r1719647618 PR Review Comment: https://git.openjdk.org/jdk/pull/20608#discussion_r1719642247 PR Review Comment: https://git.openjdk.org/jdk/pull/20608#discussion_r1719648412 PR Review Comment: https://git.openjdk.org/jdk/pull/20608#discussion_r1719649574 From aivanov at openjdk.org Fri Aug 16 10:58:50 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 16 Aug 2024 10:58:50 GMT Subject: RFR: 8290501 : Typo in javax.swing.BoundedRangeModel documentation [v3] In-Reply-To: References: Message-ID: <2WwC9zIPUg-8g8QWbDFkIXJl813pC-GEUpSKpC5mS34=.cc34f5f1-c78e-44d4-85fb-1b9a0427f192@github.com> On Fri, 16 Aug 2024 10:00:22 GMT, Renjith Kannath Pariyangad wrote: >> Documentation updated > > Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision: > > Updated import Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20465#pullrequestreview-2242465085 From aivanov at openjdk.org Fri Aug 16 11:42:48 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 16 Aug 2024 11:42:48 GMT Subject: RFR: 8337851: Some tests have name which confuse jtreg [v2] In-Reply-To: References: <9Ohvnc6MgnokscABDpbRhBYuXtjguHrcJd7eVRWSXYs=.cd938d32-de8b-4eb1-a601-421762f991f3@github.com> Message-ID: On Fri, 16 Aug 2024 01:01:52 GMT, toshiogata wrote: >> test/langtools/tools/javac/generics/parametricException/ParametricException.java line 1: >> >>> 1: /* >> >> since you're renaming this file for jtreg testing anyway could you move the jtreg tags down below the imports and expand the wildcard import? > > As you mentioned, it's a good time to make a minor improvement, so I modified the test. I propose not to edit the renamed files. First of all, the purpose of this PR is to *rename tests* to workaround a _misfeature_ of jtreg. Git does not support renames natively, therefore by editing the renamed files you could break Git ability to detect renaming. Additionally, these tests are not part of client and I am not aware of the practices in Java Compiler team. Expanding wildcard imports should be fine, yet I would rather avoid editing the renamed files as I mentioned above. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20475#discussion_r1719731264 From aivanov at openjdk.org Fri Aug 16 11:45:48 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 16 Aug 2024 11:45:48 GMT Subject: RFR: 8337851: Some tests have name which confuse jtreg [v2] In-Reply-To: References: Message-ID: On Fri, 16 Aug 2024 01:05:21 GMT, toshiogata wrote: >> Rename the tests to prevent unexpected deletion of result files when `-retain` jtreg option is specified. >> Testing: modified tests > > toshiogata has updated the pull request incrementally with one additional commit since the last revision: > > Move jtreg tags and expand wildcard imports I suggest not to edit the files and only *rename them* as it was in the first iteration of the review. ------------- Changes requested by aivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20475#pullrequestreview-2242537764 From tr at openjdk.org Fri Aug 16 11:58:16 2024 From: tr at openjdk.org (Tejesh R) Date: Fri, 16 Aug 2024 11:58:16 GMT Subject: RFR: 8338488: Add screen capture for failure case Message-ID: open/test/jdk/java/awt/Checkbox/CheckboxCheckerScalingTest.java is failing intermittently on Linux (https://bugs.openjdk.org/browse/JDK-8338153). As part of analysis I've updated the test with image writing on failure condition. ------------- Commit messages: - Updated the test with image write on failure Changes: https://git.openjdk.org/jdk/pull/20614/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20614&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8338488 Stats: 10 lines in 1 file changed: 10 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20614.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20614/head:pull/20614 PR: https://git.openjdk.org/jdk/pull/20614 From tr at openjdk.org Fri Aug 16 12:02:54 2024 From: tr at openjdk.org (Tejesh R) Date: Fri, 16 Aug 2024 12:02:54 GMT Subject: RFR: 4795384: GTK+ JFileChooser buttons should have mnemonics In-Reply-To: References: Message-ID: <6GaRCbIiFpZ7PvdAYUEy3emlqmE35I6HEJPtqVWuOPc=.d25d0a9b-a7b2-4a17-b87a-3e8052c6c9c4@github.com> On Fri, 16 Aug 2024 09:59:26 GMT, Abhishek Kumar wrote: > JFileChooser don't have the mnemonics for open and save button in GTK L&F. Fix is to add mnemonics for open and save button. > Fix can be verified by Swingset2 demo application. Mnemonics in GTK L&F are visible once alt key is pressed. > After running the SwingSet2 application, change the `L&F to GTK` and select` JFileChooser demo` from toolbar. Click on `Select Plain JFileChooser` button and then press alt key to verify the mnemonics. Adding a test for this fix would be better, I guess....... ------------- PR Review: https://git.openjdk.org/jdk/pull/20612#pullrequestreview-2242565978 From tr at openjdk.org Fri Aug 16 12:18:47 2024 From: tr at openjdk.org (Tejesh R) Date: Fri, 16 Aug 2024 12:18:47 GMT Subject: RFR: 4795384: GTK+ JFileChooser buttons should have mnemonics In-Reply-To: References: Message-ID: On Fri, 16 Aug 2024 09:59:26 GMT, Abhishek Kumar wrote: > JFileChooser don't have the mnemonics for open and save button in GTK L&F. Fix is to add mnemonics for open and save button. > Fix can be verified by Swingset2 demo application. Mnemonics in GTK L&F are visible once alt key is pressed. > After running the SwingSet2 application, change the `L&F to GTK` and select` JFileChooser demo` from toolbar. Click on `Select Plain JFileChooser` button and then press alt key to verify the mnemonics. > Adding a test for this fix would be better, I guess. Anyhow the fix looks good. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20612#issuecomment-2293401503 From aivanov at openjdk.org Fri Aug 16 14:13:52 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 16 Aug 2024 14:13:52 GMT Subject: RFR: 8332901: Choice/SelectCurrentItemTest/SelectCurrentItemTest.java doesn't open popup on macOS In-Reply-To: References: Message-ID: On Fri, 16 Aug 2024 00:51:27 GMT, Harshitha Onkar wrote: > When frame.setSize() is used, the mouse pointer on the choice drop-down button is no longer a resize indicator and the click event is received. I don't understand how using `frame.setSize` resolve the problem? Both `pack` and `setSize` call `reshape` to apply the new location and size. Did you mean `frame.setResizable(false)`? > But I guess you are planning to leave this as-is for now to test when the external fix is available for [JDK-8322653](https://bugs.openjdk.org/browse/JDK-8322653) We can modify this test to avoid JDK-8322653. I added a panel to the frame to move the mouse cursor away from the edge of the frame while I verified the test would pass. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20601#discussion_r1719900266 From aivanov at openjdk.org Fri Aug 16 14:16:49 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 16 Aug 2024 14:16:49 GMT Subject: RFR: 8332901: Choice/SelectCurrentItemTest/SelectCurrentItemTest.java doesn't open popup on macOS In-Reply-To: <9ZRnKcd-AK9eugGg6jgzcqW15_-K5MIRcY9pyMreivw=.4f50b730-3fbb-4a60-b2ea-e68b441b49b5@github.com> References: <9ZRnKcd-AK9eugGg6jgzcqW15_-K5MIRcY9pyMreivw=.4f50b730-3fbb-4a60-b2ea-e68b441b49b5@github.com> Message-ID: On Fri, 16 Aug 2024 00:47:01 GMT, Harshitha Onkar wrote: > since it passes on CI (14.3 and 14.4) do we skip problemlisting the test for now ? I'm unsure whether the test has ever run on 14.x in CI. The test has never failed for me when I submitted test jobs. As such, I have no reasons to problem-list it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20601#issuecomment-2293590229 From aivanov at openjdk.org Fri Aug 16 16:18:51 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 16 Aug 2024 16:18:51 GMT Subject: RFR: 8321140: Add comment to note difference in Metal's JButton margins [v2] In-Reply-To: References: Message-ID: On Thu, 15 Aug 2024 19:12:32 GMT, Damon Nguyen wrote: > I moved it to `BasicLookAndFeel.java` since that's where the values are specifically defined. Perhaps, we need a note in *both files*. In `MetalLookAndFeel.java` to refer to `BasicLookAndFeel` where the margin is defined, similar to what's done for check boxes and radio button. And in `BasicLookAndFeel.java` to note that the above margins are vastly different from other L&Fs. What about this text? **`MetalLookAndFeel.java`** // default margin is (2, 14, 2, 14), defined in // BasicLookAndFeel via "Button.margin" UI property. **`BasicLookAndFeel.java`** // The above margin has vastly larger horizontal values when // compared to other look and feels that don't rely on these values ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20482#discussion_r1720049626 From honkar at openjdk.org Fri Aug 16 16:47:49 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Fri, 16 Aug 2024 16:47:49 GMT Subject: RFR: 8321140: Add comment to note difference in Metal's JButton margins [v2] In-Reply-To: References: Message-ID: On Fri, 16 Aug 2024 16:16:07 GMT, Alexey Ivanov wrote: >> Agreed. This is what I found as well. Had a bit of trouble figuring out how to phrase the note since the comment was meant to differentiate Metal from the other default installed LAFs. >> >> I moved it to `BasicLookAndFeel.java` since that's where the values are specifically defined. > >> I moved it to `BasicLookAndFeel.java` since that's where the values are specifically defined. > > Perhaps, we need a note in *both files*. > > In `MetalLookAndFeel.java` to refer to `BasicLookAndFeel` where the margin is defined, similar to what's done for check boxes and radio button. > > And in `BasicLookAndFeel.java` to note that the above margins are vastly different from other L&Fs. > > What about this text? > > **`MetalLookAndFeel.java`** > > // default margin is (2, 14, 2, 14), defined in > // BasicLookAndFeel via "Button.margin" UI property. > > > **`BasicLookAndFeel.java`** > > // The above margin has vastly larger horizontal values when > // compared to other look and feels that don't rely on these values I agree, adding a note at both places looks clearer. The additional note in MetalLookAndFeel.java as above gives a quick lookup. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20482#discussion_r1720078073 From mvs at openjdk.org Fri Aug 16 17:13:53 2024 From: mvs at openjdk.org (Manukumar V S) Date: Fri, 16 Aug 2024 17:13:53 GMT Subject: RFR: 8338103: Stabilize and open source a Swing OGL ButtonResizeTest In-Reply-To: <8--CxVHS_jclzzN2PWYkI0W3yr7w1al5PSqRdis-PUc=.2f57c378-49cc-40bc-b042-f6aa9bfed07d@github.com> References: <8--CxVHS_jclzzN2PWYkI0W3yr7w1al5PSqRdis-PUc=.2f57c378-49cc-40bc-b042-f6aa9bfed07d@github.com> Message-ID: On Fri, 9 Aug 2024 18:45:18 GMT, Manukumar V S wrote: > This PR creates a new test by stabilising and open sourcing a closed test. > This test verifies that the OpenGL pipeline does not create artifacts with swing components after window is zoomed to maximum size and then resized back to normal. > This test is run twice, with and without the flags "-Dsun.java2d.opengl=True -Dsun.java2d.opengl.fbobject=false" . > > This is tested(15 times per platform) in all the available mach5 headful platforms and found to be stable. Any volunteers for a review?. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20532#issuecomment-2293864431 From mvs at openjdk.org Fri Aug 16 17:14:52 2024 From: mvs at openjdk.org (Manukumar V S) Date: Fri, 16 Aug 2024 17:14:52 GMT Subject: RFR: 8337886: java/awt/Frame/MaximizeUndecoratedTest.java fails in OEL due to a slight color difference [v2] In-Reply-To: <1vVV9gF1wPCRLSRL8G50nWrriNzIaFfmuRDhW19rUSA=.f2a24bb3-9574-402d-b346-ab31737be122@github.com> References: <2HljLuH3vumJyEMqhCWnGVnAWCJaMrbVbf0PgBO8ATg=.3bd94f6d-124b-4e4a-be15-ec319f552223@github.com> <1vVV9gF1wPCRLSRL8G50nWrriNzIaFfmuRDhW19rUSA=.f2a24bb3-9574-402d-b346-ab31737be122@github.com> Message-ID: <5CGDsIkId_sEVos84hS8ZlsBWXS-VtPdl5LWh5uJKdE=.f421120d-b2bd-45fd-aadc-dfc6370c772e@github.com> On Fri, 16 Aug 2024 07:36:01 GMT, Manukumar V S wrote: >> java/awt/Frame/MaximizeUndecoratedTest.java fails in OEL due to a slight color difference in the background color. This is currently reproduced only for Oracle Linux. >> >> The Color object I'm getting for each of these Point objects: >> new Point(maxBounds.x + OFFSET, maxBounds.y + OFFSET) --> java.awt.Color[r=0,g=255,b=0] >> new Point(maxBounds.width - OFFSET, maxBounds.y + OFFSET) --> java.awt.Color[r=0,g=207,b=0] >> new Point(maxBounds.width - OFFSET, maxBounds.height - OFFSET) --> java.awt.Color[r=0,g=255,b=0] >> new Point(maxBounds.x + OFFSET, maxBounds.height - OFFSET) --> java.awt.Color[r=0,g=255,b=0] >> >> So, the issue occurs for the second Point object --> new Point(maxBounds.width - OFFSET, maxBounds.y + OFFSET) - java.awt.Color[r=0,g=207,b=0] >> >> >> Fix: >> When the offset is increased from 2 to 5, it works fine in all the platforms. >> >> This test verifies whether the frame is maximised or not by checking its four border points(by comparing it's colour with GREEN). But in OEL, the top left and top right borders are curved, so there is a possibility of error if we directly compare those points with GREEN colour, that's why an OFFSET is needed. But an OFFSET of 2 is not sufficient for OEL, and for safety I will change it to 5. I don't see this issue in Ubuntu as the borders as rectangular there, but not curved. >> >> Testing: >> Tested using mach5 in all the available platforms and it works fine everywhere(results attached in bug). >> Tested manually in OEL 8 and 9(both x64 and aarch64) and it works fine there also. > > Manukumar V S has updated the pull request incrementally with one additional commit since the last revision: > > Changing the OFFSET to a safer value 5 Any volunteers for a review?. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20486#issuecomment-2293865497 From honkar at openjdk.org Fri Aug 16 17:31:48 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Fri, 16 Aug 2024 17:31:48 GMT Subject: RFR: 8332901: Choice/SelectCurrentItemTest/SelectCurrentItemTest.java doesn't open popup on macOS In-Reply-To: References: Message-ID: On Fri, 16 Aug 2024 14:11:27 GMT, Alexey Ivanov wrote: > I don't understand how using frame.setSize resolve the problem? Both pack and setSize call reshape to apply the new location and size. When the frame width and height is increased then the mouse is no longer a resize indicator which makes the 1st click (on the choice dropdown button) work but the 2nd click on the choice item needs to be adjusted accordingly. I believe frame.setResizable(false) or adding a panel as you suggested is a better and easier option. > We can modify this test to avoid JDK-8322653 Since there are already few tests problemlisted to track the external issue JDK-8322653, I think any of the above workarounds that you suggested can be added to avoid JDK-8322653. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20601#discussion_r1720121844 From honkar at openjdk.org Fri Aug 16 17:55:49 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Fri, 16 Aug 2024 17:55:49 GMT Subject: RFR: 8337886: java/awt/Frame/MaximizeUndecoratedTest.java fails in OEL due to a slight color difference [v2] In-Reply-To: <1vVV9gF1wPCRLSRL8G50nWrriNzIaFfmuRDhW19rUSA=.f2a24bb3-9574-402d-b346-ab31737be122@github.com> References: <2HljLuH3vumJyEMqhCWnGVnAWCJaMrbVbf0PgBO8ATg=.3bd94f6d-124b-4e4a-be15-ec319f552223@github.com> <1vVV9gF1wPCRLSRL8G50nWrriNzIaFfmuRDhW19rUSA=.f2a24bb3-9574-402d-b346-ab31737be122@github.com> Message-ID: On Fri, 16 Aug 2024 07:36:01 GMT, Manukumar V S wrote: >> java/awt/Frame/MaximizeUndecoratedTest.java fails in OEL due to a slight color difference in the background color. This is currently reproduced only for Oracle Linux. >> >> The Color object I'm getting for each of these Point objects: >> new Point(maxBounds.x + OFFSET, maxBounds.y + OFFSET) --> java.awt.Color[r=0,g=255,b=0] >> new Point(maxBounds.width - OFFSET, maxBounds.y + OFFSET) --> java.awt.Color[r=0,g=207,b=0] >> new Point(maxBounds.width - OFFSET, maxBounds.height - OFFSET) --> java.awt.Color[r=0,g=255,b=0] >> new Point(maxBounds.x + OFFSET, maxBounds.height - OFFSET) --> java.awt.Color[r=0,g=255,b=0] >> >> So, the issue occurs for the second Point object --> new Point(maxBounds.width - OFFSET, maxBounds.y + OFFSET) - java.awt.Color[r=0,g=207,b=0] >> >> >> Fix: >> When the offset is increased from 2 to 5, it works fine in all the platforms. >> >> This test verifies whether the frame is maximised or not by checking its four border points(by comparing it's colour with GREEN). But in OEL, the top left and top right borders are curved, so there is a possibility of error if we directly compare those points with GREEN colour, that's why an OFFSET is needed. But an OFFSET of 2 is not sufficient for OEL, and for safety I will change it to 5. I don't see this issue in Ubuntu as the borders as rectangular there, but not curved. >> >> Testing: >> Tested using mach5 in all the available platforms and it works fine everywhere(results attached in bug). >> Tested manually in OEL 8 and 9(both x64 and aarch64) and it works fine there also. > > Manukumar V S has updated the pull request incrementally with one additional commit since the last revision: > > Changing the OFFSET to a safer value 5 LGTM, please wait and check if the others have anything additional to add or clarify before integrating. ------------- Marked as reviewed by honkar (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20486#pullrequestreview-2243234199 From dnguyen at openjdk.org Fri Aug 16 18:49:48 2024 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 16 Aug 2024 18:49:48 GMT Subject: RFR: 8337886: java/awt/Frame/MaximizeUndecoratedTest.java fails in OEL due to a slight color difference [v2] In-Reply-To: <1vVV9gF1wPCRLSRL8G50nWrriNzIaFfmuRDhW19rUSA=.f2a24bb3-9574-402d-b346-ab31737be122@github.com> References: <2HljLuH3vumJyEMqhCWnGVnAWCJaMrbVbf0PgBO8ATg=.3bd94f6d-124b-4e4a-be15-ec319f552223@github.com> <1vVV9gF1wPCRLSRL8G50nWrriNzIaFfmuRDhW19rUSA=.f2a24bb3-9574-402d-b346-ab31737be122@github.com> Message-ID: On Fri, 16 Aug 2024 07:36:01 GMT, Manukumar V S wrote: >> java/awt/Frame/MaximizeUndecoratedTest.java fails in OEL due to a slight color difference in the background color. This is currently reproduced only for Oracle Linux. >> >> The Color object I'm getting for each of these Point objects: >> new Point(maxBounds.x + OFFSET, maxBounds.y + OFFSET) --> java.awt.Color[r=0,g=255,b=0] >> new Point(maxBounds.width - OFFSET, maxBounds.y + OFFSET) --> java.awt.Color[r=0,g=207,b=0] >> new Point(maxBounds.width - OFFSET, maxBounds.height - OFFSET) --> java.awt.Color[r=0,g=255,b=0] >> new Point(maxBounds.x + OFFSET, maxBounds.height - OFFSET) --> java.awt.Color[r=0,g=255,b=0] >> >> So, the issue occurs for the second Point object --> new Point(maxBounds.width - OFFSET, maxBounds.y + OFFSET) - java.awt.Color[r=0,g=207,b=0] >> >> >> Fix: >> When the offset is increased from 2 to 5, it works fine in all the platforms. >> >> This test verifies whether the frame is maximised or not by checking its four border points(by comparing it's colour with GREEN). But in OEL, the top left and top right borders are curved, so there is a possibility of error if we directly compare those points with GREEN colour, that's why an OFFSET is needed. But an OFFSET of 2 is not sufficient for OEL, and for safety I will change it to 5. I don't see this issue in Ubuntu as the borders as rectangular there, but not curved. >> >> Testing: >> Tested using mach5 in all the available platforms and it works fine everywhere(results attached in bug). >> Tested manually in OEL 8 and 9(both x64 and aarch64) and it works fine there also. > > Manukumar V S has updated the pull request incrementally with one additional commit since the last revision: > > Changing the OFFSET to a safer value 5 LGTM then. Thanks for some context ------------- Marked as reviewed by dnguyen (Committer). PR Review: https://git.openjdk.org/jdk/pull/20486#pullrequestreview-2243358613 From dnguyen at openjdk.org Fri Aug 16 18:56:25 2024 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 16 Aug 2024 18:56:25 GMT Subject: RFR: 8321140: Add comment to note difference in Metal's JButton margins [v3] In-Reply-To: References: Message-ID: <7cKNHa8y-HmCtElq-VhqJObt3xLt45-bmdGi-c9KIoQ=.09869e38-162e-4c44-84fa-135cd9cee5a3@github.com> > Previously in [JDK-8282772](https://bugs.openjdk.org/browse/JDK-8282772), there was a fix for JButtons with HTML content alignment for non-MacOS L&Fs. This fix was to make other L&Fs in line with the Aqua fix found in [JDK-8015854](https://bugs.openjdk.org/browse/JDK-8015854). > > However, the non-MacOS L&F fix caused a regression and the details and original discussion can be found in [JDK-8318590](https://bugs.openjdk.org/browse/JDK-8318590). This non-MacOS L&F fix was backed out and the current behavior for JButtons with HTML content for these L&Fs was deemed to be correct as is. > > Through discussion, a note about Metal's different margin values should be added somewhere for future reference. Metal's horizontal margins are 14 where other L&Fs are zero or some small value. This discrepancy is what caused the original issue to be filed. This change is to add a comment to `MetalLookAndFeel.java` since there is no exact spot where these values are set for the margin. It's been added where other Metal components (CheckBox, RadioButton, etc.) have comments on margins as well. > > Here are some L&F values for reference/comparison: > > Metal's margins: [top=2,left=14,bottom=2,right=14] > Aqua's margins: [top=0,left=2,bottom=0,right=2] > Motif's margins: [top=2,left=4,bottom=2,right=4] > Nimbus's margins: [top=0,left=0,bottom=0,right=0] Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: Notes in both LAFs ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20482/files - new: https://git.openjdk.org/jdk/pull/20482/files/e590b8dd..a16b29be Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20482&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20482&range=01-02 Stats: 50 lines in 2 files changed: 36 ins; 10 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/20482.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20482/head:pull/20482 PR: https://git.openjdk.org/jdk/pull/20482 From dnguyen at openjdk.org Fri Aug 16 18:56:25 2024 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 16 Aug 2024 18:56:25 GMT Subject: RFR: 8321140: Add comment to note difference in Metal's JButton margins [v3] In-Reply-To: References: Message-ID: On Fri, 16 Aug 2024 16:44:17 GMT, Harshitha Onkar wrote: >>> I moved it to `BasicLookAndFeel.java` since that's where the values are specifically defined. >> >> Perhaps, we need a note in *both files*. >> >> In `MetalLookAndFeel.java` to refer to `BasicLookAndFeel` where the margin is defined, similar to what's done for check boxes and radio button. >> >> And in `BasicLookAndFeel.java` to note that the above margins are vastly different from other L&Fs. >> >> What about this text? >> >> **`MetalLookAndFeel.java`** >> >> // default margin is (2, 14, 2, 14), defined in >> // BasicLookAndFeel via "Button.margin" UI property. >> >> >> **`BasicLookAndFeel.java`** >> >> // The above margin has vastly larger horizontal values when >> // compared to other look and feels that don't rely on these values > > I agree, adding a note at both places looks clearer. The additional note in MetalLookAndFeel.java as above gives a quick lookup. That does sound best. Added the notes to both areas as suggested. I still don't know how to not make the note in `MetalLookAndFeel.java` not feel like it's hanging, but I added the note to the same spot again. I think it's the most logical area. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20482#discussion_r1720213468 From azvegint at openjdk.org Fri Aug 16 19:16:52 2024 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Fri, 16 Aug 2024 19:16:52 GMT Subject: RFR: 8338488: Add screen capture for failure case In-Reply-To: References: Message-ID: On Fri, 16 Aug 2024 11:53:15 GMT, Tejesh R wrote: > open/test/jdk/java/awt/Checkbox/CheckboxCheckerScalingTest.java is failing intermittently on Linux (https://bugs.openjdk.org/browse/JDK-8338153). As part of analysis I've updated the test with image writing on failure condition. Marked as reviewed by azvegint (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20614#pullrequestreview-2243394676 From honkar at openjdk.org Fri Aug 16 19:18:48 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Fri, 16 Aug 2024 19:18:48 GMT Subject: RFR: 8321140: Add comment to note difference in Metal's JButton margins [v3] In-Reply-To: References: Message-ID: <7Mj3U7ahqKQI8VlnxK-1OCxf2wqQQwtVX5sj0Hqrc3w=.09e36976-4a15-4af8-ab5b-227cf7f5467a@github.com> On Fri, 16 Aug 2024 18:53:22 GMT, Damon Nguyen wrote: >> I agree, adding a note at both places looks clearer. The additional note in MetalLookAndFeel.java as above gives a quick lookup. > > That does sound best. Added the notes to both areas as suggested. I still don't know how to not make the note in `MetalLookAndFeel.java` not feel like it's hanging, but I added the note to the same spot again. I think it's the most logical area. LGTM, copyright years need to be updated for the files. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20482#discussion_r1720242318 From azvegint at openjdk.org Fri Aug 16 19:34:50 2024 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Fri, 16 Aug 2024 19:34:50 GMT Subject: RFR: 4795384: GTK+ JFileChooser buttons should have mnemonics In-Reply-To: References: Message-ID: On Fri, 16 Aug 2024 09:59:26 GMT, Abhishek Kumar wrote: > JFileChooser don't have the mnemonics for open and save button in GTK L&F. Fix is to add mnemonics for open and save button. > Fix can be verified by Swingset2 demo application. Mnemonics in GTK L&F are visible once alt key is pressed. > After running the SwingSet2 application, change the `L&F to GTK` and select` JFileChooser demo` from toolbar. Click on `Select Plain JFileChooser` button and then press alt key to verify the mnemonics. src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk.properties line 63: > 61: FileChooser.renameFileButton.textAndMnemonic=&Rename File > 62: FileChooser.cancelButton.textAndMnemonic=&Cancel > 63: FileChooser.saveButton.textAndMnemonic=Save Suggestion: FileChooser.saveButton.textAndMnemonic=&Save It looks like the Save button is the only button left in this file without a mnemonic specified. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20612#discussion_r1720266961 From azvegint at openjdk.org Fri Aug 16 19:47:50 2024 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Fri, 16 Aug 2024 19:47:50 GMT Subject: RFR: 4795384: GTK+ JFileChooser buttons should have mnemonics In-Reply-To: References: Message-ID: <5CkGHxkNcYb4iyx-nOuJ0S2hXL6_qKqTwS7ZYUL-wks=.e7be5fce-1892-40e4-945c-2983b6fad836@github.com> On Fri, 16 Aug 2024 19:32:09 GMT, Alexander Zvegintsev wrote: >> JFileChooser don't have the mnemonics for open and save button in GTK L&F. Fix is to add mnemonics for open and save button. >> Fix can be verified by Swingset2 demo application. Mnemonics in GTK L&F are visible once alt key is pressed. >> After running the SwingSet2 application, change the `L&F to GTK` and select` JFileChooser demo` from toolbar. Click on `Select Plain JFileChooser` button and then press alt key to verify the mnemonics. > > src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk.properties line 63: > >> 61: FileChooser.renameFileButton.textAndMnemonic=&Rename File >> 62: FileChooser.cancelButton.textAndMnemonic=&Cancel >> 63: FileChooser.saveButton.textAndMnemonic=Save > > Suggestion: > > FileChooser.saveButton.textAndMnemonic=&Save > > It looks like the Save button is the only button left in this file without a mnemonic specified. Hmm, the `&S` is already used by FileChooser.pathLabel.textAndMnemonic=&Selection: It looks like that `&S` is more common for the save action, so probably we might want to change the `&Selection:` to something else, e.g. `S&election:` Any thoughts? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20612#discussion_r1720283148 From serb at openjdk.org Fri Aug 16 23:27:48 2024 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 16 Aug 2024 23:27:48 GMT Subject: RFR: 4795384: GTK+ JFileChooser buttons should have mnemonics In-Reply-To: <5CkGHxkNcYb4iyx-nOuJ0S2hXL6_qKqTwS7ZYUL-wks=.e7be5fce-1892-40e4-945c-2983b6fad836@github.com> References: <5CkGHxkNcYb4iyx-nOuJ0S2hXL6_qKqTwS7ZYUL-wks=.e7be5fce-1892-40e4-945c-2983b6fad836@github.com> Message-ID: <77QiXoKfd2AEngI9nFXpQ6pbWLnlQGjDnIhzAIXsk6w=.00233562-5fb5-4b96-9c78-07c01b0702e6@github.com> On Fri, 16 Aug 2024 19:45:19 GMT, Alexander Zvegintsev wrote: >> src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk.properties line 63: >> >>> 61: FileChooser.renameFileButton.textAndMnemonic=&Rename File >>> 62: FileChooser.cancelButton.textAndMnemonic=&Cancel >>> 63: FileChooser.saveButton.textAndMnemonic=Save >> >> Suggestion: >> >> FileChooser.saveButton.textAndMnemonic=&Save >> >> It looks like the Save button is the only button left in this file without a mnemonic specified. > > Hmm, the `&S` is already used by > > FileChooser.pathLabel.textAndMnemonic=&Selection: > > > It looks like that `&S` is more common for the save action, so probably we might want to change the `&Selection:` to something else, e.g. `S&election:` > Any thoughts? mnemonics if gtk dialog were updated by the https://bugs.openjdk.org/browse/JDK-8080628, the save button was not changes since it is a default button in that dialog. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20612#discussion_r1720465815 From serb at openjdk.org Fri Aug 16 23:32:48 2024 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 16 Aug 2024 23:32:48 GMT Subject: RFR: 8337886: java/awt/Frame/MaximizeUndecoratedTest.java fails in OEL due to a slight color difference [v2] In-Reply-To: <1vVV9gF1wPCRLSRL8G50nWrriNzIaFfmuRDhW19rUSA=.f2a24bb3-9574-402d-b346-ab31737be122@github.com> References: <2HljLuH3vumJyEMqhCWnGVnAWCJaMrbVbf0PgBO8ATg=.3bd94f6d-124b-4e4a-be15-ec319f552223@github.com> <1vVV9gF1wPCRLSRL8G50nWrriNzIaFfmuRDhW19rUSA=.f2a24bb3-9574-402d-b346-ab31737be122@github.com> Message-ID: <_8yj8n0F5nfOLbDbNCfVgR24Ql56SilO7TMNgBWQNzc=.548e570a-9f79-4b3b-b4aa-6dcf640d90cf@github.com> On Fri, 16 Aug 2024 07:36:01 GMT, Manukumar V S wrote: >> java/awt/Frame/MaximizeUndecoratedTest.java fails in OEL due to a slight color difference in the background color. This is currently reproduced only for Oracle Linux. >> >> The Color object I'm getting for each of these Point objects: >> new Point(maxBounds.x + OFFSET, maxBounds.y + OFFSET) --> java.awt.Color[r=0,g=255,b=0] >> new Point(maxBounds.width - OFFSET, maxBounds.y + OFFSET) --> java.awt.Color[r=0,g=207,b=0] >> new Point(maxBounds.width - OFFSET, maxBounds.height - OFFSET) --> java.awt.Color[r=0,g=255,b=0] >> new Point(maxBounds.x + OFFSET, maxBounds.height - OFFSET) --> java.awt.Color[r=0,g=255,b=0] >> >> So, the issue occurs for the second Point object --> new Point(maxBounds.width - OFFSET, maxBounds.y + OFFSET) - java.awt.Color[r=0,g=207,b=0] >> >> >> Fix: >> When the offset is increased from 2 to 5, it works fine in all the platforms. >> >> This test verifies whether the frame is maximised or not by checking its four border points(by comparing it's colour with GREEN). But in OEL, the top left and top right borders are curved, so there is a possibility of error if we directly compare those points with GREEN colour, that's why an OFFSET is needed. But an OFFSET of 2 is not sufficient for OEL, and for safety I will change it to 5. I don't see this issue in Ubuntu as the borders as rectangular there, but not curved. >> >> Testing: >> Tested using mach5 in all the available platforms and it works fine everywhere(results attached in bug). >> Tested manually in OEL 8 and 9(both x64 and aarch64) and it works fine there also. > > Manukumar V S has updated the pull request incrementally with one additional commit since the last revision: > > Changing the OFFSET to a safer value 5 Marked as reviewed by serb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20486#pullrequestreview-2243743530 From serb at openjdk.org Fri Aug 16 23:39:51 2024 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 16 Aug 2024 23:39:51 GMT Subject: RFR: 6318027: BasicScrollBarUI does not disable timer when enclosing frame is disabled. [v4] In-Reply-To: References: Message-ID: <1Tooih61xLJcWjJjQPszzir7svE35su3SDDqT0qSNIs=.d2c53770-c719-4e6c-beda-bb40dda9c639@github.com> On Thu, 15 Aug 2024 07:26:28 GMT, Prasanta Sadhukhan wrote: >> Issue is >> BasicScrollBarUI.ArrowButtonListener starts a timer in mousePressed(), and stops it in mouseReleased(). If the frame containing the scrollbar is disabled between the MOUSE_PRESSED and the MOUSE_RELEASED events, the mouseReleased() method is never called. If the frame is then re-enabled, the still-running timer causes it to scroll all the way to the end. >> Fix is to check if [ArrowButtonListener.handledEvent](https://github.com/openjdk/jdk/blame/ee839b7f0ebe471d3877cddd2c87019ccb8ee5ae/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicScrollBarUI.java#L1567) is still set when ActionEvent is processed then stop the timer and reset this variable. >> >> CI testing is green and also SwingSet2 JScrollPane scrolling with this modification.. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Stop the timer if frame is disabled >BasicScrollBarUI.ArrowButtonListener starts a timer in mousePressed(), and stops it in mouseReleased(). If the frame containing the scrollbar is disabled between the MOUSE_PRESSED and the MOUSE_RELEASED events, the mouseReleased() method is never called. If What happens if you make the scrollbar invisible in this case? src/java.desktop/share/classes/javax/swing/plaf/basic/BasicScrollBarUI.java line 1618: > 1616: if (parent instanceof javax.swing.JFrame par) { > 1617: if (!par.isEnabled()) { > 1618: ((Timer)e.getSource()).stop(); Is the "TImer" always the source for the event? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20346#issuecomment-2294449988 PR Review Comment: https://git.openjdk.org/jdk/pull/20346#discussion_r1720473148 From serb at openjdk.org Sat Aug 17 00:01:55 2024 From: serb at openjdk.org (Sergey Bylokhov) Date: Sat, 17 Aug 2024 00:01:55 GMT Subject: RFR: 8334495: Use FFM instead of jdk.internal.misc.Unsafe in java.desktop font implementation [v2] In-Reply-To: References: Message-ID: <2V3a53u5VH98OAQPDdDzggxiIIrAg_RCvWLBq6mugTE=.ad02d172-4f0a-462e-bfdf-1ca8617f5987@github.com> On Wed, 17 Jul 2024 21:23:10 GMT, Phil Race wrote: > NB those times (124ms and 178 ms ) include the execution time for layout as well, > but the difference is what matters to answer this question and it is answered as expected. This is a good news! ------------- PR Comment: https://git.openjdk.org/jdk/pull/19777#issuecomment-2294461097 From serb at openjdk.org Sat Aug 17 00:59:03 2024 From: serb at openjdk.org (Sergey Bylokhov) Date: Sat, 17 Aug 2024 00:59:03 GMT Subject: RFR: 8336873: BasicSplitPaneDivider:oneTouchExpandableChanged() should mention that implementation depends on SplitPane.supportsOneTouchButtons property [v2] In-Reply-To: References: <4kkRV1pcjLKt4xgPWGrVfa0xTNHjjeEDEbp0e_buI7Q=.12d41a38-3f53-4dc3-b26a-9b265f0f54b3@github.com> <_qclrQho-hPrq6qT8ix-DEMP5I8pAFMKaSlBPdsfNyg=.6f817935-f665-44f3-b84d-5c764c32dea1@github.com> Message-ID: On Tue, 30 Jul 2024 03:16:27 GMT, Prasanta Sadhukhan wrote: >> I was pointing out a spelling mistake. Nothing more. > > ok..fixed.. Look like is not fixed yet? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20289#discussion_r1720494106 From duke at openjdk.org Sat Aug 17 03:21:55 2024 From: duke at openjdk.org (duke) Date: Sat, 17 Aug 2024 03:21:55 GMT Subject: RFR: 8337886: java/awt/Frame/MaximizeUndecoratedTest.java fails in OEL due to a slight color difference [v2] In-Reply-To: <1vVV9gF1wPCRLSRL8G50nWrriNzIaFfmuRDhW19rUSA=.f2a24bb3-9574-402d-b346-ab31737be122@github.com> References: <2HljLuH3vumJyEMqhCWnGVnAWCJaMrbVbf0PgBO8ATg=.3bd94f6d-124b-4e4a-be15-ec319f552223@github.com> <1vVV9gF1wPCRLSRL8G50nWrriNzIaFfmuRDhW19rUSA=.f2a24bb3-9574-402d-b346-ab31737be122@github.com> Message-ID: On Fri, 16 Aug 2024 07:36:01 GMT, Manukumar V S wrote: >> java/awt/Frame/MaximizeUndecoratedTest.java fails in OEL due to a slight color difference in the background color. This is currently reproduced only for Oracle Linux. >> >> The Color object I'm getting for each of these Point objects: >> new Point(maxBounds.x + OFFSET, maxBounds.y + OFFSET) --> java.awt.Color[r=0,g=255,b=0] >> new Point(maxBounds.width - OFFSET, maxBounds.y + OFFSET) --> java.awt.Color[r=0,g=207,b=0] >> new Point(maxBounds.width - OFFSET, maxBounds.height - OFFSET) --> java.awt.Color[r=0,g=255,b=0] >> new Point(maxBounds.x + OFFSET, maxBounds.height - OFFSET) --> java.awt.Color[r=0,g=255,b=0] >> >> So, the issue occurs for the second Point object --> new Point(maxBounds.width - OFFSET, maxBounds.y + OFFSET) - java.awt.Color[r=0,g=207,b=0] >> >> >> Fix: >> When the offset is increased from 2 to 5, it works fine in all the platforms. >> >> This test verifies whether the frame is maximised or not by checking its four border points(by comparing it's colour with GREEN). But in OEL, the top left and top right borders are curved, so there is a possibility of error if we directly compare those points with GREEN colour, that's why an OFFSET is needed. But an OFFSET of 2 is not sufficient for OEL, and for safety I will change it to 5. I don't see this issue in Ubuntu as the borders as rectangular there, but not curved. >> >> Testing: >> Tested using mach5 in all the available platforms and it works fine everywhere(results attached in bug). >> Tested manually in OEL 8 and 9(both x64 and aarch64) and it works fine there also. > > Manukumar V S has updated the pull request incrementally with one additional commit since the last revision: > > Changing the OFFSET to a safer value 5 @manukumarvs Your change (at version 26a74acbcb8e7cc5fac38a77df3c6c51642115a9) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20486#issuecomment-2294604152 From mvs at openjdk.org Sun Aug 18 01:56:03 2024 From: mvs at openjdk.org (Manukumar V S) Date: Sun, 18 Aug 2024 01:56:03 GMT Subject: RFR: 8337886: java/awt/Frame/MaximizeUndecoratedTest.java fails in OEL due to a slight color difference [v2] In-Reply-To: <1vVV9gF1wPCRLSRL8G50nWrriNzIaFfmuRDhW19rUSA=.f2a24bb3-9574-402d-b346-ab31737be122@github.com> References: <2HljLuH3vumJyEMqhCWnGVnAWCJaMrbVbf0PgBO8ATg=.3bd94f6d-124b-4e4a-be15-ec319f552223@github.com> <1vVV9gF1wPCRLSRL8G50nWrriNzIaFfmuRDhW19rUSA=.f2a24bb3-9574-402d-b346-ab31737be122@github.com> Message-ID: On Fri, 16 Aug 2024 07:36:01 GMT, Manukumar V S wrote: >> java/awt/Frame/MaximizeUndecoratedTest.java fails in OEL due to a slight color difference in the background color. This is currently reproduced only for Oracle Linux. >> >> The Color object I'm getting for each of these Point objects: >> new Point(maxBounds.x + OFFSET, maxBounds.y + OFFSET) --> java.awt.Color[r=0,g=255,b=0] >> new Point(maxBounds.width - OFFSET, maxBounds.y + OFFSET) --> java.awt.Color[r=0,g=207,b=0] >> new Point(maxBounds.width - OFFSET, maxBounds.height - OFFSET) --> java.awt.Color[r=0,g=255,b=0] >> new Point(maxBounds.x + OFFSET, maxBounds.height - OFFSET) --> java.awt.Color[r=0,g=255,b=0] >> >> So, the issue occurs for the second Point object --> new Point(maxBounds.width - OFFSET, maxBounds.y + OFFSET) - java.awt.Color[r=0,g=207,b=0] >> >> >> Fix: >> When the offset is increased from 2 to 5, it works fine in all the platforms. >> >> This test verifies whether the frame is maximised or not by checking its four border points(by comparing it's colour with GREEN). But in OEL, the top left and top right borders are curved, so there is a possibility of error if we directly compare those points with GREEN colour, that's why an OFFSET is needed. But an OFFSET of 2 is not sufficient for OEL, and for safety I will change it to 5. I don't see this issue in Ubuntu as the borders as rectangular there, but not curved. >> >> Testing: >> Tested using mach5 in all the available platforms and it works fine everywhere(results attached in bug). >> Tested manually in OEL 8 and 9(both x64 and aarch64) and it works fine there also. > > Manukumar V S has updated the pull request incrementally with one additional commit since the last revision: > > Changing the OFFSET to a safer value 5 Any sponsors? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20486#issuecomment-2295058834 From duke at openjdk.org Mon Aug 19 01:28:20 2024 From: duke at openjdk.org (toshiogata) Date: Mon, 19 Aug 2024 01:28:20 GMT Subject: RFR: 8337851: Some tests have name which confuse jtreg [v3] In-Reply-To: References: Message-ID: > Rename the tests to prevent unexpected deletion of result files when `-retain` jtreg option is specified. > Testing: modified tests toshiogata has updated the pull request incrementally with one additional commit since the last revision: Revert "Move jtreg tags and expand wildcard imports" This reverts commit 9b30df1230b7e31b42e63ae01ef1549565bcc078. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20475/files - new: https://git.openjdk.org/jdk/pull/20475/files/9b30df12..b1b2b5fe Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20475&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20475&range=01-02 Stats: 11 lines in 2 files changed: 4 ins; 6 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20475.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20475/head:pull/20475 PR: https://git.openjdk.org/jdk/pull/20475 From duke at openjdk.org Mon Aug 19 01:39:54 2024 From: duke at openjdk.org (toshiogata) Date: Mon, 19 Aug 2024 01:39:54 GMT Subject: RFR: 8337851: Some tests have name which confuse jtreg [v3] In-Reply-To: References: <9Ohvnc6MgnokscABDpbRhBYuXtjguHrcJd7eVRWSXYs=.cd938d32-de8b-4eb1-a601-421762f991f3@github.com> Message-ID: On Fri, 16 Aug 2024 11:40:20 GMT, Alexey Ivanov wrote: >> As you mentioned, it's a good time to make a minor improvement, so I modified the test. > > I propose not to edit the renamed files. > > First of all, the purpose of this PR is to *rename tests* to workaround a _misfeature_ of jtreg. > > Git does not support renames natively, therefore by editing the renamed files you could break Git ability to detect renaming. > > Additionally, these tests are not part of client and I am not aware of the practices in Java Compiler team. Expanding wildcard imports should be fine, yet I would rather avoid editing the renamed files as I mentioned above. Thank you for pointing it out. I was not aware of the git rename issue. I changed the fix to only rename files. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20475#discussion_r1721122162 From duke at openjdk.org Mon Aug 19 01:39:55 2024 From: duke at openjdk.org (toshiogata) Date: Mon, 19 Aug 2024 01:39:55 GMT Subject: RFR: 8337851: Some tests have name which confuse jtreg [v3] In-Reply-To: References: <9Ohvnc6MgnokscABDpbRhBYuXtjguHrcJd7eVRWSXYs=.cd938d32-de8b-4eb1-a601-421762f991f3@github.com> Message-ID: On Fri, 16 Aug 2024 01:02:17 GMT, toshiogata wrote: >> test/langtools/tools/javac/warnings/Serial/Serial.java line 1: >> >>> 1: /* >> >> move jtreg tags below imports and add copyrights > > The copyright has been intentionally omitted as explained in https://bugs.openjdk.org/browse/JDK-8258525 > I moved the jtreg tag. For the reason aivanov-jdk commented, I would like to only rename files in this PR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20475#discussion_r1721122202 From duke at openjdk.org Mon Aug 19 01:52:54 2024 From: duke at openjdk.org (toshiogata) Date: Mon, 19 Aug 2024 01:52:54 GMT Subject: RFR: 8337851: Some tests have name which confuse jtreg [v2] In-Reply-To: References: Message-ID: On Fri, 16 Aug 2024 11:43:05 GMT, Alexey Ivanov wrote: >> toshiogata has updated the pull request incrementally with one additional commit since the last revision: >> >> Move jtreg tags and expand wildcard imports > > I suggest not to edit the files and only *rename them* as it was in the first iteration of the review. @aivanov-jdk I agree with you. I changed the fix to only rename files. @alisenchung As aivanov-jdk commented, I would like to hold off on implementing your suggestion for refactoring in this PR. Please check the disucssion. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20475#issuecomment-2295519130 From psadhukhan at openjdk.org Mon Aug 19 02:13:54 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 19 Aug 2024 02:13:54 GMT Subject: RFR: 8336873: BasicSplitPaneDivider:oneTouchExpandableChanged() should mention that implementation depends on SplitPane.supportsOneTouchButtons property [v2] In-Reply-To: References: <4kkRV1pcjLKt4xgPWGrVfa0xTNHjjeEDEbp0e_buI7Q=.12d41a38-3f53-4dc3-b26a-9b265f0f54b3@github.com> <_qclrQho-hPrq6qT8ix-DEMP5I8pAFMKaSlBPdsfNyg=.6f817935-f665-44f3-b84d-5c764c32dea1@github.com> Message-ID: On Sat, 17 Aug 2024 00:55:50 GMT, Sergey Bylokhov wrote: >> ok..fixed.. > > Look like is not fixed yet? Spelling mistake "Tocuh" is fixed...Do you see more? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20289#discussion_r1721137908 From psadhukhan at openjdk.org Mon Aug 19 02:25:29 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 19 Aug 2024 02:25:29 GMT Subject: RFR: 6318027: BasicScrollBarUI does not disable timer when enclosing frame is disabled. [v5] In-Reply-To: References: Message-ID: > Issue is > BasicScrollBarUI.ArrowButtonListener starts a timer in mousePressed(), and stops it in mouseReleased(). If the frame containing the scrollbar is disabled between the MOUSE_PRESSED and the MOUSE_RELEASED events, the mouseReleased() method is never called. If the frame is then re-enabled, the still-running timer causes it to scroll all the way to the end. > Fix is to check if [ArrowButtonListener.handledEvent](https://github.com/openjdk/jdk/blame/ee839b7f0ebe471d3877cddd2c87019ccb8ee5ae/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicScrollBarUI.java#L1567) is still set when ActionEvent is processed then stop the timer and reset this variable. > > CI testing is green and also SwingSet2 JScrollPane scrolling with this modification.. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: test typo ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20346/files - new: https://git.openjdk.org/jdk/pull/20346/files/526c6a17..de7ad6b7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20346&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20346&range=03-04 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20346.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20346/head:pull/20346 PR: https://git.openjdk.org/jdk/pull/20346 From psadhukhan at openjdk.org Mon Aug 19 02:32:58 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 19 Aug 2024 02:32:58 GMT Subject: RFR: 6318027: BasicScrollBarUI does not disable timer when enclosing frame is disabled. [v4] In-Reply-To: <1Tooih61xLJcWjJjQPszzir7svE35su3SDDqT0qSNIs=.d2c53770-c719-4e6c-beda-bb40dda9c639@github.com> References: <1Tooih61xLJcWjJjQPszzir7svE35su3SDDqT0qSNIs=.d2c53770-c719-4e6c-beda-bb40dda9c639@github.com> Message-ID: On Fri, 16 Aug 2024 23:36:46 GMT, Sergey Bylokhov wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: >> >> Stop the timer if frame is disabled > > src/java.desktop/share/classes/javax/swing/plaf/basic/BasicScrollBarUI.java line 1618: > >> 1616: if (parent instanceof javax.swing.JFrame par) { >> 1617: if (!par.isEnabled()) { >> 1618: ((Timer)e.getSource()).stop(); > > Is the "TImer" always the source for the event? Yes, the method employs same way to stop the timer in other cases too.. Also, if the scrollbar is made invisible and then visible instead of frame, it doesn't scroll to the end and behaves as expected.. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20346#discussion_r1721146970 From duke at openjdk.org Mon Aug 19 04:18:53 2024 From: duke at openjdk.org (duke) Date: Mon, 19 Aug 2024 04:18:53 GMT Subject: RFR: 8290501 : Typo in javax.swing.BoundedRangeModel documentation [v3] In-Reply-To: References: Message-ID: On Fri, 16 Aug 2024 10:00:22 GMT, Renjith Kannath Pariyangad wrote: >> Documentation updated > > Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision: > > Updated import @Renjithkannath Your change (at version 097976f04b9da29a23e144823c0ecdb868df8143) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20465#issuecomment-2295635531 From abhiscxk at openjdk.org Mon Aug 19 05:18:48 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Mon, 19 Aug 2024 05:18:48 GMT Subject: RFR: 4795384: GTK+ JFileChooser buttons should have mnemonics In-Reply-To: References: Message-ID: On Fri, 16 Aug 2024 12:15:44 GMT, Tejesh R wrote: > Adding a test for this fix would be better, I guess....... I don't think it is required as we have SwingSet2 demo to test. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20612#issuecomment-2295687349 From abhiscxk at openjdk.org Mon Aug 19 06:24:48 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Mon, 19 Aug 2024 06:24:48 GMT Subject: RFR: 4795384: GTK+ JFileChooser buttons should have mnemonics In-Reply-To: <77QiXoKfd2AEngI9nFXpQ6pbWLnlQGjDnIhzAIXsk6w=.00233562-5fb5-4b96-9c78-07c01b0702e6@github.com> References: <5CkGHxkNcYb4iyx-nOuJ0S2hXL6_qKqTwS7ZYUL-wks=.e7be5fce-1892-40e4-945c-2983b6fad836@github.com> <77QiXoKfd2AEngI9nFXpQ6pbWLnlQGjDnIhzAIXsk6w=.00233562-5fb5-4b96-9c78-07c01b0702e6@github.com> Message-ID: On Fri, 16 Aug 2024 23:25:32 GMT, Sergey Bylokhov wrote: > mnemonics if gtk dialog were updated by the https://bugs.openjdk.org/browse/JDK-8080628, the save button was not changes since it is a default button in that dialog. Seems like the fix is to remove mnemonics for Metal Look and Feel. Mnemonics for Open, Save and Cancel buttons are present on native side (checked with gedit application on ubuntu 22.04). So, I think mnemonics for Save button should also be there in GTK L&F. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20612#discussion_r1721263942 From abhiscxk at openjdk.org Mon Aug 19 06:24:49 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Mon, 19 Aug 2024 06:24:49 GMT Subject: RFR: 4795384: GTK+ JFileChooser buttons should have mnemonics In-Reply-To: References: <5CkGHxkNcYb4iyx-nOuJ0S2hXL6_qKqTwS7ZYUL-wks=.e7be5fce-1892-40e4-945c-2983b6fad836@github.com> <77QiXoKfd2AEngI9nFXpQ6pbWLnlQGjDnIhzAIXsk6w=.00233562-5fb5-4b96-9c78-07c01b0702e6@github.com> Message-ID: On Mon, 19 Aug 2024 06:20:13 GMT, Abhishek Kumar wrote: >> mnemonics if gtk dialog were updated by the https://bugs.openjdk.org/browse/JDK-8080628, the save button was not changes since it is a default button in that dialog. > >> mnemonics if gtk dialog were updated by the https://bugs.openjdk.org/browse/JDK-8080628, the save button was not changes since it is a default button in that dialog. > > Seems like the fix is to remove mnemonics for Metal Look and Feel. > Mnemonics for Open, Save and Cancel buttons are present on native side (checked with gedit application on ubuntu 22.04). So, I think mnemonics for Save button should also be there in GTK L&F. > Hmm, the `&S` is already used by > > ``` > FileChooser.pathLabel.textAndMnemonic=&Selection: > ``` > > It looks like that `&S` is more common for the save action, so probably we might want to change the `&Selection:` to something else, e.g. `S&election:` Any thoughts? Checked in native side and `&S` is the mnemonics for Save button. So, I think it's right to have `&S` as mnemonics for `Save` and as you suggested `&e` for `Selection`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20612#discussion_r1721265040 From tr at openjdk.org Mon Aug 19 06:45:53 2024 From: tr at openjdk.org (Tejesh R) Date: Mon, 19 Aug 2024 06:45:53 GMT Subject: Integrated: 8338488: Add screen capture for failure case In-Reply-To: References: Message-ID: On Fri, 16 Aug 2024 11:53:15 GMT, Tejesh R wrote: > open/test/jdk/java/awt/Checkbox/CheckboxCheckerScalingTest.java is failing intermittently on Linux (https://bugs.openjdk.org/browse/JDK-8338153). As part of analysis I've updated the test with image writing on failure condition. This pull request has now been integrated. Changeset: 56a007dd Author: Tejesh R URL: https://git.openjdk.org/jdk/commit/56a007dd32061695d7bb0faf47e1793728e86c88 Stats: 10 lines in 1 file changed: 10 ins; 0 del; 0 mod 8338488: Add screen capture for failure case Reviewed-by: azvegint ------------- PR: https://git.openjdk.org/jdk/pull/20614 From tr at openjdk.org Mon Aug 19 06:48:59 2024 From: tr at openjdk.org (Tejesh R) Date: Mon, 19 Aug 2024 06:48:59 GMT Subject: RFR: 4795384: GTK+ JFileChooser buttons should have mnemonics In-Reply-To: References: Message-ID: On Mon, 19 Aug 2024 05:16:09 GMT, Abhishek Kumar wrote: > > Adding a test for this fix would be better, I guess....... > > I don't think it is required as we have SwingSet2 demo to test. It might be required to map a fix to a test, else only the fix exists....... ------------- PR Comment: https://git.openjdk.org/jdk/pull/20612#issuecomment-2295786448 From mvs at openjdk.org Mon Aug 19 07:19:56 2024 From: mvs at openjdk.org (Manukumar V S) Date: Mon, 19 Aug 2024 07:19:56 GMT Subject: Integrated: 8337886: java/awt/Frame/MaximizeUndecoratedTest.java fails in OEL due to a slight color difference In-Reply-To: <2HljLuH3vumJyEMqhCWnGVnAWCJaMrbVbf0PgBO8ATg=.3bd94f6d-124b-4e4a-be15-ec319f552223@github.com> References: <2HljLuH3vumJyEMqhCWnGVnAWCJaMrbVbf0PgBO8ATg=.3bd94f6d-124b-4e4a-be15-ec319f552223@github.com> Message-ID: On Wed, 7 Aug 2024 06:55:30 GMT, Manukumar V S wrote: > java/awt/Frame/MaximizeUndecoratedTest.java fails in OEL due to a slight color difference in the background color. This is currently reproduced only for Oracle Linux. > > The Color object I'm getting for each of these Point objects: > new Point(maxBounds.x + OFFSET, maxBounds.y + OFFSET) --> java.awt.Color[r=0,g=255,b=0] > new Point(maxBounds.width - OFFSET, maxBounds.y + OFFSET) --> java.awt.Color[r=0,g=207,b=0] > new Point(maxBounds.width - OFFSET, maxBounds.height - OFFSET) --> java.awt.Color[r=0,g=255,b=0] > new Point(maxBounds.x + OFFSET, maxBounds.height - OFFSET) --> java.awt.Color[r=0,g=255,b=0] > > So, the issue occurs for the second Point object --> new Point(maxBounds.width - OFFSET, maxBounds.y + OFFSET) - java.awt.Color[r=0,g=207,b=0] > > > Fix: > When the offset is increased from 2 to 5, it works fine in all the platforms. > > This test verifies whether the frame is maximised or not by checking its four border points(by comparing it's colour with GREEN). But in OEL, the top left and top right borders are curved, so there is a possibility of error if we directly compare those points with GREEN colour, that's why an OFFSET is needed. But an OFFSET of 2 is not sufficient for OEL, and for safety I will change it to 5. I don't see this issue in Ubuntu as the borders as rectangular there, but not curved. > > Testing: > Tested using mach5 in all the available platforms and it works fine everywhere(results attached in bug). > Tested manually in OEL 8 and 9(both x64 and aarch64) and it works fine there also. This pull request has now been integrated. Changeset: 15b20cb1 Author: Manukumar V S Committer: Tejesh R URL: https://git.openjdk.org/jdk/commit/15b20cb1fd18b849e49c175737dd3826c8d0ceff Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8337886: java/awt/Frame/MaximizeUndecoratedTest.java fails in OEL due to a slight color difference Reviewed-by: dnguyen, honkar, serb ------------- PR: https://git.openjdk.org/jdk/pull/20486 From abhiscxk at openjdk.org Mon Aug 19 07:24:50 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Mon, 19 Aug 2024 07:24:50 GMT Subject: RFR: 4795384: GTK+ JFileChooser buttons should have mnemonics In-Reply-To: References: Message-ID: On Mon, 19 Aug 2024 06:45:59 GMT, Tejesh R wrote: > It might be required to map a fix to a test, else only the fix exists....... Yeah, the fix is straight-forward and can be verified easily with SwingSet2 demo. So, individual test is not needed. I guess there are such cased where there is no separate test case added and SwingSet2 demo is used. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20612#issuecomment-2295844554 From tr at openjdk.org Mon Aug 19 07:31:50 2024 From: tr at openjdk.org (Tejesh R) Date: Mon, 19 Aug 2024 07:31:50 GMT Subject: RFR: 8338103: Stabilize and open source a Swing OGL ButtonResizeTest In-Reply-To: <8--CxVHS_jclzzN2PWYkI0W3yr7w1al5PSqRdis-PUc=.2f57c378-49cc-40bc-b042-f6aa9bfed07d@github.com> References: <8--CxVHS_jclzzN2PWYkI0W3yr7w1al5PSqRdis-PUc=.2f57c378-49cc-40bc-b042-f6aa9bfed07d@github.com> Message-ID: On Fri, 9 Aug 2024 18:45:18 GMT, Manukumar V S wrote: > This PR creates a new test by stabilising and open sourcing a closed test. > This test verifies that the OpenGL pipeline does not create artifacts with swing components after window is zoomed to maximum size and then resized back to normal. > This test is run twice, with and without the flags "-Dsun.java2d.opengl=True -Dsun.java2d.opengl.fbobject=false" . > > This is tested(15 times per platform) in all the available mach5 headful platforms and found to be stable. The test is failing on my windows machine with an error - _java.lang.RuntimeException: Button renderings are different after window resize, num of Diff Pixels=1576_ Images are uploaded for reference. ![image1](https://github.com/user-attachments/assets/349f9300-25ba-4402-9668-d9e89321b23c) ![image2](https://github.com/user-attachments/assets/c25fb95e-1f80-4762-9388-1b799a0184e8) ------------- PR Review: https://git.openjdk.org/jdk/pull/20532#pullrequestreview-2244799430 From abhiscxk at openjdk.org Mon Aug 19 07:32:26 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Mon, 19 Aug 2024 07:32:26 GMT Subject: RFR: 4795384: GTK+ JFileChooser buttons should have mnemonics [v2] In-Reply-To: References: Message-ID: > JFileChooser don't have the mnemonics for open and save button in GTK L&F. Fix is to add mnemonics for open and save button. > Fix can be verified by Swingset2 demo application. Mnemonics in GTK L&F are visible once alt key is pressed. > After running the SwingSet2 application, change the `L&F to GTK` and select` JFileChooser demo` from toolbar. Click on `Select Plain JFileChooser` button and then press alt key to verify the mnemonics. Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: Add mnemonics for Save and change Selection mnemonics ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20612/files - new: https://git.openjdk.org/jdk/pull/20612/files/5d16dea9..30435f66 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20612&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20612&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20612.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20612/head:pull/20612 PR: https://git.openjdk.org/jdk/pull/20612 From tr at openjdk.org Mon Aug 19 07:32:26 2024 From: tr at openjdk.org (Tejesh R) Date: Mon, 19 Aug 2024 07:32:26 GMT Subject: RFR: 4795384: GTK+ JFileChooser buttons should have mnemonics In-Reply-To: References: Message-ID: On Mon, 19 Aug 2024 07:22:39 GMT, Abhishek Kumar wrote: > > It might be required to map a fix to a test, else only the fix exists....... > > Yeah, the fix is straight-forward and can be verified easily with SwingSet2 demo. So, individual test is not needed. I guess there are such cased where there is no separate test case added and SwingSet2 demo is used. Yeah, not a mandate though. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20612#issuecomment-2295855854 From mvs at openjdk.org Mon Aug 19 09:01:53 2024 From: mvs at openjdk.org (Manukumar V S) Date: Mon, 19 Aug 2024 09:01:53 GMT Subject: RFR: 8338103: Stabilize and open source a Swing OGL ButtonResizeTest In-Reply-To: <8--CxVHS_jclzzN2PWYkI0W3yr7w1al5PSqRdis-PUc=.2f57c378-49cc-40bc-b042-f6aa9bfed07d@github.com> References: <8--CxVHS_jclzzN2PWYkI0W3yr7w1al5PSqRdis-PUc=.2f57c378-49cc-40bc-b042-f6aa9bfed07d@github.com> Message-ID: On Fri, 9 Aug 2024 18:45:18 GMT, Manukumar V S wrote: > This PR creates a new test by stabilising and open sourcing a closed test. > This test verifies that the OpenGL pipeline does not create artifacts with swing components after window is zoomed to maximum size and then resized back to normal. > This test is run twice, with and without the flags "-Dsun.java2d.opengl=True -Dsun.java2d.opengl.fbobject=false" . > > This is tested(15 times per platform) in all the available mach5 headful platforms and found to be stable. > The test is failing on my windows machine with an error - _java.lang.RuntimeException: Button renderings are different after window resize, num of Diff Pixels=1576_ Images are uploaded for reference. > > ![image1](https://private-user-images.githubusercontent.com/94159358/359016384-349f9300-25ba-4402-9668-d9e89321b23c.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjQwNTgwMzEsIm5iZiI6MTcyNDA1NzczMSwicGF0aCI6Ii85NDE1OTM1OC8zNTkwMTYzODQtMzQ5ZjkzMDAtMjViYS00NDAyLTk2NjgtZDllODkzMjFiMjNjLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNDA4MTklMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjQwODE5VDA4NTUzMVomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTVlYmY4MzNkZGJiMjY0MDUzN2Q0YzNhNzllZGUxOTU4OWY4ZjBiMDBhM2Y1YzI0OTFmYTdlYmQ5MzVjN2Q2NzMmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JmFjdG9yX2lkPTAma2V5X2lkPTAmcmVwb19pZD0wIn0.pgGc3C1vDtfnl_Zqx6wDFW7jkzsC-AjfGYdRTK3Op-s) ![image2](https://private-user-images.githubusercontent.com/94159358/359016448-c25fb95e-1f80-4762-9388-1b799a0184e8.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc 3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjQwNTgwMzEsIm5iZiI6MTcyNDA1NzczMSwicGF0aCI6Ii85NDE1OTM1OC8zNTkwMTY0NDgtYzI1ZmI5NWUtMWY4MC00NzYyLTkzODgtMWI3OTlhMDE4NGU4LnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNDA4MTklMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjQwODE5VDA4NTUzMVomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTNiZGU1MDRhZjZmNzViNzk3YjQ0MzkxMDJiZDIxZDJlN2FkZjk3MDU5NTA4NDE4N2RkOWMwMDY5MzI2MDY2ZTMmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JmFjdG9yX2lkPTAma2V5X2lkPTAmcmVwb19pZD0wIn0.8rwB9KPKg3Hpi_diZ7Rrm7BLbsVocU9j6Dn1F8j0mUM) @TejeshR13 I have run it multiple times on different windows machines(Windows 2022, 10, 11) in mach5 and it passed everywhere and visibly I don't see any differences in the images attached by you. Can you try with the updated test which is attached to the bug(it will generate two diff images if the test fails), so that we will come to know what exactly is the difference between the images. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20532#issuecomment-2296041767 From psadhukhan at openjdk.org Mon Aug 19 09:04:51 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 19 Aug 2024 09:04:51 GMT Subject: RFR: 4795384: GTK+ JFileChooser buttons should have mnemonics [v2] In-Reply-To: References: <5CkGHxkNcYb4iyx-nOuJ0S2hXL6_qKqTwS7ZYUL-wks=.e7be5fce-1892-40e4-945c-2983b6fad836@github.com> <77QiXoKfd2AEngI9nFXpQ6pbWLnlQGjDnIhzAIXsk6w=.00233562-5fb5-4b96-9c78-07c01b0702e6@github.com> Message-ID: On Mon, 19 Aug 2024 06:21:47 GMT, Abhishek Kumar wrote: >>> mnemonics if gtk dialog were updated by the https://bugs.openjdk.org/browse/JDK-8080628, the save button was not changes since it is a default button in that dialog. >> >> Seems like the fix is to remove mnemonics for Metal Look and Feel. >> Mnemonics for Open, Save and Cancel buttons are present on native side (checked with gedit application on ubuntu 22.04). So, I think mnemonics for Save button should also be there in GTK L&F. > >> Hmm, the `&S` is already used by >> >> ``` >> FileChooser.pathLabel.textAndMnemonic=&Selection: >> ``` >> >> It looks like that `&S` is more common for the save action, so probably we might want to change the `&Selection:` to something else, e.g. `S&election:` Any thoughts? > > Checked in native side and `&S` is the mnemonics for Save button. So, I think it's right to have `&S` as mnemonics for `Save` and as you suggested `&e` for `Selection`. JDK-8080628 removes these Save and Open mnemonics from gtk and it does from all locales, not only the default locale, I guess for some customer escalation, so it needs to be verified with the fix author if it will regress the expectation. If you want to reinstate the mnemonics, then I guess it needs to be reinstated for all locales gtk_de.properties, gtk_es.properties, gtk_fr.properties etc simultaneously ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20612#discussion_r1721450408 From tr at openjdk.org Mon Aug 19 09:22:50 2024 From: tr at openjdk.org (Tejesh R) Date: Mon, 19 Aug 2024 09:22:50 GMT Subject: RFR: 8338103: Stabilize and open source a Swing OGL ButtonResizeTest In-Reply-To: References: <8--CxVHS_jclzzN2PWYkI0W3yr7w1al5PSqRdis-PUc=.2f57c378-49cc-40bc-b042-f6aa9bfed07d@github.com> Message-ID: On Mon, 19 Aug 2024 08:59:00 GMT, Manukumar V S wrote: > > The test is failing on my windows machine with an error - _java.lang.RuntimeException: Button renderings are different after window resize, num of Diff Pixels=1576_ Images are uploaded for reference. > > ![image1](https://private-user-images.githubusercontent.com/94159358/359016384-349f9300-25ba-4402-9668-d9e89321b23c.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjQwNTgwMzEsIm5iZiI6MTcyNDA1NzczMSwicGF0aCI6Ii85NDE1OTM1OC8zNTkwMTYzODQtMzQ5ZjkzMDAtMjViYS00NDAyLTk2NjgtZDllODkzMjFiMjNjLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNDA4MTklMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjQwODE5VDA4NTUzMVomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTVlYmY4MzNkZGJiMjY0MDUzN2Q0YzNhNzllZGUxOTU4OWY4ZjBiMDBhM2Y1YzI0OTFmYTdlYmQ5MzVjN2Q2NzMmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JmFjdG9yX2lkPTAma2V5X2lkPTAmcmVwb19pZD0wIn0.pgGc3C1vDtfnl_Zqx6wDFW7jkzsC-AjfGYdRTK3Op-s) ![image2](https://private-user-images.githubusercontent.com/94159358/359016448-c25fb95e-1f80-4762-9388-1b799a0184e8.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ pc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjQwNTgwMzEsIm5iZiI6MTcyNDA1NzczMSwicGF0aCI6Ii85NDE1OTM1OC8zNTkwMTY0NDgtYzI1ZmI5NWUtMWY4MC00NzYyLTkzODgtMWI3OTlhMDE4NGU4LnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNDA4MTklMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjQwODE5VDA4NTUzMVomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTNiZGU1MDRhZjZmNzViNzk3YjQ0MzkxMDJiZDIxZDJlN2FkZjk3MDU5NTA4NDE4N2RkOWMwMDY5MzI2MDY2ZTMmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JmFjdG9yX2lkPTAma2V5X2lkPTAmcmVwb19pZD0wIn0.8rwB9KPKg3Hpi_diZ7Rrm7BLbsVocU9j6Dn1F8j0mUM) > > @TejeshR13 I have run it multiple times on different windows machines(Windows 2022, 10, 11) in mach5 and it passed everywhere and visibly I don't see any differences in the images attached by you. Can you try with the updated test which is attached to the bug(it will generate two diff images if the test fails), so that we will come to know what exactly is the difference between the images. If u can notice there is a slight positional difference of desktop icon of the Java app....... I guess the image comparison includes those also? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20532#issuecomment-2296085913 From mvs at openjdk.org Mon Aug 19 09:28:48 2024 From: mvs at openjdk.org (Manukumar V S) Date: Mon, 19 Aug 2024 09:28:48 GMT Subject: RFR: 8338103: Stabilize and open source a Swing OGL ButtonResizeTest In-Reply-To: References: <8--CxVHS_jclzzN2PWYkI0W3yr7w1al5PSqRdis-PUc=.2f57c378-49cc-40bc-b042-f6aa9bfed07d@github.com> Message-ID: On Mon, 19 Aug 2024 09:20:06 GMT, Tejesh R wrote: >>> The test is failing on my windows machine with an error - _java.lang.RuntimeException: Button renderings are different after window resize, num of Diff Pixels=1576_ Images are uploaded for reference. >>> >>> ![image1](https://private-user-images.githubusercontent.com/94159358/359016384-349f9300-25ba-4402-9668-d9e89321b23c.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjQwNTgwMzEsIm5iZiI6MTcyNDA1NzczMSwicGF0aCI6Ii85NDE1OTM1OC8zNTkwMTYzODQtMzQ5ZjkzMDAtMjViYS00NDAyLTk2NjgtZDllODkzMjFiMjNjLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNDA4MTklMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjQwODE5VDA4NTUzMVomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTVlYmY4MzNkZGJiMjY0MDUzN2Q0YzNhNzllZGUxOTU4OWY4ZjBiMDBhM2Y1YzI0OTFmYTdlYmQ5MzVjN2Q2NzMmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JmFjdG9yX2lkPTAma2V5X2lkPTAmcmVwb19pZD0wIn0.pgGc3C1vDtfnl_Zqx6wDFW7jkzsC-AjfGYdRTK3Op-s) ![image2](https://private-user-images.githubusercontent.com/94159358/359016448-c25fb95e-1f80-4762-9388-1b799a0184e8.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ pc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjQwNTgwMzEsIm5iZiI6MTcyNDA1NzczMSwicGF0aCI6Ii85NDE1OTM1OC8zNTkwMTY0NDgtYzI1ZmI5NWUtMWY4MC00NzYyLTkzODgtMWI3OTlhMDE4NGU4LnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNDA4MTklMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjQwODE5VDA4NTUzMVomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTNiZGU1MDRhZjZmNzViNzk3YjQ0MzkxMDJiZDIxZDJlN2FkZjk3MDU5NTA4NDE4N2RkOWMwMDY5MzI2MDY2ZTMmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JmFjdG9yX2lkPTAma2V5X2lkPTAmcmVwb19pZD0wIn0.8rwB9KPKg3Hpi_diZ7Rrm7BLbsVocU9j6Dn1F8j0mUM) >> >> @TejeshR13 I have run it multiple times on different windows machines(Windows 2022, 10, 11) in mach5 and it passed everywhere and visibly I don't see any differences in the images attached by you. Can you try with the updated test which is attached to the bug(it will generate two diff images if the test fails), so that we will come to know what exactly is the difference between the images. > >> > The test is failing on my windows machine with an error - _java.lang.RuntimeException: Button renderings are different after window resize, num of Diff Pixels=1576_ Images are uploaded for reference. >> > ![image1](https://private-user-images.githubusercontent.com/94159358/359016384-349f9300-25ba-4402-9668-d9e89321b23c.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjQwNTgwMzEsIm5iZiI6MTcyNDA1NzczMSwicGF0aCI6Ii85NDE1OTM1OC8zNTkwMTYzODQtMzQ5ZjkzMDAtMjViYS00NDAyLTk2NjgtZDllODkzMjFiMjNjLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNDA4MTklMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjQwODE5VDA4NTUzMVomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTVlYmY4MzNkZGJiMjY0MDUzN2Q0YzNhNzllZGUxOTU4OWY4ZjBiMDBhM2Y1YzI0OTFmYTdlYmQ5MzVjN2Q2NzMmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JmFjdG9yX2lkPTAma2V5X2lkPTAmcmVwb19pZD0wIn0.pgGc3C1vDtfnl_Zqx6wDFW7jkzsC-AjfGYdRTK3Op-s) ![image2](https://private-user-images.githubusercontent.com/94159358/359016448-c25fb95e-1f80-4762-9388-1b799a0184e8.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.ey Jpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjQwNTgwMzEsIm5iZiI6MTcyNDA1NzczMSwicGF0aCI6Ii85NDE1OTM1OC8zNTkwMTY0NDgtYzI1ZmI5NWUtMWY4MC00NzYyLTkzODgtMWI3OTlhMDE4NGU4LnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNDA4MTklMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjQwODE5VDA4NTUzMVomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTNiZGU1MDRhZjZmNzViNzk3YjQ0MzkxMDJiZDIxZDJlN2FkZjk3MDU5NTA4NDE4N2RkOWMwMDY5MzI2MDY2ZTMmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JmFjdG9yX2lkPTAma2V5X2lkPTAmcmVwb19pZD0wIn0.8rwB9KPKg3Hpi_diZ7Rrm7BLbsVocU9j6Dn1F8j0mUM) >> >> @TejeshR13 I have run it multiple times on different windows machines(Windows 2022, 10, 11) in mach5 and it passed everywhere and visibly I don't see any differences in the images attached by you. Can you try with the updated test which is attached to the bug(it will generate two diff images if the test fails), so that we will come to know what exactly is the difference between the images. > > If u can notice there is a slight positional difference of desktop icon of the Java app....... I guess the image comparison includes those also? @TejeshR13 , no, it just compares the Button renderings only, nothing else. `bimage = robot.createScreenCapture(new Rectangle(buttonLoc.x, buttonLoc.y, button.getWidth(), button.getHeight()));` ------------- PR Comment: https://git.openjdk.org/jdk/pull/20532#issuecomment-2296098282 From tr at openjdk.org Mon Aug 19 09:31:49 2024 From: tr at openjdk.org (Tejesh R) Date: Mon, 19 Aug 2024 09:31:49 GMT Subject: RFR: 8338103: Stabilize and open source a Swing OGL ButtonResizeTest In-Reply-To: References: <8--CxVHS_jclzzN2PWYkI0W3yr7w1al5PSqRdis-PUc=.2f57c378-49cc-40bc-b042-f6aa9bfed07d@github.com> Message-ID: On Mon, 19 Aug 2024 09:20:06 GMT, Tejesh R wrote: >>> The test is failing on my windows machine with an error - _java.lang.RuntimeException: Button renderings are different after window resize, num of Diff Pixels=1576_ Images are uploaded for reference. >>> >>> ![image1](https://private-user-images.githubusercontent.com/94159358/359016384-349f9300-25ba-4402-9668-d9e89321b23c.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjQwNTgwMzEsIm5iZiI6MTcyNDA1NzczMSwicGF0aCI6Ii85NDE1OTM1OC8zNTkwMTYzODQtMzQ5ZjkzMDAtMjViYS00NDAyLTk2NjgtZDllODkzMjFiMjNjLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNDA4MTklMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjQwODE5VDA4NTUzMVomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTVlYmY4MzNkZGJiMjY0MDUzN2Q0YzNhNzllZGUxOTU4OWY4ZjBiMDBhM2Y1YzI0OTFmYTdlYmQ5MzVjN2Q2NzMmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JmFjdG9yX2lkPTAma2V5X2lkPTAmcmVwb19pZD0wIn0.pgGc3C1vDtfnl_Zqx6wDFW7jkzsC-AjfGYdRTK3Op-s) ![image2](https://private-user-images.githubusercontent.com/94159358/359016448-c25fb95e-1f80-4762-9388-1b799a0184e8.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ pc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjQwNTgwMzEsIm5iZiI6MTcyNDA1NzczMSwicGF0aCI6Ii85NDE1OTM1OC8zNTkwMTY0NDgtYzI1ZmI5NWUtMWY4MC00NzYyLTkzODgtMWI3OTlhMDE4NGU4LnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNDA4MTklMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjQwODE5VDA4NTUzMVomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTNiZGU1MDRhZjZmNzViNzk3YjQ0MzkxMDJiZDIxZDJlN2FkZjk3MDU5NTA4NDE4N2RkOWMwMDY5MzI2MDY2ZTMmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JmFjdG9yX2lkPTAma2V5X2lkPTAmcmVwb19pZD0wIn0.8rwB9KPKg3Hpi_diZ7Rrm7BLbsVocU9j6Dn1F8j0mUM) >> >> @TejeshR13 I have run it multiple times on different windows machines(Windows 2022, 10, 11) in mach5 and it passed everywhere and visibly I don't see any differences in the images attached by you. Can you try with the updated test which is attached to the bug(it will generate two diff images if the test fails), so that we will come to know what exactly is the difference between the images. > >> > The test is failing on my windows machine with an error - _java.lang.RuntimeException: Button renderings are different after window resize, num of Diff Pixels=1576_ Images are uploaded for reference. >> > ![image1](https://private-user-images.githubusercontent.com/94159358/359016384-349f9300-25ba-4402-9668-d9e89321b23c.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjQwNTgwMzEsIm5iZiI6MTcyNDA1NzczMSwicGF0aCI6Ii85NDE1OTM1OC8zNTkwMTYzODQtMzQ5ZjkzMDAtMjViYS00NDAyLTk2NjgtZDllODkzMjFiMjNjLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNDA4MTklMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjQwODE5VDA4NTUzMVomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTVlYmY4MzNkZGJiMjY0MDUzN2Q0YzNhNzllZGUxOTU4OWY4ZjBiMDBhM2Y1YzI0OTFmYTdlYmQ5MzVjN2Q2NzMmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JmFjdG9yX2lkPTAma2V5X2lkPTAmcmVwb19pZD0wIn0.pgGc3C1vDtfnl_Zqx6wDFW7jkzsC-AjfGYdRTK3Op-s) ![image2](https://private-user-images.githubusercontent.com/94159358/359016448-c25fb95e-1f80-4762-9388-1b799a0184e8.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.ey Jpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjQwNTgwMzEsIm5iZiI6MTcyNDA1NzczMSwicGF0aCI6Ii85NDE1OTM1OC8zNTkwMTY0NDgtYzI1ZmI5NWUtMWY4MC00NzYyLTkzODgtMWI3OTlhMDE4NGU4LnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNDA4MTklMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjQwODE5VDA4NTUzMVomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTNiZGU1MDRhZjZmNzViNzk3YjQ0MzkxMDJiZDIxZDJlN2FkZjk3MDU5NTA4NDE4N2RkOWMwMDY5MzI2MDY2ZTMmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JmFjdG9yX2lkPTAma2V5X2lkPTAmcmVwb19pZD0wIn0.8rwB9KPKg3Hpi_diZ7Rrm7BLbsVocU9j6Dn1F8j0mUM) >> >> @TejeshR13 I have run it multiple times on different windows machines(Windows 2022, 10, 11) in mach5 and it passed everywhere and visibly I don't see any differences in the images attached by you. Can you try with the updated test which is attached to the bug(it will generate two diff images if the test fails), so that we will come to know what exactly is the difference between the images. > > If u can notice there is a slight positional difference of desktop icon of the Java app....... I guess the image comparison includes those also? > @TejeshR13 , no, it just compares the Button renderings only, nothing else. `bimage = robot.createScreenCapture(new Rectangle(buttonLoc.x, buttonLoc.y, button.getWidth(), button.getHeight()));` Which is exactly in the image right? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20532#issuecomment-2296103991 From mvs at openjdk.org Mon Aug 19 09:51:50 2024 From: mvs at openjdk.org (Manukumar V S) Date: Mon, 19 Aug 2024 09:51:50 GMT Subject: RFR: 8338103: Stabilize and open source a Swing OGL ButtonResizeTest In-Reply-To: References: <8--CxVHS_jclzzN2PWYkI0W3yr7w1al5PSqRdis-PUc=.2f57c378-49cc-40bc-b042-f6aa9bfed07d@github.com> Message-ID: On Mon, 19 Aug 2024 09:29:12 GMT, Tejesh R wrote: > > @TejeshR13 , no, it just compares the Button renderings only, nothing else. `bimage = robot.createScreenCapture(new Rectangle(buttonLoc.x, buttonLoc.y, button.getWidth(), button.getHeight()));` > > Which is exactly in the image right? Yes, your images contain the Windows taskbar also, but I'm not sure why it is taking that also when we capture the screen based on button's dimensions, could it be because of button.getWidth() and button.getHeight() returning wrong values? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20532#issuecomment-2296145654 From tr at openjdk.org Mon Aug 19 09:54:47 2024 From: tr at openjdk.org (Tejesh R) Date: Mon, 19 Aug 2024 09:54:47 GMT Subject: RFR: 8338103: Stabilize and open source a Swing OGL ButtonResizeTest In-Reply-To: References: <8--CxVHS_jclzzN2PWYkI0W3yr7w1al5PSqRdis-PUc=.2f57c378-49cc-40bc-b042-f6aa9bfed07d@github.com> Message-ID: On Mon, 19 Aug 2024 09:29:12 GMT, Tejesh R wrote: >>> > The test is failing on my windows machine with an error - _java.lang.RuntimeException: Button renderings are different after window resize, num of Diff Pixels=1576_ Images are uploaded for reference. >>> > ![image1](https://private-user-images.githubusercontent.com/94159358/359016384-349f9300-25ba-4402-9668-d9e89321b23c.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjQwNTgwMzEsIm5iZiI6MTcyNDA1NzczMSwicGF0aCI6Ii85NDE1OTM1OC8zNTkwMTYzODQtMzQ5ZjkzMDAtMjViYS00NDAyLTk2NjgtZDllODkzMjFiMjNjLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNDA4MTklMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjQwODE5VDA4NTUzMVomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTVlYmY4MzNkZGJiMjY0MDUzN2Q0YzNhNzllZGUxOTU4OWY4ZjBiMDBhM2Y1YzI0OTFmYTdlYmQ5MzVjN2Q2NzMmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JmFjdG9yX2lkPTAma2V5X2lkPTAmcmVwb19pZD0wIn0.pgGc3C1vDtfnl_Zqx6wDFW7jkzsC-AjfGYdRTK3Op-s) ![image2](https://private-user-images.githubusercontent.com/94159358/359016448-c25fb95e-1f80-4762-9388-1b799a0184e8.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.e yJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjQwNTgwMzEsIm5iZiI6MTcyNDA1NzczMSwicGF0aCI6Ii85NDE1OTM1OC8zNTkwMTY0NDgtYzI1ZmI5NWUtMWY4MC00NzYyLTkzODgtMWI3OTlhMDE4NGU4LnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNDA4MTklMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjQwODE5VDA4NTUzMVomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTNiZGU1MDRhZjZmNzViNzk3YjQ0MzkxMDJiZDIxZDJlN2FkZjk3MDU5NTA4NDE4N2RkOWMwMDY5MzI2MDY2ZTMmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JmFjdG9yX2lkPTAma2V5X2lkPTAmcmVwb19pZD0wIn0.8rwB9KPKg3Hpi_diZ7Rrm7BLbsVocU9j6Dn1F8j0mUM) >>> >>> @TejeshR13 I have run it multiple times on different windows machines(Windows 2022, 10, 11) in mach5 and it passed everywhere and visibly I don't see any differences in the images attached by you. Can you try with the updated test which is attached to the bug(it will generate two diff images if the test fails), so that we will come to know what exactly is the difference between the images. >> >> If u can notice there is a slight positional difference of desktop icon of the Java app....... I guess the image comparison includes those also? > >> @TejeshR13 , no, it just compares the Button renderings only, nothing else. `bimage = robot.createScreenCapture(new Rectangle(buttonLoc.x, buttonLoc.y, button.getWidth(), button.getHeight()));` > > Which is exactly in the image right? > > > @TejeshR13 , no, it just compares the Button renderings only, nothing else. `bimage = robot.createScreenCapture(new Rectangle(buttonLoc.x, buttonLoc.y, button.getWidth(), button.getHeight()));` > > > > > > Which is exactly in the image right? > > Yes, your images contain the Windows taskbar also, but I'm not sure why it is taking that also when we capture the screen based on button's dimensions, could it be because of button.getWidth() and button.getHeight() returning wrong values? Not wrong values, its just that the button is slightly behind the window icons. Better to move the button up so that it wont mix up with icon. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20532#issuecomment-2296151827 From mvs at openjdk.org Mon Aug 19 10:04:48 2024 From: mvs at openjdk.org (Manukumar V S) Date: Mon, 19 Aug 2024 10:04:48 GMT Subject: RFR: 8338103: Stabilize and open source a Swing OGL ButtonResizeTest In-Reply-To: References: <8--CxVHS_jclzzN2PWYkI0W3yr7w1al5PSqRdis-PUc=.2f57c378-49cc-40bc-b042-f6aa9bfed07d@github.com> Message-ID: On Mon, 19 Aug 2024 09:51:55 GMT, Tejesh R wrote: > > > > @TejeshR13 , no, it just compares the Button renderings only, nothing else. `bimage = robot.createScreenCapture(new Rectangle(buttonLoc.x, buttonLoc.y, button.getWidth(), button.getHeight()));` > > > > > > > > > Which is exactly in the image right? > > > > > > Yes, your images contain the Windows taskbar also, but I'm not sure why it is taking that also when we capture the screen based on button's dimensions, could it be because of button.getWidth() and button.getHeight() returning wrong values? > > Not wrong values, its just that the button is slightly behind the window icons. Better to move the button up so that it wont mix up with icon. Ohh got it, thanks for the suggestion, I will move it up and try. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20532#issuecomment-2296174348 From mvs at openjdk.org Mon Aug 19 11:00:22 2024 From: mvs at openjdk.org (Manukumar V S) Date: Mon, 19 Aug 2024 11:00:22 GMT Subject: RFR: 8338103: Stabilize and open source a Swing OGL ButtonResizeTest [v2] In-Reply-To: <8--CxVHS_jclzzN2PWYkI0W3yr7w1al5PSqRdis-PUc=.2f57c378-49cc-40bc-b042-f6aa9bfed07d@github.com> References: <8--CxVHS_jclzzN2PWYkI0W3yr7w1al5PSqRdis-PUc=.2f57c378-49cc-40bc-b042-f6aa9bfed07d@github.com> Message-ID: > This PR creates a new test by stabilising and open sourcing a closed test. > This test verifies that the OpenGL pipeline does not create artifacts with swing components after window is zoomed to maximum size and then resized back to normal. > This test is run twice, with and without the flags "-Dsun.java2d.opengl=True -Dsun.java2d.opengl.fbobject=false" . > > This is tested(15 times per platform) in all the available mach5 headful platforms and found to be stable. Manukumar V S has updated the pull request incrementally with one additional commit since the last revision: Review comments fixed : Moved the button up to prevent mix up, saved the diff image in failure cases ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20532/files - new: https://git.openjdk.org/jdk/pull/20532/files/f78935da..7549ebf0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20532&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20532&range=00-01 Stats: 22 lines in 1 file changed: 8 ins; 9 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/20532.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20532/head:pull/20532 PR: https://git.openjdk.org/jdk/pull/20532 From aivanov at openjdk.org Mon Aug 19 12:37:12 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 19 Aug 2024 12:37:12 GMT Subject: RFR: 8337851: Some tests have name which confuse jtreg [v3] In-Reply-To: References: <9Ohvnc6MgnokscABDpbRhBYuXtjguHrcJd7eVRWSXYs=.cd938d32-de8b-4eb1-a601-421762f991f3@github.com> Message-ID: <-ua0I6lCxPPp57ELQTFMnMOS8pJP03pGxmGMaVMrJYI=.e87e09a5-6475-44b5-855c-b005fff2ad1c@github.com> On Mon, 19 Aug 2024 01:37:36 GMT, toshiogata wrote: > Thank you for pointing it out. I was not aware of the git rename issue. Even if it were not for this Git ?limitation?, I still think additional changes should be requested by Java Compiler team. I am not aware of their practices. @alisenchung knows I'm advocating for expanding imports (whenever a test or source file is modified) and for moving jtreg tags below imports closer to the class declaration. At the same time, we haven't reached an agreement about it, although some people seem to support it too. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20475#discussion_r1721718761 From aivanov at openjdk.org Mon Aug 19 12:40:51 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 19 Aug 2024 12:40:51 GMT Subject: RFR: 8337851: Some tests have name which confuse jtreg [v3] In-Reply-To: References: Message-ID: On Mon, 19 Aug 2024 01:28:20 GMT, toshiogata wrote: >> Rename the tests to prevent unexpected deletion of result files when `-retain` jtreg option is specified. >> Testing: modified tests > > toshiogata has updated the pull request incrementally with one additional commit since the last revision: > > Revert "Move jtreg tags and expand wildcard imports" > > This reverts commit 9b30df1230b7e31b42e63ae01ef1549565bcc078. Looks good to me. Someone from the compiler team has to approve it too. All the changes look good, however, only one test, `URLDragTest.java`, is from the *client* area. ------------- Marked as reviewed by aivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20475#pullrequestreview-2245438992 From rkannathpari at openjdk.org Mon Aug 19 12:43:55 2024 From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad) Date: Mon, 19 Aug 2024 12:43:55 GMT Subject: Integrated: 8290501 : Typo in javax.swing.BoundedRangeModel documentation In-Reply-To: References: Message-ID: On Mon, 5 Aug 2024 10:56:49 GMT, Renjith Kannath Pariyangad wrote: > Documentation updated This pull request has now been integrated. Changeset: 6ff6b099 Author: Renjith Kannath Pariyangad URL: https://git.openjdk.org/jdk/commit/6ff6b0994380276e0096f7b55a0d659803344679 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod 8290501: Typo in javax.swing.BoundedRangeModel documentation Reviewed-by: aivanov, prr, honkar ------------- PR: https://git.openjdk.org/jdk/pull/20465 From duke at openjdk.org Mon Aug 19 13:30:57 2024 From: duke at openjdk.org (duke) Date: Mon, 19 Aug 2024 13:30:57 GMT Subject: Withdrawn: 8330988: Implementation of 8288293: Windows/gcc Port for hsdis In-Reply-To: References: Message-ID: On Tue, 23 Apr 2024 13:56:32 GMT, Julian Waters wrote: > WIP > > This changeset contains hsdis for Windows/gcc Port. It supports both the binutils and capstone backends, though the LLVM backend is left out due to compatibility issues encountered during the build. Currently, which gcc distributions are supported is still to be clarified, as several, ranging from Cygwin, to MinGW64, to the gcc subsystems from MSYS2. For this reason, the build system hack in place at the moment to compile the binutils backend on Windows is still left in place, for now. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/18915 From duke at openjdk.org Mon Aug 19 13:33:53 2024 From: duke at openjdk.org (duke) Date: Mon, 19 Aug 2024 13:33:53 GMT Subject: Withdrawn: 8328977 : JEditorPane.setPage not thread-safe, pageLoader not cancelled In-Reply-To: References: Message-ID: On Mon, 8 Apr 2024 06:09:16 GMT, Renjith Kannath Pariyangad wrote: > Hi Reviewers, > > Added pageloader cancel before new page creation along with code restructuring. Moved all page loading calls inside synchronize to make it thread safe. > > Regards, > Renjith. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/18670 From aivanov at openjdk.org Mon Aug 19 13:47:50 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 19 Aug 2024 13:47:50 GMT Subject: RFR: 8321140: Add comment to note difference in Metal's JButton margins [v3] In-Reply-To: <7cKNHa8y-HmCtElq-VhqJObt3xLt45-bmdGi-c9KIoQ=.09869e38-162e-4c44-84fa-135cd9cee5a3@github.com> References: <7cKNHa8y-HmCtElq-VhqJObt3xLt45-bmdGi-c9KIoQ=.09869e38-162e-4c44-84fa-135cd9cee5a3@github.com> Message-ID: <9jEu_KPFHMdnVZWVX6r2mFmvpBoloBD-mPgFBf0YMM0=.a700dc8a-d403-496c-b4fa-c1c85602fe19@github.com> On Fri, 16 Aug 2024 18:56:25 GMT, Damon Nguyen wrote: >> Previously in [JDK-8282772](https://bugs.openjdk.org/browse/JDK-8282772), there was a fix for JButtons with HTML content alignment for non-MacOS L&Fs. This fix was to make other L&Fs in line with the Aqua fix found in [JDK-8015854](https://bugs.openjdk.org/browse/JDK-8015854). >> >> However, the non-MacOS L&F fix caused a regression and the details and original discussion can be found in [JDK-8318590](https://bugs.openjdk.org/browse/JDK-8318590). This non-MacOS L&F fix was backed out and the current behavior for JButtons with HTML content for these L&Fs was deemed to be correct as is. >> >> Through discussion, a note about Metal's different margin values should be added somewhere for future reference. Metal's horizontal margins are 14 where other L&Fs are zero or some small value. This discrepancy is what caused the original issue to be filed. This change is to add a comment to `MetalLookAndFeel.java` since there is no exact spot where these values are set for the margin. It's been added where other Metal components (CheckBox, RadioButton, etc.) have comments on margins as well. >> >> Here are some L&F values for reference/comparison: >> >> Metal's margins: [top=2,left=14,bottom=2,right=14] >> Aqua's margins: [top=0,left=2,bottom=0,right=2] >> Motif's margins: [top=2,left=4,bottom=2,right=4] >> Nimbus's margins: [top=0,left=0,bottom=0,right=0] > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Notes in both LAFs Looks good to me. Please, update copyright year in both files. ------------- Marked as reviewed by aivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20482#pullrequestreview-2245596927 From aivanov at openjdk.org Mon Aug 19 13:57:22 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 19 Aug 2024 13:57:22 GMT Subject: RFR: 8332901: Choice/SelectCurrentItemTest/SelectCurrentItemTest.java doesn't open popup on macOS [v2] In-Reply-To: References: Message-ID: > I looked at `java/awt/Choice/SelectCurrentItemTest/SelectCurrentItemTest.java`, ran it and noticed that the test does not open the popup of the `Choice` component on macOS 14.x. > > If the popup does not open, the test does not verify anything ? it always passes. > > I refactored the test and added a mouse listener to the `Choice` component. If mouse click isn't registered, the test fails. > > The updated test fails for me locally on macOS Sonoma 14.5. This is likely the result of [JDK-8322653](https://bugs.openjdk.org/browse/JDK-8322653): _[macos14] : Mouse clicks are not received within 3 pixels of the window boundary_. > > The updated test passes on CI. Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision: Make frame non-resizable to workaround JDK-8322653 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20601/files - new: https://git.openjdk.org/jdk/pull/20601/files/2da478de..c288ab68 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20601&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20601&range=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20601.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20601/head:pull/20601 PR: https://git.openjdk.org/jdk/pull/20601 From aph at openjdk.org Mon Aug 19 14:38:52 2024 From: aph at openjdk.org (Andrew Haley) Date: Mon, 19 Aug 2024 14:38:52 GMT Subject: RFR: 8336382: Fixes error reporting in loading AWT and fonts [v3] In-Reply-To: References: Message-ID: On Mon, 15 Jul 2024 19:11:38 GMT, Phil Race wrote: > There is nothing in this PR that I would accept. It should be withdrawn. I think we're all finding it a bit hard to understand what to do. Is the problem that - This is not a bug? - This is not a bug that should be fixed? - The fix is wrong? - There is a much better way to fix it? - This is an enhancement, but it is not a worthwhile one? Please, help us here. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20169#issuecomment-2296732537 From aph at openjdk.org Mon Aug 19 14:38:53 2024 From: aph at openjdk.org (Andrew Haley) Date: Mon, 19 Aug 2024 14:38:53 GMT Subject: RFR: 8336382: Fixes error reporting in loading AWT and fonts [v3] In-Reply-To: References: Message-ID: On Wed, 24 Jul 2024 12:42:00 GMT, Karm Michal Babacek wrote: >> If there is a problem with finding and calling e.g. `java/awt/GraphicsEnvironment` in `AWTIsHeadless`, the env' Exception remains set and it is not cleared. Later, that manifests as: >> >> Fatal error reported via JNI: Could not allocate library name >> >> Which is misleading. The code path is perhaps rare in a normal JDK usage, but it has been complicating our users' bug reports in the GraalVM/native-image ecosystem for quite some time. >> >> Instead of failing later indicating that the user has incorrectly configured JNI, it bails out very soon with a message that seems as if a jstring could not have been allocated. It sends users on wild goose chases where it appears `JNU_NewStringPlatform` calls failed, e.g. >> >> * https://github.com/oracle/graal/issues/9138 >> * https://github.com/oracle/graal/issues/8475 >> * https://github.com/oracle/graal/issues/9300 >> * https://github.com/quarkusio/quarkus/issues/31596 >> * https://github.com/graalvm/mandrel/issues/292 >> * https://github.com/Karm/mandrel-integration-tests/issues/262 >> >> This commit fixes the error reporting in the AWTIsHeadless. >> >> Furthermore, when AOT compiled, there is little sense for having a JAVA_HOME, yet some parts of AWT code look for it to search fonts. In such case, an empty directory structure is enough to accommodate it, e.g. >> >> /tmp/JAVA_HOME/ >> /tmp/JAVA_HOME/conf >> /tmp/JAVA_HOME/conf/fonts >> /tmp/JAVA_HOME/lib >> >> The exception is somewhat cryptic for users again, merely stating: >> >> Exception in thread "main" java.io.IOException: Problem reading font data. >> at java.desktop at 22.0.1/java.awt.Font.createFont0(Font.java:1205) >> at java.desktop at 22.0.1/java.awt.Font.createFont(Font.java:1076) >> at imageio.Main.loadFonts(Main.java:139 >> >> Adding the cause there makes it clearer, i.e. that JAVA_HOME might be missing: >> >> Exception in thread "main" java.io.IOException: Problem reading font data. >> at java.desktop at 23-internal/java.awt.Font.createFont0(Font.java:1206) >> at java.desktop at 23-internal/java.awt.Font.createFont(Font.java:1076) >> at imageio.Main.loadFonts(Main.java:139) >> at imageio.Main.paintRectangles(Main.java:97) >> at imageio.Main.main(Main.java:195) >> at java.base at 23-internal/java.lang.invoke.LambdaForm$DMH/sa346b79c.invokeStaticInit(LambdaForm$DMH) >> Caused by: java.lang.Error: java.home property not set >> at java.desktop at 23-internal/sun.awt.FontConfiguration.findFontConfigF... > > Karm Michal Babacek has updated the pull request incrementally with one additional commit since the last revision: > > Treats missing class as a fatal error P.S. There surely is an actual problem here: the error message that is currently output misrepresents the actual cause of the failure. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20169#issuecomment-2296736175 From dnguyen at openjdk.org Mon Aug 19 16:27:21 2024 From: dnguyen at openjdk.org (Damon Nguyen) Date: Mon, 19 Aug 2024 16:27:21 GMT Subject: RFR: 8321140: Add comment to note difference in Metal's JButton margins [v4] In-Reply-To: References: Message-ID: > Previously in [JDK-8282772](https://bugs.openjdk.org/browse/JDK-8282772), there was a fix for JButtons with HTML content alignment for non-MacOS L&Fs. This fix was to make other L&Fs in line with the Aqua fix found in [JDK-8015854](https://bugs.openjdk.org/browse/JDK-8015854). > > However, the non-MacOS L&F fix caused a regression and the details and original discussion can be found in [JDK-8318590](https://bugs.openjdk.org/browse/JDK-8318590). This non-MacOS L&F fix was backed out and the current behavior for JButtons with HTML content for these L&Fs was deemed to be correct as is. > > Through discussion, a note about Metal's different margin values should be added somewhere for future reference. Metal's horizontal margins are 14 where other L&Fs are zero or some small value. This discrepancy is what caused the original issue to be filed. This change is to add a comment to `MetalLookAndFeel.java` since there is no exact spot where these values are set for the margin. It's been added where other Metal components (CheckBox, RadioButton, etc.) have comments on margins as well. > > Here are some L&F values for reference/comparison: > > Metal's margins: [top=2,left=14,bottom=2,right=14] > Aqua's margins: [top=0,left=2,bottom=0,right=2] > Motif's margins: [top=2,left=4,bottom=2,right=4] > Nimbus's margins: [top=0,left=0,bottom=0,right=0] Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: Update copyright year ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20482/files - new: https://git.openjdk.org/jdk/pull/20482/files/a16b29be..5bd6948e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20482&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20482&range=02-03 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20482.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20482/head:pull/20482 PR: https://git.openjdk.org/jdk/pull/20482 From honkar at openjdk.org Mon Aug 19 16:32:53 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Mon, 19 Aug 2024 16:32:53 GMT Subject: RFR: 8321140: Add comment to note difference in Metal's JButton margins [v4] In-Reply-To: References: Message-ID: On Mon, 19 Aug 2024 16:27:21 GMT, Damon Nguyen wrote: >> Previously in [JDK-8282772](https://bugs.openjdk.org/browse/JDK-8282772), there was a fix for JButtons with HTML content alignment for non-MacOS L&Fs. This fix was to make other L&Fs in line with the Aqua fix found in [JDK-8015854](https://bugs.openjdk.org/browse/JDK-8015854). >> >> However, the non-MacOS L&F fix caused a regression and the details and original discussion can be found in [JDK-8318590](https://bugs.openjdk.org/browse/JDK-8318590). This non-MacOS L&F fix was backed out and the current behavior for JButtons with HTML content for these L&Fs was deemed to be correct as is. >> >> Through discussion, a note about Metal's different margin values should be added somewhere for future reference. Metal's horizontal margins are 14 where other L&Fs are zero or some small value. This discrepancy is what caused the original issue to be filed. This change is to add a comment to `MetalLookAndFeel.java` since there is no exact spot where these values are set for the margin. It's been added where other Metal components (CheckBox, RadioButton, etc.) have comments on margins as well. >> >> Here are some L&F values for reference/comparison: >> >> Metal's margins: [top=2,left=14,bottom=2,right=14] >> Aqua's margins: [top=0,left=2,bottom=0,right=2] >> Motif's margins: [top=2,left=4,bottom=2,right=4] >> Nimbus's margins: [top=0,left=0,bottom=0,right=0] > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright year Marked as reviewed by honkar (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20482#pullrequestreview-2245990182 From dnguyen at openjdk.org Mon Aug 19 16:46:54 2024 From: dnguyen at openjdk.org (Damon Nguyen) Date: Mon, 19 Aug 2024 16:46:54 GMT Subject: Integrated: 8321140: Add comment to note difference in Metal's JButton margins In-Reply-To: References: Message-ID: On Tue, 6 Aug 2024 23:12:44 GMT, Damon Nguyen wrote: > Previously in [JDK-8282772](https://bugs.openjdk.org/browse/JDK-8282772), there was a fix for JButtons with HTML content alignment for non-MacOS L&Fs. This fix was to make other L&Fs in line with the Aqua fix found in [JDK-8015854](https://bugs.openjdk.org/browse/JDK-8015854). > > However, the non-MacOS L&F fix caused a regression and the details and original discussion can be found in [JDK-8318590](https://bugs.openjdk.org/browse/JDK-8318590). This non-MacOS L&F fix was backed out and the current behavior for JButtons with HTML content for these L&Fs was deemed to be correct as is. > > Through discussion, a note about Metal's different margin values should be added somewhere for future reference. Metal's horizontal margins are 14 where other L&Fs are zero or some small value. This discrepancy is what caused the original issue to be filed. This change is to add a comment to `MetalLookAndFeel.java` since there is no exact spot where these values are set for the margin. It's been added where other Metal components (CheckBox, RadioButton, etc.) have comments on margins as well. > > Here are some L&F values for reference/comparison: > > Metal's margins: [top=2,left=14,bottom=2,right=14] > Aqua's margins: [top=0,left=2,bottom=0,right=2] > Motif's margins: [top=2,left=4,bottom=2,right=4] > Nimbus's margins: [top=0,left=0,bottom=0,right=0] This pull request has now been integrated. Changeset: 6460b300 Author: Damon Nguyen URL: https://git.openjdk.org/jdk/commit/6460b300487071bcf98f5ac70d9c0a6fd6b94083 Stats: 51 lines in 2 files changed: 38 ins; 9 del; 4 mod 8321140: Add comment to note difference in Metal's JButton margins Reviewed-by: honkar, aivanov ------------- PR: https://git.openjdk.org/jdk/pull/20482 From dnguyen at openjdk.org Mon Aug 19 16:49:51 2024 From: dnguyen at openjdk.org (Damon Nguyen) Date: Mon, 19 Aug 2024 16:49:51 GMT Subject: RFR: 8338041: Keyborad Navigation of JTable, Ctrl Shift RIGHT/LEFT doesn't follow native action in GTK L&F In-Reply-To: <_kMMFJ9LnQOmUmp_3Ob1m3lj2xLKUo-ChL00Clw4xjs=.7e799f69-da05-44f4-9bf7-6e9e43b427b8@github.com> References: <_kMMFJ9LnQOmUmp_3Ob1m3lj2xLKUo-ChL00Clw4xjs=.7e799f69-da05-44f4-9bf7-6e9e43b427b8@github.com> Message-ID: <_REjx8TrYFiwhVUPfQ6dOtmKGo7_fCsVtHsnUrdCmzc=.2292c4e5-4ea6-4a88-8dba-91058816419f@github.com> On Fri, 16 Aug 2024 07:39:44 GMT, Tejesh R wrote: > In JTable, keyboard navigation keys Ctrl Shift RIGHT/LEFT doesn't follow native actions of Linux. In native the actions are extended to end of selected columns cells either LEFT/RIGHT but in swing gtk look and feel the selection is extended to one cell to left/right. This might be taken as reference of Windows OS since the same is observed in Windows native. Hence I have update the actions for Ctrl Shift RIGHT & LEFT. > Added automated test too. The fix is tested in CI and its fine. The change itself works fine. I agree with the test changes submitted already. Out of curiosity, what native app did you compare it to when you checked for native behavior? ------------- PR Review: https://git.openjdk.org/jdk/pull/20608#pullrequestreview-2246021001 From honkar at openjdk.org Mon Aug 19 16:52:49 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Mon, 19 Aug 2024 16:52:49 GMT Subject: RFR: 8332901: Choice/SelectCurrentItemTest/SelectCurrentItemTest.java doesn't open popup on macOS [v2] In-Reply-To: References: Message-ID: On Mon, 19 Aug 2024 13:57:22 GMT, Alexey Ivanov wrote: >> I looked at `java/awt/Choice/SelectCurrentItemTest/SelectCurrentItemTest.java`, ran it and noticed that the test does not open the popup of the `Choice` component on macOS 14.x. >> >> If the popup does not open, the test does not verify anything ? it always passes. >> >> I refactored the test and added a mouse listener to the `Choice` component. If mouse click isn't registered, the test fails. >> >> The updated test fails for me locally on macOS Sonoma 14.5. This is likely the result of [JDK-8322653](https://bugs.openjdk.org/browse/JDK-8322653): _[macos14] : Mouse clicks are not received within 3 pixels of the window boundary_. >> >> The updated test passes on CI. > > Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision: > > Make frame non-resizable to workaround JDK-8322653 LGTM ------------- Marked as reviewed by honkar (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20601#pullrequestreview-2246025300 From dnguyen at openjdk.org Mon Aug 19 16:53:51 2024 From: dnguyen at openjdk.org (Damon Nguyen) Date: Mon, 19 Aug 2024 16:53:51 GMT Subject: RFR: 8338041: Keyborad Navigation of JTable, Ctrl Shift RIGHT/LEFT doesn't follow native action in GTK L&F In-Reply-To: <_kMMFJ9LnQOmUmp_3Ob1m3lj2xLKUo-ChL00Clw4xjs=.7e799f69-da05-44f4-9bf7-6e9e43b427b8@github.com> References: <_kMMFJ9LnQOmUmp_3Ob1m3lj2xLKUo-ChL00Clw4xjs=.7e799f69-da05-44f4-9bf7-6e9e43b427b8@github.com> Message-ID: On Fri, 16 Aug 2024 07:39:44 GMT, Tejesh R wrote: > In JTable, keyboard navigation keys Ctrl Shift RIGHT/LEFT doesn't follow native actions of Linux. In native the actions are extended to end of selected columns cells either LEFT/RIGHT but in swing gtk look and feel the selection is extended to one cell to left/right. This might be taken as reference of Windows OS since the same is observed in Windows native. Hence I have update the actions for Ctrl Shift RIGHT & LEFT. > Added automated test too. The fix is tested in CI and its fine. Also probably worth fixing the `Keyborad` typo in the title and JBS issue to `Keyboard`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20608#issuecomment-2297012131 From dnguyen at openjdk.org Mon Aug 19 18:32:48 2024 From: dnguyen at openjdk.org (Damon Nguyen) Date: Mon, 19 Aug 2024 18:32:48 GMT Subject: RFR: 8332901: Choice/SelectCurrentItemTest/SelectCurrentItemTest.java doesn't open popup on macOS [v2] In-Reply-To: References: Message-ID: On Mon, 19 Aug 2024 13:57:22 GMT, Alexey Ivanov wrote: >> I looked at `java/awt/Choice/SelectCurrentItemTest/SelectCurrentItemTest.java`, ran it and noticed that the test does not open the popup of the `Choice` component on macOS 14.x. >> >> If the popup does not open, the test does not verify anything ? it always passes. >> >> I refactored the test and added a mouse listener to the `Choice` component. If mouse click isn't registered, the test fails. >> >> The updated test fails for me locally on macOS Sonoma 14.5. This is likely the result of [JDK-8322653](https://bugs.openjdk.org/browse/JDK-8322653): _[macos14] : Mouse clicks are not received within 3 pixels of the window boundary_. >> >> The updated test passes on CI. > > Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision: > > Make frame non-resizable to workaround JDK-8322653 LGTM as well ------------- Marked as reviewed by dnguyen (Committer). PR Review: https://git.openjdk.org/jdk/pull/20601#pullrequestreview-2246203092 From serb at openjdk.org Mon Aug 19 19:59:00 2024 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 19 Aug 2024 19:59:00 GMT Subject: RFR: 8297088: Update LCMS to 2.14 In-Reply-To: References: Message-ID: On Fri, 18 Nov 2022 08:42:12 GMT, Sergey Bylokhov wrote: >> Redo of 8295369: Update LCMS to 2.14 >> Update LCMS to newest release. >> Updated DISABLED_WARNINGS_gcc for LCMS to include type limits to prevent a build error in linux. >> Automatic tests and J2D demo tests were run. > > make/modules/java.desktop/lib/Awt2dLibraries.gmk line 308: > >> 306: libawt/java2d, \ >> 307: HEADERS_FROM_SRC := $(LIBLCMS_HEADERS_FROM_SRC), \ >> 308: DISABLED_WARNINGS_gcc := format-nonliteral type-limits stringop-truncation, \ > > it would be good to report this upstream. https://github.com/mm2/Little-CMS/issues/458 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/11217#discussion_r1722281884 From prr at openjdk.org Mon Aug 19 20:52:49 2024 From: prr at openjdk.org (Phil Race) Date: Mon, 19 Aug 2024 20:52:49 GMT Subject: RFR: 8338041: Keyborad Navigation of JTable, Ctrl Shift RIGHT/LEFT doesn't follow native action in GTK L&F In-Reply-To: References: <_kMMFJ9LnQOmUmp_3Ob1m3lj2xLKUo-ChL00Clw4xjs=.7e799f69-da05-44f4-9bf7-6e9e43b427b8@github.com> Message-ID: On Mon, 19 Aug 2024 16:51:35 GMT, Damon Nguyen wrote: > Also probably worth fixing the `Keyborad` typo in the title and JBS issue to `Keyboard`. That was the first thing I noticed about this PR :-). I fixed the JBS issue. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20608#issuecomment-2297432355 From abhiscxk at openjdk.org Tue Aug 20 04:38:51 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Tue, 20 Aug 2024 04:38:51 GMT Subject: RFR: 6318027: BasicScrollBarUI does not disable timer when enclosing frame is disabled. [v5] In-Reply-To: References: Message-ID: On Mon, 19 Aug 2024 02:25:29 GMT, Prasanta Sadhukhan wrote: >> Issue is >> BasicScrollBarUI.ArrowButtonListener starts a timer in mousePressed(), and stops it in mouseReleased(). If the frame containing the scrollbar is disabled between the MOUSE_PRESSED and the MOUSE_RELEASED events, the mouseReleased() method is never called. If the frame is then re-enabled, the still-running timer causes it to scroll all the way to the end. >> Fix is to check if [ArrowButtonListener.handledEvent](https://github.com/openjdk/jdk/blame/ee839b7f0ebe471d3877cddd2c87019ccb8ee5ae/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicScrollBarUI.java#L1567) is still set when ActionEvent is processed then stop the timer and reset this variable. >> >> CI testing is green and also SwingSet2 JScrollPane scrolling with this modification.. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > test typo src/java.desktop/macosx/classes/com/apple/laf/AquaScrollBarUI.java line 534: > 532: if (parent instanceof javax.swing.JFrame par) { > 533: if (!par.isEnabled()) { > 534: ((Timer)e.getSource()).stop(); Suggestion: ((Timer) e.getSource()).stop(); src/java.desktop/share/classes/javax/swing/plaf/basic/BasicScrollBarUI.java line 1611: > 1609: /** {@inheritDoc} */ > 1610: public void actionPerformed(ActionEvent e) { > 1611: // If frame is disabled and time is started in mousePressed Suggestion: // If frame is disabled and timer is started in mousePressed src/java.desktop/share/classes/javax/swing/plaf/basic/BasicScrollBarUI.java line 1616: > 1614: Component parent = scrollbar.getParent(); > 1615: do { > 1616: if (parent instanceof javax.swing.JFrame par) { should we import `JFrame` and just use `instanceof JFrame` ? src/java.desktop/share/classes/javax/swing/plaf/basic/BasicScrollBarUI.java line 1617: > 1615: do { > 1616: if (parent instanceof javax.swing.JFrame par) { > 1617: if (!par.isEnabled()) { I think this two condition can be combined into one. `if (parent instanceof javax.swing.JFrame par && !par.isEnabled()) ` src/java.desktop/share/classes/javax/swing/plaf/basic/BasicScrollBarUI.java line 1618: > 1616: if (parent instanceof javax.swing.JFrame par) { > 1617: if (!par.isEnabled()) { > 1618: ((Timer)e.getSource()).stop(); Suggestion: ((Timer) e.getSource()).stop(); test/jdk/javax/swing/JScrollBar/DisableFrameFromScrollBar.java line 46: > 44: import javax.swing.SwingUtilities; > 45: import javax.swing.UIManager; > 46: import javax.swing.UnsupportedLookAndFeelException; Suggestion: import javax.swing.SwingUtilities; import javax.swing.UIManager; import javax.swing.UnsupportedLookAndFeelException; import javax.swing.event.ChangeEvent; import javax.swing.event.ChangeListener; test/jdk/javax/swing/JScrollBar/DisableFrameFromScrollBar.java line 117: > 115: do { > 116: Thread.sleep(200); > 117: } while(isAdjusting && !doCheck); Suggestion: } while (isAdjusting && !doCheck); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20346#discussion_r1722670897 PR Review Comment: https://git.openjdk.org/jdk/pull/20346#discussion_r1722659957 PR Review Comment: https://git.openjdk.org/jdk/pull/20346#discussion_r1722662343 PR Review Comment: https://git.openjdk.org/jdk/pull/20346#discussion_r1722670563 PR Review Comment: https://git.openjdk.org/jdk/pull/20346#discussion_r1722661711 PR Review Comment: https://git.openjdk.org/jdk/pull/20346#discussion_r1722672027 PR Review Comment: https://git.openjdk.org/jdk/pull/20346#discussion_r1722673254 From tr at openjdk.org Tue Aug 20 05:09:52 2024 From: tr at openjdk.org (Tejesh R) Date: Tue, 20 Aug 2024 05:09:52 GMT Subject: RFR: 8338041: Keyboard Navigation of JTable, Ctrl Shift RIGHT/LEFT doesn't follow native action in GTK L&F In-Reply-To: <_REjx8TrYFiwhVUPfQ6dOtmKGo7_fCsVtHsnUrdCmzc=.2292c4e5-4ea6-4a88-8dba-91058816419f@github.com> References: <_kMMFJ9LnQOmUmp_3Ob1m3lj2xLKUo-ChL00Clw4xjs=.7e799f69-da05-44f4-9bf7-6e9e43b427b8@github.com> <_REjx8TrYFiwhVUPfQ6dOtmKGo7_fCsVtHsnUrdCmzc=.2292c4e5-4ea6-4a88-8dba-91058816419f@github.com> Message-ID: On Mon, 19 Aug 2024 16:47:37 GMT, Damon Nguyen wrote: > The change itself works fine. I agree with the test changes submitted already. Out of curiosity, what native app did you compare it to when you checked for native behavior? Libre. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20608#issuecomment-2297974627 From abhiscxk at openjdk.org Tue Aug 20 05:41:50 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Tue, 20 Aug 2024 05:41:50 GMT Subject: RFR: 4795384: GTK+ JFileChooser buttons should have mnemonics [v2] In-Reply-To: References: <5CkGHxkNcYb4iyx-nOuJ0S2hXL6_qKqTwS7ZYUL-wks=.e7be5fce-1892-40e4-945c-2983b6fad836@github.com> <77QiXoKfd2AEngI9nFXpQ6pbWLnlQGjDnIhzAIXsk6w=.00233562-5fb5-4b96-9c78-07c01b0702e6@github.com> Message-ID: On Mon, 19 Aug 2024 09:02:34 GMT, Prasanta Sadhukhan wrote: > JDK-8080628 removes these Save and Open mnemonics from gtk and it does from all locales, not only the default locale, I guess for some customer escalation, so it needs to be verified with the fix author if it will regress the expectation. Ok. > If you want to reinstate the mnemonics, then I guess it needs to be reinstated for all locales gtk_de.properties, gtk_es.properties, gtk_fr.properties etc simultaneously I guess only `gtk.properties` needs to update and other locale should be taken care by g11n process as mentioned in one of my previous [PR](https://github.com/openjdk/jdk/pull/9327#discussion_r911212025). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20612#discussion_r1722714450 From psadhukhan at openjdk.org Tue Aug 20 06:38:12 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 20 Aug 2024 06:38:12 GMT Subject: RFR: 6318027: BasicScrollBarUI does not disable timer when enclosing frame is disabled. [v6] In-Reply-To: References: Message-ID: > Issue is > BasicScrollBarUI.ArrowButtonListener starts a timer in mousePressed(), and stops it in mouseReleased(). If the frame containing the scrollbar is disabled between the MOUSE_PRESSED and the MOUSE_RELEASED events, the mouseReleased() method is never called. If the frame is then re-enabled, the still-running timer causes it to scroll all the way to the end. > Fix is to check if [ArrowButtonListener.handledEvent](https://github.com/openjdk/jdk/blame/ee839b7f0ebe471d3877cddd2c87019ccb8ee5ae/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicScrollBarUI.java#L1567) is still set when ActionEvent is processed then stop the timer and reset this variable. > > CI testing is green and also SwingSet2 JScrollPane scrolling with this modification.. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Formatting ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20346/files - new: https://git.openjdk.org/jdk/pull/20346/files/de7ad6b7..612b3ce7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20346&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20346&range=04-05 Stats: 9 lines in 3 files changed: 3 ins; 2 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/20346.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20346/head:pull/20346 PR: https://git.openjdk.org/jdk/pull/20346 From psadhukhan at openjdk.org Tue Aug 20 06:38:13 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 20 Aug 2024 06:38:13 GMT Subject: RFR: 6318027: BasicScrollBarUI does not disable timer when enclosing frame is disabled. [v5] In-Reply-To: References: Message-ID: On Tue, 20 Aug 2024 04:30:25 GMT, Abhishek Kumar wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: >> >> test typo > > src/java.desktop/macosx/classes/com/apple/laf/AquaScrollBarUI.java line 534: > >> 532: if (parent instanceof javax.swing.JFrame par) { >> 533: if (!par.isEnabled()) { >> 534: ((Timer)e.getSource()).stop(); > > Suggestion: > > ((Timer) e.getSource()).stop(); same spacing issue in other places too as mentioned above... > src/java.desktop/share/classes/javax/swing/plaf/basic/BasicScrollBarUI.java line 1611: > >> 1609: /** {@inheritDoc} */ >> 1610: public void actionPerformed(ActionEvent e) { >> 1611: // If frame is disabled and time is started in mousePressed > > Suggestion: > > // If frame is disabled and timer is started in mousePressed ok > src/java.desktop/share/classes/javax/swing/plaf/basic/BasicScrollBarUI.java line 1616: > >> 1614: Component parent = scrollbar.getParent(); >> 1615: do { >> 1616: if (parent instanceof javax.swing.JFrame par) { > > should we import `JFrame` and just use `instanceof JFrame` ? ok > src/java.desktop/share/classes/javax/swing/plaf/basic/BasicScrollBarUI.java line 1617: > >> 1615: do { >> 1616: if (parent instanceof javax.swing.JFrame par) { >> 1617: if (!par.isEnabled()) { > > I think this two condition can be combined into one. > > `if (parent instanceof javax.swing.JFrame par && !par.isEnabled()) > ` No, we need to break if frame is enabled and not look for its parent.. > src/java.desktop/share/classes/javax/swing/plaf/basic/BasicScrollBarUI.java line 1618: > >> 1616: if (parent instanceof javax.swing.JFrame par) { >> 1617: if (!par.isEnabled()) { >> 1618: ((Timer)e.getSource()).stop(); > > Suggestion: > > ((Timer) e.getSource()).stop(); other places in same method has same spacing...they can be done under one cleanup issue.. > test/jdk/javax/swing/JScrollBar/DisableFrameFromScrollBar.java line 117: > >> 115: do { >> 116: Thread.sleep(200); >> 117: } while(isAdjusting && !doCheck); > > Suggestion: > > } while (isAdjusting && !doCheck); ok ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20346#discussion_r1722762061 PR Review Comment: https://git.openjdk.org/jdk/pull/20346#discussion_r1722761162 PR Review Comment: https://git.openjdk.org/jdk/pull/20346#discussion_r1722761309 PR Review Comment: https://git.openjdk.org/jdk/pull/20346#discussion_r1722761821 PR Review Comment: https://git.openjdk.org/jdk/pull/20346#discussion_r1722761077 PR Review Comment: https://git.openjdk.org/jdk/pull/20346#discussion_r1722762234 From psadhukhan at openjdk.org Tue Aug 20 06:40:52 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 20 Aug 2024 06:40:52 GMT Subject: RFR: 4795384: GTK+ JFileChooser buttons should have mnemonics [v2] In-Reply-To: References: <5CkGHxkNcYb4iyx-nOuJ0S2hXL6_qKqTwS7ZYUL-wks=.e7be5fce-1892-40e4-945c-2983b6fad836@github.com> <77QiXoKfd2AEngI9nFXpQ6pbWLnlQGjDnIhzAIXsk6w=.00233562-5fb5-4b96-9c78-07c01b0702e6@github.com> Message-ID: On Tue, 20 Aug 2024 05:39:20 GMT, Abhishek Kumar wrote: >> JDK-8080628 removes these Save and Open mnemonics from gtk and it does from all locales, not only the default locale, I guess for some customer escalation, so it needs to be verified with the fix author if it will regress the expectation. >> >> If you want to reinstate the mnemonics, then I guess it needs to be reinstated for all locales gtk_de.properties, gtk_es.properties, gtk_fr.properties etc simultaneously > >> JDK-8080628 removes these Save and Open mnemonics from gtk and it does from all locales, not only the default locale, I guess for some customer escalation, so it needs to be verified with the fix author if it will regress the expectation. > > Ok. > >> If you want to reinstate the mnemonics, then I guess it needs to be reinstated for all locales gtk_de.properties, gtk_es.properties, gtk_fr.properties etc simultaneously > > > I guess only `gtk.properties` needs to update and other locale should be taken care by g11n process as mentioned in one of my previous [PR](https://github.com/openjdk/jdk/pull/9327#discussion_r911212025). Not sure if it still valid as I guess team doesn't exist anymore and probably Damon is doing the translations now but you can check..I brought it up since JDK-8080628 remove under one PR...so even if g11n process does it, it needs to be done offline and placed under this PR, I presume.. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20612#discussion_r1722765172 From abhiscxk at openjdk.org Tue Aug 20 06:42:52 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Tue, 20 Aug 2024 06:42:52 GMT Subject: RFR: 6318027: BasicScrollBarUI does not disable timer when enclosing frame is disabled. [v5] In-Reply-To: References: Message-ID: On Tue, 20 Aug 2024 06:34:29 GMT, Prasanta Sadhukhan wrote: >> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicScrollBarUI.java line 1617: >> >>> 1615: do { >>> 1616: if (parent instanceof javax.swing.JFrame par) { >>> 1617: if (!par.isEnabled()) { >> >> I think this two condition can be combined into one. >> >> `if (parent instanceof javax.swing.JFrame par && !par.isEnabled()) >> ` > > No, we need to break if frame is enabled and not look for its parent.. ok. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20346#discussion_r1722767220 From abhiscxk at openjdk.org Tue Aug 20 06:47:52 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Tue, 20 Aug 2024 06:47:52 GMT Subject: RFR: 6318027: BasicScrollBarUI does not disable timer when enclosing frame is disabled. [v5] In-Reply-To: References: Message-ID: On Tue, 20 Aug 2024 06:34:47 GMT, Prasanta Sadhukhan wrote: >> src/java.desktop/macosx/classes/com/apple/laf/AquaScrollBarUI.java line 534: >> >>> 532: if (parent instanceof javax.swing.JFrame par) { >>> 533: if (!par.isEnabled()) { >>> 534: ((Timer)e.getSource()).stop(); >> >> Suggestion: >> >> ((Timer) e.getSource()).stop(); > > same spacing issue in other places too as mentioned above... Ok... as you are changing the file I guess you can expand the wild imports, It's up to you. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20346#discussion_r1722772262 From abhiscxk at openjdk.org Tue Aug 20 06:49:51 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Tue, 20 Aug 2024 06:49:51 GMT Subject: RFR: 4795384: GTK+ JFileChooser buttons should have mnemonics [v2] In-Reply-To: References: <5CkGHxkNcYb4iyx-nOuJ0S2hXL6_qKqTwS7ZYUL-wks=.e7be5fce-1892-40e4-945c-2983b6fad836@github.com> <77QiXoKfd2AEngI9nFXpQ6pbWLnlQGjDnIhzAIXsk6w=.00233562-5fb5-4b96-9c78-07c01b0702e6@github.com> Message-ID: On Tue, 20 Aug 2024 06:37:53 GMT, Prasanta Sadhukhan wrote: >>> JDK-8080628 removes these Save and Open mnemonics from gtk and it does from all locales, not only the default locale, I guess for some customer escalation, so it needs to be verified with the fix author if it will regress the expectation. >> >> Ok. >> >>> If you want to reinstate the mnemonics, then I guess it needs to be reinstated for all locales gtk_de.properties, gtk_es.properties, gtk_fr.properties etc simultaneously >> >> >> I guess only `gtk.properties` needs to update and other locale should be taken care by g11n process as mentioned in one of my previous [PR](https://github.com/openjdk/jdk/pull/9327#discussion_r911212025). > > Not sure if it still valid as I guess team doesn't exist anymore and probably Damon is doing the translations now but you can check..I brought it up since JDK-8080628 remove under one PR...so even if g11n process does it, it needs to be done offline and placed under this PR, I presume.. Ok.. I will check with Damon and if it is required to update other locales, will update. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20612#discussion_r1722774839 From psadhukhan at openjdk.org Tue Aug 20 07:12:48 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 20 Aug 2024 07:12:48 GMT Subject: RFR: 4795384: GTK+ JFileChooser buttons should have mnemonics [v2] In-Reply-To: References: <5CkGHxkNcYb4iyx-nOuJ0S2hXL6_qKqTwS7ZYUL-wks=.e7be5fce-1892-40e4-945c-2983b6fad836@github.com> <77QiXoKfd2AEngI9nFXpQ6pbWLnlQGjDnIhzAIXsk6w=.00233562-5fb5-4b96-9c78-07c01b0702e6@github.com> Message-ID: On Tue, 20 Aug 2024 06:47:10 GMT, Abhishek Kumar wrote: >> Not sure if it still valid as I guess team doesn't exist anymore and probably Damon is doing the translations now but you can check..I brought it up since JDK-8080628 remove under one PR...so even if g11n process does it, it needs to be done offline and placed under this PR, I presume.. > > Ok.. I will check with Damon and if it is required to update other locales, will update. I guess this will not require g11 process as there is no new translations needed as such, you just need to add the "&" back which was removed in JDK-8080628 but more important is JDK-8080628 has the change in all trains starting from jdk8 so if you are reverting gtk from it, I guess it needs to be done/backported for all those trains, which is why understanding why JDK-8080628 was done from the fix author is important.. Is Filechooser shown in GTK L&F **same** as what is shown in native file filechooser in ubuntu? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20612#discussion_r1722800463 From tr at openjdk.org Tue Aug 20 07:26:12 2024 From: tr at openjdk.org (Tejesh R) Date: Tue, 20 Aug 2024 07:26:12 GMT Subject: RFR: 8338041: Keyboard Navigation of JTable, Ctrl Shift RIGHT/LEFT doesn't follow native action in GTK L&F [v2] In-Reply-To: <_kMMFJ9LnQOmUmp_3Ob1m3lj2xLKUo-ChL00Clw4xjs=.7e799f69-da05-44f4-9bf7-6e9e43b427b8@github.com> References: <_kMMFJ9LnQOmUmp_3Ob1m3lj2xLKUo-ChL00Clw4xjs=.7e799f69-da05-44f4-9bf7-6e9e43b427b8@github.com> Message-ID: > In JTable, keyboard navigation keys Ctrl Shift RIGHT/LEFT doesn't follow native actions of Linux. In native the actions are extended to end of selected columns cells either LEFT/RIGHT but in swing gtk look and feel the selection is extended to one cell to left/right. This might be taken as reference of Windows OS since the same is observed in Windows native. Hence I have update the actions for Ctrl Shift RIGHT & LEFT. > Added automated test too. The fix is tested in CI and its fine. Tejesh R 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 four additional commits since the last revision: - Updated review comments - Merge branch 'master' of https://git.openjdk.java.net/jdk into branch_8338041 - Test updates - Key action modified + Automatic test added ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20608/files - new: https://git.openjdk.org/jdk/pull/20608/files/ab34edf8..8c436fdd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20608&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20608&range=00-01 Stats: 151966 lines in 3309 files changed: 91575 ins; 44053 del; 16338 mod Patch: https://git.openjdk.org/jdk/pull/20608.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20608/head:pull/20608 PR: https://git.openjdk.org/jdk/pull/20608 From tr at openjdk.org Tue Aug 20 07:38:54 2024 From: tr at openjdk.org (Tejesh R) Date: Tue, 20 Aug 2024 07:38:54 GMT Subject: RFR: 8338041: Keyboard Navigation of JTable, Ctrl Shift RIGHT/LEFT doesn't follow native action in GTK L&F [v2] In-Reply-To: References: <_kMMFJ9LnQOmUmp_3Ob1m3lj2xLKUo-ChL00Clw4xjs=.7e799f69-da05-44f4-9bf7-6e9e43b427b8@github.com> Message-ID: <_fuwKfoRIWOvlw1PWtWgX1ND-yIiNXwsHlEqH2HSqy8=.e2fdb46a-bae9-4dc2-8004-8d195ce14ae0@github.com> On Fri, 16 Aug 2024 10:11:11 GMT, Abhishek Kumar wrote: >> Tejesh R 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 four additional commits since the last revision: >> >> - Updated review comments >> - Merge branch 'master' of https://git.openjdk.java.net/jdk into branch_8338041 >> - Test updates >> - Key action modified + Automatic test added > > test/jdk/javax/swing/plaf/gtk/JTableCtrlShiftRightLeftKeyTest.java line 117: > >> 115: endCellCheck) { >> 116: System.out.println("Selected Columns: "); >> 117: for (int columnAfterTabPress : selectedColumnAfterKeyPress) { > > I don't think it is required to print the selected column.. If at all it is required for debugging I guess `columnAfterTabPress` should be renamed as columns are not selected after tab press. It is required for preliminary analysis, rather than screen capturing on failure cases. I've updated the name. > test/jdk/javax/swing/plaf/gtk/JTableCtrlShiftRightLeftKeyTest.java line 120: > >> 118: System.out.println(columnAfterTabPress); >> 119: } >> 120: String key = (keySelected == KeyEvent.VK_RIGHT)? "RIGHT" : "LEFT"; > > "RIGHT" or "LEFT" can be passed as an argument to this method. This check can be removed. Yes, updated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20608#discussion_r1722833940 PR Review Comment: https://git.openjdk.org/jdk/pull/20608#discussion_r1722832733 From psadhukhan at openjdk.org Tue Aug 20 07:49:07 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 20 Aug 2024 07:49:07 GMT Subject: RFR: 6318027: BasicScrollBarUI does not disable timer when enclosing frame is disabled. [v7] In-Reply-To: References: Message-ID: > Issue is > BasicScrollBarUI.ArrowButtonListener starts a timer in mousePressed(), and stops it in mouseReleased(). If the frame containing the scrollbar is disabled between the MOUSE_PRESSED and the MOUSE_RELEASED events, the mouseReleased() method is never called. If the frame is then re-enabled, the still-running timer causes it to scroll all the way to the end. > Fix is to check if [ArrowButtonListener.handledEvent](https://github.com/openjdk/jdk/blame/ee839b7f0ebe471d3877cddd2c87019ccb8ee5ae/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicScrollBarUI.java#L1567) is still set when ActionEvent is processed then stop the timer and reset this variable. > > CI testing is green and also SwingSet2 JScrollPane scrolling with this modification.. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Expand imports ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20346/files - new: https://git.openjdk.org/jdk/pull/20346/files/612b3ce7..e15a263c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20346&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20346&range=05-06 Stats: 36 lines in 1 file changed: 27 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/20346.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20346/head:pull/20346 PR: https://git.openjdk.org/jdk/pull/20346 From psadhukhan at openjdk.org Tue Aug 20 07:49:07 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 20 Aug 2024 07:49:07 GMT Subject: RFR: 6318027: BasicScrollBarUI does not disable timer when enclosing frame is disabled. [v5] In-Reply-To: References: Message-ID: <7QetVBq5phLRnHY4cgMMH8ABP0Q2sMlNvG_-Uwfn1Ws=.ae89bafc-d122-4af7-89f5-57c642c1bdbc@github.com> On Tue, 20 Aug 2024 06:44:43 GMT, Abhishek Kumar wrote: >> same spacing issue in other places too as mentioned above... > > Ok... as you are changing the file I guess you can expand the wild imports, It's up to you. ok ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20346#discussion_r1722845765 From prappo at openjdk.org Tue Aug 20 09:10:56 2024 From: prappo at openjdk.org (Pavel Rappo) Date: Tue, 20 Aug 2024 09:10:56 GMT Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native [v2] In-Reply-To: References: Message-ID: On Wed, 13 Sep 2023 17:38:28 GMT, Justin Lu wrote: >> JDK .properties files still use ISO-8859-1 encoding with escape sequences. It would improve readability to see the native characters instead of escape sequences (especially for the L10n process). The majority of files changed are localized resource files. >> >> This change converts the Unicode escape sequences in the JDK .properties files (both in src and test) to UTF-8 native characters. Additionally, the build logic is adjusted to read the .properties files in UTF-8 while generating the ListResourceBundle files. >> >> The only escape sequence not converted was `\u0020` as this is used to denote intentional trailing white space. (E.g. `key=This is the value:\u0020`) >> >> The conversion was done using native2ascii with options `-reverse -encoding UTF-8`. >> >> If this PR is integrated, the IDE default encoding for .properties files need to be updated to UTF-8. (IntelliJ IDEA locks .properties files as ISO-8859-1 unless manually changed). > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > Replace InputStreamReader with BufferedReader src/jdk.jartool/share/classes/sun/tools/jar/resources/jar_pt_BR.properties line 95: > 93: > 94: main.usage.summary=Uso: jar [OPTION...] [ [--release VERSION] [-C dir] files] ... > 95: main.usage.summary.try=Tente `jar --ajuda' para obter mais informa??es. I was looking for something unrelated in properties files, and found this. It is surprising to see an option name being localised; it must be a bug. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15694#discussion_r1722966688 From abhiscxk at openjdk.org Tue Aug 20 09:28:48 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Tue, 20 Aug 2024 09:28:48 GMT Subject: RFR: 4795384: GTK+ JFileChooser buttons should have mnemonics [v2] In-Reply-To: References: <5CkGHxkNcYb4iyx-nOuJ0S2hXL6_qKqTwS7ZYUL-wks=.e7be5fce-1892-40e4-945c-2983b6fad836@github.com> <77QiXoKfd2AEngI9nFXpQ6pbWLnlQGjDnIhzAIXsk6w=.00233562-5fb5-4b96-9c78-07c01b0702e6@github.com> Message-ID: <6QnRwTevzYUMUgzcbyN0YZIVt_bdG8AoigN2o-ym4O0=.a3ce8b5b-071f-4506-b29f-7ee50514116e@github.com> On Tue, 20 Aug 2024 07:10:02 GMT, Prasanta Sadhukhan wrote: >I guess this will not require g11 process as there is no new translations needed as such, you just need to add the "&" back which was removed in JDK-8080628 but more important is JDK-8080628 has the change in all trains starting from jdk8 so if you are reverting gtk from it, I guess it needs to be done/backported for all those trains, which is why understanding why JDK-8080628 was done from the fix author is important.. Sure, I will check with the author of JDK-8080628. > Is Filechooser shown in GTK L&F same as what is shown in native file filechooser in ubuntu? Overall UI is different in GTK and native filechooser but the mnemonics are available for open/ cancel/ save buttons. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20612#discussion_r1722995303 From abhiscxk at openjdk.org Tue Aug 20 10:03:51 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Tue, 20 Aug 2024 10:03:51 GMT Subject: RFR: 6318027: BasicScrollBarUI does not disable timer when enclosing frame is disabled. [v7] In-Reply-To: References: Message-ID: On Tue, 20 Aug 2024 07:49:07 GMT, Prasanta Sadhukhan wrote: >> Issue is >> BasicScrollBarUI.ArrowButtonListener starts a timer in mousePressed(), and stops it in mouseReleased(). If the frame containing the scrollbar is disabled between the MOUSE_PRESSED and the MOUSE_RELEASED events, the mouseReleased() method is never called. If the frame is then re-enabled, the still-running timer causes it to scroll all the way to the end. >> Fix is to check if [ArrowButtonListener.handledEvent](https://github.com/openjdk/jdk/blame/ee839b7f0ebe471d3877cddd2c87019ccb8ee5ae/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicScrollBarUI.java#L1567) is still set when ActionEvent is processed then stop the timer and reset this variable. >> >> CI testing is green and also SwingSet2 JScrollPane scrolling with this modification.. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Expand imports minor sorting of imports. src/java.desktop/macosx/classes/com/apple/laf/AquaScrollBarUI.java line 35: > 33: import java.awt.Point; > 34: import java.awt.Rectangle; > 35: import java.awt.Insets; Suggestion: import java.awt.Graphics; import java.awt.Insets; import java.awt.Point; import java.awt.Rectangle; src/java.desktop/macosx/classes/com/apple/laf/AquaScrollBarUI.java line 61: > 59: import apple.laf.JRSUIConstants.Hit; > 60: import apple.laf.JRSUIConstants.Orientation; > 61: import apple.laf.JRSUIConstants.NothingToScroll; Suggestion: import apple.laf.JRSUIConstants.Hit; import apple.laf.JRSUIConstants.NothingToScroll; import apple.laf.JRSUIConstants.Orientation; ------------- PR Review: https://git.openjdk.org/jdk/pull/20346#pullrequestreview-2247551270 PR Review Comment: https://git.openjdk.org/jdk/pull/20346#discussion_r1723045015 PR Review Comment: https://git.openjdk.org/jdk/pull/20346#discussion_r1723046222 From tr at openjdk.org Tue Aug 20 11:08:50 2024 From: tr at openjdk.org (Tejesh R) Date: Tue, 20 Aug 2024 11:08:50 GMT Subject: RFR: 8329756: [macos] "javax/swing/JTable/KeyBoardNavigation.java" fail because most combinations of navigational keys with the Ctrl key do not work [v3] In-Reply-To: References: Message-ID: On Fri, 9 Aug 2024 21:53:11 GMT, Alisen Chung wrote: >> Tejesh R has updated the pull request incrementally with one additional commit since the last revision: >> >> Review fix > > test/jdk/javax/swing/JTable/KeyBoardNavigation.java line 1: > >> 1: /* > > When I run this test I need to expand the test window, might be better to explicitly set the size of the test frame to be larger Can't expand more due to screen height restrictions. So have chosen optimal size. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20331#discussion_r1723127725 From psadhukhan at openjdk.org Tue Aug 20 11:30:06 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 20 Aug 2024 11:30:06 GMT Subject: RFR: 6318027: BasicScrollBarUI does not disable timer when enclosing frame is disabled. [v8] In-Reply-To: References: Message-ID: > Issue is > BasicScrollBarUI.ArrowButtonListener starts a timer in mousePressed(), and stops it in mouseReleased(). If the frame containing the scrollbar is disabled between the MOUSE_PRESSED and the MOUSE_RELEASED events, the mouseReleased() method is never called. If the frame is then re-enabled, the still-running timer causes it to scroll all the way to the end. > Fix is to check if [ArrowButtonListener.handledEvent](https://github.com/openjdk/jdk/blame/ee839b7f0ebe471d3877cddd2c87019ccb8ee5ae/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicScrollBarUI.java#L1567) is still set when ActionEvent is processed then stop the timer and reset this variable. > > CI testing is green and also SwingSet2 JScrollPane scrolling with this modification.. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Sort imports ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20346/files - new: https://git.openjdk.org/jdk/pull/20346/files/e15a263c..f3a0e607 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20346&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20346&range=06-07 Stats: 4 lines in 1 file changed: 2 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20346.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20346/head:pull/20346 PR: https://git.openjdk.org/jdk/pull/20346 From aivanov at openjdk.org Tue Aug 20 13:51:26 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 20 Aug 2024 13:51:26 GMT Subject: RFR: 8332901: Choice/SelectCurrentItemTest/SelectCurrentItemTest.java doesn't open popup on macOS [v3] In-Reply-To: References: Message-ID: > I looked at `java/awt/Choice/SelectCurrentItemTest/SelectCurrentItemTest.java`, ran it and noticed that the test does not open the popup of the `Choice` component on macOS 14.x. > > If the popup does not open, the test does not verify anything ? it always passes. > > I refactored the test and added a mouse listener to the `Choice` component. If mouse click isn't registered, the test fails. > > The updated test fails for me locally on macOS Sonoma 14.5. This is likely the result of [JDK-8322653](https://bugs.openjdk.org/browse/JDK-8322653): _[macos14] : Mouse clicks are not received within 3 pixels of the window boundary_. > > The updated test passes on CI. Alexey Ivanov has updated the pull request incrementally with four additional commits since the last revision: - Remove SelectNewItemTest from ProblemList.txt - Refactor Select{New,Current}ItemTest Encapsulate the common logic in SelectCurrentItemTest. Provide overridable checkXXX() methods to modify conditions. Provide an overridable method which defines where to click in the choice popup to select an item. - Move *CurrentItem*.java and *NewItem*.java to Choice/SelectItem/ - Refactor SelectNewItemTest similar to SelectCurrentItemTest Use latches to control test flow instead of delays and volatile variables. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20601/files - new: https://git.openjdk.org/jdk/pull/20601/files/c288ab68..e6d0481b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20601&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20601&range=01-02 Stats: 618 lines in 5 files changed: 276 ins; 342 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20601.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20601/head:pull/20601 PR: https://git.openjdk.org/jdk/pull/20601 From aivanov at openjdk.org Tue Aug 20 14:47:23 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 20 Aug 2024 14:47:23 GMT Subject: RFR: 8332901: Choice/SelectCurrentItemTest/SelectCurrentItemTest.java doesn't open popup on macOS [v4] In-Reply-To: References: Message-ID: > I looked at `java/awt/Choice/SelectCurrentItemTest/SelectCurrentItemTest.java`, ran it and noticed that the test does not open the popup of the `Choice` component on macOS 14.x. > > If the popup does not open, the test does not verify anything ? it always passes. > > I refactored the test and added a mouse listener to the `Choice` component. If mouse click isn't registered, the test fails. > > The updated test fails for me locally on macOS Sonoma 14.5. This is likely the result of [JDK-8322653](https://bugs.openjdk.org/browse/JDK-8322653): _[macos14] : Mouse clicks are not received within 3 pixels of the window boundary_. > > The updated test passes on CI. Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision: Amend the copyright year in SelectCurrentItemTest ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20601/files - new: https://git.openjdk.org/jdk/pull/20601/files/e6d0481b..28ea7d23 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20601&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20601&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20601.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20601/head:pull/20601 PR: https://git.openjdk.org/jdk/pull/20601 From aivanov at openjdk.org Tue Aug 20 14:55:52 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 20 Aug 2024 14:55:52 GMT Subject: RFR: 8332901: Choice/SelectCurrentItemTest/SelectCurrentItemTest.java doesn't open popup on macOS [v4] In-Reply-To: References: Message-ID: On Tue, 20 Aug 2024 14:47:23 GMT, Alexey Ivanov wrote: >> I looked at `java/awt/Choice/SelectCurrentItemTest/SelectCurrentItemTest.java`, ran it and noticed that the test does not open the popup of the `Choice` component on macOS 14.x. >> >> If the popup does not open, the test does not verify anything ? it always passes. >> >> I refactored the test and added a mouse listener to the `Choice` component. If mouse click isn't registered, the test fails. >> >> The updated test fails for me locally on macOS Sonoma 14.5. This is likely the result of [JDK-8322653](https://bugs.openjdk.org/browse/JDK-8322653): _[macos14] : Mouse clicks are not received within 3 pixels of the window boundary_. >> >> The updated test passes on CI. > > Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision: > > Amend the copyright year in SelectCurrentItemTest While I worked on another backport, I found `SelectNewItemTest.java`. This test is basically the same: the only difference is that it selects *a new item* in the choice popup and expects `ItemEvent`. I updated the other test too and refactored both of them to re-use common functionality. I moved both tests ? `test/jdk/java/awt/Choice/SelectCurrentItemTest/SelectCurrentItemTest.java` and `test/jdk/java/awt/Choice/SelectNewItemTest/SelectNewItemTest.java` ? to `test/jdk/java/awt/Choice/SelectItem/` folder. The `SelectCurrentItemTest` is the main one as the oldest; and `SelectNewItemTest` now extends `SelectCurrentItemTest`. Both updated tests pass in CI and locally on macOS 14.x. Non-resizable frame is used to workaround [JDK-8322653](https://bugs.openjdk.org/browse/JDK-8322653). I will update JBS issue and the description of the PR accordingly. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20601#issuecomment-2299059110 From aivanov at openjdk.org Tue Aug 20 15:22:49 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 20 Aug 2024 15:22:49 GMT Subject: RFR: 8332901: Select{Current,New}ItemTest.java for Choice don't open popup on macOS [v4] In-Reply-To: References: Message-ID: On Tue, 20 Aug 2024 14:47:23 GMT, Alexey Ivanov wrote: >> I looked at `java/awt/Choice/SelectCurrentItemTest/SelectCurrentItemTest.java`, ran it and noticed that the test does not open the popup of the `Choice` component on macOS 14.x. >> >> If the popup does not open, the test does not verify anything ? it always passes. >> >> I refactored the test and added a mouse listener to the `Choice` component. If mouse click isn't registered, the test fails. >> >> Later, I found a similar test: `test/jdk/java/awt/Choice/SelectNewItemTest/SelectNewItemTest.java`. It clicks on another item in the Choice popup and expects to receive `ItemEvent`. >> >> I refactored both tests and moved them into `Choice/SelectItem` folder. >> >> `SelectCurrentItemTest` encapsulates the common test logic and provides overridable methods to customise conditions for `SelectNewItemTest`. >> >> Now, `SelectNewItemTest` extends `SelectCurrentItemTest` and overrides the conditions as well as the coordinates for clicking the popup of the `Choice` component. >> >> ~~The updated test fails for me locally on macOS Sonoma 14.5. This is likely the result of [JDK-8322653](https://bugs.openjdk.org/browse/JDK-8322653): _[macos14] : Mouse clicks are not received within 3 pixels of the window boundary_.~~ >> >> To work around JDK-8322653, both tests use non-resizable frame. Both updated tests pass on CI and locally on macOS 14.5. This is why I removed `SelectNewItemTest` from problem-list. > > Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision: > > Amend the copyright year in SelectCurrentItemTest Unfortunately, Git does not recognise the files are moved with so many additional changes. As a workaround, I can submit a new issue and integrate it where the files are moved only. This way we could preserve the history of the changes to the tests. Do you have any opinions? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20601#issuecomment-2299122660 From naoto at openjdk.org Tue Aug 20 15:30:58 2024 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 20 Aug 2024 15:30:58 GMT Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native [v2] In-Reply-To: References: Message-ID: <9wZvcGjRkpfRm02paHISi86ynU0aYrW9WoinmyIb-RM=.9795a780-b857-4de3-bca6-075305fbd9f7@github.com> On Tue, 20 Aug 2024 09:07:54 GMT, Pavel Rappo wrote: >> Justin Lu has updated the pull request incrementally with one additional commit since the last revision: >> >> Replace InputStreamReader with BufferedReader > > src/jdk.jartool/share/classes/sun/tools/jar/resources/jar_pt_BR.properties line 95: > >> 93: >> 94: main.usage.summary=Uso: jar [OPTION...] [ [--release VERSION] [-C dir] files] ... >> 95: main.usage.summary.try=Tente `jar --ajuda' para obter mais informa??es. > > I was looking for something unrelated in properties files, and found this. It is surprising to see an option name being localised; it must be a bug. Good catch, Pavel. It is indeed a bug. This type of overtranslation l10n bug happens all the time, and hard to catch. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15694#discussion_r1723520963 From honkar at openjdk.org Tue Aug 20 16:48:20 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Tue, 20 Aug 2024 16:48:20 GMT Subject: RFR: 8332901: Select{Current,New}ItemTest.java for Choice don't open popup on macOS [v4] In-Reply-To: References: Message-ID: On Tue, 20 Aug 2024 15:20:35 GMT, Alexey Ivanov wrote: > Unfortunately, Git does not recognise the files are moved with so many additional changes. > > As a workaround, I can submit a new issue and integrate it where the files are moved only. This way we could preserve the history of the changes to the tests. > > Do you have any opinions? @aivanov-jdk Does it work if you move the test files using `git mv`, commit it and in the next commit modify the files I mean 2 separate commits - one for move and another one that modifies the files. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20601#issuecomment-2299304448 From aivanov at openjdk.org Tue Aug 20 17:04:11 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 20 Aug 2024 17:04:11 GMT Subject: RFR: 8332901: Select{Current,New}ItemTest.java for Choice don't open popup on macOS [v4] In-Reply-To: References: Message-ID: On Tue, 20 Aug 2024 15:20:35 GMT, Alexey Ivanov wrote: >> Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision: >> >> Amend the copyright year in SelectCurrentItemTest > > Unfortunately, Git does not recognise the files are moved with so many additional changes. > > As a workaround, I can submit a new issue and integrate it where the files are moved only. This way we could preserve the history of the changes to the tests. > > Do you have any opinions? > @aivanov-jdk Does it work if you move the test files using `git mv`, commit it and in the next commit modify the files > I mean 2 separate commits - one for move and another one that modifies the files. That's exactly what I did if you look at the history of the commits. It doesn't work in the code review. It won't work after integration either. After integration, individual commits are lost, everything is squashed into one changeset. The only reliable way to preserve the history across renames (and modification) is to integrate a separate changeset where the files are only renamed without any modifications. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20601#issuecomment-2299331866 From honkar at openjdk.org Tue Aug 20 17:51:03 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Tue, 20 Aug 2024 17:51:03 GMT Subject: RFR: 8332901: Select{Current,New}ItemTest.java for Choice don't open popup on macOS [v4] In-Reply-To: References: Message-ID: On Tue, 20 Aug 2024 14:47:23 GMT, Alexey Ivanov wrote: >> I looked at `java/awt/Choice/SelectCurrentItemTest/SelectCurrentItemTest.java`, ran it and noticed that the test does not open the popup of the `Choice` component on macOS 14.x. >> >> If the popup does not open, the test does not verify anything ? it always passes. >> >> I refactored the test and added a mouse listener to the `Choice` component. If mouse click isn't registered, the test fails. >> >> Later, I found a similar test: `test/jdk/java/awt/Choice/SelectNewItemTest/SelectNewItemTest.java`. It clicks on another item in the Choice popup and expects to receive `ItemEvent`. >> >> I refactored both tests and moved them into `Choice/SelectItem` folder. >> >> `SelectCurrentItemTest` encapsulates the common test logic and provides overridable methods to customise conditions for `SelectNewItemTest`. >> >> Now, `SelectNewItemTest` extends `SelectCurrentItemTest` and overrides the conditions as well as the coordinates for clicking the popup of the `Choice` component. >> >> ~~The updated test fails for me locally on macOS Sonoma 14.5. This is likely the result of [JDK-8322653](https://bugs.openjdk.org/browse/JDK-8322653): _[macos14] : Mouse clicks are not received within 3 pixels of the window boundary_.~~ >> >> To work around JDK-8322653, both tests use non-resizable frame. Both updated tests pass on CI and locally on macOS 14.5. This is why I removed `SelectNewItemTest` from problem-list. > > Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision: > > Amend the copyright year in SelectCurrentItemTest LGTM Ideally these two tests can be combined since they are very similar and it also means one test less to run on CI. But since you are reusing the `SelectCurrentItemTest` test code and overriding the methods, this approach is cleaner and doesn't make the test complicated. ------------- Marked as reviewed by honkar (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20601#pullrequestreview-2248662075 From aivanov at openjdk.org Tue Aug 20 20:07:04 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 20 Aug 2024 20:07:04 GMT Subject: RFR: 8332901: Select{Current,New}ItemTest.java for Choice don't open popup on macOS [v4] In-Reply-To: References: Message-ID: On Tue, 20 Aug 2024 17:48:24 GMT, Harshitha Onkar wrote: > Ideally these two tests can be combined since they are very similar and it also means one test less to run on CI. I believe the difference is close to negligible. Creating UI and waiting for it to be displayed likely takes more than compiling the test source code and starting a new JVM process. > But since you are reusing the `SelectCurrentItemTest` test code and overriding the methods, this approach is cleaner and doesn't make the test complicated. Yes, I think it's cleaner this way. Each test does one thing and tests its own scenario. The old `SelectNewItemTest` also verified the case where the same item was selected from the popup again. Thus, it repeated what `SelectCurrentItemTest` did for a long time. So I removed it. I found another test which tests the same scenario as `SelectNewItemTest`, it's `test/jdk/java/awt/event/ComponentEvent/ComponentItemEventTest.java`. It was added in #11786. I'm going to submit a bug to remove this scenario from the `ComponentItemEventTest` test. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20601#issuecomment-2299668696 From achung at openjdk.org Tue Aug 20 23:53:45 2024 From: achung at openjdk.org (Alisen Chung) Date: Tue, 20 Aug 2024 23:53:45 GMT Subject: RFR: 7188058: Background of TextComponents are not changing colors to the default disabled color when set to uneditable [v5] In-Reply-To: References: Message-ID: <095gCTeexK0MP5AzEUrNwAOtXDzFiNDUIjd5LHbh-sY=.fb49a844-8568-4713-9f34-8e1641e11efe@github.com> > Currently the bug described in the issue is that the colors of the TextComponents do not change when setting TextComponents to uneditable. The default uneditable color (SystemColor.control) happens to be the same as the default for the editable color for some L&Fs, so the fix may not be initially noticeable. However, the bug still exists where the the color is not being changed when changing between editable and uneditable. You can check by changing TextComponent.getBackground() code to return Color.GRAY on line 342 and you can see that TextComponents are not changing to a gray background when set to uneditable. > > This fix adds a private setBackground method in TextComponent so that TextArea and TextField can change the background color to the correct color (SystemColor.control) when set uneditable by overriding the TextComponent setEditable. You can verify the fix by changing this color to Color.GRAY and verifying the backgrounds change to gray when the TextComponents are disabled. Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: fix import ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19876/files - new: https://git.openjdk.org/jdk/pull/19876/files/ccf63c8a..f8b94687 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19876&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19876&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/19876.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19876/head:pull/19876 PR: https://git.openjdk.org/jdk/pull/19876 From achung at openjdk.org Tue Aug 20 23:54:04 2024 From: achung at openjdk.org (Alisen Chung) Date: Tue, 20 Aug 2024 23:54:04 GMT Subject: RFR: 4795384: GTK+ JFileChooser buttons should have mnemonics [v2] In-Reply-To: References: Message-ID: <9G6-JjDdYFObG1jpDyROdE66wUgYhQrD18F_2MIAYnA=.c42fa0a3-d482-4a1a-a71f-7a5bfa72958d@github.com> On Mon, 19 Aug 2024 07:32:26 GMT, Abhishek Kumar wrote: >> JFileChooser don't have the mnemonics for open and save button in GTK L&F. Fix is to add mnemonics for open and save button. >> Fix can be verified by Swingset2 demo application. Mnemonics in GTK L&F are visible once alt key is pressed. >> After running the SwingSet2 application, change the `L&F to GTK` and select` JFileChooser demo` from toolbar. Click on `Select Plain JFileChooser` button and then press alt key to verify the mnemonics. > > Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: > > Add mnemonics for Save and change Selection mnemonics src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk.properties line 67: > 65: FileChooser.saveDialogTitle.textAndMnemonic=Save > 66: FileChooser.openDialogTitle.textAndMnemonic=Open > 67: FileChooser.pathLabel.textAndMnemonic=S&election: is this a typo? why is the S moved before the &? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20612#discussion_r1724108666 From dnguyen at openjdk.org Wed Aug 21 00:20:06 2024 From: dnguyen at openjdk.org (Damon Nguyen) Date: Wed, 21 Aug 2024 00:20:06 GMT Subject: RFR: 8338103: Stabilize and open source a Swing OGL ButtonResizeTest [v2] In-Reply-To: References: <8--CxVHS_jclzzN2PWYkI0W3yr7w1al5PSqRdis-PUc=.2f57c378-49cc-40bc-b042-f6aa9bfed07d@github.com> Message-ID: On Mon, 19 Aug 2024 11:00:22 GMT, Manukumar V S wrote: >> This PR creates a new test by stabilising and open sourcing a closed test. >> This test verifies that the OpenGL pipeline does not create artifacts with swing components after window is zoomed to maximum size and then resized back to normal. >> This test is run twice, with and without the flags "-Dsun.java2d.opengl=True -Dsun.java2d.opengl.fbobject=false" . >> >> This is tested(15 times per platform) in all the available mach5 headful platforms and found to be stable. > > Manukumar V S has updated the pull request incrementally with one additional commit since the last revision: > > Review comments fixed : Moved the button up to prevent mix up, saved the diff image in failure cases test/jdk/javax/swing/JButton/SwingButtonResizeTestWithOpenGL.java line 126: > 124: > 125: frame.setExtendedState(JFrame.MAXIMIZED_BOTH); //maximize > 126: // frame from normal size Suggestion: // some platforms may not support maximize frame if (frame.getToolkit().isFrameStateSupported(JFrame.MAXIMIZED_BOTH)) { robot.waitForIdle(); frame.setExtendedState(JFrame.MAXIMIZED_BOTH); //maximize // frame from normal size I see some of your comments with and without a space after the `//`. Maybe standardize this to have the space. test/jdk/javax/swing/JButton/SwingButtonResizeTestWithOpenGL.java line 148: > 146: int numDiffPixels = di.getNumDiffPixels(); > 147: if (numDiffPixels != 0) { > 148: throw new RuntimeException("Button renderings are " + "different after window resize," + " num of Diff Pixels=" + numDiffPixels); Why are these prints composed of multiple strings with `+` joining them instead of one continuous string sentence? Seems a little odd and is seen multiple times throughout the test. Suggestion: System.out.println("Getting image of JButton after resize..image2"); bimage2 = getButtonImage(); File file2 = new File("image2.png"); saveButtonImage(bimage2, file2); // compare button images from before and after frame resize DiffImage di = new DiffImage(bimage1.getWidth(), bimage1.getHeight()); di.compare(bimage1, bimage2); System.out.println("Taking the diff of two images, image1 and image2"); // results of image comparison int numDiffPixels = di.getNumDiffPixels(); if (numDiffPixels != 0) { throw new RuntimeException("Button renderings are different after window resize, num of Diff Pixels = " + numDiffPixels); test/jdk/javax/swing/JButton/SwingButtonResizeTestWithOpenGL.java line 260: > 258: nDiff = 0; > 259: for (x = minx1; x < (minx1 + w1); x++) { > 260: for (y = miny1; y < (miny1 + h1); y++) { What's wrong with declaring the variable inside the for loop parameters? Condenses the code a bit too. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20532#discussion_r1724122331 PR Review Comment: https://git.openjdk.org/jdk/pull/20532#discussion_r1724123521 PR Review Comment: https://git.openjdk.org/jdk/pull/20532#discussion_r1724126553 From abhiscxk at openjdk.org Wed Aug 21 03:53:06 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Wed, 21 Aug 2024 03:53:06 GMT Subject: RFR: 4795384: GTK+ JFileChooser buttons should have mnemonics [v2] In-Reply-To: <9G6-JjDdYFObG1jpDyROdE66wUgYhQrD18F_2MIAYnA=.c42fa0a3-d482-4a1a-a71f-7a5bfa72958d@github.com> References: <9G6-JjDdYFObG1jpDyROdE66wUgYhQrD18F_2MIAYnA=.c42fa0a3-d482-4a1a-a71f-7a5bfa72958d@github.com> Message-ID: On Tue, 20 Aug 2024 23:51:08 GMT, Alisen Chung wrote: >> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: >> >> Add mnemonics for Save and change Selection mnemonics > > src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk.properties line 67: > >> 65: FileChooser.saveDialogTitle.textAndMnemonic=Save >> 66: FileChooser.openDialogTitle.textAndMnemonic=Open >> 67: FileChooser.pathLabel.textAndMnemonic=S&election: > > is this a typo? why is the S moved before the &? No, that's not a typo. Proposed fix is to have mnemonic &S for save &e for Selection. Refer https://github.com/openjdk/jdk/pull/20612#discussion_r1720283148 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20612#discussion_r1724336908 From abhiscxk at openjdk.org Wed Aug 21 05:05:10 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Wed, 21 Aug 2024 05:05:10 GMT Subject: RFR: 6318027: BasicScrollBarUI does not disable timer when enclosing frame is disabled. [v8] In-Reply-To: References: Message-ID: On Tue, 20 Aug 2024 11:30:06 GMT, Prasanta Sadhukhan wrote: >> Issue is >> BasicScrollBarUI.ArrowButtonListener starts a timer in mousePressed(), and stops it in mouseReleased(). If the frame containing the scrollbar is disabled between the MOUSE_PRESSED and the MOUSE_RELEASED events, the mouseReleased() method is never called. If the frame is then re-enabled, the still-running timer causes it to scroll all the way to the end. >> Fix is to check if [ArrowButtonListener.handledEvent](https://github.com/openjdk/jdk/blame/ee839b7f0ebe471d3877cddd2c87019ccb8ee5ae/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicScrollBarUI.java#L1567) is still set when ActionEvent is processed then stop the timer and reset this variable. >> >> CI testing is green and also SwingSet2 JScrollPane scrolling with this modification.. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Sort imports Ran the test and verified the latest fix on different platforms (mac, windows and linux). It works as expected and looks good to me now. ------------- Marked as reviewed by abhiscxk (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20346#pullrequestreview-2249722192 From tr at openjdk.org Wed Aug 21 06:54:04 2024 From: tr at openjdk.org (Tejesh R) Date: Wed, 21 Aug 2024 06:54:04 GMT Subject: RFR: 6318027: BasicScrollBarUI does not disable timer when enclosing frame is disabled. [v8] In-Reply-To: References: Message-ID: On Tue, 20 Aug 2024 11:30:06 GMT, Prasanta Sadhukhan wrote: >> Issue is >> BasicScrollBarUI.ArrowButtonListener starts a timer in mousePressed(), and stops it in mouseReleased(). If the frame containing the scrollbar is disabled between the MOUSE_PRESSED and the MOUSE_RELEASED events, the mouseReleased() method is never called. If the frame is then re-enabled, the still-running timer causes it to scroll all the way to the end. >> Fix is to check if [ArrowButtonListener.handledEvent](https://github.com/openjdk/jdk/blame/ee839b7f0ebe471d3877cddd2c87019ccb8ee5ae/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicScrollBarUI.java#L1567) is still set when ActionEvent is processed then stop the timer and reset this variable. >> >> CI testing is green and also SwingSet2 JScrollPane scrolling with this modification.. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Sort imports Looks good to me. ------------- Marked as reviewed by tr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20346#pullrequestreview-2249878461 From psadhukhan at openjdk.org Wed Aug 21 07:07:12 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 21 Aug 2024 07:07:12 GMT Subject: Integrated: 6318027: BasicScrollBarUI does not disable timer when enclosing frame is disabled. In-Reply-To: References: Message-ID: On Fri, 26 Jul 2024 06:03:28 GMT, Prasanta Sadhukhan wrote: > Issue is > BasicScrollBarUI.ArrowButtonListener starts a timer in mousePressed(), and stops it in mouseReleased(). If the frame containing the scrollbar is disabled between the MOUSE_PRESSED and the MOUSE_RELEASED events, the mouseReleased() method is never called. If the frame is then re-enabled, the still-running timer causes it to scroll all the way to the end. > Fix is to check if [ArrowButtonListener.handledEvent](https://github.com/openjdk/jdk/blame/ee839b7f0ebe471d3877cddd2c87019ccb8ee5ae/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicScrollBarUI.java#L1567) is still set when ActionEvent is processed then stop the timer and reset this variable. > > CI testing is green and also SwingSet2 JScrollPane scrolling with this modification.. This pull request has now been integrated. Changeset: cafb3dc4 Author: Prasanta Sadhukhan URL: https://git.openjdk.org/jdk/commit/cafb3dc49157daf12c1a0e5d78acca8188c56918 Stats: 260 lines in 3 files changed: 247 ins; 0 del; 13 mod 6318027: BasicScrollBarUI does not disable timer when enclosing frame is disabled. Reviewed-by: abhiscxk, tr ------------- PR: https://git.openjdk.org/jdk/pull/20346 From psadhukhan at openjdk.org Wed Aug 21 08:39:31 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 21 Aug 2024 08:39:31 GMT Subject: RFR: 8335231: [macos] Test java/awt/print/PrinterJob/Cancel/PrinterJobCancel.java failed on macOS because the case didn't get the expected PrintAbortException [v7] In-Reply-To: References: Message-ID: > When a printjob is cancelled midway, `PrinterAbortException `was not thrown in macos. because > firstly,` cancelCheck` invokes` LWCToolkit.invokeLater` with null as parameter causing it to fail with NPE and > secondly PrinterAbortException was consumed silently when `printLoop` throws any exception > which is rectified to throw the PrinterAbortException when encountered.. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Store if its PrinterAbortException ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20027/files - new: https://git.openjdk.org/jdk/pull/20027/files/6a1c7ce5..44ef8cda Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20027&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20027&range=05-06 Stats: 4 lines in 2 files changed: 2 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20027.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20027/head:pull/20027 PR: https://git.openjdk.org/jdk/pull/20027 From mvs at openjdk.org Wed Aug 21 19:12:41 2024 From: mvs at openjdk.org (Manukumar V S) Date: Wed, 21 Aug 2024 19:12:41 GMT Subject: RFR: 8338103: Stabilize and open source a Swing OGL ButtonResizeTest [v3] In-Reply-To: <8--CxVHS_jclzzN2PWYkI0W3yr7w1al5PSqRdis-PUc=.2f57c378-49cc-40bc-b042-f6aa9bfed07d@github.com> References: <8--CxVHS_jclzzN2PWYkI0W3yr7w1al5PSqRdis-PUc=.2f57c378-49cc-40bc-b042-f6aa9bfed07d@github.com> Message-ID: > This PR creates a new test by stabilising and open sourcing a closed test. > This test verifies that the OpenGL pipeline does not create artifacts with swing components after window is zoomed to maximum size and then resized back to normal. > This test is run twice, with and without the flags "-Dsun.java2d.opengl=True -Dsun.java2d.opengl.fbobject=false" . > > This is tested(15 times per platform) in all the available mach5 headful platforms and found to be stable. Manukumar V S has updated the pull request incrementally with one additional commit since the last revision: Review comments fixed: Standardized comments, avoid unnecessary variables and string concats ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20532/files - new: https://git.openjdk.org/jdk/pull/20532/files/7549ebf0..20f33fd8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20532&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20532&range=01-02 Stats: 15 lines in 1 file changed: 0 ins; 3 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/20532.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20532/head:pull/20532 PR: https://git.openjdk.org/jdk/pull/20532 From duke at openjdk.org Wed Aug 21 19:24:04 2024 From: duke at openjdk.org (lawrence.andrews) Date: Wed, 21 Aug 2024 19:24:04 GMT Subject: RFR: 8338103: Stabilize and open source a Swing OGL ButtonResizeTest [v3] In-Reply-To: References: <8--CxVHS_jclzzN2PWYkI0W3yr7w1al5PSqRdis-PUc=.2f57c378-49cc-40bc-b042-f6aa9bfed07d@github.com> Message-ID: On Wed, 21 Aug 2024 19:12:41 GMT, Manukumar V S wrote: >> This PR creates a new test by stabilising and open sourcing a closed test. >> This test verifies that the OpenGL pipeline does not create artifacts with swing components after window is zoomed to maximum size and then resized back to normal. >> This test is run twice, with and without the flags "-Dsun.java2d.opengl=True -Dsun.java2d.opengl.fbobject=false" . >> >> This is tested(15 times per platform) in all the available mach5 headful platforms and found to be stable. > > Manukumar V S has updated the pull request incrementally with one additional commit since the last revision: > > Review comments fixed: Standardized comments, avoid unnecessary variables and string concats test/jdk/javax/swing/JButton/SwingButtonResizeTestWithOpenGL.java line 133: > 131: System.out.println("Frame is back to normal"); > 132: frame.setExtendedState(JFrame.NORMAL); //resize from > 133: // maximum size to normal I think the comment should be above the frame.setExtendedState(JFrame.NORMAL); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20532#discussion_r1725644440 From ihse at openjdk.org Wed Aug 21 21:58:34 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 21 Aug 2024 21:58:34 GMT Subject: RFR: 8338768: Introduce runtime lookup to check for static builds Message-ID: As a preparation for Hermetic Java, we need to have a way to look up during runtime if we are using a statically linked library or not. This change will be the first step needed towards compiling the object files only once, and then link them into either dynamic or static libraries. (The only exception will be the linktype.c[pp] files, which needs to be compiled twice, once for the dynamic libraries and once for the static libraries.) Getting there will require further work though. This is part of the changes that make up the draft PR https://github.com/openjdk/jdk/pull/19478, which I have broken out. ------------- Commit messages: - 8338768: Introduce runtime lookup to check for static builds Changes: https://git.openjdk.org/jdk/pull/20666/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20666&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8338768 Stats: 203 lines in 11 files changed: 109 ins; 21 del; 73 mod Patch: https://git.openjdk.org/jdk/pull/20666.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20666/head:pull/20666 PR: https://git.openjdk.org/jdk/pull/20666 From ihse at openjdk.org Wed Aug 21 22:14:40 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 21 Aug 2024 22:14:40 GMT Subject: RFR: 8338768: Introduce runtime lookup to check for static builds [v2] In-Reply-To: References: Message-ID: <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com> > As a preparation for Hermetic Java, we need to have a way to look up during runtime if we are using a statically linked library or not. > > This change will be the first step needed towards compiling the object files only once, and then link them into either dynamic or static libraries. (The only exception will be the linktype.c[pp] files, which needs to be compiled twice, once for the dynamic libraries and once for the static libraries.) Getting there will require further work though. > > This is part of the changes that make up the draft PR https://github.com/openjdk/jdk/pull/19478, which I have broken out. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Also update build to link properly ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20666/files - new: https://git.openjdk.org/jdk/pull/20666/files/e917f6a2..072a910d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20666&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20666&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20666.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20666/head:pull/20666 PR: https://git.openjdk.org/jdk/pull/20666 From prr at openjdk.org Wed Aug 21 23:54:05 2024 From: prr at openjdk.org (Phil Race) Date: Wed, 21 Aug 2024 23:54:05 GMT Subject: RFR: 8338768: Introduce runtime lookup to check for static builds [v2] In-Reply-To: <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com> References: <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com> Message-ID: On Wed, 21 Aug 2024 22:14:40 GMT, Magnus Ihse Bursie wrote: >> As a preparation for Hermetic Java, we need to have a way to look up during runtime if we are using a statically linked library or not. >> >> This change will be the first step needed towards compiling the object files only once, and then link them into either dynamic or static libraries. (The only exception will be the linktype.c[pp] files, which needs to be compiled twice, once for the dynamic libraries and once for the static libraries.) Getting there will require further work though. >> >> This is part of the changes that make up the draft PR https://github.com/openjdk/jdk/pull/19478, which I have broken out. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Also update build to link properly AWT changes look fine. ------------- Marked as reviewed by prr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20666#pullrequestreview-2252384240 From honkar at openjdk.org Thu Aug 22 00:05:08 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Thu, 22 Aug 2024 00:05:08 GMT Subject: RFR: 8338041: Keyboard Navigation of JTable, Ctrl Shift RIGHT/LEFT doesn't follow native action in GTK L&F [v2] In-Reply-To: References: <_kMMFJ9LnQOmUmp_3Ob1m3lj2xLKUo-ChL00Clw4xjs=.7e799f69-da05-44f4-9bf7-6e9e43b427b8@github.com> Message-ID: On Tue, 20 Aug 2024 07:26:12 GMT, Tejesh R wrote: >> In JTable, keyboard navigation keys Ctrl Shift RIGHT/LEFT doesn't follow native actions of Linux. In native the actions are extended to end of selected columns cells either LEFT/RIGHT but in swing gtk look and feel the selection is extended to one cell to left/right. This might be taken as reference of Windows OS since the same is observed in Windows native. Hence I have update the actions for Ctrl Shift RIGHT & LEFT. >> Added automated test too. The fix is tested in CI and its fine. > > Tejesh R 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 four additional commits since the last revision: > > - Updated review comments > - Merge branch 'master' of https://git.openjdk.java.net/jdk into branch_8338041 > - Test updates > - Key action modified + Automatic test added test/jdk/javax/swing/plaf/gtk/JTableCtrlShiftRightLeftKeyTest.java line 124: > 122: String failureMsg = "Test Failure. Failed to select cells for Ctrl" + > 123: " Shift " + key + " selection"; > 124: throw new RuntimeException(failureMsg); Suggestion: A StringBuffer can be used to log the errors and the RuntimeException can be thrown at the end after checking both cases- left and right selection similar to this test https://github.com/openjdk/jdk/blob/47c8a6a8db979fe862be876008feb76cdc9dccfd/test/jdk/javax/swing/plaf/metal/MetalBorders/ScaledMetalBorderTest.java#L82 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20608#discussion_r1725977520 From honkar at openjdk.org Thu Aug 22 00:20:08 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Thu, 22 Aug 2024 00:20:08 GMT Subject: RFR: 8338041: Keyboard Navigation of JTable, Ctrl Shift RIGHT/LEFT doesn't follow native action in GTK L&F [v2] In-Reply-To: References: <_kMMFJ9LnQOmUmp_3Ob1m3lj2xLKUo-ChL00Clw4xjs=.7e799f69-da05-44f4-9bf7-6e9e43b427b8@github.com> Message-ID: On Tue, 20 Aug 2024 07:26:12 GMT, Tejesh R wrote: >> In JTable, keyboard navigation keys Ctrl Shift RIGHT/LEFT doesn't follow native actions of Linux. In native the actions are extended to end of selected columns cells either LEFT/RIGHT but in swing gtk look and feel the selection is extended to one cell to left/right. This might be taken as reference of Windows OS since the same is observed in Windows native. Hence I have update the actions for Ctrl Shift RIGHT & LEFT. >> Added automated test too. The fix is tested in CI and its fine. > > Tejesh R 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 four additional commits since the last revision: > > - Updated review comments > - Merge branch 'master' of https://git.openjdk.java.net/jdk into branch_8338041 > - Test updates > - Key action modified + Automatic test added Fix looks good and works similar to native app - Libre Calc on linux. ------------- PR Review: https://git.openjdk.org/jdk/pull/20608#pullrequestreview-2252454523 From jiangli at openjdk.org Thu Aug 22 00:33:02 2024 From: jiangli at openjdk.org (Jiangli Zhou) Date: Thu, 22 Aug 2024 00:33:02 GMT Subject: RFR: 8338768: Introduce runtime lookup to check for static builds [v2] In-Reply-To: <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com> References: <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com> Message-ID: <5_BKiz0spEIxGN2mZJHiAoaSOWOdnH8kf5POgG9sQ9g=.9339d838-9f04-4d28-93b8-647ad90e805a@github.com> On Wed, 21 Aug 2024 22:14:40 GMT, Magnus Ihse Bursie wrote: >> As a preparation for Hermetic Java, we need to have a way to look up during runtime if we are using a statically linked library or not. >> >> This change will be the first step needed towards compiling the object files only once, and then link them into either dynamic or static libraries. (The only exception will be the linktype.c[pp] files, which needs to be compiled twice, once for the dynamic libraries and once for the static libraries.) Getting there will require further work though. >> >> This is part of the changes that make up the draft PR https://github.com/openjdk/jdk/pull/19478, which I have broken out. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Also update build to link properly I compared the extracted changes in this PR with the related parts in https://github.com/openjdk/jdk/pull/19478. They look ok. My concern (as discussed in https://github.com/openjdk/jdk/pull/19478#issuecomment-2278421931) is that these runtime changes for static JDK can't be tested even they are relatively simple, without the the actual linking change. Any timeline for the static linking changes? ------------- PR Review: https://git.openjdk.org/jdk/pull/20666#pullrequestreview-2252486767 From dholmes at openjdk.org Thu Aug 22 02:49:09 2024 From: dholmes at openjdk.org (David Holmes) Date: Thu, 22 Aug 2024 02:49:09 GMT Subject: RFR: 8338768: Introduce runtime lookup to check for static builds [v2] In-Reply-To: <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com> References: <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com> Message-ID: On Wed, 21 Aug 2024 22:14:40 GMT, Magnus Ihse Bursie wrote: >> As a preparation for Hermetic Java, we need to have a way to look up during runtime if we are using a statically linked library or not. >> >> This change will be the first step needed towards compiling the object files only once, and then link them into either dynamic or static libraries. (The only exception will be the linktype.c[pp] files, which needs to be compiled twice, once for the dynamic libraries and once for the static libraries.) Getting there will require further work though. >> >> This is part of the changes that make up the draft PR https://github.com/openjdk/jdk/pull/19478, which I have broken out. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Also update build to link properly Sorry but I don't understand the point of changing build-time constructs using `ifdef STATIC_BUILD` into what appear to be runtime checks, but the result of which is already determined at build time. These are not really runtime checks. ------------- PR Review: https://git.openjdk.org/jdk/pull/20666#pullrequestreview-2252973892 From tejesh.r at oracle.com Thu Aug 22 05:00:04 2024 From: tejesh.r at oracle.com (Tejesh R) Date: Thu, 22 Aug 2024 05:00:04 +0000 Subject: Seeking feedback on a possible JDatePicker Swing component Message-ID: Hello Swing Community, Swing has a rich set of UI components in the core Java Platform. But it lacks a Date Picker which is a significant gap for many applications and so we are considering revisiting the idea of a Date Picker in core Swing. The function core of a DatePicker is to let a user select a day [and time?], or range of days [and time ? ], within optional application specified constraints. The JXDatePicker component was previously explored as part of the long defunct external SwingX project. This proposal does not imply reviving JXDatePicker, but being informed by it and date pickers for other platforms. Before even starting on this, we are seeking feedback from the community - Is it of interest ? - Would you use it ? - What features must it have ? - What features are nice to have ? - Do you have any experiences of other date pickers that reinforce those responses ? - Anything else ? If we move forward, we would propose a JEP and also expect that we would deliver it first as a preview feature [1] , so that it may evolve in response to feedback before becoming final. Please let us know your thoughts and suggestions on this proposal. Regards, Tejesh R. JDK client team [1] https://openjdk.org/jeps/12 -------------- next part -------------- An HTML attachment was scrubbed... URL: From abhiscxk at openjdk.org Thu Aug 22 05:29:25 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Thu, 22 Aug 2024 05:29:25 GMT Subject: RFR: 8338668: Test javax/swing/JFileChooser/8080628/bug8080628.java doesn't test for GTK L&F Message-ID: This test should have failed with the [changeset](https://github.com/openjdk/jdk/pull/20612) proposed for [JDK-4795384](https://bugs.openjdk.org/browse/JDK-4795384) but it didn't because GTK look and feel isn't supported in headless environment. Fix is to run the test with headful environment on linux platform. Tested in CI pipeline and link attached to JBS. ------------- Commit messages: - added headful tag for linux platform Changes: https://git.openjdk.org/jdk/pull/20671/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20671&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8338668 Stats: 14 lines in 1 file changed: 12 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20671.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20671/head:pull/20671 PR: https://git.openjdk.org/jdk/pull/20671 From jwaters at openjdk.org Thu Aug 22 05:30:02 2024 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 22 Aug 2024 05:30:02 GMT Subject: RFR: 8338768: Introduce runtime lookup to check for static builds [v2] In-Reply-To: References: <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com> Message-ID: <6Qu9wbsWf_YxFFvfA6KveCLOheMOsbo4z--gZzQh9xY=.b1d013f6-eb34-4d50-b19b-64c684cdea13@github.com> On Thu, 22 Aug 2024 02:46:34 GMT, David Holmes wrote: > Sorry but I don't understand the point of changing build-time constructs using `ifdef STATIC_BUILD` into what appear to be runtime checks, but the result of which is already determined at build time. These are not really runtime checks. I believe the new methods are for checking whether the JDK was statically linked or not, but I half agree with your point. The change to using the new methods instead of preprocessor checks don't seem to really do anything. Maybe the new methods can be kept alongside the preprocessor checks ------------- PR Comment: https://git.openjdk.org/jdk/pull/20666#issuecomment-2303813593 From tr at openjdk.org Thu Aug 22 05:31:07 2024 From: tr at openjdk.org (Tejesh R) Date: Thu, 22 Aug 2024 05:31:07 GMT Subject: RFR: 8338041: Keyboard Navigation of JTable, Ctrl Shift RIGHT/LEFT doesn't follow native action in GTK L&F [v2] In-Reply-To: References: <_kMMFJ9LnQOmUmp_3Ob1m3lj2xLKUo-ChL00Clw4xjs=.7e799f69-da05-44f4-9bf7-6e9e43b427b8@github.com> Message-ID: <38-MYnZBRfPlNK33Zq2OWMdVtEZNZ2VvzS7Jib830gM=.47b92c4c-3377-4527-a3c0-6661284f03c9@github.com> On Thu, 22 Aug 2024 00:01:49 GMT, Harshitha Onkar wrote: >> Tejesh R 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 four additional commits since the last revision: >> >> - Updated review comments >> - Merge branch 'master' of https://git.openjdk.java.net/jdk into branch_8338041 >> - Test updates >> - Key action modified + Automatic test added > > test/jdk/javax/swing/plaf/gtk/JTableCtrlShiftRightLeftKeyTest.java line 124: > >> 122: String failureMsg = "Test Failure. Failed to select cells for Ctrl" + >> 123: " Shift " + key + " selection"; >> 124: throw new RuntimeException(failureMsg); > > Suggestion: A StringBuffer can be used to log the errors and the RuntimeException can be thrown at the end after checking both cases- left and right selection similar to this test https://github.com/openjdk/jdk/blob/47c8a6a8db979fe862be876008feb76cdc9dccfd/test/jdk/javax/swing/plaf/metal/MetalBorders/ScaledMetalBorderTest.java#L82 Noted, StringBuffer can be used to log errors. But I don't think it's required here since we are not appending anything to Error message and also when either of selection fails its better to throw exception without proceeding to other side of test. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20608#discussion_r1726359461 From ihse at openjdk.org Thu Aug 22 08:46:03 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 22 Aug 2024 08:46:03 GMT Subject: RFR: 8338768: Introduce runtime lookup to check for static builds [v2] In-Reply-To: <5_BKiz0spEIxGN2mZJHiAoaSOWOdnH8kf5POgG9sQ9g=.9339d838-9f04-4d28-93b8-647ad90e805a@github.com> References: <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com> <5_BKiz0spEIxGN2mZJHiAoaSOWOdnH8kf5POgG9sQ9g=.9339d838-9f04-4d28-93b8-647ad90e805a@github.com> Message-ID: On Thu, 22 Aug 2024 00:30:07 GMT, Jiangli Zhou wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: >> >> Also update build to link properly > > I compared the extracted changes in this PR with the related parts in https://github.com/openjdk/jdk/pull/19478. They look ok. My concern (as discussed in https://github.com/openjdk/jdk/pull/19478#issuecomment-2278421931) is that these runtime changes for static JDK can't be tested even they are relatively simple, without the the actual linking change. Any timeline for the static linking changes? @jianglizhou > [...] these runtime changes for static JDK can't be tested [...] Yes, they can. This is just a pure refactoring of existing code. I have deliberately kept out addition of the new places where static linking exceptions are needed in the code. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20666#issuecomment-2304110701 From ihse at openjdk.org Thu Aug 22 08:59:03 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 22 Aug 2024 08:59:03 GMT Subject: RFR: 8338768: Introduce runtime lookup to check for static builds [v2] In-Reply-To: References: <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com> Message-ID: On Thu, 22 Aug 2024 02:46:34 GMT, David Holmes wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: >> >> Also update build to link properly > > Sorry but I don't understand the point of changing build-time constructs using `ifdef STATIC_BUILD` into what appear to be runtime checks, but the result of which is already determined at build time. These are not really runtime checks. @dholmes-ora > Sorry but I don't understand the point of changing build-time constructs using ifdef STATIC_BUILD into what appear to be runtime checks, but the result of which is already determined at build time. I apologize. I did not express the intent of this change clear enough. The background is that we want to build and test statically linked native libraries. Currently, building a statically linked version requires recompiling all native source code into a completely new set of .o files, which are then linked into a static library. This is extremely wasteful. Most of the code is completely identical for static and dynamic libraries. To fix this, me, Jiangli and her team have been working on a way to get around this. By moving the ifdef check to a new file that just contains a single function, we only need to compile this single file twice -- once for the static library, and once for the dynamic library. All other .o files is compiled just once, and then you link "all other files" + "the one special file for your kind of library" to get what you want. Unfortunately, there is also one more blocker before this can be achieved. That is the reason the corresponding change in the build system is not included in this patch. (So this is a preparation for these future changes, but not the complete solution.) The missing part is that the `[JNI|Agent]_On[Un]Load` functions need to be able to use the static linked naming scheme, even for dynamically linked libraries. This is trivial per se, but requires a spec change, which has not yet happened. The reason I want to get this partial solution into the mainline right now, instead of waiting for the spec change and the complete build system fix, is that these new functions for checking for static/dynamic are needed by additional changes that Jiangli have created upstream, and that I am trying to help her get integrated. (The goal of these changes is to make not just static libraries, but to link these static libraries with the java launcher into a statically linked launcher, which is a pre-requisite for the rest of the Hermetic Java story.) ------------- PR Comment: https://git.openjdk.org/jdk/pull/20666#issuecomment-2304133213 From honkar at openjdk.org Thu Aug 22 15:31:08 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Thu, 22 Aug 2024 15:31:08 GMT Subject: RFR: 8338041: Keyboard Navigation of JTable, Ctrl Shift RIGHT/LEFT doesn't follow native action in GTK L&F [v2] In-Reply-To: References: <_kMMFJ9LnQOmUmp_3Ob1m3lj2xLKUo-ChL00Clw4xjs=.7e799f69-da05-44f4-9bf7-6e9e43b427b8@github.com> Message-ID: On Tue, 20 Aug 2024 07:26:12 GMT, Tejesh R wrote: >> In JTable, keyboard navigation keys Ctrl Shift RIGHT/LEFT doesn't follow native actions of Linux. In native the actions are extended to end of selected columns cells either LEFT/RIGHT but in swing gtk look and feel the selection is extended to one cell to left/right. This might be taken as reference of Windows OS since the same is observed in Windows native. Hence I have update the actions for Ctrl Shift RIGHT & LEFT. >> Added automated test too. The fix is tested in CI and its fine. > > Tejesh R 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 four additional commits since the last revision: > > - Updated review comments > - Merge branch 'master' of https://git.openjdk.java.net/jdk into branch_8338041 > - Test updates > - Key action modified + Automatic test added Marked as reviewed by honkar (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20608#pullrequestreview-2254950525 From serb at openjdk.org Thu Aug 22 15:59:16 2024 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 22 Aug 2024 15:59:16 GMT Subject: RFR: 8338785: The java.awt.datatransfer.SystemFlavorMap#FLAVOR_MAP_KEY field is not used Message-ID: The unused `java.awt.datatransfer.SystemFlavorMap#FLAVOR_MAP_KEY` field is deleted. It was unused since [8037485](https://bugs.openjdk.org/browse/JDK-8037485): Refactor java.awt.datatransfer to eliminate dependency on AWT. See: https://github.com/openjdk/jdk/commit/0fecd7769453dfb3ef1609b057a9e69aee57d0c1#diff-2c0c7e0dbcabe2bced2907f383bdb4e2a3ed64686c219f37f7c6469ecc47d4baL198 ------------- Commit messages: - 8338785: The java.awt.datatransfer.SystemFlavorMap#FLAVOR_MAP_KEY field is not used Changes: https://git.openjdk.org/jdk/pull/20670/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20670&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8338785 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20670.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20670/head:pull/20670 PR: https://git.openjdk.org/jdk/pull/20670 From duke at openjdk.org Thu Aug 22 16:20:09 2024 From: duke at openjdk.org (duke) Date: Thu, 22 Aug 2024 16:20:09 GMT Subject: Withdrawn: 8297191 : [macos] printing page range "page 2 to 2" or "page 2 to 4" on macOS leads to not print In-Reply-To: References: Message-ID: On Mon, 17 Jun 2024 05:54:37 GMT, Renjith Kannath Pariyangad wrote: > Hi Reviewers, > > This fix will resolve page range not printing proper pages if the rage begin from 2 or above on Mac machines. > I have verified the manual range related tests like PageRanges.java, ClippedImages.java and test.java and confirmed its fixing the issue. > > Please review and let me know your suggestions if any. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/19740 From mvs at openjdk.org Thu Aug 22 18:04:46 2024 From: mvs at openjdk.org (Manukumar V S) Date: Thu, 22 Aug 2024 18:04:46 GMT Subject: RFR: 8338103: Stabilize and open source a Swing OGL ButtonResizeTest [v4] In-Reply-To: <8--CxVHS_jclzzN2PWYkI0W3yr7w1al5PSqRdis-PUc=.2f57c378-49cc-40bc-b042-f6aa9bfed07d@github.com> References: <8--CxVHS_jclzzN2PWYkI0W3yr7w1al5PSqRdis-PUc=.2f57c378-49cc-40bc-b042-f6aa9bfed07d@github.com> Message-ID: > This PR creates a new test by stabilising and open sourcing a closed test. > This test verifies that the OpenGL pipeline does not create artifacts with swing components after window is zoomed to maximum size and then resized back to normal. > This test is run twice, with and without the flags "-Dsun.java2d.opengl=True -Dsun.java2d.opengl.fbobject=false" . > > This is tested(15 times per platform) in all the available mach5 headful platforms and found to be stable. Manukumar V S has updated the pull request incrementally with one additional commit since the last revision: Review comment fixed : Changed the position of line comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20532/files - new: https://git.openjdk.org/jdk/pull/20532/files/20f33fd8..75c44d43 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20532&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20532&range=02-03 Stats: 10 lines in 1 file changed: 0 ins; 2 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/20532.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20532/head:pull/20532 PR: https://git.openjdk.org/jdk/pull/20532 From swinxythecat at gmail.com Thu Aug 22 18:06:42 2024 From: swinxythecat at gmail.com (SWinxy) Date: Thu, 22 Aug 2024 14:06:42 -0400 Subject: Seeking feedback on a possible JDatePicker Swing component In-Reply-To: References: Message-ID: Tejesh, I think it would be a nice feature, and I would be happy to help with it. There are a lot of considerations for displaying calendars. I don't think we should have the date & time combined into one UI component, but separate components, the former of which I'll focus on here. There are two parts to it: first is textbox(es), and second a calendar grid. Here are some requirements that I can think of right now: - Start of the week. Different regions of the world have the week start on different days, usually Sunday or Monday, but some start on Saturday. [1] macOS and Windows both let you change this to any day of the week. On macOS, this is defined by NSCalendar's firstWeekday. - Should there be one text field, or should there be three for day-month-year? Allow the dev to choose? If multiple text boxes, the ways to traverse to the next field should include the period, space, slash, and dash keys in addition to the tab key. (This is because people can type 10/10/10 or 10.10.10 all at once and not have to press tab.) Pasting in a date should be supported in either case, and converted to the displayed locale. - The UI should update in response to a notification from the system that the user has changed their preferred calendar format. - Either way we have the text box, allowing the developer to choose if they want a text box with a popup calendar grid or one that is in the same panel would be ideal. (That is, they add it to the same panel themself.) - The calendar grid should be able to be oriented horizontally or vertically. (When the calendar moves around, does it go left-right or up-down?) Calendar grids often show the previous and next months' dates as padding when the start and end of the month aren't cleanly cut by the start and ends of the week. When going horizontally, the developer should have the option to show or hide those dates. When vertical, the developer should be able to decide if the grid is continuous or interrupted. (To pad with numbers or to pad with empty space.) - UI for changing the month and year of the grid. This can take the form of left-right arrows, scrolling, and/or dropdown for the month and a text field for the year. Extra things: - Calendar type. Most people use Gregorian, but a small number of people can choose otherwise for their systems. macOS gives me a bunch of options, but Windows only allows me to do Gregorian. This is a "wow wouldn't it be cool" optional feature. - A 'today' button, which selects the current date. - How to represent a date range with a calendar and a textbox, I'm not sure. The easy workaround would be to have the developer create two of these date pickers. But a way to select a range would be welcome. - If we do also have a component for time, should we allow for the changing of timezones in the UI? Timezones are too much imo. I'm relying on screenshots on Google for date pickers and NSDatePicker for what features they have. I'm sure I would be able to make use of this somewhere in my own Swing app. SWinxy [1] https://en.wikipedia.org/wiki/Week On Thu, Aug 22, 2024 at 2:29?AM Tejesh R wrote: > Hello Swing Community, > > > > Swing has a rich set of UI components in the core Java Platform. > But it lacks a Date Picker which is a significant gap for many > applications and so we are considering revisiting the idea of a Date Picker > in core Swing. > > The function core of a DatePicker is to let a user select a day [and > time?], or range of days [and time ? ], > within optional application specified constraints. > > The JXDatePicker component was previously explored as part of the long > defunct external SwingX project. > This proposal does not imply reviving JXDatePicker, but being informed by > it and date pickers for other platforms. > > Before even starting on this, we are seeking feedback from the community > > - Is it of interest ? > > - Would you use it ? > > - What features must it have ? > > - What features are nice to have ? > > - Do you have any experiences of other date pickers that reinforce those > responses ? > > - Anything else ? > > If we move forward, we would propose a JEP and also expect that we would > deliver it first as a preview feature [1] , so that it may evolve in > response to feedback before becoming final. > > Please let us know your thoughts and suggestions on this proposal. > > > > Regards, > > Tejesh R. > > JDK client team > > > > [1] https://openjdk.org/jeps/12 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Thu Aug 22 18:18:08 2024 From: duke at openjdk.org (SWinxy) Date: Thu, 22 Aug 2024 18:18:08 GMT Subject: RFR: 8338785: The java.awt.datatransfer.SystemFlavorMap#FLAVOR_MAP_KEY field is not used In-Reply-To: References: Message-ID: On Thu, 22 Aug 2024 03:59:57 GMT, Sergey Bylokhov wrote: > The unused `java.awt.datatransfer.SystemFlavorMap#FLAVOR_MAP_KEY` field is deleted. > > It was unused since [8037485](https://bugs.openjdk.org/browse/JDK-8037485): Refactor java.awt.datatransfer to eliminate dependency on AWT. > > See: > https://github.com/openjdk/jdk/commit/0fecd7769453dfb3ef1609b057a9e69aee57d0c1#diff-2c0c7e0dbcabe2bced2907f383bdb4e2a3ed64686c219f37f7c6469ecc47d4baL198 Looks like the removal was overlooked, as in 8037485 it was copied to `DesktopDatatransferServiceImpl`. ------------- Marked as reviewed by SWinxy at github.com (no known OpenJDK username). PR Review: https://git.openjdk.org/jdk/pull/20670#pullrequestreview-2255347264 From achung at openjdk.org Thu Aug 22 21:31:09 2024 From: achung at openjdk.org (Alisen Chung) Date: Thu, 22 Aug 2024 21:31:09 GMT Subject: RFR: 8338041: Keyboard Navigation of JTable, Ctrl Shift RIGHT/LEFT doesn't follow native action in GTK L&F [v2] In-Reply-To: References: <_kMMFJ9LnQOmUmp_3Ob1m3lj2xLKUo-ChL00Clw4xjs=.7e799f69-da05-44f4-9bf7-6e9e43b427b8@github.com> Message-ID: On Tue, 20 Aug 2024 07:26:12 GMT, Tejesh R wrote: >> In JTable, keyboard navigation keys Ctrl Shift RIGHT/LEFT doesn't follow native actions of Linux. In native the actions are extended to end of selected columns cells either LEFT/RIGHT but in swing gtk look and feel the selection is extended to one cell to left/right. This might be taken as reference of Windows OS since the same is observed in Windows native. Hence I have update the actions for Ctrl Shift RIGHT & LEFT. >> Added automated test too. The fix is tested in CI and its fine. > > Tejesh R 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 four additional commits since the last revision: > > - Updated review comments > - Merge branch 'master' of https://git.openjdk.java.net/jdk into branch_8338041 > - Test updates > - Key action modified + Automatic test added src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKLookAndFeel.java line 1062: > 1060: "shift KP_RIGHT", "selectNextColumnExtendSelection", > 1061: "ctrl shift RIGHT", "selectLastColumnExtendSelection", > 1062: "ctrl shift KP_RIGHT", "selectNextColumnExtendSelection", should KP_RIGHT also be changed to selectLastColumnExtendSelection? Should keypad shortcuts be identical to the arrow key shortcuts? src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKLookAndFeel.java line 1070: > 1068: "shift KP_LEFT", "selectPreviousColumnExtendSelection", > 1069: "ctrl shift LEFT", "selectFirstColumnExtendSelection", > 1070: "ctrl shift KP_LEFT", "selectPreviousColumnExtendSelection", here as well ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20608#discussion_r1727876631 PR Review Comment: https://git.openjdk.org/jdk/pull/20608#discussion_r1727877541 From achung at openjdk.org Thu Aug 22 21:37:03 2024 From: achung at openjdk.org (Alisen Chung) Date: Thu, 22 Aug 2024 21:37:03 GMT Subject: RFR: 8338668: Test javax/swing/JFileChooser/8080628/bug8080628.java doesn't test for GTK L&F In-Reply-To: References: Message-ID: On Thu, 22 Aug 2024 05:24:24 GMT, Abhishek Kumar wrote: > This test should have failed with the [changeset](https://github.com/openjdk/jdk/pull/20612) proposed for [JDK-4795384](https://bugs.openjdk.org/browse/JDK-4795384) but it didn't because GTK look and feel isn't supported in headless environment. > > Fix is to run the test with headful environment on linux platform. > > Tested in CI pipeline and link attached to JBS. test/jdk/javax/swing/JFileChooser/8080628/bug8080628.java line 1: > 1: /* Could you also clean up the main method and remove the extra overhead in the SwingUtilities.invokeAndWait call? Also remember to update copyright years test/jdk/javax/swing/JFileChooser/8080628/bug8080628.java line 46: > 44: * @key headful > 45: * @summary No mnemonics on Open and Save buttons in JFileChooser. > 46: * @requires os.family == "linux" Looks like jtreg tags were accidentally duped. Did you mean to only replace the author tag with the requires tag? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20671#discussion_r1727920316 PR Review Comment: https://git.openjdk.org/jdk/pull/20671#discussion_r1727912409 From honkar at openjdk.org Thu Aug 22 21:57:03 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Thu, 22 Aug 2024 21:57:03 GMT Subject: RFR: 8338668: Test javax/swing/JFileChooser/8080628/bug8080628.java doesn't test for GTK L&F In-Reply-To: References: Message-ID: On Thu, 22 Aug 2024 21:32:08 GMT, Alisen Chung wrote: >> This test should have failed with the [changeset](https://github.com/openjdk/jdk/pull/20612) proposed for [JDK-4795384](https://bugs.openjdk.org/browse/JDK-4795384) but it didn't because GTK look and feel isn't supported in headless environment. >> >> Fix is to run the test with headful environment on linux platform. >> >> Tested in CI pipeline and link attached to JBS. > > test/jdk/javax/swing/JFileChooser/8080628/bug8080628.java line 46: > >> 44: * @key headful >> 45: * @summary No mnemonics on Open and Save buttons in JFileChooser. >> 46: * @requires os.family == "linux" > > Looks like jtreg tags were accidentally duped. Did you mean to only replace the author tag with the requires tag? @alisenchung Multiple jtreg headers are added to run with different configuration The 1st one runs in headless mode on platforms other than linux `@requires os.family != "linux"` The 2nd one runs in headful mode on linux `@requires os.family == "linux"` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20671#discussion_r1727966090 From honkar at openjdk.org Thu Aug 22 22:05:03 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Thu, 22 Aug 2024 22:05:03 GMT Subject: RFR: 8338668: Test javax/swing/JFileChooser/8080628/bug8080628.java doesn't test for GTK L&F In-Reply-To: References: Message-ID: On Thu, 22 Aug 2024 05:24:24 GMT, Abhishek Kumar wrote: > This test should have failed with the [changeset](https://github.com/openjdk/jdk/pull/20612) proposed for [JDK-4795384](https://bugs.openjdk.org/browse/JDK-4795384) but it didn't because GTK look and feel isn't supported in headless environment. > > Fix is to run the test with headful environment on linux platform. > > Tested in CI pipeline and link attached to JBS. @kumarabhi006 > Fix is to run the test with headful environment on linux platform. Does this have to do with not loading the gtk files in headless mode? https://github.com/openjdk/jdk/blob/master/src/java.desktop/unix/native/libawt_xawt/awt/gtk_interface.c#L26C1-L28C7 ------------- PR Comment: https://git.openjdk.org/jdk/pull/20671#issuecomment-2305824986 From honkar at openjdk.org Thu Aug 22 22:15:07 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Thu, 22 Aug 2024 22:15:07 GMT Subject: RFR: 8338041: Keyboard Navigation of JTable, Ctrl Shift RIGHT/LEFT doesn't follow native action in GTK L&F [v2] In-Reply-To: References: <_kMMFJ9LnQOmUmp_3Ob1m3lj2xLKUo-ChL00Clw4xjs=.7e799f69-da05-44f4-9bf7-6e9e43b427b8@github.com> Message-ID: On Thu, 22 Aug 2024 21:24:50 GMT, Alisen Chung wrote: >> Tejesh R 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 four additional commits since the last revision: >> >> - Updated review comments >> - Merge branch 'master' of https://git.openjdk.java.net/jdk into branch_8338041 >> - Test updates >> - Key action modified + Automatic test added > > src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKLookAndFeel.java line 1062: > >> 1060: "shift KP_RIGHT", "selectNextColumnExtendSelection", >> 1061: "ctrl shift RIGHT", "selectLastColumnExtendSelection", >> 1062: "ctrl shift KP_RIGHT", "selectNextColumnExtendSelection", > > should KP_RIGHT also be changed to selectLastColumnExtendSelection? Should keypad shortcuts be identical to the arrow key shortcuts? Good catch. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20608#discussion_r1727982100 From honkar at openjdk.org Thu Aug 22 22:22:03 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Thu, 22 Aug 2024 22:22:03 GMT Subject: RFR: 8338785: The java.awt.datatransfer.SystemFlavorMap#FLAVOR_MAP_KEY field is not used In-Reply-To: References: Message-ID: On Thu, 22 Aug 2024 03:59:57 GMT, Sergey Bylokhov wrote: > The unused `java.awt.datatransfer.SystemFlavorMap#FLAVOR_MAP_KEY` field is deleted. > > It was unused since [8037485](https://bugs.openjdk.org/browse/JDK-8037485): Refactor java.awt.datatransfer to eliminate dependency on AWT. > > See: > https://github.com/openjdk/jdk/commit/0fecd7769453dfb3ef1609b057a9e69aee57d0c1#diff-2c0c7e0dbcabe2bced2907f383bdb4e2a3ed64686c219f37f7c6469ecc47d4baL198 Marked as reviewed by honkar (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20670#pullrequestreview-2255898784 From dholmes at openjdk.org Thu Aug 22 22:52:05 2024 From: dholmes at openjdk.org (David Holmes) Date: Thu, 22 Aug 2024 22:52:05 GMT Subject: RFR: 8338768: Introduce runtime lookup to check for static builds [v2] In-Reply-To: References: <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com> Message-ID: On Thu, 22 Aug 2024 08:54:56 GMT, Magnus Ihse Bursie wrote: >> Sorry but I don't understand the point of changing build-time constructs using `ifdef STATIC_BUILD` into what appear to be runtime checks, but the result of which is already determined at build time. These are not really runtime checks. > > @dholmes-ora > >> Sorry but I don't understand the point of changing build-time constructs using ifdef STATIC_BUILD into what appear to be runtime checks, but the result of which is already determined at build time. > > I apologize. I did not express the intent of this change clear enough. > > The background is that we want to build and test statically linked native libraries. Currently, building a statically linked version requires recompiling all native source code into a completely new set of .o files, which are then linked into a static library. > > This is extremely wasteful. Most of the code is completely identical for static and dynamic libraries. To fix this, me, Jiangli and her team have been working on a way to get around this. > > By moving the ifdef check to a new file that just contains a single function, we only need to compile this single file twice -- once for the static library, and once for the dynamic library. All other .o files is compiled just once, and then you link "all other files" + "the one special file for your kind of library" to get what you want. > > Unfortunately, there is also one more blocker before this can be achieved. That is the reason the corresponding change in the build system is not included in this patch. (So this is a preparation for these future changes, but not the complete solution.) The missing part is that the `[JNI|Agent]_On[Un]Load` functions need to be able to use the static linked naming scheme, even for dynamically linked libraries. This is trivial per se, but requires a spec change, which has not yet happened. > > The reason I want to get this partial solution into the mainline right now, instead of waiting for the spec change and the complete build system fix, is that these new functions for checking for static/dynamic are needed by additional changes that Jiangli have created upstream, and that I am trying to help her get integrated. (The goal of these changes is to make not just static libraries, but to link these static libraries with the java launcher into a statically linked launcher, which is a pre-requisite for the rest of the Hermetic Java story.) @magicus is the final intent here that this one magic file will be compiled first with an inline declaration such that when the other files containing the apparent runtime check get compiled, it can actually be determined at build time and so have the same effects as the old ifdef logic? Otherwise it concerns me that a build-time issue that affects a handful of people becomes a runtime issue that affects every single instance of a running Java program. There are also other source-level solutions possible here by refactoring the code that has static vs dynamic linking dependencies into its own files and the build system can then select which set of files to compile. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20666#issuecomment-2305875408 From dnguyen at openjdk.org Thu Aug 22 23:38:08 2024 From: dnguyen at openjdk.org (Damon Nguyen) Date: Thu, 22 Aug 2024 23:38:08 GMT Subject: RFR: 8338785: The java.awt.datatransfer.SystemFlavorMap#FLAVOR_MAP_KEY field is not used In-Reply-To: References: Message-ID: On Thu, 22 Aug 2024 03:59:57 GMT, Sergey Bylokhov wrote: > The unused `java.awt.datatransfer.SystemFlavorMap#FLAVOR_MAP_KEY` field is deleted. > > It was unused since [8037485](https://bugs.openjdk.org/browse/JDK-8037485): Refactor java.awt.datatransfer to eliminate dependency on AWT. > > See: > https://github.com/openjdk/jdk/commit/0fecd7769453dfb3ef1609b057a9e69aee57d0c1#diff-2c0c7e0dbcabe2bced2907f383bdb4e2a3ed64686c219f37f7c6469ecc47d4baL198 Simple removal. Looks harmless. ------------- Marked as reviewed by dnguyen (Committer). PR Review: https://git.openjdk.org/jdk/pull/20670#pullrequestreview-2255966272 From dnguyen at openjdk.org Thu Aug 22 23:57:04 2024 From: dnguyen at openjdk.org (Damon Nguyen) Date: Thu, 22 Aug 2024 23:57:04 GMT Subject: RFR: 8329756: [macos] "javax/swing/JTable/KeyBoardNavigation.java" fail because most combinations of navigational keys with the Ctrl key do not work [v3] In-Reply-To: References: Message-ID: On Tue, 30 Jul 2024 05:17:12 GMT, Tejesh R wrote: >> Mismatch in key combinations, I have taken native macos Numbers application as reference to verify. Have added `Ctrl-Shift Left/Right` action keys similar to `Ctrl-Shift UP/DOWN` which would be expected functionality. I've removed those test instructions which are not applicable/implemented/not working in Macos keyboard navigation. > > Tejesh R has updated the pull request incrementally with one additional commit since the last revision: > > Review fix If the test window (not the instruction window) can't be expanded more, then LGTM. The test window has a vertical scroll (which is fine), but also a horizontal scroll (which can be avoided by expanding the width a bit more). Tested all of the instructed key combinations on a Mac device. All works as described with the changes. ------------- Marked as reviewed by dnguyen (Committer). PR Review: https://git.openjdk.org/jdk/pull/20331#pullrequestreview-2255979897 From psadhukhan at openjdk.org Fri Aug 23 04:29:07 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 23 Aug 2024 04:29:07 GMT Subject: RFR: 7188058: Background of TextComponents are not changing colors to the default disabled color when set to uneditable [v5] In-Reply-To: <095gCTeexK0MP5AzEUrNwAOtXDzFiNDUIjd5LHbh-sY=.fb49a844-8568-4713-9f34-8e1641e11efe@github.com> References: <095gCTeexK0MP5AzEUrNwAOtXDzFiNDUIjd5LHbh-sY=.fb49a844-8568-4713-9f34-8e1641e11efe@github.com> Message-ID: <9N8EtzrVB-E5O4pEd-FsudqecadPPEreSGrIBPyTRRg=.b1fd306f-4b00-4872-8565-2fcefe2bbe08@github.com> On Tue, 20 Aug 2024 23:53:45 GMT, Alisen Chung wrote: >> Currently the bug described in the issue is that the colors of the TextComponents do not change when setting TextComponents to uneditable. The default uneditable color (SystemColor.control) happens to be the same as the default for the editable color for some L&Fs, so the fix may not be initially noticeable. However, the bug still exists where the the color is not being changed when changing between editable and uneditable. You can check by changing TextComponent.getBackground() code to return Color.GRAY on line 342 and you can see that TextComponents are not changing to a gray background when set to uneditable. >> >> This fix adds a private setBackground method in TextComponent so that TextArea and TextField can change the background color to the correct color (SystemColor.control) when set uneditable by overriding the TextComponent setEditable. You can verify the fix by changing this color to Color.GRAY and verifying the backgrounds change to gray when the TextComponents are disabled. > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > fix import Code change looks good now but for me testcase is passing even without the fix.. Also, since the testcase is just testing the background color, I think it can be made automated and even headless by using textfield/textarea rendering to BufferedImage ------------- PR Comment: https://git.openjdk.org/jdk/pull/19876#issuecomment-2306221948 From prr at openjdk.org Fri Aug 23 04:39:02 2024 From: prr at openjdk.org (Phil Race) Date: Fri, 23 Aug 2024 04:39:02 GMT Subject: RFR: 8338785: The java.awt.datatransfer.SystemFlavorMap#FLAVOR_MAP_KEY field is not used In-Reply-To: References: Message-ID: On Thu, 22 Aug 2024 03:59:57 GMT, Sergey Bylokhov wrote: > The unused `java.awt.datatransfer.SystemFlavorMap#FLAVOR_MAP_KEY` field is deleted. > > It was unused since [8037485](https://bugs.openjdk.org/browse/JDK-8037485): Refactor java.awt.datatransfer to eliminate dependency on AWT. > > See: > https://github.com/openjdk/jdk/commit/0fecd7769453dfb3ef1609b057a9e69aee57d0c1#diff-2c0c7e0dbcabe2bced2907f383bdb4e2a3ed64686c219f37f7c6469ecc47d4baL198 Marked as reviewed by prr (Reviewer). If it builds I can't see a problem. ------------- PR Review: https://git.openjdk.org/jdk/pull/20670#pullrequestreview-2256344006 PR Comment: https://git.openjdk.org/jdk/pull/20670#issuecomment-2306269463 From prr at openjdk.org Fri Aug 23 04:46:03 2024 From: prr at openjdk.org (Phil Race) Date: Fri, 23 Aug 2024 04:46:03 GMT Subject: RFR: 4795384: GTK+ JFileChooser buttons should have mnemonics [v2] In-Reply-To: References: Message-ID: On Mon, 19 Aug 2024 07:32:26 GMT, Abhishek Kumar wrote: >> JFileChooser don't have the mnemonics for open and save button in GTK L&F. Fix is to add mnemonics for open and save button. >> Fix can be verified by Swingset2 demo application. Mnemonics in GTK L&F are visible once alt key is pressed. >> After running the SwingSet2 application, change the `L&F to GTK` and select` JFileChooser demo` from toolbar. Click on `Select Plain JFileChooser` button and then press alt key to verify the mnemonics. > > Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: > > Add mnemonics for Save and change Selection mnemonics After some "umming" I think we should withdraw this PR The bug https://bugs.openjdk.org/browse/JDK-4795384 is a VERY old bug which said lots of things didn't have a mnemonic. Looks to me like most were addressed, then a couple which went too far (arguably) were undone in 8080628 and this PR is addressing putting those back under the bug that said there were no mnemonics for more than these. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20612#issuecomment-2306281804 From tejesh.r at oracle.com Fri Aug 23 05:17:12 2024 From: tejesh.r at oracle.com (Tejesh R) Date: Fri, 23 Aug 2024 05:17:12 +0000 Subject: [External] : Re: Seeking feedback on a possible JDatePicker Swing component In-Reply-To: References: Message-ID: Hello SWinxy, Thank you for the feedback. We will consider your feedback suggestions and these are really helpful in this proposal. Regards, Tejesh R From: SWinxy Sent: 22 August 2024 23:37 To: Tejesh R Cc: client-libs-dev at openjdk.java.net Subject: [External] : Re: Seeking feedback on a possible JDatePicker Swing component Tejesh, I think it would be a nice feature, and I would be happy to help with it. There are a lot of considerations for displaying calendars. I don't think we should have the date & time combined into one UI component, but separate components, the former of which I'll focus on here. There are two parts to it: first is textbox(es), and second a calendar grid. Here are some requirements that I can think of right now: - Start of the week. Different regions of the world have the week start on different days, usually Sunday or Monday, but some start on Saturday. [1] macOS and Windows both let you change this to any day of the week. On macOS, this is defined by NSCalendar's firstWeekday. - Should there be one text field, or should there be three for day-month-year? Allow the dev to choose? If multiple text boxes, the ways to traverse to the next field should include the period, space, slash, and dash keys in addition to the tab key. (This is because people can type 10/10/10 or 10.10.10 all at once and not have to press tab.) Pasting in a date should be supported in either case, and converted to the displayed locale. - The UI should update in response to a notification from the system that the user has changed their preferred calendar format. - Either way we have the text box, allowing the developer to choose if they want a text box with a popup calendar grid or one that is in the same panel would be ideal. (That is, they add it to the same panel themself.) - The calendar grid should be able to be oriented horizontally or vertically. (When the calendar moves around, does it go left-right or up-down?) Calendar grids often show the previous and next months' dates as padding when the start and end of the month aren't cleanly cut by the start and ends of the week. When going horizontally, the developer should have the option to show or hide those dates. When vertical, the developer should be able to decide if the grid is continuous or interrupted. (To pad with numbers or to pad with empty space.) - UI for changing the month and year of the grid. This can take the form of left-right arrows, scrolling, and/or dropdown for the month and a text field for the year. Extra things: - Calendar type. Most people use Gregorian, but a small number of people can choose otherwise for their systems. macOS gives me a bunch of options, but Windows only allows me to do Gregorian. This is a "wow wouldn't it be cool" optional feature. - A 'today' button, which selects the current date. - How to represent a date range with a calendar and a textbox, I'm not sure. The easy workaround would be to have the developer create two of these date pickers. But a way to select a range would be welcome. - If we do also have a component for time, should we allow for the changing of timezones in the UI? Timezones are too much imo. I'm relying on screenshots on Google for date pickers and NSDatePicker for what features they have. I'm sure I would be able to make use of this somewhere in my own Swing app. SWinxy [1] https://en.wikipedia.org/wiki/Week On Thu, Aug 22, 2024 at 2:29?AM Tejesh R > wrote: Hello Swing Community, Swing has a rich set of UI components in the core Java Platform. But it lacks a Date Picker which is a significant gap for many applications and so we are considering revisiting the idea of a Date Picker in core Swing. The function core of a DatePicker is to let a user select a day [and time?], or range of days [and time ? ], within optional application specified constraints. The JXDatePicker component was previously explored as part of the long defunct external SwingX project. This proposal does not imply reviving JXDatePicker, but being informed by it and date pickers for other platforms. Before even starting on this, we are seeking feedback from the community - Is it of interest ? - Would you use it ? - What features must it have ? - What features are nice to have ? - Do you have any experiences of other date pickers that reinforce those responses ? - Anything else ? If we move forward, we would propose a JEP and also expect that we would deliver it first as a preview feature [1] , so that it may evolve in response to feedback before becoming final. Please let us know your thoughts and suggestions on this proposal. Regards, Tejesh R. JDK client team [1] https://openjdk.org/jeps/12 -------------- next part -------------- An HTML attachment was scrubbed... URL: From abhiscxk at openjdk.org Fri Aug 23 05:28:12 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Fri, 23 Aug 2024 05:28:12 GMT Subject: RFR: 7188058: Background of TextComponents are not changing colors to the default disabled color when set to uneditable [v5] In-Reply-To: <095gCTeexK0MP5AzEUrNwAOtXDzFiNDUIjd5LHbh-sY=.fb49a844-8568-4713-9f34-8e1641e11efe@github.com> References: <095gCTeexK0MP5AzEUrNwAOtXDzFiNDUIjd5LHbh-sY=.fb49a844-8568-4713-9f34-8e1641e11efe@github.com> Message-ID: On Tue, 20 Aug 2024 23:53:45 GMT, Alisen Chung wrote: >> Currently the bug described in the issue is that the colors of the TextComponents do not change when setting TextComponents to uneditable. The default uneditable color (SystemColor.control) happens to be the same as the default for the editable color for some L&Fs, so the fix may not be initially noticeable. However, the bug still exists where the the color is not being changed when changing between editable and uneditable. You can check by changing TextComponent.getBackground() code to return Color.GRAY on line 342 and you can see that TextComponents are not changing to a gray background when set to uneditable. >> >> This fix adds a private setBackground method in TextComponent so that TextArea and TextField can change the background color to the correct color (SystemColor.control) when set uneditable by overriding the TextComponent setEditable. You can verify the fix by changing this color to Color.GRAY and verifying the backgrounds change to gray when the TextComponents are disabled. > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > fix import src/java.desktop/share/classes/java/awt/TextArea.java line 610: > 608: > 609: @Override > 610: public synchronized void setEditable(boolean b) { `setEditable` method is overridden in both `TextArea` and `TextField` class and method implementation is same. Since both of them are inherited from `TextComponent` class, could we move the code to `TextComponent's setEditable` method and remove them from respective classes? test/jdk/java/awt/TextComponent/BackgroundTest.java line 1: > 1: /* @ Ran the test on mac machine and I observed no changes with or without your fix. And the text on first textfield seems selected and due to that it is of different color. Is it possible to make them unselected at test start up, so that the background color can be verified for enabled and disabled case easily? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19876#discussion_r1728380686 PR Review Comment: https://git.openjdk.org/jdk/pull/19876#discussion_r1728381311 From abhiscxk at openjdk.org Fri Aug 23 05:40:05 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Fri, 23 Aug 2024 05:40:05 GMT Subject: RFR: 8329756: [macos] "javax/swing/JTable/KeyBoardNavigation.java" fail because most combinations of navigational keys with the Ctrl key do not work In-Reply-To: References: Message-ID: On Thu, 25 Jul 2024 16:07:11 GMT, Tejesh R wrote: >> @TejeshR13 Looks like the bug is not accessible. > >> @TejeshR13 Looks like the bug is not accessible. > > Update the bug, PR should sync with the updates. @TejeshR13 Already approved by me. Are you going to address Damon's comment `also a horizontal scroll (which can be avoided by expanding the width a bit more).` ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20331#issuecomment-2306327696 From abhiscxk at openjdk.org Fri Aug 23 06:11:07 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Fri, 23 Aug 2024 06:11:07 GMT Subject: RFR: 4795384: GTK+ JFileChooser buttons should have mnemonics [v2] In-Reply-To: References: Message-ID: On Fri, 23 Aug 2024 04:43:12 GMT, Phil Race wrote: > After some "umming" I think we should withdraw this PR The bug https://bugs.openjdk.org/browse/JDK-4795384 is a VERY old bug which said lots of things didn't have a mnemonic. Looks to me like most were addressed, then a couple which went too far (arguably) were undone in 8080628 and this PR is addressing putting those back under the bug that said there were no mnemonics for more than these. Ok. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20612#issuecomment-2306358887 From abhiscxk at openjdk.org Fri Aug 23 06:11:08 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Fri, 23 Aug 2024 06:11:08 GMT Subject: Withdrawn: 4795384: GTK+ JFileChooser buttons should have mnemonics In-Reply-To: References: Message-ID: <8L5P1usIKNOD_td2O0Rr0dm7xIJh3cAU2nMCULd0l0E=.817671eb-b8ad-4c60-a4c2-885b83963a14@github.com> On Fri, 16 Aug 2024 09:59:26 GMT, Abhishek Kumar wrote: > JFileChooser don't have the mnemonics for open and save button in GTK L&F. Fix is to add mnemonics for open and save button. > Fix can be verified by Swingset2 demo application. Mnemonics in GTK L&F are visible once alt key is pressed. > After running the SwingSet2 application, change the `L&F to GTK` and select` JFileChooser demo` from toolbar. Click on `Select Plain JFileChooser` button and then press alt key to verify the mnemonics. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/20612 From tr at openjdk.org Fri Aug 23 06:24:08 2024 From: tr at openjdk.org (Tejesh R) Date: Fri, 23 Aug 2024 06:24:08 GMT Subject: RFR: 8329756: [macos] "javax/swing/JTable/KeyBoardNavigation.java" fail because most combinations of navigational keys with the Ctrl key do not work [v3] In-Reply-To: References: Message-ID: On Thu, 22 Aug 2024 23:54:08 GMT, Damon Nguyen wrote: > If the test window (not the instruction window) can't be expanded more, then LGTM. The test window has a vertical scroll (which is fine), but also a horizontal scroll (which can be avoided by expanding the width a bit more). > > Tested all of the instructed key combinations on a Mac device. All works as described with the changes. Scroll pane are part of test process both horizontal and vertical. It's added on purpose to check the scroll up/down/left/right on key selection. No plans to avoid it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20331#issuecomment-2306373781 From abhiscxk at openjdk.org Fri Aug 23 06:51:03 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Fri, 23 Aug 2024 06:51:03 GMT Subject: RFR: 8329756: [macos] "javax/swing/JTable/KeyBoardNavigation.java" fail because most combinations of navigational keys with the Ctrl key do not work [v3] In-Reply-To: References: Message-ID: On Tue, 30 Jul 2024 05:17:12 GMT, Tejesh R wrote: >> Mismatch in key combinations, I have taken native macos Numbers application as reference to verify. Have added `Ctrl-Shift Left/Right` action keys similar to `Ctrl-Shift UP/DOWN` which would be expected functionality. I've removed those test instructions which are not applicable/implemented/not working in Macos keyboard navigation. > > Tejesh R has updated the pull request incrementally with one additional commit since the last revision: > > Review fix Looks good to me. ------------- Marked as reviewed by abhiscxk (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20331#pullrequestreview-2256487248 From tr at openjdk.org Fri Aug 23 06:56:02 2024 From: tr at openjdk.org (Tejesh R) Date: Fri, 23 Aug 2024 06:56:02 GMT Subject: RFR: 8338041: Keyboard Navigation of JTable, Ctrl Shift RIGHT/LEFT doesn't follow native action in GTK L&F [v2] In-Reply-To: References: <_kMMFJ9LnQOmUmp_3Ob1m3lj2xLKUo-ChL00Clw4xjs=.7e799f69-da05-44f4-9bf7-6e9e43b427b8@github.com> Message-ID: On Thu, 22 Aug 2024 22:12:10 GMT, Harshitha Onkar wrote: >> src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKLookAndFeel.java line 1062: >> >>> 1060: "shift KP_RIGHT", "selectNextColumnExtendSelection", >>> 1061: "ctrl shift RIGHT", "selectLastColumnExtendSelection", >>> 1062: "ctrl shift KP_RIGHT", "selectNextColumnExtendSelection", >> >> should KP_RIGHT also be changed to selectLastColumnExtendSelection? Should keypad shortcuts be identical to the arrow key shortcuts? > > Good catch. Actually all KP short cuts are miss aligned with native. So I thought of handling it separately. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20608#discussion_r1728463879 From abhiscxk at openjdk.org Fri Aug 23 06:56:08 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Fri, 23 Aug 2024 06:56:08 GMT Subject: RFR: 8338668: Test javax/swing/JFileChooser/8080628/bug8080628.java doesn't test for GTK L&F In-Reply-To: References: Message-ID: On Thu, 22 Aug 2024 21:32:08 GMT, Alisen Chung wrote: >> This test should have failed with the [changeset](https://github.com/openjdk/jdk/pull/20612) proposed for [JDK-4795384](https://bugs.openjdk.org/browse/JDK-4795384) but it didn't because GTK look and feel isn't supported in headless environment. >> >> Fix is to run the test with headful environment on linux platform. >> >> Tested in CI pipeline and link attached to JBS. > > test/jdk/javax/swing/JFileChooser/8080628/bug8080628.java line 46: > >> 44: * @key headful >> 45: * @summary No mnemonics on Open and Save buttons in JFileChooser. >> 46: * @requires os.family == "linux" > > Looks like jtreg tags were accidentally duped. Did you mean to only replace the author tag with the requires tag? @alisenchung As @honkar-jdk explained this is to run different configuration for different platforms. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20671#discussion_r1728463547 From aivanov at openjdk.org Fri Aug 23 08:59:04 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 23 Aug 2024 08:59:04 GMT Subject: RFR: 8338668: Test javax/swing/JFileChooser/8080628/bug8080628.java doesn't test for GTK L&F In-Reply-To: References: Message-ID: On Thu, 22 Aug 2024 05:24:24 GMT, Abhishek Kumar wrote: > This test should have failed with the [changeset](https://github.com/openjdk/jdk/pull/20612) proposed for [JDK-4795384](https://bugs.openjdk.org/browse/JDK-4795384) but it didn't because GTK look and feel isn't supported in headless environment. > > Fix is to run the test with headful environment on linux platform. > > Tested in CI pipeline and link attached to JBS. Please, update the copyright year. test/jdk/javax/swing/JFileChooser/8080628/bug8080628.java line 105: > 103: } > 104: } > 105: I'd rather keep this blank line. Most classes have blank line between the closing brace of the last method and the closing brace of the class itself. ------------- Marked as reviewed by aivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20671#pullrequestreview-2256726122 PR Review Comment: https://git.openjdk.org/jdk/pull/20671#discussion_r1728627065 From aivanov at openjdk.org Fri Aug 23 09:02:09 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 23 Aug 2024 09:02:09 GMT Subject: RFR: 8338668: Test javax/swing/JFileChooser/8080628/bug8080628.java doesn't test for GTK L&F In-Reply-To: References: Message-ID: On Thu, 22 Aug 2024 22:02:13 GMT, Harshitha Onkar wrote: > @kumarabhi006 > > > Fix is to run the test with headful environment on linux platform. > > Does this have to do with not loading the gtk files in headless mode? https://github.com/openjdk/jdk/blob/master/src/java.desktop/unix/native/libawt_xawt/awt/gtk_interface.c#L26C1-L28C7 Yes, that's exactly the problem. Abhishek and I discussed !20612, and I expected this test to fail with the changes on the review but it didn't. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20671#issuecomment-2306632164 From mcimadamore at openjdk.org Fri Aug 23 09:03:32 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 23 Aug 2024 09:03:32 GMT Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v10] In-Reply-To: References: Message-ID: > This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting the use of JNI in the following ways: > > * `System::load` and `System::loadLibrary` are now restricted methods > * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods > * binding a JNI `native` method declaration to a native implementation is now considered a restricted operation > > This PR slightly changes the way in which the JDK deals with restricted methods, even for FFM API calls. In Java 22, the single `--enable-native-access` was used both to specify a set of modules for which native access should be allowed *and* to specify whether illegal native access (that is, native access occurring from a module not specified by `--enable-native-access`) should be treated as an error or a warning. More specifically, an error is only issued if the `--enable-native-access flag` is used at least once. > > Here, a new flag is introduced, namely `illegal-native-access=allow/warn/deny`, which is used to specify what should happen when access to a restricted method and/or functionality is found outside the set of modules specified with `--enable-native-access`. The default policy is `warn`, but users can select `allow` to suppress the warnings, or `deny` to cause `IllegalCallerException` to be thrown. This aligns the treatment of restricted methods with other mechanisms, such as `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`. > > Some changes were required in the package-info javadoc for `java.lang.foreign`, to reflect the changes in the command line flags described above. Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision: - Merge branch 'master' into restricted_jni - Merge branch 'master' into restricted_jni - Address review comments - Add note on --illegal-native-access default value in the launcher help - Address review comment - Refine warning text for JNI method binding - Address review comments Improve warning for JNI methods, similar to what's described in JEP 472 Beef up tests - Address review comments - Fix another typo - Fix typo - ... and 3 more: https://git.openjdk.org/jdk/compare/f7ea738c...04622748 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19213/files - new: https://git.openjdk.org/jdk/pull/19213/files/ff51ac6a..04622748 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19213&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19213&range=08-09 Stats: 51278 lines in 1477 files changed: 28775 ins; 15348 del; 7155 mod Patch: https://git.openjdk.org/jdk/pull/19213.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19213/head:pull/19213 PR: https://git.openjdk.org/jdk/pull/19213 From tr at openjdk.org Fri Aug 23 09:22:06 2024 From: tr at openjdk.org (Tejesh R) Date: Fri, 23 Aug 2024 09:22:06 GMT Subject: RFR: 8338103: Stabilize and open source a Swing OGL ButtonResizeTest [v4] In-Reply-To: References: <8--CxVHS_jclzzN2PWYkI0W3yr7w1al5PSqRdis-PUc=.2f57c378-49cc-40bc-b042-f6aa9bfed07d@github.com> Message-ID: <4jhm1Pyb7WWHpNc9-1hueicO4bXx-uj0zsQZwsMgJyA=.7d11c011-e46b-4f55-be70-c2eb662ec14e@github.com> On Thu, 22 Aug 2024 18:04:46 GMT, Manukumar V S wrote: >> This PR creates a new test by stabilising and open sourcing a closed test. >> This test verifies that the OpenGL pipeline does not create artifacts with swing components after window is zoomed to maximum size and then resized back to normal. >> This test is run twice, with and without the flags "-Dsun.java2d.opengl=True -Dsun.java2d.opengl.fbobject=false" . >> >> This is tested(15 times per platform) in all the available mach5 headful platforms and found to be stable. > > Manukumar V S has updated the pull request incrementally with one additional commit since the last revision: > > Review comment fixed : Changed the position of line comments Looks good to me. ------------- Marked as reviewed by tr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20532#pullrequestreview-2256774844 From abhiscxk at openjdk.org Fri Aug 23 09:28:22 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Fri, 23 Aug 2024 09:28:22 GMT Subject: RFR: 8338668: Test javax/swing/JFileChooser/8080628/bug8080628.java doesn't test for GTK L&F [v2] In-Reply-To: References: Message-ID: > This test should have failed with the [changeset](https://github.com/openjdk/jdk/pull/20612) proposed for [JDK-4795384](https://bugs.openjdk.org/browse/JDK-4795384) but it didn't because GTK look and feel isn't supported in headless environment. > > Fix is to run the test with headful environment on linux platform. > > Tested in CI pipeline and link attached to JBS. Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: Review comment update ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20671/files - new: https://git.openjdk.org/jdk/pull/20671/files/72677087..892a8437 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20671&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20671&range=00-01 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20671.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20671/head:pull/20671 PR: https://git.openjdk.org/jdk/pull/20671 From abhiscxk at openjdk.org Fri Aug 23 09:28:22 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Fri, 23 Aug 2024 09:28:22 GMT Subject: RFR: 8338668: Test javax/swing/JFileChooser/8080628/bug8080628.java doesn't test for GTK L&F In-Reply-To: References: Message-ID: <5Nepf3hcnXQdvisDKsmCeYsqKJWWalQPzEVS3kE2KkM=.79d910a6-fe28-4421-9878-975195936586@github.com> On Fri, 23 Aug 2024 08:59:52 GMT, Alexey Ivanov wrote: > > @kumarabhi006 > > > Fix is to run the test with headful environment on linux platform. > > > > > > Does this have to do with not loading the gtk files in headless mode? https://github.com/openjdk/jdk/blob/master/src/java.desktop/unix/native/libawt_xawt/awt/gtk_interface.c#L26C1-L28C7 > > Yes, that's exactly the problem. > > Abhishek and I discussed !20612, and I expected this test to fail with the changes on the review but it didn't. Yes, since this file is not included in headless environment, related gtk libraries are not loaded. @honkar-jdk Thanks for pointing it out. @aivanov-jdk Please re-review again. Due to recent changes, it is required to review the latest commit. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20671#issuecomment-2306674817 PR Comment: https://git.openjdk.org/jdk/pull/20671#issuecomment-2306677974 From abhiscxk at openjdk.org Fri Aug 23 09:28:22 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Fri, 23 Aug 2024 09:28:22 GMT Subject: RFR: 8338668: Test javax/swing/JFileChooser/8080628/bug8080628.java doesn't test for GTK L&F [v2] In-Reply-To: References: Message-ID: On Thu, 22 Aug 2024 21:33:56 GMT, Alisen Chung wrote: >> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: >> >> Review comment update > > test/jdk/javax/swing/JFileChooser/8080628/bug8080628.java line 1: > >> 1: /* > > Could you also clean up the main method and remove the extra overhead in the SwingUtilities.invokeAndWait call? Also remember to update copyright years I think that is ok.. it's pretty simple where runnable interface run method is overridden and is supposed to run the test. copyright year updated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20671#discussion_r1728662804 From psadhukhan at openjdk.org Fri Aug 23 09:35:39 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 23 Aug 2024 09:35:39 GMT Subject: RFR: 8190329: [macos] Swing InterOp Platform.exit() crash Message-ID: The testcase calls Platform.exit before the dialog is made visible but on macOS, JavaFX takes over the AppKit thread and uses that as the FX application thread. As part of the FX platform shutdown process, it detaches that thread from the JVM. This means that the AppKit thread is no longer available to Java processes so AWT crashes when it ties to access appkit thread. Fix is made to check if the thread has been detached for move-resize notification event before proceeding.. ------------- Commit messages: - 8190329: [macos] Swing InterOp Platform.exit() crash Changes: https://git.openjdk.org/jdk/pull/20688/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20688&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8190329 Stats: 7 lines in 1 file changed: 7 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20688.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20688/head:pull/20688 PR: https://git.openjdk.org/jdk/pull/20688 From aivanov at openjdk.org Fri Aug 23 09:54:04 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 23 Aug 2024 09:54:04 GMT Subject: RFR: 8338668: Test javax/swing/JFileChooser/8080628/bug8080628.java doesn't test for GTK L&F [v2] In-Reply-To: References: Message-ID: <6Ls9ujqrhiFsJXEXm5y-JiswWJ2j8jG7iH337U-vmcc=.a8b69d89-f822-499c-8919-811bf3dfa813@github.com> On Fri, 23 Aug 2024 09:28:22 GMT, Abhishek Kumar wrote: >> This test should have failed with the [changeset](https://github.com/openjdk/jdk/pull/20612) proposed for [JDK-4795384](https://bugs.openjdk.org/browse/JDK-4795384) but it didn't because GTK look and feel isn't supported in headless environment. >> >> Fix is to run the test with headful environment on linux platform. >> >> Tested in CI pipeline and link attached to JBS. > > Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: > > Review comment update Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20671#pullrequestreview-2256835788 From aivanov at openjdk.org Fri Aug 23 09:54:05 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 23 Aug 2024 09:54:05 GMT Subject: RFR: 8338668: Test javax/swing/JFileChooser/8080628/bug8080628.java doesn't test for GTK L&F [v2] In-Reply-To: References: Message-ID: On Fri, 23 Aug 2024 09:21:02 GMT, Abhishek Kumar wrote: >> test/jdk/javax/swing/JFileChooser/8080628/bug8080628.java line 1: >> >>> 1: /* >> >> Could you also clean up the main method and remove the extra overhead in the SwingUtilities.invokeAndWait call? Also remember to update copyright years > > I think that is ok.. it's pretty simple where runnable interface run method is overridden and is supposed to run the test. > copyright year updated. What do you mean? Replacing `new Runnable` with lambda? Does it add value? Sure the code becomes shorter? However, the test still does its job. And IDE still shows the compact version displaying the body of the `run` method only. Given that no other code is changed, except for adding additional output, I'd rather keep it as it is. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20671#discussion_r1728705048 From ihse at openjdk.org Fri Aug 23 10:07:03 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 23 Aug 2024 10:07:03 GMT Subject: RFR: 8338768: Introduce runtime lookup to check for static builds [v2] In-Reply-To: References: <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com> Message-ID: On Thu, 22 Aug 2024 22:49:50 GMT, David Holmes wrote: > is the final intent here that this one magic file will be compiled first with an inline declaration such that when the other files containing the apparent runtime check get compiled, it can actually be determined at build time and so have the same effects as the old ifdef logic? Theoretically, this is a valid complaint: what is now inlined at compilation time will require an additional function call. And yes, if that had been a performance issue, I would have needed to do something like that. But, if you look at the actual functions that are affected, you can see that it is just a handful of calls that are all done at startup time. Adding like half a dozen calls to a trivial function before loading a DLL will not even be measurable, compared to all the work the OS will do afterwards when loading the DLL. So no, I do not intend to complicate the code further. Any impact of this code is measured in a few additional machine code operations. > There are also other source-level solutions possible here by refactoring the code that has static vs dynamic linking dependencies into its own files and the build system can then select which set of files to compile. There are definitely refactoring/restructuring opportunities to be had, both in Hotspot and in the JDK libraries! Overall, I have found a lot of redundant work, duplicated code, and legacy code that does not make sense anymore (like trying to differentiate between a JRE and a JDK) when setting up the initial environment wrt the basic dynamic libraries. But in the grand scheme of things, I don't think it is reasonable that we spend too much efforts on cleaning up that. While it is definitely a "lava flow" anti-pattern, it mostly works, and starting to poke around will risk breaking things. We don't have a good testing story for the JDK bootstrapping. This is the same problem as the build is facing: you would need to have a ton of differently configured environments to be able to test all possible installations and paths etc. The patch presented here seem to me to be a cautious middle ground -- fixing what is needed to be able to progress, but doing so in a way that every single change is trivially and obviously correct. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20666#issuecomment-2306752185 From tr at openjdk.org Fri Aug 23 10:54:10 2024 From: tr at openjdk.org (Tejesh R) Date: Fri, 23 Aug 2024 10:54:10 GMT Subject: Integrated: 8329756: [macos] "javax/swing/JTable/KeyBoardNavigation.java" fail because most combinations of navigational keys with the Ctrl key do not work In-Reply-To: References: Message-ID: <9d_GyfDfdMXzdelwNroECG3UIIKkWZ3p2qqlHIHxKNI=.971c98d8-558f-4c2b-8895-95d906cb6797@github.com> On Thu, 25 Jul 2024 14:04:32 GMT, Tejesh R wrote: > Mismatch in key combinations, I have taken native macos Numbers application as reference to verify. Have added `Ctrl-Shift Left/Right` action keys similar to `Ctrl-Shift UP/DOWN` which would be expected functionality. I've removed those test instructions which are not applicable/implemented/not working in Macos keyboard navigation. This pull request has now been integrated. Changeset: 916f1aa0 Author: Tejesh R URL: https://git.openjdk.org/jdk/commit/916f1aa04f6fcc6da9bf9d725e3639cf4c0755a1 Stats: 16 lines in 2 files changed: 2 ins; 5 del; 9 mod 8329756: [macos] "javax/swing/JTable/KeyBoardNavigation.java" fail because most combinations of navigational keys with the Ctrl key do not work Reviewed-by: abhiscxk, dnguyen ------------- PR: https://git.openjdk.org/jdk/pull/20331 From duke at openjdk.org Fri Aug 23 12:20:06 2024 From: duke at openjdk.org (duke) Date: Fri, 23 Aug 2024 12:20:06 GMT Subject: RFR: 8338103: Stabilize and open source a Swing OGL ButtonResizeTest [v4] In-Reply-To: References: <8--CxVHS_jclzzN2PWYkI0W3yr7w1al5PSqRdis-PUc=.2f57c378-49cc-40bc-b042-f6aa9bfed07d@github.com> Message-ID: On Thu, 22 Aug 2024 18:04:46 GMT, Manukumar V S wrote: >> This PR creates a new test by stabilising and open sourcing a closed test. >> This test verifies that the OpenGL pipeline does not create artifacts with swing components after window is zoomed to maximum size and then resized back to normal. >> This test is run twice, with and without the flags "-Dsun.java2d.opengl=True -Dsun.java2d.opengl.fbobject=false" . >> >> This is tested(15 times per platform) in all the available mach5 headful platforms and found to be stable. > > Manukumar V S has updated the pull request incrementally with one additional commit since the last revision: > > Review comment fixed : Changed the position of line comments @manukumarvs Your change (at version 75c44d439bbd94c25d4e193c49574cf997b31f1b) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20532#issuecomment-2306973909 From andy.goryachev at oracle.com Fri Aug 23 16:25:09 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Fri, 23 Aug 2024 16:25:09 +0000 Subject: Seeking feedback on a possible JDatePicker Swing component In-Reply-To: References: Message-ID: In addition to SWinxy very good comments, allow me to suggest a few more items: * ability to set the date format, locale, calendar separately * possibly show additional information such as week numbers * make sure the new component is fully accessible * option to grey out or hide past or future dates * ability to highlight / decorate certain days (e.g. holidays), today's date, and weekends * ability to show more than one month, either vertically, horizontally, or in a grid another suggestion is possibly consider making it consistent with the JavaFX DatePicker: https://github.com/andy-goryachev-oracle/Test/blob/main/screenshots/Screenshot%202024-08-23%20at%2009.02.31.png and lastly, the implementation should be cognizant of the time zones, to avoid bugs like this one https://github.com/yui/yui2/pull/15 cheers, -andy From: client-libs-dev on behalf of SWinxy Date: Thursday, August 22, 2024 at 11:08 To: Tejesh R Cc: client-libs-dev at openjdk.java.net Subject: Re: Seeking feedback on a possible JDatePicker Swing component Tejesh, I think it would be a nice feature, and I would be happy to help with it. There are a lot of considerations for displaying calendars. I don't think we should have the date & time combined into one UI component, but separate components, the former of which I'll focus on here. There are two parts to it: first is textbox(es), and second a calendar grid. Here are some requirements that I can think of right now: - Start of the week. Different regions of the world have the week start on different days, usually Sunday or Monday, but some start on Saturday. [1] macOS and Windows both let you change this to any day of the week. On macOS, this is defined by NSCalendar's firstWeekday. - Should there be one text field, or should there be three for day-month-year? Allow the dev to choose? If multiple text boxes, the ways to traverse to the next field should include the period, space, slash, and dash keys in addition to the tab key. (This is because people can type 10/10/10 or 10.10.10 all at once and not have to press tab.) Pasting in a date should be supported in either case, and converted to the displayed locale. - The UI should update in response to a notification from the system that the user has changed their preferred calendar format. - Either way we have the text box, allowing the developer to choose if they want a text box with a popup calendar grid or one that is in the same panel would be ideal. (That is, they add it to the same panel themself.) - The calendar grid should be able to be oriented horizontally or vertically. (When the calendar moves around, does it go left-right or up-down?) Calendar grids often show the previous and next months' dates as padding when the start and end of the month aren't cleanly cut by the start and ends of the week. When going horizontally, the developer should have the option to show or hide those dates. When vertical, the developer should be able to decide if the grid is continuous or interrupted. (To pad with numbers or to pad with empty space.) - UI for changing the month and year of the grid. This can take the form of left-right arrows, scrolling, and/or dropdown for the month and a text field for the year. Extra things: - Calendar type. Most people use Gregorian, but a small number of people can choose otherwise for their systems. macOS gives me a bunch of options, but Windows only allows me to do Gregorian. This is a "wow wouldn't it be cool" optional feature. - A 'today' button, which selects the current date. - How to represent a date range with a calendar and a textbox, I'm not sure. The easy workaround would be to have the developer create two of these date pickers. But a way to select a range would be welcome. - If we do also have a component for time, should we allow for the changing of timezones in the UI? Timezones are too much imo. I'm relying on screenshots on Google for date pickers and NSDatePicker for what features they have. I'm sure I would be able to make use of this somewhere in my own Swing app. SWinxy [1] https://en.wikipedia.org/wiki/Week On Thu, Aug 22, 2024 at 2:29?AM Tejesh R > wrote: Hello Swing Community, Swing has a rich set of UI components in the core Java Platform. But it lacks a Date Picker which is a significant gap for many applications and so we are considering revisiting the idea of a Date Picker in core Swing. The function core of a DatePicker is to let a user select a day [and time?], or range of days [and time ? ], within optional application specified constraints. The JXDatePicker component was previously explored as part of the long defunct external SwingX project. This proposal does not imply reviving JXDatePicker, but being informed by it and date pickers for other platforms. Before even starting on this, we are seeking feedback from the community - Is it of interest ? - Would you use it ? - What features must it have ? - What features are nice to have ? - Do you have any experiences of other date pickers that reinforce those responses ? - Anything else ? If we move forward, we would propose a JEP and also expect that we would deliver it first as a preview feature [1] , so that it may evolve in response to feedback before becoming final. Please let us know your thoughts and suggestions on this proposal. Regards, Tejesh R. JDK client team [1] https://openjdk.org/jeps/12 -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Fri Aug 23 17:47:47 2024 From: philip.race at oracle.com (Philip Race) Date: Fri, 23 Aug 2024 10:47:47 -0700 Subject: Seeking feedback on a possible JDatePicker Swing component In-Reply-To: References: Message-ID: <2fc61c6d-012e-4042-8863-b860a5aa057d@oracle.com> It would be helpful if replies were structured so as to answer the questions we asked. These are very much in priority order. Unless there's yes answers to the 1st & 2nd question, the feature set and comparisons really don't matter .. -phil. On 8/23/24 9:25 AM, Andy Goryachev wrote: > > - Is it of interest ? > > - Would you use it ? > > - What features must it have ? > > - What features are nice to have ? > > - Do you have any experiences of other date pickers that reinforce > those responses ? > > - Anything else ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From honkar at openjdk.org Fri Aug 23 17:51:08 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Fri, 23 Aug 2024 17:51:08 GMT Subject: RFR: 8338668: Test javax/swing/JFileChooser/8080628/bug8080628.java doesn't test for GTK L&F [v2] In-Reply-To: References: Message-ID: <9YRoInJLBoVvAaN8S9KcLbibwlf2irpb4mZLFmFsYDU=.00d1ee4b-45d8-41e3-b275-ba4067c6cf65@github.com> On Fri, 23 Aug 2024 09:28:22 GMT, Abhishek Kumar wrote: >> This test should have failed with the [changeset](https://github.com/openjdk/jdk/pull/20612) proposed for [JDK-4795384](https://bugs.openjdk.org/browse/JDK-4795384) but it didn't because GTK look and feel isn't supported in headless environment. >> >> Fix is to run the test with headful environment on linux platform. >> >> Tested in CI pipeline and link attached to JBS. > > Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: > > Review comment update Marked as reviewed by honkar (Reviewer). Test fix looks good. Works as expected on linux and non-linux platforms. ------------- PR Review: https://git.openjdk.org/jdk/pull/20671#pullrequestreview-2257786026 PR Comment: https://git.openjdk.org/jdk/pull/20671#issuecomment-2307542366 From prr at openjdk.org Fri Aug 23 18:00:03 2024 From: prr at openjdk.org (Phil Race) Date: Fri, 23 Aug 2024 18:00:03 GMT Subject: RFR: 8190329: [macos] Swing InterOp Platform.exit() crash In-Reply-To: References: Message-ID: <0ErO4olMuzO-dyyZ0gMyL6I2Q3kJk3NWMhdUeJ682Qc=.52bd1eb8-5045-4bc1-b391-698768fe59d5@github.com> On Fri, 23 Aug 2024 09:17:43 GMT, Prasanta Sadhukhan wrote: > The testcase calls Platform.exit before the dialog is made visible but > on macOS, JavaFX takes over the AppKit thread and uses that as the FX application thread. As part of the FX platform shutdown process, it detaches that thread from the JVM. This means that the AppKit thread is no longer available to Java processes > so AWT crashes when it ties to access appkit thread. > Fix is made to check if the thread has been detached for move-resize notification event before proceeding.. src/java.desktop/macosx/native/libawt_lwawt/awt/AWTWindow.m line 640: > 638: if (ret == JNI_EDETACHED) { > 639: return; > 640: } This seems like a completely arbitrary location in the AWT code for a test of something that would seem completely unexpected. Can you PROVE that this is the only place that this will ever be needed ? And if you can't, this isn't the right fix. If you can it needs some comments. Also : does AWT detach the AppKit thread from the VM on shutdown ? IF not why does FX have to do it ? If it does, then could FX also crash if FX is embedded in an AWT app. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20688#discussion_r1729333420 From prr at openjdk.org Fri Aug 23 18:06:06 2024 From: prr at openjdk.org (Phil Race) Date: Fri, 23 Aug 2024 18:06:06 GMT Subject: RFR: 8338668: Test javax/swing/JFileChooser/8080628/bug8080628.java doesn't test for GTK L&F [v2] In-Reply-To: References: Message-ID: On Fri, 23 Aug 2024 09:28:22 GMT, Abhishek Kumar wrote: >> This test should have failed with the [changeset](https://github.com/openjdk/jdk/pull/20612) proposed for [JDK-4795384](https://bugs.openjdk.org/browse/JDK-4795384) but it didn't because GTK look and feel isn't supported in headless environment. >> >> Fix is to run the test with headful environment on linux platform. >> >> Tested in CI pipeline and link attached to JBS. > > Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: > > Review comment update I guess this is OK. It is a bit of an anomaly that GTK requires headful and not so easy to explain to users, but it is a lot easier to fix a test than deal with making GTK work in headless mode .. ------------- Marked as reviewed by prr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20671#pullrequestreview-2257810893 From prr at openjdk.org Fri Aug 23 18:11:10 2024 From: prr at openjdk.org (Phil Race) Date: Fri, 23 Aug 2024 18:11:10 GMT Subject: RFR: 8338041: Keyboard Navigation of JTable, Ctrl Shift RIGHT/LEFT doesn't follow native action in GTK L&F [v2] In-Reply-To: References: <_kMMFJ9LnQOmUmp_3Ob1m3lj2xLKUo-ChL00Clw4xjs=.7e799f69-da05-44f4-9bf7-6e9e43b427b8@github.com> Message-ID: On Tue, 20 Aug 2024 07:26:12 GMT, Tejesh R wrote: >> In JTable, keyboard navigation keys Ctrl Shift RIGHT/LEFT doesn't follow native actions of Linux. In native the actions are extended to end of selected columns cells either LEFT/RIGHT but in swing gtk look and feel the selection is extended to one cell to left/right. This might be taken as reference of Windows OS since the same is observed in Windows native. Hence I have update the actions for Ctrl Shift RIGHT & LEFT. >> Added automated test too. The fix is tested in CI and its fine. > > Tejesh R 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 four additional commits since the last revision: > > - Updated review comments > - Merge branch 'master' of https://git.openjdk.java.net/jdk into branch_8338041 > - Test updates > - Key action modified + Automatic test added Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20608#pullrequestreview-2257819221 From prr at openjdk.org Fri Aug 23 18:18:03 2024 From: prr at openjdk.org (Phil Race) Date: Fri, 23 Aug 2024 18:18:03 GMT Subject: RFR: 8332901: Select{Current,New}ItemTest.java for Choice don't open popup on macOS [v4] In-Reply-To: References: Message-ID: On Tue, 20 Aug 2024 14:47:23 GMT, Alexey Ivanov wrote: >> I looked at `java/awt/Choice/SelectCurrentItemTest/SelectCurrentItemTest.java`, ran it and noticed that the test does not open the popup of the `Choice` component on macOS 14.x. >> >> If the popup does not open, the test does not verify anything ? it always passes. >> >> I refactored the test and added a mouse listener to the `Choice` component. If mouse click isn't registered, the test fails. >> >> Later, I found a similar test: `test/jdk/java/awt/Choice/SelectNewItemTest/SelectNewItemTest.java`. It clicks on another item in the Choice popup and expects to receive `ItemEvent`. >> >> I refactored both tests and moved them into `Choice/SelectItem` folder. >> >> `SelectCurrentItemTest` encapsulates the common test logic and provides overridable methods to customise conditions for `SelectNewItemTest`. >> >> Now, `SelectNewItemTest` extends `SelectCurrentItemTest` and overrides the conditions as well as the coordinates for clicking the popup of the `Choice` component. >> >> ~~The updated test fails for me locally on macOS Sonoma 14.5. This is likely the result of [JDK-8322653](https://bugs.openjdk.org/browse/JDK-8322653): _[macos14] : Mouse clicks are not received within 3 pixels of the window boundary_.~~ >> >> To work around JDK-8322653, both tests use non-resizable frame. Both updated tests pass on CI and locally on macOS 14.5. This is why I removed `SelectNewItemTest` from problem-list. > > Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision: > > Amend the copyright year in SelectCurrentItemTest Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20601#pullrequestreview-2257828851 From prr at openjdk.org Fri Aug 23 18:22:05 2024 From: prr at openjdk.org (Phil Race) Date: Fri, 23 Aug 2024 18:22:05 GMT Subject: RFR: 8338425: java.lang.NullPointerException when About MenuItem is selected from SwingSet2DemoTest.java In-Reply-To: References: Message-ID: <_z4_CeEKpwazG5ZfPJfRlklsI_ViMHpyZOartkG9MlM=.e0df96fc-46ca-4105-80c5-9e2be04d9887@github.com> On Thu, 15 Aug 2024 00:58:18 GMT, lawrence.andrews wrote: > Added the missing jpg file & tested and NPE is not seen any more Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20589#pullrequestreview-2257836393 From prr at openjdk.org Fri Aug 23 18:30:06 2024 From: prr at openjdk.org (Phil Race) Date: Fri, 23 Aug 2024 18:30:06 GMT Subject: RFR: 8337287: Update image in javax.swing.text.Document.insert In-Reply-To: References: Message-ID: On Mon, 29 Jul 2024 18:33:08 GMT, Phil Race wrote: >> This changeset updates the image in the documentation for the `Document.insert` method. The image in `Document.remove` was updated by [JDK-4622866](https://bugs.openjdk.org/browse/JDK-4622866) in PR #15701. >> >> Now the illustration of inserting looks similar to removing. The new image is in SVG format. >> >> For reference: >> >> - [`Document.insert` in JDK 22](https://docs.oracle.com/en/java/javase/22/docs/api/java.desktop/javax/swing/text/Document.html#insertString(int,java.lang.String,javax.swing.text.AttributeSet)); >> - [Updated docs for JDK 24](https://cr.openjdk.org/~aivanov/8337287/api/java.desktop/javax/swing/text/Document.html#insertString(int,java.lang.String,javax.swing.text.AttributeSet)). >> >> As in the case with `remove`, I marked up to classes and members with {@code}. > > Marked as reviewed by prr (Reviewer). > @prrace Does it make sense to add a sentence which describes the image? I added one for `remove` to explain all the `Position`s in the removed area are collapsed. > > Inserting a string is more straightforward: all the `Position`s at and after the insertion point are moved by the length of the inserted string. I missed this question. Yes, sure. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20376#issuecomment-2307600260 From prr at openjdk.org Fri Aug 23 18:28:07 2024 From: prr at openjdk.org (Phil Race) Date: Fri, 23 Aug 2024 18:28:07 GMT Subject: RFR: 8337851: Some tests have name which confuse jtreg [v3] In-Reply-To: References: Message-ID: On Mon, 19 Aug 2024 01:28:20 GMT, toshiogata wrote: >> Rename the tests to prevent unexpected deletion of result files when `-retain` jtreg option is specified. >> Testing: modified tests > > toshiogata has updated the pull request incrementally with one additional commit since the last revision: > > Revert "Move jtreg tags and expand wildcard imports" > > This reverts commit 9b30df1230b7e31b42e63ae01ef1549565bcc078. Some one else should decide bout the langtools changes but for the AWT one I agree the minimal rename is all we need here to solve the specific problem which has nothing to do with the test itself. ------------- Marked as reviewed by prr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20475#pullrequestreview-2257847981 From prr at openjdk.org Fri Aug 23 18:39:04 2024 From: prr at openjdk.org (Phil Race) Date: Fri, 23 Aug 2024 18:39:04 GMT Subject: RFR: 8338103: Stabilize and open source a Swing OGL ButtonResizeTest [v4] In-Reply-To: References: <8--CxVHS_jclzzN2PWYkI0W3yr7w1al5PSqRdis-PUc=.2f57c378-49cc-40bc-b042-f6aa9bfed07d@github.com> Message-ID: <7AO_JKocjYGnAp7JfzOFaN8uYMw48LhLbnI1ilkFE5g=.aeb55a93-784f-405b-b46f-ed6391f53431@github.com> On Thu, 22 Aug 2024 18:04:46 GMT, Manukumar V S wrote: >> This PR creates a new test by stabilising and open sourcing a closed test. >> This test verifies that the OpenGL pipeline does not create artifacts with swing components after window is zoomed to maximum size and then resized back to normal. >> This test is run twice, with and without the flags "-Dsun.java2d.opengl=True -Dsun.java2d.opengl.fbobject=false" . >> >> This is tested(15 times per platform) in all the available mach5 headful platforms and found to be stable. > > Manukumar V S has updated the pull request incrementally with one additional commit since the last revision: > > Review comment fixed : Changed the position of line comments test/jdk/javax/swing/JButton/SwingButtonResizeTestWithOpenGL.java line 54: > 52: * a JButton. A file image of the component will be saved before and after > 53: * window resize. The test passes if both button images are the same. > 54: * @run main/othervm -Dsun.java2d.opengl=True -Dsun.java2d.opengl.fbobject=false SwingButtonResizeTestWithOpenGL Does this really work well on Windows ? Commonly OpenGL tests fail on Windows. Did you test it there ? Also is there any reason we can't test this with additional pipelines on specific platforms ? The behaviours being tested are Java behaviours so it ought to pass in other cases too. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20532#discussion_r1729377430 From mvs at openjdk.org Fri Aug 23 18:53:10 2024 From: mvs at openjdk.org (Manukumar V S) Date: Fri, 23 Aug 2024 18:53:10 GMT Subject: RFR: 8338103: Stabilize and open source a Swing OGL ButtonResizeTest [v4] In-Reply-To: <7AO_JKocjYGnAp7JfzOFaN8uYMw48LhLbnI1ilkFE5g=.aeb55a93-784f-405b-b46f-ed6391f53431@github.com> References: <8--CxVHS_jclzzN2PWYkI0W3yr7w1al5PSqRdis-PUc=.2f57c378-49cc-40bc-b042-f6aa9bfed07d@github.com> <7AO_JKocjYGnAp7JfzOFaN8uYMw48LhLbnI1ilkFE5g=.aeb55a93-784f-405b-b46f-ed6391f53431@github.com> Message-ID: On Fri, 23 Aug 2024 18:36:40 GMT, Phil Race wrote: >> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision: >> >> Review comment fixed : Changed the position of line comments > > test/jdk/javax/swing/JButton/SwingButtonResizeTestWithOpenGL.java line 54: > >> 52: * a JButton. A file image of the component will be saved before and after >> 53: * window resize. The test passes if both button images are the same. >> 54: * @run main/othervm -Dsun.java2d.opengl=True -Dsun.java2d.opengl.fbobject=false SwingButtonResizeTestWithOpenGL > > Does this really work well on Windows ? Commonly OpenGL tests fail on Windows. > Ah I see in the bug report you say you tested on all platforms OK. > > Also is there any reason we can't test this with additional pipelines on specific platforms ? > The behaviours being tested are Java behaviours so it ought to pass in other cases too. Yes, I tested it on different windows platforms (Windows 10,11,2022) and it succeeded everywhere. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20532#discussion_r1729391151 From mickleness at gmail.com Fri Aug 23 20:43:31 2024 From: mickleness at gmail.com (Jeremy Wood) Date: Fri, 23 Aug 2024 20:43:31 +0000 Subject: Seeking feedback on a possible JDatePicker Swing component In-Reply-To: <2fc61c6d-012e-4042-8863-b860a5aa057d@oracle.com> References: <2fc61c6d-012e-4042-8863-b860a5aa057d@oracle.com> Message-ID: > Is it of interest ? Yes > Would you use it ? As needed, sure. Our current app doesn?t really need a date picker, though. I can imagine other apps that would. > What features must it have? 1. A data model that supports choosing one date. 2. A highlighter that lets us decorate arbitrary dates. > What features are nice to have? 1. Like ListSelectionModel: the ability to specify whether it is single-selection, continuous selection (a date range), or multiple selection intervals. 2. Maybe this is implied, but I would want a well-designed BasicDatePicker class that we can customize as needed. > Do you have any experiences of other date pickers that reinforce those responses ? No. > Anything else ? A date picker is the only thing that a stranger has asked me for ( https://github.com/mickleness/pumpernickel/issues/79 ), which may speak to its popularity. I would be curious if anyone?s familiar with existing open source approaches (like https://github.com/JDatePicker/JDatePicker )? (How do they measure up, what are their shortcomings, etc.) Is there anything an official javax.swing.JDatePicker can bring to the table that open source solutions can?t? ------ Original Message ------ >From "Philip Race" To "Andy Goryachev" ; "SWinxy" ; "Tejesh R" Cc "client-libs-dev at openjdk.java.net" Date 8/23/2024 1:47:47?PM Subject Re: Seeking feedback on a possible JDatePicker Swing component >It would be helpful if replies were structured so as to answer the >questions we asked. >These are very much in priority order. Unless there's yes answers to >the 1st & 2nd question, >the feature set and comparisons really don't matter .. > >-phil. > >On 8/23/24 9:25 AM, Andy Goryachev wrote: >> >>- Is it of interest ? >> >>- Would you use it ? >> >>- What features must it have ? >> >>- What features are nice to have ? >> >>- Do you have any experiences of other date pickers that reinforce >>those responses ? >> >>- Anything else ? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jjg at openjdk.org Fri Aug 23 22:17:04 2024 From: jjg at openjdk.org (Jonathan Gibbons) Date: Fri, 23 Aug 2024 22:17:04 GMT Subject: RFR: 8337851: Some tests have name which confuse jtreg [v3] In-Reply-To: <-ua0I6lCxPPp57ELQTFMnMOS8pJP03pGxmGMaVMrJYI=.e87e09a5-6475-44b5-855c-b005fff2ad1c@github.com> References: <9Ohvnc6MgnokscABDpbRhBYuXtjguHrcJd7eVRWSXYs=.cd938d32-de8b-4eb1-a601-421762f991f3@github.com> <-ua0I6lCxPPp57ELQTFMnMOS8pJP03pGxmGMaVMrJYI=.e87e09a5-6475-44b5-855c-b005fff2ad1c@github.com> Message-ID: On Mon, 19 Aug 2024 12:34:15 GMT, Alexey Ivanov wrote: >> Thank you for pointing it out. I was not aware of the git rename issue. >> I changed the fix to only rename files. > >> Thank you for pointing it out. I was not aware of the git rename issue. > > Even if it were not for this Git ?limitation?, I still think additional changes should be requested by Java Compiler team. I am not aware of their practices. > > @alisenchung knows I'm advocating for expanding imports (whenever a test or source file is modified) and for moving jtreg tags below imports closer to the class declaration. At the same time, we haven't reached an agreement about it, although some people seem to support it too. With my official `jtreg` hat on, I recommend always placing the `jtreg` tags immediately after any legal header comments and _before_ any of the source code that comprises the test. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20475#discussion_r1729563721 From jjg at openjdk.org Fri Aug 23 22:34:04 2024 From: jjg at openjdk.org (Jonathan Gibbons) Date: Fri, 23 Aug 2024 22:34:04 GMT Subject: RFR: 8337851: Some tests have name which confuse jtreg [v3] In-Reply-To: References: Message-ID: On Mon, 19 Aug 2024 01:28:20 GMT, toshiogata wrote: >> Rename the tests to prevent unexpected deletion of result files when `-retain` jtreg option is specified. >> Testing: modified tests > > toshiogata has updated the pull request incrementally with one additional commit since the last revision: > > Revert "Move jtreg tags and expand wildcard imports" > > This reverts commit 9b30df1230b7e31b42e63ae01ef1549565bcc078. Moving files from one directory to another can sometimes be a bit risky, especially for `javac` tests, because that implies moving the classes from one unnamed package to a different unnamed package. Please confirm that all tests under `test/langtools/tools/javac` continue to pass after the files have been moved. You can either run just those tests, or run all langtools `tier1` tests if that is easier. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20475#issuecomment-2307886982 From jjg at openjdk.org Fri Aug 23 22:39:03 2024 From: jjg at openjdk.org (Jonathan Gibbons) Date: Fri, 23 Aug 2024 22:39:03 GMT Subject: RFR: 8337851: Some tests have name which confuse jtreg [v3] In-Reply-To: References: Message-ID: On Fri, 23 Aug 2024 22:31:04 GMT, Jonathan Gibbons wrote: >> toshiogata has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert "Move jtreg tags and expand wildcard imports" >> >> This reverts commit 9b30df1230b7e31b42e63ae01ef1549565bcc078. > > Moving files from one directory to another can sometimes be a bit risky, especially for `javac` tests, because that implies moving the classes from one unnamed package to a different unnamed package. > > Please confirm that all tests under `test/langtools/tools/javac` continue to pass after the files have been moved. You can either run just those tests, or run all langtools `tier1` tests if that is easier. > > @jonathan-gibbons Is this a bug in jtreg, or where these files actually improperly named? > > Not a bug as such, but maybe a little-known misfeature. `jtreg` has always had problems with filenames that could cause confusion, and the general sense has generally been, "if it hurts, don't do it!". That being said, our overall library API and infrastructure is way better these days than in times past, and it might be reasonable to file an Enhancement for `jtreg` to have a utility/check/test to detect these anomalous situations. > > In the meantime, renaming the files to avoid the problem is the recommended solution. Filed https://bugs.openjdk.org/browse/CODETOOLS-7903803 ------------- PR Comment: https://git.openjdk.org/jdk/pull/20475#issuecomment-2307890897 From prr at openjdk.org Fri Aug 23 23:33:02 2024 From: prr at openjdk.org (Phil Race) Date: Fri, 23 Aug 2024 23:33:02 GMT Subject: RFR: 8336873: BasicSplitPaneDivider:oneTouchExpandableChanged() should mention that implementation depends on SplitPane.supportsOneTouchButtons property [v3] In-Reply-To: References: Message-ID: On Tue, 30 Jul 2024 03:14:05 GMT, Prasanta Sadhukhan wrote: >> BasicSplitPaneDivider:oneTouchExpandableChanged() spec doesn't mention that it will create left/right button only if L&F supports SplitPane.supportsOneTouchButtons which is now added in javadoc.. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > typo I'm not terribly happy (or impressed) that we do not have a place to document Swing properties which applications are supposed to know about except for random mentions in javadoc. We should look into doing this, but in a separate bug as it is a bigger issue than this. Can you make it clear it is a "Swing" property and update the CSR too. ------------- PR Review: https://git.openjdk.org/jdk/pull/20289#pullrequestreview-2258242959 From kcr at openjdk.org Fri Aug 23 23:50:03 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 23 Aug 2024 23:50:03 GMT Subject: RFR: 8190329: [macos] Swing InterOp Platform.exit() crash In-Reply-To: <0ErO4olMuzO-dyyZ0gMyL6I2Q3kJk3NWMhdUeJ682Qc=.52bd1eb8-5045-4bc1-b391-698768fe59d5@github.com> References: <0ErO4olMuzO-dyyZ0gMyL6I2Q3kJk3NWMhdUeJ682Qc=.52bd1eb8-5045-4bc1-b391-698768fe59d5@github.com> Message-ID: On Fri, 23 Aug 2024 17:56:57 GMT, Phil Race wrote: >> The testcase calls Platform.exit before the dialog is made visible but >> on macOS, JavaFX takes over the AppKit thread and uses that as the FX application thread. As part of the FX platform shutdown process, it detaches that thread from the JVM. This means that the AppKit thread is no longer available to Java processes >> so AWT crashes when it ties to access appkit thread. >> Fix is made to check if the thread has been detached for move-resize notification event before proceeding.. > > src/java.desktop/macosx/native/libawt_lwawt/awt/AWTWindow.m line 640: > >> 638: if (ret == JNI_EDETACHED) { >> 639: return; >> 640: } > > This seems like a completely arbitrary location in the AWT code for a test of something that would seem completely unexpected. > Can you PROVE that this is the only place that this will ever be needed ? > And if you can't, this isn't the right fix. > If you can it needs some comments. > > Also : does AWT detach the AppKit thread from the VM on shutdown ? > IF not why does FX have to do it ? If it does, then could FX also crash if FX is embedded in an AWT app. I'm also not sure that this is the right fix. It seems like it will fix one specific place where AWT could do an upcall on the AppKit thread after FX has detached without addressing the problem as a whole. Another possible fix would be to have AWT not use the cached JNI Env when it is not the NSApplication owner. I don't know how viable this fix would be, or whether it is the right fix, but it would prevent the crash in all possible places. > Also : does AWT detach the AppKit thread from the VM on shutdown ? I doubt it, since there isn't AFAIK an explicit toolkit shutdown in AWT like there is in FX. > IF not why does FX have to do it ? If it does, then could FX also crash if FX is embedded in an AWT app. FX only detaches the AppKit thread when it is the NSApplication owner, and thus attached the thread in the first place. In the case of FX embedded in an AWT app, it won't detach the thread. We could explore what it would take for FX to not detach the AppKit thread from Java. At a minimum, it would require attaching the AppKit thread as a daemon (which AWT already does), and then creating a non-daemon Java thread that we would then terminate at FX toolkit shutdown. This would need to be tested carefully, but might be the cleanest solution. One thing to note is that anything we do here will be about avoiding a crash in AWT, not about having the UI remain functional. In this case FX is the "owner" of the native Window system event loop (and NSApplication on macOS). Applications should not shutdown the FX toolkit (meaning, not call `Platform.exit`) and expect AWT to continue to work. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20688#discussion_r1729612142 From serb at openjdk.org Sat Aug 24 00:09:06 2024 From: serb at openjdk.org (Sergey Bylokhov) Date: Sat, 24 Aug 2024 00:09:06 GMT Subject: Integrated: 8338785: The java.awt.datatransfer.SystemFlavorMap#FLAVOR_MAP_KEY field is not used In-Reply-To: References: Message-ID: On Thu, 22 Aug 2024 03:59:57 GMT, Sergey Bylokhov wrote: > The unused `java.awt.datatransfer.SystemFlavorMap#FLAVOR_MAP_KEY` field is deleted. > > It was unused since [8037485](https://bugs.openjdk.org/browse/JDK-8037485): Refactor java.awt.datatransfer to eliminate dependency on AWT. > > See: > https://github.com/openjdk/jdk/commit/0fecd7769453dfb3ef1609b057a9e69aee57d0c1#diff-2c0c7e0dbcabe2bced2907f383bdb4e2a3ed64686c219f37f7c6469ecc47d4baL198 This pull request has now been integrated. Changeset: 5671f836 Author: Sergey Bylokhov URL: https://git.openjdk.org/jdk/commit/5671f836039ef1683e3e9ce5b7cf0fa2f1860e2d Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod 8338785: The java.awt.datatransfer.SystemFlavorMap#FLAVOR_MAP_KEY field is not used Reviewed-by: honkar, dnguyen, prr ------------- PR: https://git.openjdk.org/jdk/pull/20670 From prr at openjdk.org Sat Aug 24 00:07:02 2024 From: prr at openjdk.org (Phil Race) Date: Sat, 24 Aug 2024 00:07:02 GMT Subject: RFR: 8190329: [macos] Swing InterOp Platform.exit() crash In-Reply-To: References: <0ErO4olMuzO-dyyZ0gMyL6I2Q3kJk3NWMhdUeJ682Qc=.52bd1eb8-5045-4bc1-b391-698768fe59d5@github.com> Message-ID: On Fri, 23 Aug 2024 23:47:12 GMT, Kevin Rushforth wrote: > I'm also not sure that this is the right fix. It seems like it will fix one specific place where AWT could do an upcall on the AppKit thread after FX has detached without addressing the problem as a whole. > > Another possible fix would be to have AWT not use the cached JNI Env when it is not the NSApplication owner. I don't know how viable this fix would be, or whether it is the right fix, but it would prevent the crash in all possible places. That sounds like lots of places would need to be updated to do this. > > > Also : does AWT detach the AppKit thread from the VM on shutdown ? > > I doubt it, since there isn't AFAIK an explicit toolkit shutdown in AWT like there is in FX. > > > IF not why does FX have to do it ? If it does, then could FX also crash if FX is embedded in an AWT app. > > FX only detaches the AppKit thread when it is the NSApplication owner, and thus attached the thread in the first place. In the case of FX embedded in an AWT app, it won't detach the thread. I didn't expect it to, but I was trying to understand why an AWT exit doesn't cause FX to crash. System.exit() is the AWT equivalent and AWT *could* have a shutdown hook to do the same. It just happens not to. > > We could explore what it would take for FX to not detach the AppKit thread from Java. At a minimum, it would require attaching the AppKit thread as a daemon (which AWT already does), and then creating a non-daemon Java thread that we would then terminate at FX toolkit shutdown. This would need to be tested carefully, but might be the cleanest solution. I would like to see that explored. What does SWT do ? > > One thing to note is that anything we do here will be about avoiding a crash in AWT, not about having the UI remain functional. In this case FX is the "owner" of the native Window system event loop (and NSApplication on macOS). Applications should not shutdown the FX toolkit (meaning, not call `Platform.exit`) and expect AWT to continue to work. I guess Platform.exit for FX embedded inside AWT is a no-op ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20688#discussion_r1729619888 From serb at openjdk.org Sat Aug 24 00:14:03 2024 From: serb at openjdk.org (Sergey Bylokhov) Date: Sat, 24 Aug 2024 00:14:03 GMT Subject: RFR: 8337287: Update image in javax.swing.text.Document.insert In-Reply-To: References: Message-ID: On Mon, 29 Jul 2024 13:43:42 GMT, Alexey Ivanov wrote: > This changeset updates the image in the documentation for the `Document.insert` method. The image in `Document.remove` was updated by [JDK-4622866](https://bugs.openjdk.org/browse/JDK-4622866) in PR #15701. > > Now the illustration of inserting looks similar to removing. The new image is in SVG format. > > For reference: > > - [`Document.insert` in JDK 22](https://docs.oracle.com/en/java/javase/22/docs/api/java.desktop/javax/swing/text/Document.html#insertString(int,java.lang.String,javax.swing.text.AttributeSet)); > - [Updated docs for JDK 24](https://cr.openjdk.org/~aivanov/8337287/api/java.desktop/javax/swing/text/Document.html#insertString(int,java.lang.String,javax.swing.text.AttributeSet)). > > As in the case with `remove`, I marked up to classes and members with {@code}. Just curious why the chars are not in the middle of the boxes? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20376#issuecomment-2307945039 From serb at openjdk.org Sat Aug 24 00:16:02 2024 From: serb at openjdk.org (Sergey Bylokhov) Date: Sat, 24 Aug 2024 00:16:02 GMT Subject: RFR: 8336873: BasicSplitPaneDivider:oneTouchExpandableChanged() should mention that implementation depends on SplitPane.supportsOneTouchButtons property [v3] In-Reply-To: References: Message-ID: On Fri, 23 Aug 2024 23:30:53 GMT, Phil Race wrote: > Can you make it clear it is a "Swing" property and update the CSR too. Maybe we can improve the javadoc tool for that? It is currently possible to mark/highlight the system properties in the doc, it should be possible to do the same for Swing props, and then we can generate the list of such props and links to the specs where it is used. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20289#issuecomment-2307946438 From serb at openjdk.org Sat Aug 24 00:29:02 2024 From: serb at openjdk.org (Sergey Bylokhov) Date: Sat, 24 Aug 2024 00:29:02 GMT Subject: RFR: 8190329: [macos] Swing InterOp Platform.exit() crash In-Reply-To: References: <0ErO4olMuzO-dyyZ0gMyL6I2Q3kJk3NWMhdUeJ682Qc=.52bd1eb8-5045-4bc1-b391-698768fe59d5@github.com> Message-ID: <8DNMrEM6VOHBG8LuUX068hTh-LfMIM8pylXfiIST8PY=.070d587f-c0fa-4caf-ab46-4b4ccad29c7a@github.com> On Sat, 24 Aug 2024 00:04:33 GMT, Phil Race wrote: >> I'm also not sure that this is the right fix. It seems like it will fix one specific place where AWT could do an upcall on the AppKit thread after FX has detached without addressing the problem as a whole. >> >> Another possible fix would be to have AWT not use the cached JNI Env when it is not the NSApplication owner. I don't know how viable this fix would be, or whether it is the right fix, but it would prevent the crash in all possible places. >> >>> Also : does AWT detach the AppKit thread from the VM on shutdown ? >> >> I doubt it, since there isn't AFAIK an explicit toolkit shutdown in AWT like there is in FX. >> >>> IF not why does FX have to do it ? If it does, then could FX also crash if FX is embedded in an AWT app. >> >> FX only detaches the AppKit thread when it is the NSApplication owner, and thus attached the thread in the first place. In the case of FX embedded in an AWT app, it won't detach the thread. >> >> We could explore what it would take for FX to not detach the AppKit thread from Java. At a minimum, it would require attaching the AppKit thread as a daemon (which AWT already does), and then creating a non-daemon Java thread that we would then terminate at FX toolkit shutdown. This would need to be tested carefully, but might be the cleanest solution. >> >> One thing to note is that anything we do here will be about avoiding a crash in AWT, not about having the UI remain functional. In this case FX is the "owner" of the native Window system event loop (and NSApplication on macOS). Applications should not shutdown the FX toolkit (meaning, not call `Platform.exit`) and expect AWT to continue to work. > >> I'm also not sure that this is the right fix. It seems like it will fix one specific place where AWT could do an upcall on the AppKit thread after FX has detached without addressing the problem as a whole. >> >> Another possible fix would be to have AWT not use the cached JNI Env when it is not the NSApplication owner. I don't know how viable this fix would be, or whether it is the right fix, but it would prevent the crash in all possible places. > > That sounds like lots of places would need to be updated to do this. >> >> > Also : does AWT detach the AppKit thread from the VM on shutdown ? >> >> I doubt it, since there isn't AFAIK an explicit toolkit shutdown in AWT like there is in FX. >> >> > IF not why does FX have to do it ? If it does, then could FX also crash if FX is embedded in an AWT app. >> >> FX only detaches the AppKit thread when it is the NSApplication owner, and thus attached the thread in the first place. In the case of FX embedded in an AWT app, it won't detach the thread. > > I didn't expect it to, but I was trying to understand why an AWT exit doesn't cause FX to crash. System.exit() is the AWT equivalent and AWT *could* have a shutdown hook to do the same. It just happens not to. > >> >> We could explore what it would take for FX to not detach the AppKit thread from Java. At a minimum, it would require attaching the AppKit thread as a daemon (which AWT already does), and then creating a non-daemon Java thread that we would then terminate at FX toolkit shutdown. This would need to be tested carefully, but might be the cleanest solution. > > I would like to see that explored. What does SWT do ? > >> >> One thing to note is that anything we do here will be about avoiding a crash in AWT, not about having the UI remain functional. In this case FX is the "owner" of the native Window system event loop (and NSApplication on macOS). Applications should not shutdown the FX toolkit (meaning, not call `Platform.exit`) and expect AWT to continue to work. > > I guess Platform.exit for FX embedded inside AWT is a no-op ? We probably should replace the usage of getJNIEnv. - JNIEnv *env = [ThreadUtilities getJNIEnv]; + JNIEnv *env = [ThreadUtilities getJNIEnvUncached]; The getJNIEnv seems unsafe if some 3p libs like FX can detach the thread. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20688#discussion_r1729628129 From jwaters at openjdk.org Sat Aug 24 04:38:03 2024 From: jwaters at openjdk.org (Julian Waters) Date: Sat, 24 Aug 2024 04:38:03 GMT Subject: RFR: 8336289: Obliterate most references to _snprintf in the Windows JDK [v3] In-Reply-To: References: Message-ID: On Tue, 16 Jul 2024 08:59:20 GMT, Julian Waters wrote: >> snprintf has been available for all officially and unofficially supported compilers for Windows, Visual Studio since version 2015 and gcc since, well, forever. snprintf is conforming to C99 since the start when compiling using gcc, and 2015 when using Visual Studio. Since it conforms to C99 and provides better semantics than _snprintf, and is not compiler specific, we should use it in most places where we currently use _snprintf. This makes JDK code where this is used more robust due to the null terminating guarantee of snprintf. Since most of the changes are extremely simple, I've included all of them hoping to get this all done in one shot. The only places _snprintf is not replaced is places where I'm not sure whether the code is ours or not (As in, imported source code for external libraries). Note that the existing checks in place for the size of the characters written still work, as the return value of snprintf works mostly the same as _snprintf. The only difference is the nu ll terminating character at the end and the returning of the number of written characters if the buffer was terminated early, as seen here: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170 >> >> Reviews Required: 2 for HotSpot, jdk.hotspot.agent, and jdk.jdwp.agent, 1 for awt and jdk.accessibility, 1 for java.base, 1 for security, 1 for jdk.management(?) > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > Revert Standard Integer type rewrite I was going to ask for a security review, but I decided to only do that after I change the copyright years in the files that need it. Well, when I have the time that is... ------------- PR Comment: https://git.openjdk.org/jdk/pull/20153#issuecomment-2308076996 From jwaters at openjdk.org Sat Aug 24 05:06:18 2024 From: jwaters at openjdk.org (Julian Waters) Date: Sat, 24 Aug 2024 05:06:18 GMT Subject: RFR: 8336289: Obliterate most references to _snprintf in the Windows JDK [v4] In-Reply-To: References: Message-ID: > snprintf has been available for all officially and unofficially supported compilers for Windows, Visual Studio since version 2015 and gcc since, well, forever. snprintf is conforming to C99 since the start when compiling using gcc, and 2015 when using Visual Studio. Since it conforms to C99 and provides better semantics than _snprintf, and is not compiler specific, we should use it in most places where we currently use _snprintf. This makes JDK code where this is used more robust due to the null terminating guarantee of snprintf. Since most of the changes are extremely simple, I've included all of them hoping to get this all done in one shot. The only places _snprintf is not replaced is places where I'm not sure whether the code is ours or not (As in, imported source code for external libraries). Note that the existing checks in place for the size of the characters written still work, as the return value of snprintf works mostly the same as _snprintf. The only difference is the nul l terminating character at the end and the returning of the number of written characters if the buffer was terminated early, as seen here: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170 > > Reviews Required: 2 for HotSpot, jdk.hotspot.agent, and jdk.jdwp.agent, 1 for awt and jdk.accessibility, 1 for java.base, 1 for security, 1 for jdk.management(?) Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Change copyright years and formatting ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20153/files - new: https://git.openjdk.org/jdk/pull/20153/files/a0477b8b..e14ef6b6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20153&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20153&range=02-03 Stats: 46 lines in 10 files changed: 0 ins; 0 del; 46 mod Patch: https://git.openjdk.org/jdk/pull/20153.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20153/head:pull/20153 PR: https://git.openjdk.org/jdk/pull/20153 From jwaters at openjdk.org Sat Aug 24 05:12:42 2024 From: jwaters at openjdk.org (Julian Waters) Date: Sat, 24 Aug 2024 05:12:42 GMT Subject: RFR: 8336289: Obliterate most references to _snprintf in the Windows JDK [v5] In-Reply-To: References: Message-ID: <_LI2j7i2WUtuzSXitbNtJVWRcmQFfOKASpJZ9P-iV_k=.467c12a0-ac63-4c22-8e8d-f4ea4b1c8f9c@github.com> > snprintf has been available for all officially and unofficially supported compilers for Windows, Visual Studio since version 2015 and gcc since, well, forever. snprintf is conforming to C99 since the start when compiling using gcc, and 2015 when using Visual Studio. Since it conforms to C99 and provides better semantics than _snprintf, and is not compiler specific, we should use it in most places where we currently use _snprintf. This makes JDK code where this is used more robust due to the null terminating guarantee of snprintf. Since most of the changes are extremely simple, I've included all of them hoping to get this all done in one shot. The only places _snprintf is not replaced is places where I'm not sure whether the code is ours or not (As in, imported source code for external libraries). Note that the existing checks in place for the size of the characters written still work, as the return value of snprintf works mostly the same as _snprintf. The only difference is the nul l terminating character at the end and the returning of the number of written characters if the buffer was terminated early, as seen here: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170 > > Reviews Required: 2 for HotSpot, jdk.hotspot.agent, and jdk.jdwp.agent, 1 for awt and jdk.accessibility, 1 for java.base, 1 for security, 1 for jdk.management(?) Julian Waters 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 five additional commits since the last revision: - Merge branch 'master' into snprintf - Change copyright years and formatting - Revert Standard Integer type rewrite - USe os::snprintf in HotSpot - Obliterate most references to _snprintf in the Windows JDK ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20153/files - new: https://git.openjdk.org/jdk/pull/20153/files/e14ef6b6..d8f7b849 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20153&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20153&range=03-04 Stats: 56099 lines in 1629 files changed: 32020 ins; 16189 del; 7890 mod Patch: https://git.openjdk.org/jdk/pull/20153.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20153/head:pull/20153 PR: https://git.openjdk.org/jdk/pull/20153 From jwaters at openjdk.org Sat Aug 24 05:12:42 2024 From: jwaters at openjdk.org (Julian Waters) Date: Sat, 24 Aug 2024 05:12:42 GMT Subject: RFR: 8336289: Obliterate most references to _snprintf in the Windows JDK [v4] In-Reply-To: References: Message-ID: <3ewsuSYlM6tvlOjvAlBCPcam2tLiPTx_fv9le9GKpJY=.1030005f-dcbc-4b65-a7f1-c35382f60cc0@github.com> On Sat, 24 Aug 2024 05:06:18 GMT, Julian Waters wrote: >> snprintf has been available for all officially and unofficially supported compilers for Windows, Visual Studio since version 2015 and gcc since, well, forever. snprintf is conforming to C99 since the start when compiling using gcc, and 2015 when using Visual Studio. Since it conforms to C99 and provides better semantics than _snprintf, and is not compiler specific, we should use it in most places where we currently use _snprintf. This makes JDK code where this is used more robust due to the null terminating guarantee of snprintf. Since most of the changes are extremely simple, I've included all of them hoping to get this all done in one shot. The only places _snprintf is not replaced is places where I'm not sure whether the code is ours or not (As in, imported source code for external libraries). Note that the existing checks in place for the size of the characters written still work, as the return value of snprintf works mostly the same as _snprintf. The only difference is the nu ll terminating character at the end and the returning of the number of written characters if the buffer was terminated early, as seen here: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170 >> >> Reviews Required: 2 for HotSpot, jdk.hotspot.agent, and jdk.jdwp.agent, 1 for awt and jdk.accessibility, 1 for java.base, 1 for security, 1 for jdk.management(?) > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > Change copyright years and formatting Alright, never mind, I've gone ahead with the copyright anyway, and in the process also fought my OCD and given the snprintf calls proper formatting too. Now awaiting re-review from all, as well as the missing review from security ------------- PR Comment: https://git.openjdk.org/jdk/pull/20153#issuecomment-2308107303 From jpai at openjdk.org Sat Aug 24 05:24:10 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Sat, 24 Aug 2024 05:24:10 GMT Subject: RFR: 8336289: Obliterate most references to _snprintf in the Windows JDK [v5] In-Reply-To: <_LI2j7i2WUtuzSXitbNtJVWRcmQFfOKASpJZ9P-iV_k=.467c12a0-ac63-4c22-8e8d-f4ea4b1c8f9c@github.com> References: <_LI2j7i2WUtuzSXitbNtJVWRcmQFfOKASpJZ9P-iV_k=.467c12a0-ac63-4c22-8e8d-f4ea4b1c8f9c@github.com> Message-ID: On Sat, 24 Aug 2024 05:12:42 GMT, Julian Waters wrote: >> snprintf has been available for all officially and unofficially supported compilers for Windows, Visual Studio since version 2015 and gcc since, well, forever. snprintf is conforming to C99 since the start when compiling using gcc, and 2015 when using Visual Studio. Since it conforms to C99 and provides better semantics than _snprintf, and is not compiler specific, we should use it in most places where we currently use _snprintf. This makes JDK code where this is used more robust due to the null terminating guarantee of snprintf. Since most of the changes are extremely simple, I've included all of them hoping to get this all done in one shot. The only places _snprintf is not replaced is places where I'm not sure whether the code is ours or not (As in, imported source code for external libraries). Note that the existing checks in place for the size of the characters written still work, as the return value of snprintf works mostly the same as _snprintf. The only difference is the nu ll terminating character at the end and the returning of the number of written characters if the buffer was terminated early, as seen here: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170 >> >> Reviews Required: 2 for HotSpot, jdk.hotspot.agent, and jdk.jdwp.agent, 1 for awt and jdk.accessibility, 1 for java.base, 1 for security, 1 for jdk.management(?) > > Julian Waters 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 five additional commits since the last revision: > > - Merge branch 'master' into snprintf > - Change copyright years and formatting > - Revert Standard Integer type rewrite > - USe os::snprintf in HotSpot > - Obliterate most references to _snprintf in the Windows JDK Marked as reviewed by jpai (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20153#pullrequestreview-2258410435 From mvs at openjdk.org Sat Aug 24 06:33:04 2024 From: mvs at openjdk.org (Manukumar V S) Date: Sat, 24 Aug 2024 06:33:04 GMT Subject: RFR: 8338103: Stabilize and open source a Swing OGL ButtonResizeTest [v4] In-Reply-To: <7AO_JKocjYGnAp7JfzOFaN8uYMw48LhLbnI1ilkFE5g=.aeb55a93-784f-405b-b46f-ed6391f53431@github.com> References: <8--CxVHS_jclzzN2PWYkI0W3yr7w1al5PSqRdis-PUc=.2f57c378-49cc-40bc-b042-f6aa9bfed07d@github.com> <7AO_JKocjYGnAp7JfzOFaN8uYMw48LhLbnI1ilkFE5g=.aeb55a93-784f-405b-b46f-ed6391f53431@github.com> Message-ID: On Fri, 23 Aug 2024 18:36:40 GMT, Phil Race wrote: >> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision: >> >> Review comment fixed : Changed the position of line comments > > test/jdk/javax/swing/JButton/SwingButtonResizeTestWithOpenGL.java line 54: > >> 52: * a JButton. A file image of the component will be saved before and after >> 53: * window resize. The test passes if both button images are the same. >> 54: * @run main/othervm -Dsun.java2d.opengl=True -Dsun.java2d.opengl.fbobject=false SwingButtonResizeTestWithOpenGL > > Does this really work well on Windows ? Commonly OpenGL tests fail on Windows. > Ah I see in the bug report you say you tested on all platforms OK. > > Also is there any reason we can't test this with additional pipelines on specific platforms ? > The behaviours being tested are Java behaviours so it ought to pass in other cases too. @prrace I?m not sure I understand what you meant by 'testing this with additional pipelines on specific platforms.' Are you suggesting that we should test this not only with -Dsun.java2d.opengl=True -Dsun.java2d.opengl.fbobject=false, but also with other parameters? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20532#discussion_r1729782315 From kcr at openjdk.org Sat Aug 24 12:39:07 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 24 Aug 2024 12:39:07 GMT Subject: RFR: 8190329: [macos] Swing InterOp Platform.exit() crash In-Reply-To: <8DNMrEM6VOHBG8LuUX068hTh-LfMIM8pylXfiIST8PY=.070d587f-c0fa-4caf-ab46-4b4ccad29c7a@github.com> References: <0ErO4olMuzO-dyyZ0gMyL6I2Q3kJk3NWMhdUeJ682Qc=.52bd1eb8-5045-4bc1-b391-698768fe59d5@github.com> <8DNMrEM6VOHBG8LuUX068hTh-LfMIM8pylXfiIST8PY=.070d587f-c0fa-4caf-ab46-4b4ccad29c7a@github.com> Message-ID: On Sat, 24 Aug 2024 00:26:47 GMT, Sergey Bylokhov wrote: >>> I'm also not sure that this is the right fix. It seems like it will fix one specific place where AWT could do an upcall on the AppKit thread after FX has detached without addressing the problem as a whole. >>> >>> Another possible fix would be to have AWT not use the cached JNI Env when it is not the NSApplication owner. I don't know how viable this fix would be, or whether it is the right fix, but it would prevent the crash in all possible places. >> >> That sounds like lots of places would need to be updated to do this. >>> >>> > Also : does AWT detach the AppKit thread from the VM on shutdown ? >>> >>> I doubt it, since there isn't AFAIK an explicit toolkit shutdown in AWT like there is in FX. >>> >>> > IF not why does FX have to do it ? If it does, then could FX also crash if FX is embedded in an AWT app. >>> >>> FX only detaches the AppKit thread when it is the NSApplication owner, and thus attached the thread in the first place. In the case of FX embedded in an AWT app, it won't detach the thread. >> >> I didn't expect it to, but I was trying to understand why an AWT exit doesn't cause FX to crash. System.exit() is the AWT equivalent and AWT *could* have a shutdown hook to do the same. It just happens not to. >> >>> >>> We could explore what it would take for FX to not detach the AppKit thread from Java. At a minimum, it would require attaching the AppKit thread as a daemon (which AWT already does), and then creating a non-daemon Java thread that we would then terminate at FX toolkit shutdown. This would need to be tested carefully, but might be the cleanest solution. >> >> I would like to see that explored. What does SWT do ? >> >>> >>> One thing to note is that anything we do here will be about avoiding a crash in AWT, not about having the UI remain functional. In this case FX is the "owner" of the native Window system event loop (and NSApplication on macOS). Applications should not shutdown the FX toolkit (meaning, not call `Platform.exit`) and expect AWT to continue to work. >> >> I guess Platform.exit for FX embedded inside AWT is a no-op ? > > We probably should replace the usage of getJNIEnv. > > - JNIEnv *env = [ThreadUtilities getJNIEnv]; > + JNIEnv *env = [ThreadUtilities getJNIEnvUncached]; > > > The getJNIEnv seems unsafe if some 3p libs like FX can detach the thread. > > Another possible fix would be to have AWT not use the cached JNI Env when it is not the NSApplication owner. I don't know how viable this fix would be, or whether it is the right fix, but it would prevent the crash in all possible places. > > That sounds like lots of places would need to be updated to do this. No, only in one place. The idea I had -- and did a quick prototype of -- was to change the implementation of `[ThreadUtilities getJNIEnv]` to check a flag to see whether or not AWT was the owner of the NSApplication and, if not, effectively do the same thing as `getJNIEnvUncached`. What that would then do would be to re-attach the AppKit thread to the JVM if FX had detached it. This will avoid the crash in all places without having to change the callers of `getJNIEnv` > We could explore what it would take for FX to not detach the AppKit thread from Java. At a minimum, it would require attaching the AppKit thread as a daemon (which AWT already does), and then creating a non-daemon Java thread that we would then terminate at FX toolkit shutdown. This would need to be tested carefully, but might be the cleanest solution. > > I would like to see that explored. What does SWT do ? I'll explore this for FX. I think it will be pretty easy. No idea what SWT does. > > One thing to note is that anything we do here will be about avoiding a crash in AWT, not about having the UI remain functional. In this case FX is the "owner" of the native Window system event loop (and NSApplication on macOS). Applications should not shutdown the FX toolkit (meaning, not call `Platform.exit`) and expect AWT to continue to work. > > I guess Platform.exit for FX embedded inside AWT is a no-op ? Not a no-op, since it still shuts down the FX toolkit and renderer, but it doesn't detach the AppkitThread from the JVM. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20688#discussion_r1729953756 From prr at openjdk.org Sat Aug 24 20:33:30 2024 From: prr at openjdk.org (Phil Race) Date: Sat, 24 Aug 2024 20:33:30 GMT Subject: RFR: 8338928: Update SwingSet2 "About" image to reference openjdk.org Message-ID: Update the image used when displaying SwingSet2->File->About to include up to date URLs. ------------- Commit messages: - 8338928 Changes: https://git.openjdk.org/jdk/pull/20703/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20703&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8338928 Stats: 0 lines in 1 file changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20703.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20703/head:pull/20703 PR: https://git.openjdk.org/jdk/pull/20703 From prr at openjdk.org Sat Aug 24 20:34:04 2024 From: prr at openjdk.org (Phil Race) Date: Sat, 24 Aug 2024 20:34:04 GMT Subject: RFR: 8338425: java.lang.NullPointerException when About MenuItem is selected from SwingSet2DemoTest.java In-Reply-To: References: Message-ID: <6kl1aP2b1N8HYsZqoeZDIhTXAWW4uFfqBq6RkQ_SJ-c=.4612283e-e1a3-4c20-8aea-2edf578f7d83@github.com> On Thu, 15 Aug 2024 00:58:18 GMT, lawrence.andrews wrote: > Added the missing jpg file & tested and NPE is not seen any more So .. I think you might want to update this PR to use the image I've just posted over in this other PR : https://github.com/openjdk/jdk/pull/20703/files ------------- PR Comment: https://git.openjdk.org/jdk/pull/20589#issuecomment-2308529054 From prr at openjdk.org Sat Aug 24 21:19:02 2024 From: prr at openjdk.org (Phil Race) Date: Sat, 24 Aug 2024 21:19:02 GMT Subject: RFR: 8190329: [macos] Swing InterOp Platform.exit() crash In-Reply-To: References: <0ErO4olMuzO-dyyZ0gMyL6I2Q3kJk3NWMhdUeJ682Qc=.52bd1eb8-5045-4bc1-b391-698768fe59d5@github.com> <8DNMrEM6VOHBG8LuUX068hTh-LfMIM8pylXfiIST8PY=.070d587f-c0fa-4caf-ab46-4b4ccad29c7a@github.com> Message-ID: On Sat, 24 Aug 2024 12:36:55 GMT, Kevin Rushforth wrote: > > > Another possible fix would be to have AWT not use the cached JNI Env when it is not the NSApplication owner. I don't know how viable this fix would be, or whether it is the right fix, but it would prevent the crash in all possible places. > > > > > > That sounds like lots of places would need to be updated to do this. > > No, only in one place. The idea I had -- and did a quick prototype of -- was to change the implementation of `[ThreadUtilities getJNIEnv]` to check a flag to see whether or not AWT was the owner of the NSApplication and, if not, effectively do the same thing as `getJNIEnvUncached`. What that would then do would be to re-attach the AppKit thread to the JVM if FX had detached it. This will avoid the crash in all places without having to change the callers of `getJNIEnv` I've looked and I think that would work. Minimal overhead in the 99.99% "non-embedded" case. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20688#discussion_r1730137603 From alanb at openjdk.org Sun Aug 25 15:00:03 2024 From: alanb at openjdk.org (Alan Bateman) Date: Sun, 25 Aug 2024 15:00:03 GMT Subject: RFR: 8338768: Introduce runtime lookup to check for static builds [v2] In-Reply-To: References: <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com> Message-ID: On Fri, 23 Aug 2024 10:04:42 GMT, Magnus Ihse Bursie wrote: > But, if you look at the actual functions that are affected, you can see that it is just a handful of calls that are all done at startup time. That is true for now but there 30-50 other places that will need attention once this effort is further along. Everywhere that deals with user editable configuration (conf tree) will change, as will everywhere that reads JDK internal files in the lib directory. It will be possible to abstract some of this but just to say that it a lot of it will be in Java code rather than native code. Also there will be specifically changes that goes with some of this, something for later if there is JEP that proposes builds to produce a static image. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20666#issuecomment-2308884916 From dholmes at openjdk.org Mon Aug 26 01:46:16 2024 From: dholmes at openjdk.org (David Holmes) Date: Mon, 26 Aug 2024 01:46:16 GMT Subject: RFR: 8336289: Obliterate most references to _snprintf in the Windows JDK [v5] In-Reply-To: <_LI2j7i2WUtuzSXitbNtJVWRcmQFfOKASpJZ9P-iV_k=.467c12a0-ac63-4c22-8e8d-f4ea4b1c8f9c@github.com> References: <_LI2j7i2WUtuzSXitbNtJVWRcmQFfOKASpJZ9P-iV_k=.467c12a0-ac63-4c22-8e8d-f4ea4b1c8f9c@github.com> Message-ID: On Sat, 24 Aug 2024 05:12:42 GMT, Julian Waters wrote: >> snprintf has been available for all officially and unofficially supported compilers for Windows, Visual Studio since version 2015 and gcc since, well, forever. snprintf is conforming to C99 since the start when compiling using gcc, and 2015 when using Visual Studio. Since it conforms to C99 and provides better semantics than _snprintf, and is not compiler specific, we should use it in most places where we currently use _snprintf. This makes JDK code where this is used more robust due to the null terminating guarantee of snprintf. Since most of the changes are extremely simple, I've included all of them hoping to get this all done in one shot. The only places _snprintf is not replaced is places where I'm not sure whether the code is ours or not (As in, imported source code for external libraries). Note that the existing checks in place for the size of the characters written still work, as the return value of snprintf works mostly the same as _snprintf. The only difference is the nu ll terminating character at the end and the returning of the number of written characters if the buffer was terminated early, as seen here: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170 >> >> Reviews Required: 2 for HotSpot, jdk.hotspot.agent, and jdk.jdwp.agent, 1 for awt and jdk.accessibility, 1 for java.base, 1 for security, 1 for jdk.management(?) > > Julian Waters 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 five additional commits since the last revision: > > - Merge branch 'master' into snprintf > - Change copyright years and formatting > - Revert Standard Integer type rewrite > - USe os::snprintf in HotSpot > - Obliterate most references to _snprintf in the Windows JDK Still good for me. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20153#pullrequestreview-2259495896 From dholmes at openjdk.org Mon Aug 26 02:10:03 2024 From: dholmes at openjdk.org (David Holmes) Date: Mon, 26 Aug 2024 02:10:03 GMT Subject: RFR: 8338768: Introduce runtime lookup to check for static builds [v2] In-Reply-To: <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com> References: <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com> Message-ID: On Wed, 21 Aug 2024 22:14:40 GMT, Magnus Ihse Bursie wrote: >> As a preparation for Hermetic Java, we need to have a way to look up during runtime if we are using a statically linked library or not. >> >> This change will be the first step needed towards compiling the object files only once, and then link them into either dynamic or static libraries. (The only exception will be the linktype.c[pp] files, which needs to be compiled twice, once for the dynamic libraries and once for the static libraries.) Getting there will require further work though. >> >> This is part of the changes that make up the draft PR https://github.com/openjdk/jdk/pull/19478, which I have broken out. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Also update build to link properly I understand the cost overhead experienced by any individual Java run may be lost in the noise, but it still impacts every single Java run just to save some time/resources for the handful of builders of statically linked VMs. I am not a fan. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20666#issuecomment-2309162391 From kbarrett at openjdk.org Mon Aug 26 02:52:06 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 26 Aug 2024 02:52:06 GMT Subject: RFR: 8336289: Obliterate most references to _snprintf in the Windows JDK [v5] In-Reply-To: <_LI2j7i2WUtuzSXitbNtJVWRcmQFfOKASpJZ9P-iV_k=.467c12a0-ac63-4c22-8e8d-f4ea4b1c8f9c@github.com> References: <_LI2j7i2WUtuzSXitbNtJVWRcmQFfOKASpJZ9P-iV_k=.467c12a0-ac63-4c22-8e8d-f4ea4b1c8f9c@github.com> Message-ID: On Sat, 24 Aug 2024 05:12:42 GMT, Julian Waters wrote: >> snprintf has been available for all officially and unofficially supported compilers for Windows, Visual Studio since version 2015 and gcc since, well, forever. snprintf is conforming to C99 since the start when compiling using gcc, and 2015 when using Visual Studio. Since it conforms to C99 and provides better semantics than _snprintf, and is not compiler specific, we should use it in most places where we currently use _snprintf. This makes JDK code where this is used more robust due to the null terminating guarantee of snprintf. Since most of the changes are extremely simple, I've included all of them hoping to get this all done in one shot. The only places _snprintf is not replaced is places where I'm not sure whether the code is ours or not (As in, imported source code for external libraries). Note that the existing checks in place for the size of the characters written still work, as the return value of snprintf works mostly the same as _snprintf. The only difference is the nu ll terminating character at the end and the returning of the number of written characters if the buffer was terminated early, as seen here: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170 >> >> Reviews Required: 2 for HotSpot, jdk.hotspot.agent, and jdk.jdwp.agent, 1 for awt and jdk.accessibility, 1 for java.base, 1 for security, 1 for jdk.management(?) > > Julian Waters 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 five additional commits since the last revision: > > - Merge branch 'master' into snprintf > - Change copyright years and formatting > - Revert Standard Integer type rewrite > - USe os::snprintf in HotSpot > - Obliterate most references to _snprintf in the Windows JDK Still good. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20153#pullrequestreview-2259597625 From abhiscxk at openjdk.org Mon Aug 26 04:34:07 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Mon, 26 Aug 2024 04:34:07 GMT Subject: RFR: 8338041: Keyboard Navigation of JTable, Ctrl Shift RIGHT/LEFT doesn't follow native action in GTK L&F [v2] In-Reply-To: References: <_kMMFJ9LnQOmUmp_3Ob1m3lj2xLKUo-ChL00Clw4xjs=.7e799f69-da05-44f4-9bf7-6e9e43b427b8@github.com> Message-ID: On Tue, 20 Aug 2024 07:26:12 GMT, Tejesh R wrote: >> In JTable, keyboard navigation keys Ctrl Shift RIGHT/LEFT doesn't follow native actions of Linux. In native the actions are extended to end of selected columns cells either LEFT/RIGHT but in swing gtk look and feel the selection is extended to one cell to left/right. This might be taken as reference of Windows OS since the same is observed in Windows native. Hence I have update the actions for Ctrl Shift RIGHT & LEFT. >> Added automated test too. The fix is tested in CI and its fine. > > Tejesh R 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 four additional commits since the last revision: > > - Updated review comments > - Merge branch 'master' of https://git.openjdk.java.net/jdk into branch_8338041 > - Test updates > - Key action modified + Automatic test added Looks good to me now. ------------- Marked as reviewed by abhiscxk (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20608#pullrequestreview-2259708505 From duke at openjdk.org Mon Aug 26 07:38:04 2024 From: duke at openjdk.org (toshiogata) Date: Mon, 26 Aug 2024 07:38:04 GMT Subject: RFR: 8337851: Some tests have name which confuse jtreg [v3] In-Reply-To: References: Message-ID: On Fri, 23 Aug 2024 22:36:51 GMT, Jonathan Gibbons wrote: >> Moving files from one directory to another can sometimes be a bit risky, especially for `javac` tests, because that implies moving the classes from one unnamed package to a different unnamed package. >> >> Please confirm that all tests under `test/langtools/tools/javac` continue to pass after the files have been moved. You can either run just those tests, or run all langtools `tier1` tests if that is easier. > >> > @jonathan-gibbons Is this a bug in jtreg, or where these files actually improperly named? >> >> Not a bug as such, but maybe a little-known misfeature. `jtreg` has always had problems with filenames that could cause confusion, and the general sense has generally been, "if it hurts, don't do it!". That being said, our overall library API and infrastructure is way better these days than in times past, and it might be reasonable to file an Enhancement for `jtreg` to have a utility/check/test to detect these anomalous situations. >> >> In the meantime, renaming the files to avoid the problem is the recommended solution. > > Filed https://bugs.openjdk.org/browse/CODETOOLS-7903803 @jonathan-gibbons Thank you for your comment and filing jtreg enhancement. I confirmed that all tests under langtools/tools/javac passed after renaming. $ jtreg_7_4_1/jtreg/bin/jtreg -dir:jdk/test/langtools -retain:all -verbose:summary -ignore:quiet -exclude:jdk/test/langtools/ProblemList.txt -jdk:jdk-24+12 tools/javac Directory "JTwork" not found: creating Directory "JTreport" not found: creating Passed: tools/javac/4241573/T4241573.java Passed: tools/javac/4846262/CheckEBCDICLocaleTest.java ... Passed: tools/javac/generics/odersky/Test3.java Passed: tools/javac/generics/odersky/Test4.java Passed: tools/javac/generics/parametricException/J.java Passed: tools/javac/generics/parametricException/ParametricException.java Passed: tools/javac/generics/rare/6665356/T6665356.java Passed: tools/javac/generics/rare/Rare1.java ... Passed: tools/javac/warnings/Serial/RecordExtern.java Passed: tools/javac/warnings/Serial/RecordSerial.java Passed: tools/javac/warnings/Serial/Serial.java Passed: tools/javac/warnings/Serial/SerialMethodArity.java Passed: tools/javac/warnings/Serial/SerialMethodMods.java ... Passed: tools/javac/VersionOpt.java Passed: tools/javac/VoidArray.java Test results: passed: 3,869 ------------- PR Comment: https://git.openjdk.org/jdk/pull/20475#issuecomment-2309542735 From psadhukhan at openjdk.org Mon Aug 26 08:54:15 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 26 Aug 2024 08:54:15 GMT Subject: RFR: 8336873: BasicSplitPaneDivider:oneTouchExpandableChanged() should mention that implementation depends on SplitPane.supportsOneTouchButtons property [v4] In-Reply-To: References: Message-ID: > BasicSplitPaneDivider:oneTouchExpandableChanged() spec doesn't mention that it will create left/right button only if L&F supports SplitPane.supportsOneTouchButtons which is now added in javadoc.. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Mention Swing property ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20289/files - new: https://git.openjdk.org/jdk/pull/20289/files/906799ed..331ddcdd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20289&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20289&range=02-03 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20289.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20289/head:pull/20289 PR: https://git.openjdk.org/jdk/pull/20289 From psadhukhan at openjdk.org Mon Aug 26 08:57:03 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 26 Aug 2024 08:57:03 GMT Subject: RFR: 8336873: BasicSplitPaneDivider:oneTouchExpandableChanged() should mention that implementation depends on SplitPane.supportsOneTouchButtons property [v3] In-Reply-To: References: Message-ID: On Sat, 24 Aug 2024 00:13:46 GMT, Sergey Bylokhov wrote: > Can you make it clear it is a "Swing" property and update the CSR too. Swing property is mentioned.. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20289#issuecomment-2309697695 From mcimadamore at openjdk.org Mon Aug 26 09:20:18 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 26 Aug 2024 09:20:18 GMT Subject: Integrated: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI In-Reply-To: References: Message-ID: <3nep7-Z8_feW39di9cTU1O07lgFQD4WmSHQia-UUS7c=.18fb2776-9f8a-47c8-be58-8cd1dd30d45f@github.com> On Mon, 13 May 2024 10:42:26 GMT, Maurizio Cimadamore wrote: > This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting the use of JNI in the following ways: > > * `System::load` and `System::loadLibrary` are now restricted methods > * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods > * binding a JNI `native` method declaration to a native implementation is now considered a restricted operation > > This PR slightly changes the way in which the JDK deals with restricted methods, even for FFM API calls. In Java 22, the single `--enable-native-access` was used both to specify a set of modules for which native access should be allowed *and* to specify whether illegal native access (that is, native access occurring from a module not specified by `--enable-native-access`) should be treated as an error or a warning. More specifically, an error is only issued if the `--enable-native-access flag` is used at least once. > > Here, a new flag is introduced, namely `illegal-native-access=allow/warn/deny`, which is used to specify what should happen when access to a restricted method and/or functionality is found outside the set of modules specified with `--enable-native-access`. The default policy is `warn`, but users can select `allow` to suppress the warnings, or `deny` to cause `IllegalCallerException` to be thrown. This aligns the treatment of restricted methods with other mechanisms, such as `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`. > > Some changes were required in the package-info javadoc for `java.lang.foreign`, to reflect the changes in the command line flags described above. This pull request has now been integrated. Changeset: 20d8f58c Author: Maurizio Cimadamore URL: https://git.openjdk.org/jdk/commit/20d8f58c92009a46dfb91b951e7d87b4cb8e8b41 Stats: 532 lines in 107 files changed: 341 ins; 52 del; 139 mod 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI Reviewed-by: jpai, prr, ihse, kcr, alanb ------------- PR: https://git.openjdk.org/jdk/pull/19213 From ihse at openjdk.org Mon Aug 26 09:39:04 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 26 Aug 2024 09:39:04 GMT Subject: RFR: 8338768: Introduce runtime lookup to check for static builds [v2] In-Reply-To: References: <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com> Message-ID: On Sun, 25 Aug 2024 14:57:22 GMT, Alan Bateman wrote: > That is true for now but there 30-50 other places that will need attention once this effort is further along. Everywhere that deals with user editable configuration (conf tree) will change, as will everywhere that reads JDK internal files in the lib directory. Well, yes and no. What you are talking about is the Hermetic Java project as a whole. This is about making the build smarter and more efficient at producing static libraries. While static libraries are a sine qua non for Hermetic Java, it is also produced by other reasons. (For instance, the GraalVM and the Mobile Project). It is true that Hermetic Java was what actually got me to prioritize getting static builds to work properly, but the fact is that it has been a sore point for a long time, and the fact that we need to build all object files twice is actually putting a noticable effect on the Oracle CI system. So please don't confuse the cleanup of static builds with the eventual goals of Hermetic Java. The runtime changes needed to read config files from a single binary will need to stand on it's own. The changes in this PR is good for us, regardless of however Hermetic Java proceeds. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20666#issuecomment-2309780980 From ihse at openjdk.org Mon Aug 26 09:42:04 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 26 Aug 2024 09:42:04 GMT Subject: RFR: 8338768: Introduce runtime lookup to check for static builds [v2] In-Reply-To: References: <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com> Message-ID: <4zUGEcC6eLmdq0wAqDCgAjsU17u6-sQNv8KZVQ8pCKc=.f8801e0b-8351-4af9-9825-70ccfa63847a@github.com> On Mon, 26 Aug 2024 02:07:39 GMT, David Holmes wrote: > but it still impacts every single Java run just to save some time/resources for the handful of builders of statically linked VMs. Seriously? I challenge you do prove there is any effect at all. :-/ Also, there is not a "handful" of builders of static libraries. Our internal CI system builds static libraries all the time, and I for one would be glad to use these resources on more productive stuff than building all object files twice. Also, the intention is to enable static builds by default on GHA, once the entire process of making static builds "dirt cheap" is finished, to avoid regressions. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20666#issuecomment-2309786734 From abhiscxk at openjdk.org Mon Aug 26 10:28:05 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Mon, 26 Aug 2024 10:28:05 GMT Subject: RFR: 8338928: Update SwingSet2 "About" image to reference openjdk.org In-Reply-To: References: Message-ID: On Sat, 24 Aug 2024 20:28:41 GMT, Phil Race wrote: > Update the image used when displaying SwingSet2->File->About to include up to date URLs. Marked as reviewed by abhiscxk (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20703#pullrequestreview-2260348994 From mullan at openjdk.org Mon Aug 26 11:10:07 2024 From: mullan at openjdk.org (Sean Mullan) Date: Mon, 26 Aug 2024 11:10:07 GMT Subject: RFR: 8336289: Obliterate most references to _snprintf in the Windows JDK [v5] In-Reply-To: <_LI2j7i2WUtuzSXitbNtJVWRcmQFfOKASpJZ9P-iV_k=.467c12a0-ac63-4c22-8e8d-f4ea4b1c8f9c@github.com> References: <_LI2j7i2WUtuzSXitbNtJVWRcmQFfOKASpJZ9P-iV_k=.467c12a0-ac63-4c22-8e8d-f4ea4b1c8f9c@github.com> Message-ID: On Sat, 24 Aug 2024 05:12:42 GMT, Julian Waters wrote: >> snprintf has been available for all officially and unofficially supported compilers for Windows, Visual Studio since version 2015 and gcc since, well, forever. snprintf is conforming to C99 since the start when compiling using gcc, and 2015 when using Visual Studio. Since it conforms to C99 and provides better semantics than _snprintf, and is not compiler specific, we should use it in most places where we currently use _snprintf. This makes JDK code where this is used more robust due to the null terminating guarantee of snprintf. Since most of the changes are extremely simple, I've included all of them hoping to get this all done in one shot. The only places _snprintf is not replaced is places where I'm not sure whether the code is ours or not (As in, imported source code for external libraries). Note that the existing checks in place for the size of the characters written still work, as the return value of snprintf works mostly the same as _snprintf. The only difference is the nu ll terminating character at the end and the returning of the number of written characters if the buffer was terminated early, as seen here: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170 >> >> Reviews Required: 2 for HotSpot, jdk.hotspot.agent, and jdk.jdwp.agent, 1 for awt and jdk.accessibility, 1 for java.base, 1 for security, 1 for jdk.management(?) > > Julian Waters 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 five additional commits since the last revision: > > - Merge branch 'master' into snprintf > - Change copyright years and formatting > - Revert Standard Integer type rewrite > - USe os::snprintf in HotSpot > - Obliterate most references to _snprintf in the Windows JDK The change to j2secmod_md.c looks fine to me. ------------- Marked as reviewed by mullan (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20153#pullrequestreview-2260416114 From jwaters at openjdk.org Mon Aug 26 12:27:07 2024 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 26 Aug 2024 12:27:07 GMT Subject: RFR: 8336289: Obliterate most references to _snprintf in the Windows JDK [v5] In-Reply-To: <_LI2j7i2WUtuzSXitbNtJVWRcmQFfOKASpJZ9P-iV_k=.467c12a0-ac63-4c22-8e8d-f4ea4b1c8f9c@github.com> References: <_LI2j7i2WUtuzSXitbNtJVWRcmQFfOKASpJZ9P-iV_k=.467c12a0-ac63-4c22-8e8d-f4ea4b1c8f9c@github.com> Message-ID: On Sat, 24 Aug 2024 05:12:42 GMT, Julian Waters wrote: >> snprintf has been available for all officially and unofficially supported compilers for Windows, Visual Studio since version 2015 and gcc since, well, forever. snprintf is conforming to C99 since the start when compiling using gcc, and 2015 when using Visual Studio. Since it conforms to C99 and provides better semantics than _snprintf, and is not compiler specific, we should use it in most places where we currently use _snprintf. This makes JDK code where this is used more robust due to the null terminating guarantee of snprintf. Since most of the changes are extremely simple, I've included all of them hoping to get this all done in one shot. The only places _snprintf is not replaced is places where I'm not sure whether the code is ours or not (As in, imported source code for external libraries). Note that the existing checks in place for the size of the characters written still work, as the return value of snprintf works mostly the same as _snprintf. The only difference is the nu ll terminating character at the end and the returning of the number of written characters if the buffer was terminated early, as seen here: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170 >> >> Reviews Required: 2 for HotSpot, jdk.hotspot.agent, and jdk.jdwp.agent, 1 for awt and jdk.accessibility, 1 for java.base, 1 for security, 1 for jdk.management(?) > > Julian Waters 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 five additional commits since the last revision: > > - Merge branch 'master' into snprintf > - Change copyright years and formatting > - Revert Standard Integer type rewrite > - USe os::snprintf in HotSpot > - Obliterate most references to _snprintf in the Windows JDK Awesome! Will wait a while before integrating so objections, if any, can be raised. If no objections are raised by tomorrow morning I'll proceed with integration ------------- PR Comment: https://git.openjdk.org/jdk/pull/20153#issuecomment-2310083308 From taylor.smock at kaart.com Mon Aug 26 14:26:14 2024 From: taylor.smock at kaart.com (Taylor Smock) Date: Mon, 26 Aug 2024 08:26:14 -0600 Subject: Seeking feedback on a possible JDatePicker Swing component In-Reply-To: References: Message-ID: <4223ecf1-77bc-4be4-b05e-d27cd292c69c@kaart.com> On 8/21/24 23:00, Tejesh R wrote: > Hello Swing Community, > [...] so we are considering revisiting the idea of a Date Picker in core Swing. [...] > - Is it of interest ? Yes. The OSS application I work on (https://josm.openstreetmap.de) has some areas in the UI where it would be nice to have a date picker. Some plugins for the app use third-party components to provide a date picker UI, but the non-plugin date pickers are text only. > - Would you use it ? Yes. Eventually -- whenever we make the version of Java with the date picker the minimum required version. That will probably be a decade after GA for the date picker. For reference, we only stopped supporting Java 8 in the past year. We still support Java 11, and we will _likely_ be held back by the default-jre in Debian going forward. We *do* support the latest Java versions, but for our users, we try to support as many versions of possible (we distribute jlink binaries, jars, and jnlp files (for OpenWebStart)). > - What features must it have ? For our usage, we just need users to be able to pick dates; almost all of our use cases don't require time as well. So: * User selection of a date > - What features are nice to have ? * User selection of a date range -- this can be done outside of the JDK if necessary. > - Do you have any experiences of other date pickers that reinforce those responses ? I've used https://github.com/JDatePicker/JDatePicker in the past in a plugin for the OSS application. > - Anything else ? No. From jpai at openjdk.org Mon Aug 26 15:58:04 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 26 Aug 2024 15:58:04 GMT Subject: RFR: 8336289: Obliterate most references to _snprintf in the Windows JDK [v5] In-Reply-To: References: <_LI2j7i2WUtuzSXitbNtJVWRcmQFfOKASpJZ9P-iV_k=.467c12a0-ac63-4c22-8e8d-f4ea4b1c8f9c@github.com> Message-ID: On Mon, 26 Aug 2024 12:24:30 GMT, Julian Waters wrote: > If no objections are raised by tomorrow morning I'll proceed with integration I've run this PR against latest mainline in our CI for tier1, tier2 and tier3 and there were no failures. So yes, I think you can go ahead with the integration. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20153#issuecomment-2310538487 From honkar at openjdk.org Mon Aug 26 18:26:03 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Mon, 26 Aug 2024 18:26:03 GMT Subject: RFR: 8338928: Update SwingSet2 "About" image to reference openjdk.org In-Reply-To: References: Message-ID: <4sIsLvcLAST-vyf1gnB-m0rQfkvZ2DmUnIMNrqtXK1M=.08fb698b-dc38-46ff-9cbf-ff0a22e338f4@github.com> On Sat, 24 Aug 2024 20:28:41 GMT, Phil Race wrote: > Update the image used when displaying SwingSet2->File->About to include up to date URLs. Marked as reviewed by honkar (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20703#pullrequestreview-2261327982 From honkar at openjdk.org Mon Aug 26 18:32:04 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Mon, 26 Aug 2024 18:32:04 GMT Subject: RFR: 8338425: java.lang.NullPointerException when About MenuItem is selected from SwingSet2DemoTest.java In-Reply-To: References: Message-ID: On Thu, 15 Aug 2024 00:58:18 GMT, lawrence.andrews wrote: > Added the missing jpg file & tested and NPE is not seen any more @lawrence-andrew Please add the updated image (that has correct openjdk urls) as suggested here https://github.com/openjdk/jdk/pull/20589#issuecomment-2308529054 for both locations - SwingSet and SwingSet2. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20589#issuecomment-2310815803 From prr at openjdk.org Mon Aug 26 18:55:11 2024 From: prr at openjdk.org (Phil Race) Date: Mon, 26 Aug 2024 18:55:11 GMT Subject: Integrated: 8338928: Update SwingSet2 "About" image to reference openjdk.org In-Reply-To: References: Message-ID: On Sat, 24 Aug 2024 20:28:41 GMT, Phil Race wrote: > Update the image used when displaying SwingSet2->File->About to include up to date URLs. This pull request has now been integrated. Changeset: 0c744ea7 Author: Phil Race URL: https://git.openjdk.org/jdk/commit/0c744ea7e75ba117503afe9c03993f3532742bb3 Stats: 0 lines in 1 file changed: 0 ins; 0 del; 0 mod 8338928: Update SwingSet2 "About" image to reference openjdk.org Reviewed-by: abhiscxk, honkar ------------- PR: https://git.openjdk.org/jdk/pull/20703 From azvegint at openjdk.org Mon Aug 26 19:08:32 2024 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Mon, 26 Aug 2024 19:08:32 GMT Subject: RFR: 8332158: [XWayland] test/jdk/java/awt/Mouse/EnterExitEvents/ResizingFrameTest.java Message-ID: There are two mouse pointer locations on Wayland: `#1` Wayland compositor - can be controlled by a physical mouse device, or libei, this location is visible on a screen as a mouse cursor and is propagated to `#2`. `#2` Inside the XWayland server - most of the time this is the same as `#1`, unless we have changed it programmatically, e.g. by using the XTest extension protocol, but it does not move the visible mouse cursor in `#1`. Our tests in X11 compatibility mode using this approach(aka `java.awt.Robot#mouseMove`) This test moves the mouse cursor to a specific location over a window in `#2`, which most likely isn't the same as the visible cursor location in `#1`. If the window was moved/resized and placed under the visible cursor location, that cursor location is also set for `#2`, and from the test's perspective, the mouse has just been moved to a different location without the test expecting it, causing unexpected mouse enter/exit events. We can try to smooth this out with additional `robot.mouseMove` calls, but it looks like we are missing the point of the test. So for now it is better to skip the test on Wayland. Another way is to use libei to move the visible mouse cursor on the system ([JDK-8280983](https://bugs.openjdk.org/browse/JDK-8280983)), but its support is not yet widespread on supported systems. Testing looks good. ------------- Commit messages: - 8332158: [XWayland] test/jdk/java/awt/Mouse/EnterExitEvents/ResizingFrameTest.java Changes: https://git.openjdk.org/jdk/pull/20717/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20717&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8332158 Stats: 15 lines in 2 files changed: 10 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/20717.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20717/head:pull/20717 PR: https://git.openjdk.org/jdk/pull/20717 From serb at openjdk.org Mon Aug 26 19:37:02 2024 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 26 Aug 2024 19:37:02 GMT Subject: RFR: 8332158: [XWayland] test/jdk/java/awt/Mouse/EnterExitEvents/ResizingFrameTest.java In-Reply-To: References: Message-ID: On Mon, 26 Aug 2024 19:02:56 GMT, Alexander Zvegintsev wrote: > There are two mouse pointer locations on Wayland: > > `#1` Wayland compositor - can be controlled by a physical mouse device, or libei, this location is visible on a screen as a mouse cursor and is propagated to `#2`. > > `#2` Inside the XWayland server - most of the time this is the same as `#1`, unless we have changed it programmatically, e.g. by using the XTest extension protocol, but it does not move the visible mouse cursor in `#1`. > Our tests in X11 compatibility mode using this approach(aka `java.awt.Robot#mouseMove`) > > This test moves the mouse cursor to a specific location over a window in `#2`, which most likely isn't the same as the visible cursor location in `#1`. > If the window was moved/resized and placed under the visible cursor location, that cursor location is also set for `#2`, and from the test's perspective, the mouse has just been moved to a different location without the test expecting it, causing unexpected mouse enter/exit events. > > We can try to smooth this out with additional `robot.mouseMove` calls, but it looks like we are missing the point of the test. > So for now it is better to skip the test on Wayland. > > Another way is to use libei to move the visible mouse cursor on the system ([JDK-8280983](https://bugs.openjdk.org/browse/JDK-8280983)), but its support is not yet widespread on supported systems. > > Testing looks good. Marked as reviewed by serb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20717#pullrequestreview-2261469263 From vladimir.petko at canonical.com Mon Aug 26 20:44:12 2024 From: vladimir.petko at canonical.com (Vladimir Petko) Date: Tue, 27 Aug 2024 08:44:12 +1200 Subject: Accessibility provider classpath In-Reply-To: <20230920222055.qy7bmcrdzivdzj5h@begin> References: <9c169b73-cf45-03cd-f7ac-8508ac0f866f@oracle.com> <20230920222055.qy7bmcrdzivdzj5h@begin> Message-ID: Hi, A recap of the problem i am trying to solve below: Java accessibility requires accessibility provider classes to be present in the application classpath. In Java 8 accessibility provider jar was added to the "lib/ext" directory and the accessibility provider was added to the boot classpath. Some Linux distributions carried a patch that modified the boot classpath for Java 11 and up to include a predefined accessibility provider. Updating the boot classpath was a security risk and did not allow for alternative implementations of the accessibility provider that are configurable system-wide. Since Java runtime attempts to load accessibility using the application's classpath, a user has to modify each application's classpath to enable accessibility. This is a bad user experience. Sometimes it is not possible, e.g. the application files are immutable. Accessibility provider classpath can be specified in a new additional property in accessibility.properties. The older versions of JDK will ignore it and the change will not break an existing functionality. I have prepared a prototype[1] and was wondering if it would be ok to raise an enhancement issue and implement it. Best Regards, Vladimir. [1] https://github.com/openjdk/jdk/compare/master...vpa1977:jdk:accessibility_proto On Thu, Sep 21, 2023 at 10:21?AM Samuel Thibault wrote: > > Vladimir Petko, le jeu. 21 sept. 2023 10:11:38 +1200, a ecrit: > > Samuel, please correct me if I'm wrong. The requirement is for the > > per-user (or system-wide) enablement of accessibility. The > > per-application setup is a bad user experience, and it would be nice > > to have a single point - properties file - that enables it. > > Yes, that's it. > > It is meaningless to enable accessibility only for some applicatins: > either the user needs it for all applications, or they don't need it at > all. > > Samuel > > > Java 8 achieves this by putting the accessibility provider jar in the > > 'ext' directory. Java 11 and up requires including an accessibility > > provider in the modules files. > > > > Any updates and fixes to the accessibility provider will require new > > releases of the openjdk package in Debian and Ubuntu. Adding > > accessibility providers to the build dependencies of the openjdk > > package also creates a circular build dependency that might introduce > > issues requiring careful synchronization between releases. > > > > I propose to add a new property 'java.accessibility.module_path'. The > > property will contain the list of locations of accessibility modules. > > Toolkit will construct the classloader using this path and the system > > class loader as a parent. Older releases will ignore this property. > > > > This feature will allow installation of the accessibility provider > > separate from the openjdk package and will satisfy the requirement of > > per-user and system-wide enablement of the accessibility provider. > > > > Best Regards, > > Vladimir. > > > > On Thu, Sep 21, 2023 at 9:48?AM Philip Race wrote: > > > > > > Can you explain your need for this (a lot) better ? > > > > > > The location and loading is specified to be done by > > > java.util.ServiceLoader. > > > Whilst this might be possible by some enhanced syntax, which if present > > > invokes ServiceLoader specifying a ClassLoader for this jar file, it > > > would clearly be new API and only for future releases. > > > NB it would also be fiddly to implement as the value of the property is > > > a list of class names and > > > you can't add jar names to that without breaking older JDKs and > > > so you'd need some way to match new lines referencing the JAR file for > > > each class .. > > > > > > And likely we'd want to have new APIs like this - if they make sense - to > > > be focused on a module, not a jar, but building a runtime image from > > > modules using jlink is a normal thing to do, so I'm not sure what such > > > an API would look like and seems to be not what you want. > > > > > > I also don't understand the use case / problem. > > > Whatever launches your application can set > > > -Djavax.accessibility.assistive_technologies=<..> > > > and set the -cp to include your jar and you don't need to do anything > > > to the runtime image. > > > > > > -phil > > > > > > On 9/20/23 1:33 PM, Vladimir Petko wrote: > > > > Hi, > > > > > > > > Java accessibility.properties (.accessibility.properties) allows > > > > setting the class name of the accessibility provider but not the jar > > > > file containing it. > > > > > > > > Was there any consideration that prevents this feature from being > > > > implemented, such as security? > > > > > > > > It would be nice to have it implemented to allow system-wide/per-user > > > > configuration of the accessibility provider without rebuilding the > > > > runtime image. > > > > > > > > If this is something acceptable, I am happy to create an enhancement > > > > issue and work on it. > > > > > > > > Best Regards, > > > > Vladimir. > > > > > > > -- > Samuel > --- > Pour une ?valuation ind?pendante, transparente et rigoureuse ! > Je soutiens la Commission d'?valuation de l'Inria. From samuel.thibault at ens-lyon.org Mon Aug 26 21:10:58 2024 From: samuel.thibault at ens-lyon.org (Samuel Thibault) Date: Mon, 26 Aug 2024 23:10:58 +0200 Subject: Accessibility provider classpath In-Reply-To: References: <9c169b73-cf45-03cd-f7ac-8508ac0f866f@oracle.com> <20230920222055.qy7bmcrdzivdzj5h@begin> Message-ID: Hello, Vladimir Petko, le mar. 27 ao?t 2024 08:44:12 +1200, a ecrit: > A recap of the problem i am trying to solve below: > > Java accessibility requires accessibility provider classes to be > present in the application classpath. > > In Java 8 accessibility provider jar was added to the "lib/ext" > directory and the accessibility provider was added to the boot > classpath. Some Linux distributions carried a patch that modified the > boot classpath for Java 11 and up to include a predefined > accessibility provider. > > Updating the boot classpath was a security risk and did not allow for > alternative implementations of the accessibility provider that are > configurable system-wide. > > Since Java runtime attempts to load accessibility using the > application's classpath, a user has to modify each application's > classpath to enable accessibility. This is a bad user experience. > Sometimes it is not possible, e.g. the application files are > immutable. > > Accessibility provider classpath can be specified in a new additional > property in accessibility.properties. The older versions of JDK will > ignore it and the change will not break an existing functionality. So distributions would set in accessibility.properties's assistive_technologies.classpath the classpath to be used? Yes, that would be a nice way. I'm eager to see if openjdk eventually understands that this is needed (last time I tried to raise the issue, Oracle wasn't even realizing that accessibility was completely broken). > I have prepared a prototype[1] Thanks for this! > and was wondering if it would be ok to raise an enhancement issue and > implement it. FWIW, I'm all for it! Samuel > [1] https://github.com/openjdk/jdk/compare/master...vpa1977:jdk:accessibility_proto > > On Thu, Sep 21, 2023 at 10:21?AM Samuel Thibault > wrote: > > > > Vladimir Petko, le jeu. 21 sept. 2023 10:11:38 +1200, a ecrit: > > > Samuel, please correct me if I'm wrong. The requirement is for the > > > per-user (or system-wide) enablement of accessibility. The > > > per-application setup is a bad user experience, and it would be nice > > > to have a single point - properties file - that enables it. > > > > Yes, that's it. > > > > It is meaningless to enable accessibility only for some applicatins: > > either the user needs it for all applications, or they don't need it at > > all. > > > > Samuel > > > > > Java 8 achieves this by putting the accessibility provider jar in the > > > 'ext' directory. Java 11 and up requires including an accessibility > > > provider in the modules files. > > > > > > Any updates and fixes to the accessibility provider will require new > > > releases of the openjdk package in Debian and Ubuntu. Adding > > > accessibility providers to the build dependencies of the openjdk > > > package also creates a circular build dependency that might introduce > > > issues requiring careful synchronization between releases. > > > > > > I propose to add a new property 'java.accessibility.module_path'. The > > > property will contain the list of locations of accessibility modules. > > > Toolkit will construct the classloader using this path and the system > > > class loader as a parent. Older releases will ignore this property. > > > > > > This feature will allow installation of the accessibility provider > > > separate from the openjdk package and will satisfy the requirement of > > > per-user and system-wide enablement of the accessibility provider. > > > > > > Best Regards, > > > Vladimir. > > > > > > On Thu, Sep 21, 2023 at 9:48?AM Philip Race wrote: > > > > > > > > Can you explain your need for this (a lot) better ? > > > > > > > > The location and loading is specified to be done by > > > > java.util.ServiceLoader. > > > > Whilst this might be possible by some enhanced syntax, which if present > > > > invokes ServiceLoader specifying a ClassLoader for this jar file, it > > > > would clearly be new API and only for future releases. > > > > NB it would also be fiddly to implement as the value of the property is > > > > a list of class names and > > > > you can't add jar names to that without breaking older JDKs and > > > > so you'd need some way to match new lines referencing the JAR file for > > > > each class .. > > > > > > > > And likely we'd want to have new APIs like this - if they make sense - to > > > > be focused on a module, not a jar, but building a runtime image from > > > > modules using jlink is a normal thing to do, so I'm not sure what such > > > > an API would look like and seems to be not what you want. > > > > > > > > I also don't understand the use case / problem. > > > > Whatever launches your application can set > > > > -Djavax.accessibility.assistive_technologies=<..> > > > > and set the -cp to include your jar and you don't need to do anything > > > > to the runtime image. > > > > > > > > -phil > > > > > > > > On 9/20/23 1:33 PM, Vladimir Petko wrote: > > > > > Hi, > > > > > > > > > > Java accessibility.properties (.accessibility.properties) allows > > > > > setting the class name of the accessibility provider but not the jar > > > > > file containing it. > > > > > > > > > > Was there any consideration that prevents this feature from being > > > > > implemented, such as security? > > > > > > > > > > It would be nice to have it implemented to allow system-wide/per-user > > > > > configuration of the accessibility provider without rebuilding the > > > > > runtime image. > > > > > > > > > > If this is something acceptable, I am happy to create an enhancement > > > > > issue and work on it. > > > > > > > > > > Best Regards, > > > > > Vladimir. > > > > > > > > > > > -- > > Samuel > > --- > > Pour une ?valuation ind?pendante, transparente et rigoureuse ! > > Je soutiens la Commission d'?valuation de l'Inria. > -- Samuel RR> Ce que je cherche ? d?montrer, c'est qu'il est injuste de faire RR> l'amalgame entre du bulk mail et du courrier non-solicit? tr?s cibl? un suppositoire non reclam?, meme tres bien cibl?, reste un suppositoire. -+-OS in : Guide du Neuneu d'Usenet - Plein le cul de la pub ? neuneu -+- From kcr at openjdk.org Mon Aug 26 21:18:02 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 26 Aug 2024 21:18:02 GMT Subject: RFR: 8190329: [macos] Swing InterOp Platform.exit() crash In-Reply-To: References: <0ErO4olMuzO-dyyZ0gMyL6I2Q3kJk3NWMhdUeJ682Qc=.52bd1eb8-5045-4bc1-b391-698768fe59d5@github.com> <8DNMrEM6VOHBG8LuUX068hTh-LfMIM8pylXfiIST8PY=.070d587f-c0fa-4caf-ab46-4b4ccad29c7a@github.com> Message-ID: On Sat, 24 Aug 2024 21:16:00 GMT, Phil Race wrote: >>> > Another possible fix would be to have AWT not use the cached JNI Env when it is not the NSApplication owner. I don't know how viable this fix would be, or whether it is the right fix, but it would prevent the crash in all possible places. >>> >>> That sounds like lots of places would need to be updated to do this. >> >> No, only in one place. The idea I had -- and did a quick prototype of -- was to change the implementation of `[ThreadUtilities getJNIEnv]` to check a flag to see whether or not AWT was the owner of the NSApplication and, if not, effectively do the same thing as `getJNIEnvUncached`. What that would then do would be to re-attach the AppKit thread to the JVM if FX had detached it. This will avoid the crash in all places without having to change the callers of `getJNIEnv` >> >> > We could explore what it would take for FX to not detach the AppKit thread from Java. At a minimum, it would require attaching the AppKit thread as a daemon (which AWT already does), and then creating a non-daemon Java thread that we would then terminate at FX toolkit shutdown. This would need to be tested carefully, but might be the cleanest solution. >>> >>> I would like to see that explored. What does SWT do ? >> >> I'll explore this for FX. I think it will be pretty easy. No idea what SWT does. >> >>> > One thing to note is that anything we do here will be about avoiding a crash in AWT, not about having the UI remain functional. In this case FX is the "owner" of the native Window system event loop (and NSApplication on macOS). Applications should not shutdown the FX toolkit (meaning, not call `Platform.exit`) and expect AWT to continue to work. >>> >>> I guess Platform.exit for FX embedded inside AWT is a no-op ? >> >> Not a no-op, since it still shuts down the FX toolkit and renderer, but it doesn't detach the AppkitThread from the JVM. > >> > > Another possible fix would be to have AWT not use the cached JNI Env when it is not the NSApplication owner. I don't know how viable this fix would be, or whether it is the right fix, but it would prevent the crash in all possible places. >> > >> > >> > That sounds like lots of places would need to be updated to do this. >> >> No, only in one place. The idea I had -- and did a quick prototype of -- was to change the implementation of `[ThreadUtilities getJNIEnv]` to check a flag to see whether or not AWT was the owner of the NSApplication and, if not, effectively do the same thing as `getJNIEnvUncached`. What that would then do would be to re-attach the AppKit thread to the JVM if FX had detached it. This will avoid the crash in all places without having to change the callers of `getJNIEnv` > > I've looked and I think that would work. Minimal overhead in the 99.99% "non-embedded" case. Here is a Draft PR that fixes this in FX, if we decide to go that route: openjdk/jfx#1545 I added three new regression tests. Two of them (including one that reproduces this crash) fail without the fix. All three pass with the fix. If you prefer, we can continue to explore whether or not to fix this in AWT in addition to or instead of the AWT fix. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20688#discussion_r1731835683 From kcr at openjdk.org Mon Aug 26 21:32:03 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 26 Aug 2024 21:32:03 GMT Subject: RFR: 8190329: [macos] Swing InterOp Platform.exit() crash In-Reply-To: References: <0ErO4olMuzO-dyyZ0gMyL6I2Q3kJk3NWMhdUeJ682Qc=.52bd1eb8-5045-4bc1-b391-698768fe59d5@github.com> <8DNMrEM6VOHBG8LuUX068hTh-LfMIM8pylXfiIST8PY=.070d587f-c0fa-4caf-ab46-4b4ccad29c7a@github.com> Message-ID: On Mon, 26 Aug 2024 21:15:03 GMT, Kevin Rushforth wrote: > If you prefer, we can continue to explore whether or not to fix this in AWT in addition to or instead of the AWT fix. typo: I meant "...in addition to or instead of the FX fix." ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20688#discussion_r1731848508 From honkar at openjdk.org Mon Aug 26 21:36:09 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Mon, 26 Aug 2024 21:36:09 GMT Subject: RFR: 8332158: [XWayland] test/jdk/java/awt/Mouse/EnterExitEvents/ResizingFrameTest.java In-Reply-To: References: Message-ID: On Mon, 26 Aug 2024 19:02:56 GMT, Alexander Zvegintsev wrote: > There are two mouse pointer locations on Wayland: > > `#1` Wayland compositor - can be controlled by a physical mouse device, or libei, this location is visible on a screen as a mouse cursor and is propagated to `#2`. > > `#2` Inside the XWayland server - most of the time this is the same as `#1`, unless we have changed it programmatically, e.g. by using the XTest extension protocol, but it does not move the visible mouse cursor in `#1`. > Our tests in X11 compatibility mode using this approach(aka `java.awt.Robot#mouseMove`) > > This test moves the mouse cursor to a specific location over a window in `#2`, which most likely isn't the same as the visible cursor location in `#1`. > If the window was moved/resized and placed under the visible cursor location, that cursor location is also set for `#2`, and from the test's perspective, the mouse has just been moved to a different location without the test expecting it, causing unexpected mouse enter/exit events. > > We can try to smooth this out with additional `robot.mouseMove` calls, but it looks like we are missing the point of the test. > So for now it is better to skip the test on Wayland. > > Another way is to use libei to move the visible mouse cursor on the system ([JDK-8280983](https://bugs.openjdk.org/browse/JDK-8280983)), but its support is not yet widespread on supported systems. > > Testing looks good. @azvegint There are a couple of cases (1st six cases in the test) that pass on Wayland. Would it be better to run only these cases on Wayland or is skipping the entire test a better option? ------------- PR Review: https://git.openjdk.org/jdk/pull/20717#pullrequestreview-2261689157 From lorenzo.bigagli at cnr.it Mon Aug 26 21:30:08 2024 From: lorenzo.bigagli at cnr.it (LORENZO BIGAGLI) Date: Mon, 26 Aug 2024 21:30:08 +0000 Subject: Seeking feedback on a possible CheckboxTree Swing component In-Reply-To: References: Message-ID: Dear Tejesh, all, given your interesting proposal, I would like to take the opportunity to suggest another potentially useful addition to the Swing library: a tree-like component with checkable nodes, something like this: [cid:4f7587eb-cab9-4501-bede-e9034b0cbae9 at eurprd07.prod.outlook.com] While there have been several efforts in that direction, none have really consolidated. Some years ago, we proposed an implementation that garnered some interest (see GitHub, some documentation and the attached JavaWorld article). Unfortunately, at the time, we couldn?t put much effort to maintain it or channel it through the JCP. If the community believes it would still be useful, I?d be willing to contribute towards that goal in the most appropriate form (I?d probably need some guidance, as I'm pretty new here). Thanks for your attention and feedback. Best regards, LB Il giorno 22 ago 2024, alle ore 07:00, Tejesh R ha scritto: Hello Swing Community, Swing has a rich set of UI components in the core Java Platform. But it lacks a Date Picker which is a significant gap for many applications and so we are considering revisiting the idea of a Date Picker in core Swing. The function core of a DatePicker is to let a user select a day [and time?], or range of days [and time ? ], within optional application specified constraints. The JXDatePicker component was previously explored as part of the long defunct external SwingX project. This proposal does not imply reviving JXDatePicker, but being informed by it and date pickers for other platforms. Before even starting on this, we are seeking feedback from the community - Is it of interest ? - Would you use it ? - What features must it have ? - What features are nice to have ? - Do you have any experiences of other date pickers that reinforce those responses ? - Anything else ? If we move forward, we would propose a JEP and also expect that we would deliver it first as a preview feature [1] , so that it may evolve in response to feedback before becoming final. Please let us know your thoughts and suggestions on this proposal. Regards, Tejesh R. JDK client team [1] https://openjdk.org/jeps/12 ? Lorenzo Bigagli, PhD National Research Council of Italy Institute of Atmospheric Pollution Research (CNR-IIA) Earth and Space Science Informatics Laboratory (ESSI-Lab) a: Florence Research Area via Madonna del Piano, 10 50019 Sesto Fiorentino (Florence), Italy t: +39 055 5226582 f: +39 055 5226593 m: lorenzo.bigagli at cnr.it -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: checkboxtree.jpg Type: image/jpeg Size: 44740 bytes Desc: checkboxtree.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 2007-JavaWorld - CheckboxTree with comments.pdf Type: application/pdf Size: 515896 bytes Desc: 2007-JavaWorld - CheckboxTree with comments.pdf URL: From prr at openjdk.org Mon Aug 26 21:50:03 2024 From: prr at openjdk.org (Phil Race) Date: Mon, 26 Aug 2024 21:50:03 GMT Subject: RFR: 8190329: [macos] Swing InterOp Platform.exit() crash In-Reply-To: References: <0ErO4olMuzO-dyyZ0gMyL6I2Q3kJk3NWMhdUeJ682Qc=.52bd1eb8-5045-4bc1-b391-698768fe59d5@github.com> <8DNMrEM6VOHBG8LuUX068hTh-LfMIM8pylXfiIST8PY=.070d587f-c0fa-4caf-ab46-4b4ccad29c7a@github.com> Message-ID: On Mon, 26 Aug 2024 21:29:42 GMT, Kevin Rushforth wrote: >> Here is a Draft PR that fixes this in FX, if we decide to go that route: openjdk/jfx#1545 >> >> I added three new regression tests. Two of them (including one that reproduces this crash) fail without the fix. All three pass with the fix. >> >> If you prefer, we can continue to explore whether or not to fix this in AWT in addition to or instead of the AWT fix. > >> If you prefer, we can continue to explore whether or not to fix this in AWT in addition to or instead of the AWT fix. > > typo: I meant "...in addition to or instead of the FX fix." I am starting to think it best to do both of these. It will improve interop of both toolkits with other toolkits, besides each other, and you get the problem fixed no matter whether you have a fixed JDK or a fixed FX. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20688#discussion_r1731862756 From azvegint at openjdk.org Mon Aug 26 22:13:07 2024 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Mon, 26 Aug 2024 22:13:07 GMT Subject: RFR: 8332158: [XWayland] test/jdk/java/awt/Mouse/EnterExitEvents/ResizingFrameTest.java In-Reply-To: References: Message-ID: <9R-FzOLtvr71RAyHRpftbIUkoy_l-A29UcOgfLE9CYo=.0dc54735-77fc-4d30-9fbb-1741919b1091@github.com> On Mon, 26 Aug 2024 21:33:12 GMT, Harshitha Onkar wrote: > @azvegint There are a couple of cases (1st six cases in the test) that pass on Wayland. Would it be better to run only these cases on Wayland or is skipping the entire test a better option? This is one of the options, but I tend to skip the test as a temporary solution, until the [proper system-wide mouse/keyboard emulation](https://bugs.openjdk.org/browse/JDK-8280983) solution is used. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20717#issuecomment-2311192492 From honkar at openjdk.org Mon Aug 26 22:19:25 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Mon, 26 Aug 2024 22:19:25 GMT Subject: RFR: 8332158: [XWayland] test/jdk/java/awt/Mouse/EnterExitEvents/ResizingFrameTest.java In-Reply-To: References: Message-ID: On Mon, 26 Aug 2024 19:02:56 GMT, Alexander Zvegintsev wrote: > There are two mouse pointer locations on Wayland: > > `#1` Wayland compositor - can be controlled by a physical mouse device, or libei, this location is visible on a screen as a mouse cursor and is propagated to `#2`. > > `#2` Inside the XWayland server - most of the time this is the same as `#1`, unless we have changed it programmatically, e.g. by using the XTest extension protocol, but it does not move the visible mouse cursor in `#1`. > Our tests in X11 compatibility mode using this approach(aka `java.awt.Robot#mouseMove`) > > This test moves the mouse cursor to a specific location over a window in `#2`, which most likely isn't the same as the visible cursor location in `#1`. > If the window was moved/resized and placed under the visible cursor location, that cursor location is also set for `#2`, and from the test's perspective, the mouse has just been moved to a different location without the test expecting it, causing unexpected mouse enter/exit events. > > We can try to smooth this out with additional `robot.mouseMove` calls, but it looks like we are missing the point of the test. > So for now it is better to skip the test on Wayland. > > Another way is to use libei to move the visible mouse cursor on the system ([JDK-8280983](https://bugs.openjdk.org/browse/JDK-8280983)), but its support is not yet widespread on supported systems. > > Testing looks good. Marked as reviewed by honkar (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20717#pullrequestreview-2261748747 From kcr at openjdk.org Mon Aug 26 22:54:02 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 26 Aug 2024 22:54:02 GMT Subject: RFR: 8190329: [macos] Swing InterOp Platform.exit() crash In-Reply-To: References: <0ErO4olMuzO-dyyZ0gMyL6I2Q3kJk3NWMhdUeJ682Qc=.52bd1eb8-5045-4bc1-b391-698768fe59d5@github.com> <8DNMrEM6VOHBG8LuUX068hTh-LfMIM8pylXfiIST8PY=.070d587f-c0fa-4caf-ab46-4b4ccad29c7a@github.com> Message-ID: On Mon, 26 Aug 2024 21:47:37 GMT, Phil Race wrote: >>> If you prefer, we can continue to explore whether or not to fix this in AWT in addition to or instead of the AWT fix. >> >> typo: I meant "...in addition to or instead of the FX fix." > > I am starting to think it best to do both of these. It will improve interop of both toolkits with other toolkits, besides each other, and you get the problem fixed no matter whether you have a fixed JDK or a fixed FX. That makes sense to me. I sent a quick (definitely not finished) prototype of the idea I mentioned to @prsadhuk offline, so maybe he can take that as a starting point for the fix. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20688#discussion_r1731913130 From kcr at openjdk.org Mon Aug 26 22:54:03 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 26 Aug 2024 22:54:03 GMT Subject: RFR: 8190329: [macos] Swing InterOp Platform.exit() crash In-Reply-To: References: <0ErO4olMuzO-dyyZ0gMyL6I2Q3kJk3NWMhdUeJ682Qc=.52bd1eb8-5045-4bc1-b391-698768fe59d5@github.com> <8DNMrEM6VOHBG8LuUX068hTh-LfMIM8pylXfiIST8PY=.070d587f-c0fa-4caf-ab46-4b4ccad29c7a@github.com> Message-ID: <4NuTyjCwGeHcUsCaYKP9540duSe1Crw4N8jtPOXoOHs=.10edafb5-c984-4192-85e0-68f81b393899@github.com> On Mon, 26 Aug 2024 22:50:43 GMT, Kevin Rushforth wrote: >> I am starting to think it best to do both of these. It will improve interop of both toolkits with other toolkits, besides each other, and you get the problem fixed no matter whether you have a fixed JDK or a fixed FX. > > That makes sense to me. I sent a quick (definitely not finished) prototype of the idea I mentioned to @prsadhuk offline, so maybe he can take that as a starting point for the fix. If we do fix it in both, we will need two bug IDs. I can file a new one for JavaFX in that case. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20688#discussion_r1731913691 From jiangli at openjdk.org Tue Aug 27 00:44:04 2024 From: jiangli at openjdk.org (Jiangli Zhou) Date: Tue, 27 Aug 2024 00:44:04 GMT Subject: RFR: 8338768: Introduce runtime lookup to check for static builds [v2] In-Reply-To: <5_BKiz0spEIxGN2mZJHiAoaSOWOdnH8kf5POgG9sQ9g=.9339d838-9f04-4d28-93b8-647ad90e805a@github.com> References: <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com> <5_BKiz0spEIxGN2mZJHiAoaSOWOdnH8kf5POgG9sQ9g=.9339d838-9f04-4d28-93b8-647ad90e805a@github.com> Message-ID: On Thu, 22 Aug 2024 00:30:07 GMT, Jiangli Zhou wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: >> >> Also update build to link properly > > I compared the extracted changes in this PR with the related parts in https://github.com/openjdk/jdk/pull/19478. They look ok. My concern (as discussed in https://github.com/openjdk/jdk/pull/19478#issuecomment-2278421931) is that these runtime changes for static JDK can't be tested even they are relatively simple, without the the actual linking change. Any timeline for the static linking changes? > @jianglizhou > > > [...] these runtime changes for static JDK can't be tested [...] > > Yes, they can. This is just a pure refactoring of existing code. I have deliberately kept out addition of the new places where static linking exceptions are needed in the code. Hi @magicus, perhaps the answer is both `yes` and `no`. Since your `src/hotspot/share/runtime/linkType.cpp` change removes the needs of requiring `#ifdef STATIC_BUILD` macro from various affected JDK source files to handle the differences between dynamic linking and static linking. From that sense, it's probably `yes` (can be tested as before) as `linkType.cpp` still uses `#ifdef STATIC_BUILD`, and the dynamic v.s. static differences are still determined at build time and not at runtime, as @dholmes-ora and @TheShermanTanker have pointed out. In theory, things (especially the dynamic case) could be tested as before since the fundamental is unchanged. That's different from the changes in https://github.com/openjdk/leyden/tree/hermetic-java-runtime, which does the actual runtime checks. Since the mainline doesn't have the needed build changes to have the ability to link a `javastatic` binary, from that point of view all the `static` cases in the PR cannot be tested yet. We could test them by integrating into https://github.com/openjdk/leyden/tree/hermetic-java-runtime and downstream codebase (with full hermetic Java support) after the PR is approved/submitted in the mainline. That might help. To ease some of @dholmes-ora's concern (and my concern as well) that the initial change could affect all Java instances, perhaps providing the build support for statically linking `javastatic` should be done as an immediate follow-up step (I'm continually nudging you toward that direction :-)). We have multiple goals to achieve in the build system for just the static-Java-only part and we probably want to consider adding the support in following sequence: 1) Capability of building a fully statically linked `javastatic` executable 2) Allow linking both `java` (with dynamic linking support) and `javatatic` using the same set of `.o` object files ? ? - Eliminate the needs of `#ifdef STATIC_BUILD` macro. Your `linkType.cpp` change seems to be able to limit the macro usage within one file and just conditionally compile the single file only. So that helps. ? ? - May involve spec changes for `JNI_OnLoad` and friends to use `JNI_OnLoad_` naming for dynamic linking support. The needed spec change for the static linking case (built in library support) has already been done in the past by others. 3) General solution for duplicating symbol issue - `objcopy` for symbol hiding ------------- PR Comment: https://git.openjdk.org/jdk/pull/20666#issuecomment-2311351447 From abhiscxk at openjdk.org Tue Aug 27 04:18:10 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Tue, 27 Aug 2024 04:18:10 GMT Subject: Integrated: 8338668: Test javax/swing/JFileChooser/8080628/bug8080628.java doesn't test for GTK L&F In-Reply-To: References: Message-ID: On Thu, 22 Aug 2024 05:24:24 GMT, Abhishek Kumar wrote: > This test should have failed with the [changeset](https://github.com/openjdk/jdk/pull/20612) proposed for [JDK-4795384](https://bugs.openjdk.org/browse/JDK-4795384) but it didn't because GTK look and feel isn't supported in headless environment. > > Fix is to run the test with headful environment on linux platform. > > Tested in CI pipeline and link attached to JBS. This pull request has now been integrated. Changeset: b8e8e965 Author: Abhishek Kumar URL: https://git.openjdk.org/jdk/commit/b8e8e965e541881605f9dbcd4d9871d4952b9232 Stats: 14 lines in 1 file changed: 12 ins; 0 del; 2 mod 8338668: Test javax/swing/JFileChooser/8080628/bug8080628.java doesn't test for GTK L&F Reviewed-by: aivanov, honkar, prr ------------- PR: https://git.openjdk.org/jdk/pull/20671 From jwaters at openjdk.org Tue Aug 27 04:18:12 2024 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 27 Aug 2024 04:18:12 GMT Subject: Integrated: 8336289: Obliterate most references to _snprintf in the Windows JDK In-Reply-To: References: Message-ID: On Fri, 12 Jul 2024 06:29:34 GMT, Julian Waters wrote: > snprintf has been available for all officially and unofficially supported compilers for Windows, Visual Studio since version 2015 and gcc since, well, forever. snprintf is conforming to C99 since the start when compiling using gcc, and 2015 when using Visual Studio. Since it conforms to C99 and provides better semantics than _snprintf, and is not compiler specific, we should use it in most places where we currently use _snprintf. This makes JDK code where this is used more robust due to the null terminating guarantee of snprintf. Since most of the changes are extremely simple, I've included all of them hoping to get this all done in one shot. The only places _snprintf is not replaced is places where I'm not sure whether the code is ours or not (As in, imported source code for external libraries). Note that the existing checks in place for the size of the characters written still work, as the return value of snprintf works mostly the same as _snprintf. The only difference is the nul l terminating character at the end and the returning of the number of written characters if the buffer was terminated early, as seen here: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170 > > Reviews Required: 2 for HotSpot, jdk.hotspot.agent, and jdk.jdwp.agent, 1 for awt and jdk.accessibility, 1 for java.base, 1 for security, 1 for jdk.management(?) This pull request has now been integrated. Changeset: cd9e241f Author: Julian Waters URL: https://git.openjdk.org/jdk/commit/cd9e241f0ec10c7b31d36cbfb994bc20d81a0517 Stats: 70 lines in 12 files changed: 0 ins; 16 del; 54 mod 8336289: Obliterate most references to _snprintf in the Windows JDK Reviewed-by: kbarrett, dholmes, jpai, mullan, djelinski, prr ------------- PR: https://git.openjdk.org/jdk/pull/20153 From jwaters at openjdk.org Tue Aug 27 04:18:11 2024 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 27 Aug 2024 04:18:11 GMT Subject: RFR: 8336289: Obliterate most references to _snprintf in the Windows JDK [v5] In-Reply-To: <_LI2j7i2WUtuzSXitbNtJVWRcmQFfOKASpJZ9P-iV_k=.467c12a0-ac63-4c22-8e8d-f4ea4b1c8f9c@github.com> References: <_LI2j7i2WUtuzSXitbNtJVWRcmQFfOKASpJZ9P-iV_k=.467c12a0-ac63-4c22-8e8d-f4ea4b1c8f9c@github.com> Message-ID: On Sat, 24 Aug 2024 05:12:42 GMT, Julian Waters wrote: >> snprintf has been available for all officially and unofficially supported compilers for Windows, Visual Studio since version 2015 and gcc since, well, forever. snprintf is conforming to C99 since the start when compiling using gcc, and 2015 when using Visual Studio. Since it conforms to C99 and provides better semantics than _snprintf, and is not compiler specific, we should use it in most places where we currently use _snprintf. This makes JDK code where this is used more robust due to the null terminating guarantee of snprintf. Since most of the changes are extremely simple, I've included all of them hoping to get this all done in one shot. The only places _snprintf is not replaced is places where I'm not sure whether the code is ours or not (As in, imported source code for external libraries). Note that the existing checks in place for the size of the characters written still work, as the return value of snprintf works mostly the same as _snprintf. The only difference is the nu ll terminating character at the end and the returning of the number of written characters if the buffer was terminated early, as seen here: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170 >> >> Reviews Required: 2 for HotSpot, jdk.hotspot.agent, and jdk.jdwp.agent, 1 for awt and jdk.accessibility, 1 for java.base, 1 for security, 1 for jdk.management(?) > > Julian Waters 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 five additional commits since the last revision: > > - Merge branch 'master' into snprintf > - Change copyright years and formatting > - Revert Standard Integer type rewrite > - USe os::snprintf in HotSpot > - Obliterate most references to _snprintf in the Windows JDK Thanks everyone for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/20153#issuecomment-2311533460 From prr at openjdk.org Tue Aug 27 06:01:10 2024 From: prr at openjdk.org (Phil Race) Date: Tue, 27 Aug 2024 06:01:10 GMT Subject: RFR: 8338103: Stabilize and open source a Swing OGL ButtonResizeTest [v4] In-Reply-To: References: <8--CxVHS_jclzzN2PWYkI0W3yr7w1al5PSqRdis-PUc=.2f57c378-49cc-40bc-b042-f6aa9bfed07d@github.com> <7AO_JKocjYGnAp7JfzOFaN8uYMw48LhLbnI1ilkFE5g=.aeb55a93-784f-405b-b46f-ed6391f53431@github.com> Message-ID: On Sat, 24 Aug 2024 06:30:44 GMT, Manukumar V S wrote: >> test/jdk/javax/swing/JButton/SwingButtonResizeTestWithOpenGL.java line 54: >> >>> 52: * a JButton. A file image of the component will be saved before and after >>> 53: * window resize. The test passes if both button images are the same. >>> 54: * @run main/othervm -Dsun.java2d.opengl=True -Dsun.java2d.opengl.fbobject=false SwingButtonResizeTestWithOpenGL >> >> Does this really work well on Windows ? Commonly OpenGL tests fail on Windows. >> Ah I see in the bug report you say you tested on all platforms OK. >> >> Also is there any reason we can't test this with additional pipelines on specific platforms ? >> The behaviours being tested are Java behaviours so it ought to pass in other cases too. > > @prrace I?m not sure I understand what you meant by 'testing this with additional pipelines on specific platforms.' Are you suggesting that we should test this not only with -Dsun.java2d.opengl=True -Dsun.java2d.opengl.fbobject=false, but also with other parameters? Pipeline. You can't easily know what will be chosen on a test system, so you need to do things like @run main/othervm -Dsun.java2d.xrender=false @run main/othervm -Dsun.java2d.xrender=true @run main/othervm -Dsun.java2d.d3d=false @run main/othervm -Dsun.java2d.d3d=true In some cases, nothing will change but if the test is cheap and fast, nothing lost ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20532#discussion_r1732176864 From tr at openjdk.org Tue Aug 27 06:09:11 2024 From: tr at openjdk.org (Tejesh R) Date: Tue, 27 Aug 2024 06:09:11 GMT Subject: RFR: 8338153: java/awt/Checkbox/CheckboxCheckerScalingTest.java test failed on linux machine Message-ID: Test failed intermittently on particular host. Though analysis pointed out to a test frame at left top on that host, I've updated the test for further stabilizing it. Two things done here: 1. Move the frame to center of the screen rather than left top. 2. Added tolerance checks for color comparison - this is based on analysis reports where the image didn't had exact black color which is supposed to be. So like other test cases, providing some tolerance for comparison. ------------- Commit messages: - Adding tolerance for comparison + position change Changes: https://git.openjdk.org/jdk/pull/20723/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20723&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8338153 Stats: 10 lines in 1 file changed: 9 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20723.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20723/head:pull/20723 PR: https://git.openjdk.org/jdk/pull/20723 From mvs at openjdk.org Tue Aug 27 08:58:39 2024 From: mvs at openjdk.org (Manukumar V S) Date: Tue, 27 Aug 2024 08:58:39 GMT Subject: RFR: 8338103: Stabilize and open source a Swing OGL ButtonResizeTest [v5] In-Reply-To: <8--CxVHS_jclzzN2PWYkI0W3yr7w1al5PSqRdis-PUc=.2f57c378-49cc-40bc-b042-f6aa9bfed07d@github.com> References: <8--CxVHS_jclzzN2PWYkI0W3yr7w1al5PSqRdis-PUc=.2f57c378-49cc-40bc-b042-f6aa9bfed07d@github.com> Message-ID: > This PR creates a new test by stabilising and open sourcing a closed test. > This test verifies that the OpenGL pipeline does not create artifacts with swing components after window is zoomed to maximum size and then resized back to normal. > This test is run twice, with and without the flags "-Dsun.java2d.opengl=True -Dsun.java2d.opengl.fbobject=false" . > > This is tested(15 times per platform) in all the available mach5 headful platforms and found to be stable. Manukumar V S has updated the pull request incrementally with one additional commit since the last revision: Review comments fixed : Added more pipelines to the test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20532/files - new: https://git.openjdk.org/jdk/pull/20532/files/75c44d43..fccae9c9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20532&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20532&range=03-04 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20532.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20532/head:pull/20532 PR: https://git.openjdk.org/jdk/pull/20532 From mvs at openjdk.org Tue Aug 27 08:58:39 2024 From: mvs at openjdk.org (Manukumar V S) Date: Tue, 27 Aug 2024 08:58:39 GMT Subject: RFR: 8338103: Stabilize and open source a Swing OGL ButtonResizeTest [v4] In-Reply-To: References: <8--CxVHS_jclzzN2PWYkI0W3yr7w1al5PSqRdis-PUc=.2f57c378-49cc-40bc-b042-f6aa9bfed07d@github.com> <7AO_JKocjYGnAp7JfzOFaN8uYMw48LhLbnI1ilkFE5g=.aeb55a93-784f-405b-b46f-ed6391f53431@github.com> Message-ID: On Tue, 27 Aug 2024 05:58:30 GMT, Phil Race wrote: >> @prrace I?m not sure I understand what you meant by 'testing this with additional pipelines on specific platforms.' Are you suggesting that we should test this not only with -Dsun.java2d.opengl=True -Dsun.java2d.opengl.fbobject=false, but also with other parameters? > > Pipeline. You can't easily know what will be chosen on a test system, so you need to do things like > @run main/othervm -Dsun.java2d.xrender=false > @run main/othervm -Dsun.java2d.xrender=true > @run main/othervm -Dsun.java2d.d3d=false > @run main/othervm -Dsun.java2d.d3d=true > > In some cases, nothing will change but if the test is cheap and fast, nothing lost Thanks @prrace , I have added more pipelines to the test, please have a look. I have rerun this again on all platforms with mach5 and the results are updated in the bug as a comment. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20532#discussion_r1732422038 From brice.dutheil at gmail.com Tue Aug 27 10:42:18 2024 From: brice.dutheil at gmail.com (Brice Dutheil) Date: Tue, 27 Aug 2024 12:42:18 +0200 Subject: Seeking feedback on a possible JDatePicker Swing component In-Reply-To: <4223ecf1-77bc-4be4-b05e-d27cd292c69c@kaart.com> References: <4223ecf1-77bc-4be4-b05e-d27cd292c69c@kaart.com> Message-ID: **Is it of interest ?** I believe it is of interest. **Would you use it ?** If date / time input is definitely necessary, much better than searching for various implementations having varying quality / support. However recently we had to write a Combo like for time range (e.g. `Aug 25, 11:52 am ? Aug 27, 11:52 am` , and drop down with options like Past X Hours, Past X Days), which is a tad different than a date time picker. **What features must it have ?** While I tend to agree with the enumerated features of SWinxy and Andy Goryachev, I believe the model should be open and extensible enough to support features that are nice but non critical (e.g. one may want to select multiple dates, or a range). I believe the formatting in particular should work for multiple locales and multiple formats, as french dates are entered in a human way, but recognizing ISO 8601 could be nice as well. On the Swing aspect : I believe there should be three main components working together but usable on their own : 1. A combobox-like with a text field using a customizable parser. This combobox-like could create a popup that can be any component (current combobox do not allow anything else than a JList based popup). This would allow one to customize the popup (placement left-right, width and its content, e.g. two months, adding other controls on any side) or even reuse this combobox-like for other purposes (e.g. an hex color text whose popup is a color picker). 2. The combobox-like editor could benefit from being date time aware, e.g. to select parts like the month or the minute. 3. The calendar time view, that could be used outside the popup, e.g. for a multi-month panel. This calendar view should allow some tweaking of the rendering (decorations), e.g. one may want to reuse this calendar view to represent something that spans over an interval (like on multiple days). The calendar should support mouse motion, when hovering, to tweak the day or a span over days (that may be represented as line, or dots, etc). So for example one could compose these components to create a time-range selector. **What features are nice to have ?** I believe some features like OS formatting are nice but not essential and possibly not wanted. **Do you have any experiences of other date pickers that reinforce those responses ?** I have used the Datadog time range picker which is very practical to use from a user standpoint. **Anything else ?** Nothing at this time -- Brice On Mon, Aug 26, 2024 at 4:27?PM Taylor Smock wrote: > On 8/21/24 23:00, Tejesh R wrote: > > Hello Swing Community, > > [...] so we are considering revisiting the idea of a Date Picker in core > Swing. [...] > > - Is it of interest ? > Yes. The OSS application I work on (https://josm.openstreetmap.de) has > some areas in the UI where it would be nice to have a date picker. Some > plugins for the app use third-party components to provide a date picker UI, > but the non-plugin date pickers are text only. > > - Would you use it ? > Yes. Eventually -- whenever we make the version of Java with the date > picker the minimum required version. That will probably be a decade after > GA for the date picker. For reference, we only stopped supporting Java 8 in > the past year. We still support Java 11, and we will _likely_ be held back > by the default-jre in Debian going forward. > We *do* support the latest Java versions, but for our users, we try to > support as many versions of possible (we distribute jlink binaries, jars, > and jnlp files (for OpenWebStart)). > > - What features must it have ? > For our usage, we just need users to be able to pick dates; almost all of > our use cases don't require time as well. > So: > * User selection of a date > > - What features are nice to have ? > * User selection of a date range -- this can be done outside of the JDK if > necessary. > > - Do you have any experiences of other date pickers that reinforce those > responses ? > I've used https://github.com/JDatePicker/JDatePicker in the past in a > plugin for the OSS application. > > - Anything else ? > No. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aivanov at openjdk.org Tue Aug 27 12:58:09 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 27 Aug 2024 12:58:09 GMT Subject: RFR: 8337851: Some tests have name which confuse jtreg [v3] In-Reply-To: References: <9Ohvnc6MgnokscABDpbRhBYuXtjguHrcJd7eVRWSXYs=.cd938d32-de8b-4eb1-a601-421762f991f3@github.com> <-ua0I6lCxPPp57ELQTFMnMOS8pJP03pGxmGMaVMrJYI=.e87e09a5-6475-44b5-855c-b005fff2ad1c@github.com> Message-ID: <5m5fXgRoiwNZBV49deCIdmBxsGff6gOJ_Z99zr_Pyfc=.96edb6e6-231f-4771-8362-28131c46c613@github.com> On Fri, 23 Aug 2024 22:14:12 GMT, Jonathan Gibbons wrote: > With my official `jtreg` hat on, I recommend always placing the `jtreg` tags immediately after any legal header comments and _before_ any and all of the source code that comprises the test. @jonathan-gibbons Are there any disadvantages to placing jtreg tags right before the test class declaration, after all the import statements? It is more convenient when viewing test code in IDE: the jtreg tags are clearly visible. If the tags are after the legal header, they're collapsed together with the legal header (and imports). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20475#discussion_r1732798992 From ihse at openjdk.org Tue Aug 27 13:50:03 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 27 Aug 2024 13:50:03 GMT Subject: RFR: 8338768: Introduce runtime lookup to check for static builds [v2] In-Reply-To: <4zUGEcC6eLmdq0wAqDCgAjsU17u6-sQNv8KZVQ8pCKc=.f8801e0b-8351-4af9-9825-70ccfa63847a@github.com> References: <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com> <4zUGEcC6eLmdq0wAqDCgAjsU17u6-sQNv8KZVQ8pCKc=.f8801e0b-8351-4af9-9825-70ccfa63847a@github.com> Message-ID: On Mon, 26 Aug 2024 09:39:28 GMT, Magnus Ihse Bursie wrote: >> I understand the cost overhead experienced by any individual Java run may be lost in the noise, but it still impacts every single Java run just to save some time/resources for the handful of builders of statically linked VMs. I am not a fan. > >> but it still impacts every single Java run just to save some time/resources for the handful of builders of statically linked VMs. > > Seriously? I challenge you do prove there is any effect at all. :-/ > > Also, there is not a "handful" of builders of static libraries. Our internal CI system builds static libraries all the time, and I for one would be glad to use these resources on more productive stuff than building all object files twice. > > Also, the intention is to enable static builds by default on GHA, once the entire process of making static builds "dirt cheap" is finished, to avoid regressions. > Hi @magicus, perhaps the answer is both yes and no. [...] Since the mainline doesn't have the needed build changes to have the ability to link a javastatic binary, from that point of view all the static cases in the PR cannot be tested yet. I don't think that is correct. This PR just modifies the existing places where static and dynamic libraries are handled differently. These have been put in place by prior users of static libraries (mobile, graal), and do not require the Hermetic Java "javastatic" launcher to test. I honestly thought this part was going to be a no-brainer, a simple preparation for future things to come. I'm surprised that it seems to be so controversial. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20666#issuecomment-2312613235 From ihse at openjdk.org Tue Aug 27 13:58:07 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 27 Aug 2024 13:58:07 GMT Subject: RFR: 8338768: Introduce runtime lookup to check for static builds [v2] In-Reply-To: <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com> References: <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com> Message-ID: On Wed, 21 Aug 2024 22:14:40 GMT, Magnus Ihse Bursie wrote: >> As a preparation for Hermetic Java, we need to have a way to look up during runtime if we are using a statically linked library or not. >> >> This change will be the first step needed towards compiling the object files only once, and then link them into either dynamic or static libraries. (The only exception will be the linktype.c[pp] files, which needs to be compiled twice, once for the dynamic libraries and once for the static libraries.) Getting there will require further work though. >> >> This is part of the changes that make up the draft PR https://github.com/openjdk/jdk/pull/19478, which I have broken out. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Also update build to link properly And the discussion whether the checks are made "dynamically" or "statically" is too simplified to be really helpful. Currently, we compile two sets of all object files, with slightly different compiler arguments, one for dynamic libraries and one for static libraries. Files that are doing things differently for these two modes have an #ifdef, so the alternative way of doing things are not included in the object file. In your branch, you still have a separate compilation of all files for static builds, but you also try to figure out through various means (which involves jumping through some hoops to get the bootstrapping right) if this is a static build or a dynamic build. In a way, one could argue that this is just worse than the current solution, since you are still recompiling all files separately for static libraries so you could "know" at build time if you are static or not. What I am trying to do is to get to a point where we can compile almost all files just once, and then have two trivially small files that are compiled twice, with just a different value of a define that makes the difference. To propagate this information to all other object files, they need to call the function provided in this object file. So, is it then a "build time" lookup or a "runtime lookup", or a "static lookup" vs "dynamic lookup"? The semantics does not really matter. The whole point is that the difference in build is reduced to an absolute minimum. Sure, this single "lookup" function could be created more like the way you are doing in your branch to try to figure this out without the help of the build system, but there is really no point in that. This is a simple and elegant solution. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20666#issuecomment-2312637272 From prr at openjdk.org Tue Aug 27 16:20:10 2024 From: prr at openjdk.org (Phil Race) Date: Tue, 27 Aug 2024 16:20:10 GMT Subject: RFR: 8338041: Keyboard Navigation of JTable, Ctrl Shift RIGHT/LEFT doesn't follow native action in GTK L&F [v2] In-Reply-To: References: <_kMMFJ9LnQOmUmp_3Ob1m3lj2xLKUo-ChL00Clw4xjs=.7e799f69-da05-44f4-9bf7-6e9e43b427b8@github.com> Message-ID: On Tue, 20 Aug 2024 07:26:12 GMT, Tejesh R wrote: >> In JTable, keyboard navigation keys Ctrl Shift RIGHT/LEFT doesn't follow native actions of Linux. In native the actions are extended to end of selected columns cells either LEFT/RIGHT but in swing gtk look and feel the selection is extended to one cell to left/right. This might be taken as reference of Windows OS since the same is observed in Windows native. Hence I have update the actions for Ctrl Shift RIGHT & LEFT. >> Added automated test too. The fix is tested in CI and its fine. > > Tejesh R 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 four additional commits since the last revision: > > - Updated review comments > - Merge branch 'master' of https://git.openjdk.java.net/jdk into branch_8338041 > - Test updates > - Key action modified + Automatic test added Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20608#pullrequestreview-2263914407 From prr at openjdk.org Tue Aug 27 16:49:05 2024 From: prr at openjdk.org (Phil Race) Date: Tue, 27 Aug 2024 16:49:05 GMT Subject: RFR: 8338103: Stabilize and open source a Swing OGL ButtonResizeTest [v4] In-Reply-To: References: <8--CxVHS_jclzzN2PWYkI0W3yr7w1al5PSqRdis-PUc=.2f57c378-49cc-40bc-b042-f6aa9bfed07d@github.com> <7AO_JKocjYGnAp7JfzOFaN8uYMw48LhLbnI1ilkFE5g=.aeb55a93-784f-405b-b46f-ed6391f53431@github.com> Message-ID: On Tue, 27 Aug 2024 08:55:23 GMT, Manukumar V S wrote: >> Pipeline. You can't easily know what will be chosen on a test system, so you need to do things like >> @run main/othervm -Dsun.java2d.xrender=false >> @run main/othervm -Dsun.java2d.xrender=true >> @run main/othervm -Dsun.java2d.d3d=false >> @run main/othervm -Dsun.java2d.d3d=true >> >> In some cases, nothing will change but if the test is cheap and fast, nothing lost > > Thanks @prrace , I have added more pipelines to the test, please have a look. I have rerun this again on all platforms with mach5 and the results are updated in the bug as a comment. Looks like it failed on Linux with the default pipeline, which should be xrender. That's a bit surprising. You should verify this and if necessary file a bug and exclude that failing combination from testing. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20532#discussion_r1733220691 From prr at openjdk.org Tue Aug 27 16:54:07 2024 From: prr at openjdk.org (Phil Race) Date: Tue, 27 Aug 2024 16:54:07 GMT Subject: RFR: 8338103: Stabilize and open source a Swing OGL ButtonResizeTest [v4] In-Reply-To: References: <8--CxVHS_jclzzN2PWYkI0W3yr7w1al5PSqRdis-PUc=.2f57c378-49cc-40bc-b042-f6aa9bfed07d@github.com> <7AO_JKocjYGnAp7JfzOFaN8uYMw48LhLbnI1ilkFE5g=.aeb55a93-784f-405b-b46f-ed6391f53431@github.com> Message-ID: On Tue, 27 Aug 2024 16:46:23 GMT, Phil Race wrote: >> Thanks @prrace , I have added more pipelines to the test, please have a look. I have rerun this again on all platforms with mach5 and the results are updated in the bug as a comment. > > Looks like it failed on Linux with the default pipeline, which should be xrender. That's a bit surprising. > You should verify this and if necessary file a bug and exclude that failing combination from testing. Also, I see you added metal. I think I'm going to request an extra layer on top of what I previously suggested. It is possible to have multiple @test tags, not just @run tags, so you can do platform-specific things on just the specific platform, so it would become /* @test @requires("os.name"="windows") @run main/othervm -Dsun.java2d.d3d=false @run main/othervm -Dsun.java2d.d3d=true */ /* @test @requires("os.name"="macos") @run main/othervm -Dsun.java2d.d3d=false @run main/othervm -Dsun.java2d.metal=true */ /* @test @requires("os.name"="linux") @run main/othervm -Dsun.java2d.xrender=false @run main/othervm -Dsun.java2d.xrender=true */ and finally the one that is cross-platform AND defaults /* @test @run/main/othervm @run main/othervm -Dsun.java2d.opengl=false @run main/othervm -Dsun.java2d.opengl=true */ ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20532#discussion_r1733227340 From prr at openjdk.org Tue Aug 27 17:04:13 2024 From: prr at openjdk.org (Phil Race) Date: Tue, 27 Aug 2024 17:04:13 GMT Subject: RFR: 8336873: BasicSplitPaneDivider:oneTouchExpandableChanged() should mention that implementation depends on SplitPane.supportsOneTouchButtons property [v4] In-Reply-To: References: Message-ID: On Mon, 26 Aug 2024 08:54:15 GMT, Prasanta Sadhukhan wrote: >> BasicSplitPaneDivider:oneTouchExpandableChanged() spec doesn't mention that it will create left/right button only if L&F supports SplitPane.supportsOneTouchButtons which is now added in javadoc.. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Mention Swing property Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20289#pullrequestreview-2264008752 From azvegint at openjdk.org Tue Aug 27 17:19:09 2024 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Tue, 27 Aug 2024 17:19:09 GMT Subject: Integrated: 8332158: [XWayland] test/jdk/java/awt/Mouse/EnterExitEvents/ResizingFrameTest.java In-Reply-To: References: Message-ID: On Mon, 26 Aug 2024 19:02:56 GMT, Alexander Zvegintsev wrote: > There are two mouse pointer locations on Wayland: > > `#1` Wayland compositor - can be controlled by a physical mouse device, or libei, this location is visible on a screen as a mouse cursor and is propagated to `#2`. > > `#2` Inside the XWayland server - most of the time this is the same as `#1`, unless we have changed it programmatically, e.g. by using the XTest extension protocol, but it does not move the visible mouse cursor in `#1`. > Our tests in X11 compatibility mode using this approach(aka `java.awt.Robot#mouseMove`) > > This test moves the mouse cursor to a specific location over a window in `#2`, which most likely isn't the same as the visible cursor location in `#1`. > If the window was moved/resized and placed under the visible cursor location, that cursor location is also set for `#2`, and from the test's perspective, the mouse has just been moved to a different location without the test expecting it, causing unexpected mouse enter/exit events. > > We can try to smooth this out with additional `robot.mouseMove` calls, but it looks like we are missing the point of the test. > So for now it is better to skip the test on Wayland. > > Another way is to use libei to move the visible mouse cursor on the system ([JDK-8280983](https://bugs.openjdk.org/browse/JDK-8280983)), but its support is not yet widespread on supported systems. > > Testing looks good. This pull request has now been integrated. Changeset: b1b4cd42 Author: Alexander Zvegintsev URL: https://git.openjdk.org/jdk/commit/b1b4cd429a4135840966975dd0c068fe428e2ee6 Stats: 15 lines in 2 files changed: 10 ins; 0 del; 5 mod 8332158: [XWayland] test/jdk/java/awt/Mouse/EnterExitEvents/ResizingFrameTest.java Reviewed-by: serb, honkar ------------- PR: https://git.openjdk.org/jdk/pull/20717 From mvs at openjdk.org Tue Aug 27 17:26:04 2024 From: mvs at openjdk.org (Manukumar V S) Date: Tue, 27 Aug 2024 17:26:04 GMT Subject: RFR: 8338103: Stabilize and open source a Swing OGL ButtonResizeTest [v4] In-Reply-To: References: <8--CxVHS_jclzzN2PWYkI0W3yr7w1al5PSqRdis-PUc=.2f57c378-49cc-40bc-b042-f6aa9bfed07d@github.com> <7AO_JKocjYGnAp7JfzOFaN8uYMw48LhLbnI1ilkFE5g=.aeb55a93-784f-405b-b46f-ed6391f53431@github.com> Message-ID: On Tue, 27 Aug 2024 16:51:51 GMT, Phil Race wrote: >> Looks like it failed on Linux with the default pipeline, which should be xrender. That's a bit surprising. >> You should verify this and if necessary file a bug and exclude that failing combination from testing. > > Also, I see you added metal. > I think I'm going to request an extra layer on top of what I previously suggested. > > It is possible to have multiple @test tags, not just @run tags, so you can do platform-specific things on just the specific platform, so it would become > > /* @test > @requires("os.name"="windows") > @run main/othervm -Dsun.java2d.d3d=false > @run main/othervm -Dsun.java2d.d3d=true > */ > > /* @test > @requires("os.name"="macos") > @run main/othervm -Dsun.java2d.d3d=false > @run main/othervm -Dsun.java2d.metal=true > */ > > > /* @test > @requires("os.name"="linux") > @run main/othervm -Dsun.java2d.xrender=false > @run main/othervm -Dsun.java2d.xrender=true > */ > > and finally the one that is cross-platform AND defaults > /* @test > @run/main/othervm > @run main/othervm -Dsun.java2d.opengl=false > @run main/othervm -Dsun.java2d.opengl=true > */ > Looks like it failed on Linux with the default pipeline, which should be xrender. That's a bit surprising. You should verify this and if necessary file a bug and exclude that failing combination from testing. Yea, that's true, but it failed on a particular machine only and that too it was a plain run without any flags(@run main/othervm SwingButtonResizeTestWithOpenGL), the runs with xrender and other flags were successful in the same machine. I just rerun it 10 times on different linux machines and I couldn't observe the failure again(the latest results are attached as a comment to the bug), so it looks like a machine specific issue and I could see some UI debris from the previous runs on the screenshots. anyway I will check it again with @test tags. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20532#discussion_r1733264403 From jiangli at openjdk.org Tue Aug 27 17:56:03 2024 From: jiangli at openjdk.org (Jiangli Zhou) Date: Tue, 27 Aug 2024 17:56:03 GMT Subject: RFR: 8338768: Introduce runtime lookup to check for static builds [v2] In-Reply-To: <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com> References: <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com> Message-ID: <3fVMocxS8IOcl2YdBhyFtAd7U8oUkR_arFRFKQNrktI=.e896558e-9e20-49bc-a298-13de3e0f3f11@github.com> On Wed, 21 Aug 2024 22:14:40 GMT, Magnus Ihse Bursie wrote: >> As a preparation for Hermetic Java, we need to have a way to look up during runtime if we are using a statically linked library or not. >> >> This change will be the first step needed towards compiling the object files only once, and then link them into either dynamic or static libraries. (The only exception will be the linktype.c[pp] files, which needs to be compiled twice, once for the dynamic libraries and once for the static libraries.) Getting there will require further work though. >> >> This is part of the changes that make up the draft PR https://github.com/openjdk/jdk/pull/19478, which I have broken out. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Also update build to link properly Marked as reviewed by jiangli (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20666#pullrequestreview-2264106008 From jiangli at openjdk.org Tue Aug 27 17:56:04 2024 From: jiangli at openjdk.org (Jiangli Zhou) Date: Tue, 27 Aug 2024 17:56:04 GMT Subject: RFR: 8338768: Introduce runtime lookup to check for static builds [v2] In-Reply-To: References: <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com> Message-ID: <8qxU0njJxPJtQiUvMkU2NlOY7xhV3xz17YBXPSDi11E=.69e5a2eb-96fd-462c-9f5d-b9af254701fa@github.com> On Tue, 27 Aug 2024 13:55:51 GMT, Magnus Ihse Bursie wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: >> >> Also update build to link properly > > And the discussion whether the checks are made "dynamically" or "statically" is too simplified to be really helpful. > > Currently, we compile two sets of all object files, with slightly different compiler arguments, one for dynamic libraries and one for static libraries. Files that are doing things differently for these two modes have an #ifdef, so the alternative way of doing things are not included in the object file. > > In your branch, you still have a separate compilation of all files for static builds, but you also try to figure out through various means (which involves jumping through some hoops to get the bootstrapping right) if this is a static build or a dynamic build. In a way, one could argue that this is just worse than the current solution, since you are still recompiling all files separately for static libraries so you could "know" at build time if you are static or not. > > What I am trying to do is to get to a point where we can compile almost all files just once, and then have two trivially small files that are compiled twice, with just a different value of a define that makes the difference. To propagate this information to all other object files, they need to call the function provided in this object file. So, is it then a "build time" lookup or a "runtime lookup", or a "static lookup" vs "dynamic lookup"? The semantics does not really matter. The whole point is that the difference in build is reduced to an absolute minimum. Sure, this single "lookup" function could be created more like the way you are doing in your branch to try to figure this out without the help of the build system, but there is really no point in that. This is a simple and elegant solution. We had a zoom discussion with @magicus and others on this PR (as part of regular hermetic Java meeting) this morning. @magicus mentioned that he has a PR in progress with the static linking part, which helps address my specific concern. > In your branch, you still have a separate compilation of all files for static builds, but you also try to figure out through various means (which involves jumping through some hoops to get the bootstrapping right) if this is a static build or a dynamic build. In a way, one could argue that this is just worse than the current solution, since you are still recompiling all files separately for static libraries so you could "know" at build time if you are static or not. Yes, the .o files are recompiled for creating the static libraries currently. That causes observable large overhead in terms of both memory and build duration for building JDK itself. In real world constraint environments, both overhead are problematic and cause build issues. So steps toward building the `.so` and `.a` using the same set of `.o` object files should be one of our end goals (just to re-iterate its importance), but would be "ok" without during the initial phases when we are building/integrating hermetic/static support in JDK mainline. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20666#issuecomment-2313180693 From mvs at openjdk.org Tue Aug 27 18:24:26 2024 From: mvs at openjdk.org (Manukumar V S) Date: Tue, 27 Aug 2024 18:24:26 GMT Subject: RFR: 8338103: Stabilize and open source a Swing OGL ButtonResizeTest [v6] In-Reply-To: <8--CxVHS_jclzzN2PWYkI0W3yr7w1al5PSqRdis-PUc=.2f57c378-49cc-40bc-b042-f6aa9bfed07d@github.com> References: <8--CxVHS_jclzzN2PWYkI0W3yr7w1al5PSqRdis-PUc=.2f57c378-49cc-40bc-b042-f6aa9bfed07d@github.com> Message-ID: > This PR creates a new test by stabilising and open sourcing a closed test. > This test verifies that the OpenGL pipeline does not create artifacts with swing components after window is zoomed to maximum size and then resized back to normal. > This test is run twice, with and without the flags "-Dsun.java2d.opengl=True -Dsun.java2d.opengl.fbobject=false" . > > This is tested(15 times per platform) in all the available mach5 headful platforms and found to be stable. Manukumar V S has updated the pull request incrementally with one additional commit since the last revision: Review comment fixed : Added different @test tags for different platforms ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20532/files - new: https://git.openjdk.org/jdk/pull/20532/files/fccae9c9..5694b681 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20532&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20532&range=04-05 Stats: 23 lines in 1 file changed: 18 ins; 1 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/20532.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20532/head:pull/20532 PR: https://git.openjdk.org/jdk/pull/20532 From mvs at openjdk.org Tue Aug 27 18:28:13 2024 From: mvs at openjdk.org (Manukumar V S) Date: Tue, 27 Aug 2024 18:28:13 GMT Subject: RFR: 8338103: Stabilize and open source a Swing OGL ButtonResizeTest [v4] In-Reply-To: References: <8--CxVHS_jclzzN2PWYkI0W3yr7w1al5PSqRdis-PUc=.2f57c378-49cc-40bc-b042-f6aa9bfed07d@github.com> <7AO_JKocjYGnAp7JfzOFaN8uYMw48LhLbnI1ilkFE5g=.aeb55a93-784f-405b-b46f-ed6391f53431@github.com> Message-ID: <1muWfhQ9M49V-jc7PMNmZUU5CKl-1JqexahIubxqZEs=.02d41358-98ce-4603-b31a-2991518f5453@github.com> On Tue, 27 Aug 2024 16:51:51 GMT, Phil Race wrote: >> Looks like it failed on Linux with the default pipeline, which should be xrender. That's a bit surprising. >> You should verify this and if necessary file a bug and exclude that failing combination from testing. > > Also, I see you added metal. > I think I'm going to request an extra layer on top of what I previously suggested. > > It is possible to have multiple @test tags, not just @run tags, so you can do platform-specific things on just the specific platform, so it would become > > /* @test > @requires("os.name"="windows") > @run main/othervm -Dsun.java2d.d3d=false > @run main/othervm -Dsun.java2d.d3d=true > */ > > /* @test > @requires("os.name"="macos") > @run main/othervm -Dsun.java2d.d3d=false > @run main/othervm -Dsun.java2d.metal=true > */ > > > /* @test > @requires("os.name"="linux") > @run main/othervm -Dsun.java2d.xrender=false > @run main/othervm -Dsun.java2d.xrender=true > */ > > and finally the one that is cross-platform AND defaults > /* @test > @run/main/othervm > @run main/othervm -Dsun.java2d.opengl=false > @run main/othervm -Dsun.java2d.opengl=true > */ @prrace I have added @test tags for different platforms and the corresponding mach5 runs are attached in the bug as a new comment, please have a look. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20532#discussion_r1733337022 From ihse at openjdk.org Tue Aug 27 22:31:16 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 27 Aug 2024 22:31:16 GMT Subject: RFR: 8339120: Use more fine-granular gcc unused warnings In-Reply-To: References: Message-ID: On Tue, 27 Aug 2024 20:04:21 GMT, Magnus Ihse Bursie wrote: > Currently, we issue -Wno-unused for all files in gcc, which is a rather big sledgehammer to get rid of some warnings that proliferate in a few areas of the build. > > We should instead leave -Wunused turned on (as done by -Wall) and use a much more fine-grained approach to disabling specific warnings in specific files or libraries. If at some point the diff seems larger than needed, it could be that I have reordered things where the alphabetic order had capsized. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20733#issuecomment-2313681273 From serb at openjdk.org Tue Aug 27 22:31:24 2024 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 27 Aug 2024 22:31:24 GMT Subject: RFR: 8337457: Redundant Math.round call in AquaProgressBarUI#getStringPlacement In-Reply-To: <19pO_6uB0XN1R849SUo0-rytPb4YNs8AqyfxBYn6ElM=.c1ebaa7e-2334-4d75-9b95-2e8f74d8cb6c@github.com> References: <19pO_6uB0XN1R849SUo0-rytPb4YNs8AqyfxBYn6ElM=.c1ebaa7e-2334-4d75-9b95-2e8f74d8cb6c@github.com> Message-ID: On Wed, 31 Jul 2024 07:12:35 GMT, Prasanta Sadhukhan wrote: > Since Math.round with integer argument returns the same value, and also since all arguments and calculations in the AquaProgressBarUI#getStringPlacement are integer arithmetic, Math.round is redundant and can be removed src/java.desktop/macosx/classes/com/apple/laf/AquaProgressBarUI.java line 259: > 257: } > 258: > 259: return new Point(x + (width / 2 - stringWidth / 2), y + ((height + fontSizer.getAscent() - fontSizer.getLeading() - fontSizer.getDescent()) / 2) - 1); There was the same bug in the BasicProgressBarUI#getStringPlacement, but it seems it was fixed in the opposite way by replacing the "2" ->> "2.0", see https://github.com/openjdk/jdk/commit/338fb4d94a6a66b21ff39fccf541bbfb63251e6c ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20400#discussion_r1733593021 From ihse at openjdk.org Tue Aug 27 22:31:15 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 27 Aug 2024 22:31:15 GMT Subject: RFR: 8339120: Use more fine-granular gcc unused warnings Message-ID: Currently, we issue -Wno-unused for all files in gcc, which is a rather big sledgehammer to get rid of some warnings that proliferate in a few areas of the build. We should instead leave -Wunused turned on (as done by -Wall) and use a much more fine-grained approach to disabling specific warnings in specific files or libraries. ------------- Commit messages: - Fix debug builds - Try fixing static builds on zero - Fix zero - Fix libfallbackLinker - Also update native tests - 8339120: Use more fine-granular gcc unused warnings Changes: https://git.openjdk.org/jdk/pull/20733/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20733&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8339120 Stats: 50 lines in 17 files changed: 28 ins; 0 del; 22 mod Patch: https://git.openjdk.org/jdk/pull/20733.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20733/head:pull/20733 PR: https://git.openjdk.org/jdk/pull/20733 From jiangli at openjdk.org Tue Aug 27 23:17:19 2024 From: jiangli at openjdk.org (Jiangli Zhou) Date: Tue, 27 Aug 2024 23:17:19 GMT Subject: RFR: 8338768: Introduce runtime lookup to check for static builds [v2] In-Reply-To: References: <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com> Message-ID: On Tue, 27 Aug 2024 13:55:51 GMT, Magnus Ihse Bursie wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: >> >> Also update build to link properly > > And the discussion whether the checks are made "dynamically" or "statically" is too simplified to be really helpful. > > Currently, we compile two sets of all object files, with slightly different compiler arguments, one for dynamic libraries and one for static libraries. Files that are doing things differently for these two modes have an #ifdef, so the alternative way of doing things are not included in the object file. > > In your branch, you still have a separate compilation of all files for static builds, but you also try to figure out through various means (which involves jumping through some hoops to get the bootstrapping right) if this is a static build or a dynamic build. In a way, one could argue that this is just worse than the current solution, since you are still recompiling all files separately for static libraries so you could "know" at build time if you are static or not. > > What I am trying to do is to get to a point where we can compile almost all files just once, and then have two trivially small files that are compiled twice, with just a different value of a define that makes the difference. To propagate this information to all other object files, they need to call the function provided in this object file. So, is it then a "build time" lookup or a "runtime lookup", or a "static lookup" vs "dynamic lookup"? The semantics does not really matter. The whole point is that the difference in build is reduced to an absolute minimum. Sure, this single "lookup" function could be created more like the way you are doing in your branch to try to figure this out without the help of the build system, but there is really no point in that. This is a simple and elegant solution. @magicus please also specify contributor properly to so it's clear part of the change is based on/extracted from https://github.com/openjdk/leyden/tree/hermetic-java-runtime. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20666#issuecomment-2313737779 From psadhukhan at openjdk.org Wed Aug 28 02:19:08 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 28 Aug 2024 02:19:08 GMT Subject: RFR: 8190329: [macos] Swing InterOp Platform.exit() crash [v2] In-Reply-To: References: Message-ID: > The testcase calls Platform.exit before the dialog is made visible but > on macOS, JavaFX takes over the AppKit thread and uses that as the FX application thread. As part of the FX platform shutdown process, it detaches that thread from the JVM. This means that the AppKit thread is no longer available to Java processes > so AWT crashes when it ties to access appkit thread. > Fix is made to check if the thread has been detached for move-resize notification event before proceeding.. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Reattach thread if AWT is the owner of NSApplication ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20688/files - new: https://git.openjdk.org/jdk/pull/20688/files/678eb13f..effb3f09 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20688&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20688&range=00-01 Stats: 25 lines in 4 files changed: 14 ins; 8 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/20688.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20688/head:pull/20688 PR: https://git.openjdk.org/jdk/pull/20688 From psadhukhan at openjdk.org Wed Aug 28 02:19:08 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 28 Aug 2024 02:19:08 GMT Subject: RFR: 8190329: [macos] Swing InterOp Platform.exit() crash [v2] In-Reply-To: <4NuTyjCwGeHcUsCaYKP9540duSe1Crw4N8jtPOXoOHs=.10edafb5-c984-4192-85e0-68f81b393899@github.com> References: <0ErO4olMuzO-dyyZ0gMyL6I2Q3kJk3NWMhdUeJ682Qc=.52bd1eb8-5045-4bc1-b391-698768fe59d5@github.com> <8DNMrEM6VOHBG8LuUX068hTh-LfMIM8pylXfiIST8PY=.070d587f-c0fa-4caf-ab46-4b4ccad29c7a@github.com> <4NuTyjCwGeHcUsCaYKP9540duSe1Crw4N8jtPOXoOHs=.10edafb5-c984-4192-85e0-68f81b393899@github.com> Message-ID: On Mon, 26 Aug 2024 22:51:40 GMT, Kevin Rushforth wrote: >> That makes sense to me. I sent a quick (definitely not finished) prototype of the idea I mentioned to @prsadhuk offline, so maybe he can take that as a starting point for the fix. > > If we do fix it in both, we will need two bug IDs. I can file a new one for JavaFX in that case. NSApplication owner checked for reattaching the thread..CI testing is green... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20688#discussion_r1733778142 From duke at openjdk.org Wed Aug 28 02:24:31 2024 From: duke at openjdk.org (duke) Date: Wed, 28 Aug 2024 02:24:31 GMT Subject: Withdrawn: JDK-8314731 : Add support for the alt attribute in the image type input HTML tag In-Reply-To: References: Message-ID: On Thu, 17 Aug 2023 00:16:07 GMT, ScientificWare wrote: > This is referenced in Java Bug Database as > - [JDK-8314731 : Adds support for the alt attribute in the image type input HTML tag.](https://bugs.java.com/bugdatabase/view_bug?bug_id=8314731) > > This is tracked in JBS as > - [JDK-8314731 : Add support for the alt attribute in the image type input HTML tag](https://bugs.openjdk.java.net/browse/JDK-8314731) > > According [HTML 3.2 specification](https://www.w3.org/TR/2018/SPSD-html32-20180315/#input) > > `alt` is not an attribute of the `input` element. > > According [HTML 4.01 specifications](https://www.w3.org/TR/html4/interact/forms.html#h-17.4) : > >> ... For accessibility reasons, authors should provide [alternate text](https://www.w3.org/TR/html4/struct/objects.html#alternate-text) for the image via the [alt](https://www.w3.org/TR/html4/struct/objects.html#adef-alt) attribute. ... > > This feature is not implemented in `FormView.java`. > > ?? ~~This also affects the HTML 32 DTD~~ > > ![Screenshot_20230817_025316](https://github.com/openjdk/jdk/assets/19194678/8e580574-d842-4a65-884b-26e33cd12138) > > Left before the patch and right after the patch. > > > import java.awt.BorderLayout; > import java.awt.Dimension; > import javax.swing.JEditorPane; > import javax.swing.JFrame; > import javax.swing.JScrollPane; > import javax.swing.SwingUtilities; > import javax.swing.text.Document; > import javax.swing.text.html.HTMLEditorKit; > import javax.swing.text.html.StyleSheet; > > public class HTMLAddsSupportAltInputTag { > public static void main(String[] args) { > new HTMLAddsSupportAltInputTag(); > } > > public HTMLAddsSupportAltInputTag() { > SwingUtilities.invokeLater(new Runnable(){ > public void run(){ > JEditorPane jEditorPane = new JEditorPane(); > jEditorPane.setEditable(false); > JScrollPane scrollPane = new JScrollPane(jEditorPane); > HTMLEditorKit kit = new HTMLEditorKit(); > jEditorPane.setEditorKit(kit); > StyleSheet styleSheet = kit.getStyleSheet(); > styleSheet.addRule(""" > body { > color: #000; > font-family:times; > margin: 4px; > } > """); > String htmlString = """ > > > >

> >

> References: Message-ID: On Tue, 27 Aug 2024 20:04:21 GMT, Magnus Ihse Bursie wrote: > Currently, we issue -Wno-unused for all files in gcc, which is a rather big sledgehammer to get rid of some warnings that proliferate in a few areas of the build. > > We should instead leave -Wunused turned on (as done by -Wall) and use a much more fine-grained approach to disabling specific warnings in specific files or libraries. That's a lot of new warnings, but I like the idea of being more fine grained in what is disabled and enabled ------------- Marked as reviewed by jwaters (Committer). PR Review: https://git.openjdk.org/jdk/pull/20733#pullrequestreview-2265064013 From abhiscxk at openjdk.org Wed Aug 28 04:27:17 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Wed, 28 Aug 2024 04:27:17 GMT Subject: RFR: 8338153: java/awt/Checkbox/CheckboxCheckerScalingTest.java test failed on linux machine In-Reply-To: References: Message-ID: On Tue, 27 Aug 2024 06:04:47 GMT, Tejesh R wrote: > Test failed intermittently on particular host. Though analysis pointed out to a test frame at left top on that host, I've updated the test for further stabilizing it. Two things done here: > 1. Move the frame to center of the screen rather than left top. > 2. Added tolerance checks for color comparison - this is based on analysis reports where the image didn't had exact black color which is supposed to be. So like other test cases, providing some tolerance for comparison. @TejeshR13 Did you check the current changes on CI system? Did you observe any failure on the particular machine where it failed in CI? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20723#issuecomment-2314221287 From tr at openjdk.org Wed Aug 28 04:46:25 2024 From: tr at openjdk.org (Tejesh R) Date: Wed, 28 Aug 2024 04:46:25 GMT Subject: Integrated: 8338041: Keyboard Navigation of JTable, Ctrl Shift RIGHT/LEFT doesn't follow native action in GTK L&F In-Reply-To: <_kMMFJ9LnQOmUmp_3Ob1m3lj2xLKUo-ChL00Clw4xjs=.7e799f69-da05-44f4-9bf7-6e9e43b427b8@github.com> References: <_kMMFJ9LnQOmUmp_3Ob1m3lj2xLKUo-ChL00Clw4xjs=.7e799f69-da05-44f4-9bf7-6e9e43b427b8@github.com> Message-ID: On Fri, 16 Aug 2024 07:39:44 GMT, Tejesh R wrote: > In JTable, keyboard navigation keys Ctrl Shift RIGHT/LEFT doesn't follow native actions of Linux. In native the actions are extended to end of selected columns cells either LEFT/RIGHT but in swing gtk look and feel the selection is extended to one cell to left/right. This might be taken as reference of Windows OS since the same is observed in Windows native. Hence I have update the actions for Ctrl Shift RIGHT & LEFT. > Added automated test too. The fix is tested in CI and its fine. This pull request has now been integrated. Changeset: 8e88da05 Author: Tejesh R URL: https://git.openjdk.org/jdk/commit/8e88da05b9966892e117b779d59a2e311a557a8d Stats: 141 lines in 2 files changed: 139 ins; 0 del; 2 mod 8338041: Keyboard Navigation of JTable, Ctrl Shift RIGHT/LEFT doesn't follow native action in GTK L&F Reviewed-by: honkar, prr, abhiscxk ------------- PR: https://git.openjdk.org/jdk/pull/20608 From abhiscxk at openjdk.org Wed Aug 28 05:27:24 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Wed, 28 Aug 2024 05:27:24 GMT Subject: RFR: 8338103: Stabilize and open source a Swing OGL ButtonResizeTest [v6] In-Reply-To: References: <8--CxVHS_jclzzN2PWYkI0W3yr7w1al5PSqRdis-PUc=.2f57c378-49cc-40bc-b042-f6aa9bfed07d@github.com> Message-ID: <0NbRtU-LzUgcDU1ZVeLCkeRQzPsv-AVE2Bq-GtsqfjM=.dbe954da-4afb-4f9b-adab-6ed9f3876f60@github.com> On Tue, 27 Aug 2024 18:24:26 GMT, Manukumar V S wrote: >> This PR creates a new test by stabilising and open sourcing a closed test. >> This test verifies that the OpenGL pipeline does not create artifacts with swing components after window is zoomed to maximum size and then resized back to normal. >> This test is run twice, with and without the flags "-Dsun.java2d.opengl=True -Dsun.java2d.opengl.fbobject=false" . >> >> This is tested(15 times per platform) in all the available mach5 headful platforms and found to be stable. > > Manukumar V S has updated the pull request incrementally with one additional commit since the last revision: > > Review comment fixed : Added different @test tags for different platforms test/jdk/javax/swing/JButton/SwingButtonResizeTestWithOpenGL.java line 2: > 1: /* > 2: * Copyright (c) 2015, 2024, Oracle and/or its affiliates. All rights reserved. I think the copyright year should be just 2024. Looks like the test is added in the repo first time. Suggestion: * Copyright (c) 2024, Oracle and/or its affiliates. All rights reserved. test/jdk/javax/swing/JButton/SwingButtonResizeTestWithOpenGL.java line 29: > 27: import javax.swing.SwingUtilities; > 28: import java.awt.Color; > 29: import java.awt.Dimension; Please sort the imports. Usually `java.awt` imports are placed before `javax.swing`. test/jdk/javax/swing/JButton/SwingButtonResizeTestWithOpenGL.java line 53: > 51: * resized back to normal. The test case simulates this operation using > 52: * a JButton. A file image of the component will be saved before and after > 53: * window resize. The test passes if both button images are the same. Suggestion: * resized back to normal. The test case simulates this operation using * a JButton. A file image of the component will be saved before and after test/jdk/javax/swing/JButton/SwingButtonResizeTestWithOpenGL.java line 99: > 97: button = new JButton("Button A"); > 98: frame.setLocationRelativeTo(null); > 99: frame.setLocation(200, 200); Isn't it redundant to `setLocation` of frame after calling `setLocationRelativeTo`? test/jdk/javax/swing/JButton/SwingButtonResizeTestWithOpenGL.java line 133: > 131: } else { > 132: System.out.println("Button focus not gained..."); > 133: throw new RuntimeException("Can't gain focus on button even after waiting too long.."); Crosses the limit of 80 columns here and few more lines below. Please limit it to 80 columns. test/jdk/javax/swing/JButton/SwingButtonResizeTestWithOpenGL.java line 145: > 143: if (frame.getToolkit().isFrameStateSupported(JFrame.MAXIMIZED_BOTH)) { > 144: robot.waitForIdle(); > 145: //maximize frame from normal size Suggestion: // maximize frame from normal size test/jdk/javax/swing/JButton/SwingButtonResizeTestWithOpenGL.java line 152: > 150: if (frame.getToolkit().isFrameStateSupported(JFrame.NORMAL)) { > 151: System.out.println("Frame is back to normal"); > 152: //resize from maximum size to normal Suggestion: // resize from maximum size to normal test/jdk/javax/swing/JButton/SwingButtonResizeTestWithOpenGL.java line 159: > 157: bimage2 = getButtonImage(); > 158: File file2 = new File("image2.png"); > 159: saveButtonImage(bimage2, file2); We are saving these images even in the case where test passes. Generally, we should save image only in case of test failure for debugging purpose. test/jdk/javax/swing/JButton/SwingButtonResizeTestWithOpenGL.java line 168: > 166: int numDiffPixels = di.getNumDiffPixels(); > 167: if (numDiffPixels != 0) { > 168: throw new RuntimeException("Button renderings are different after window resize, num of Diff Pixels=" + numDiffPixels); I think the `compare` method can be modified to return `true/false` based on the nDiff value. If **nDiff is not equal to zero** which you are checking at [L300](https://github.com/openjdk/jdk/blob/5694b6811e06793ddaf1984e909cc0e925d93047/test/jdk/javax/swing/JButton/SwingButtonResizeTestWithOpenGL.java#L300) then you can return `false`, evaluate the return value inside if condition and throw RTE with the num of diff pixels value. If **nDiff is equal to zero** then compare method should return `true` and test should pass. Code snippet can be changed to something like this... > System.out.println("Taking the diff of two images, image1 and image2"); > // results of image comparison > if (!di.compare(bimage1, bimage2)) { > throw new RuntimeException("Button renderings are different after window resize, num of Diff Pixels=" + di.getNumDiffPixels()); } test/jdk/javax/swing/JButton/SwingButtonResizeTestWithOpenGL.java line 181: > 179: } > 180: } finally { > 181: disposeFrame(); should be disposed on EDT. test/jdk/javax/swing/JButton/SwingButtonResizeTestWithOpenGL.java line 185: > 183: } > 184: > 185: //Capture button rendering as a BufferedImage Suggestion: // Capture button rendering as a BufferedImage test/jdk/javax/swing/JButton/SwingButtonResizeTestWithOpenGL.java line 203: > 201: } > 202: > 203: //Save BufferedImage to PNG file Suggestion: // Save BufferedImage to PNG file ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20532#discussion_r1733987202 PR Review Comment: https://git.openjdk.org/jdk/pull/20532#discussion_r1733967856 PR Review Comment: https://git.openjdk.org/jdk/pull/20532#discussion_r1733970039 PR Review Comment: https://git.openjdk.org/jdk/pull/20532#discussion_r1733971416 PR Review Comment: https://git.openjdk.org/jdk/pull/20532#discussion_r1733990904 PR Review Comment: https://git.openjdk.org/jdk/pull/20532#discussion_r1733988634 PR Review Comment: https://git.openjdk.org/jdk/pull/20532#discussion_r1733988706 PR Review Comment: https://git.openjdk.org/jdk/pull/20532#discussion_r1733997751 PR Review Comment: https://git.openjdk.org/jdk/pull/20532#discussion_r1734007708 PR Review Comment: https://git.openjdk.org/jdk/pull/20532#discussion_r1733992703 PR Review Comment: https://git.openjdk.org/jdk/pull/20532#discussion_r1733991797 PR Review Comment: https://git.openjdk.org/jdk/pull/20532#discussion_r1733992309 From kbarrett at openjdk.org Wed Aug 28 06:41:19 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 28 Aug 2024 06:41:19 GMT Subject: RFR: 8339120: Use more fine-granular gcc unused warnings In-Reply-To: References: Message-ID: On Tue, 27 Aug 2024 20:04:21 GMT, Magnus Ihse Bursie wrote: > Currently, we issue -Wno-unused for all files in gcc, which is a rather big sledgehammer to get rid of some warnings that proliferate in a few areas of the build. > > We should instead leave -Wunused turned on (as done by -Wall) and use a much more fine-grained approach to disabling specific warnings in specific files or libraries. We should make a similar set of changes for clang, though doing that in a separate proposal is good. Is there a JBS issue for that yet? make/autoconf/flags-cflags.m4 line 239: > 237: # Additional warnings that are not activated by -Wall and -Wextra > 238: WARNINGS_ENABLE_ADDITIONAL="-Wpointer-arith -Wreturn-type -Wsign-compare \ > 239: -Wtrampolines -Wundef -Wunused-const-variable -Wunused-function \ I think we don't want `-Wunused-const-variable=2` (eqv. `-Wunused-const-variable`) for C++ code. Recall that C++ const variables default to internal linkage (e.g. implicitly static). It's normal to have a non-local constant in a header file that isn't used by every translation unit. For C++ use `-Wunused-const-variable=1`. I think doing this might eliminate the need for disabling this warning in a bunch of other places in this PR. ------------- Changes requested by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20733#pullrequestreview-2265277235 PR Review Comment: https://git.openjdk.org/jdk/pull/20733#discussion_r1734067573 From tr at openjdk.org Wed Aug 28 06:48:26 2024 From: tr at openjdk.org (Tejesh R) Date: Wed, 28 Aug 2024 06:48:26 GMT Subject: RFR: 8338153: java/awt/Checkbox/CheckboxCheckerScalingTest.java test failed on linux machine In-Reply-To: References: Message-ID: On Wed, 28 Aug 2024 04:24:56 GMT, Abhishek Kumar wrote: > @TejeshR13 Did you check the current changes on CI system? Did you observe any failure on the particular machine where it failed in CI? Yes and it didn't fail. Since it is failing intermittently, not sure if we can reproduce it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20723#issuecomment-2314449117 From mvs at openjdk.org Wed Aug 28 08:38:20 2024 From: mvs at openjdk.org (Manukumar V S) Date: Wed, 28 Aug 2024 08:38:20 GMT Subject: RFR: 8338103: Stabilize and open source a Swing OGL ButtonResizeTest [v6] In-Reply-To: <0NbRtU-LzUgcDU1ZVeLCkeRQzPsv-AVE2Bq-GtsqfjM=.dbe954da-4afb-4f9b-adab-6ed9f3876f60@github.com> References: <8--CxVHS_jclzzN2PWYkI0W3yr7w1al5PSqRdis-PUc=.2f57c378-49cc-40bc-b042-f6aa9bfed07d@github.com> <0NbRtU-LzUgcDU1ZVeLCkeRQzPsv-AVE2Bq-GtsqfjM=.dbe954da-4afb-4f9b-adab-6ed9f3876f60@github.com> Message-ID: On Wed, 28 Aug 2024 04:50:29 GMT, Abhishek Kumar wrote: >> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision: >> >> Review comment fixed : Added different @test tags for different platforms > > test/jdk/javax/swing/JButton/SwingButtonResizeTestWithOpenGL.java line 2: > >> 1: /* >> 2: * Copyright (c) 2015, 2024, Oracle and/or its affiliates. All rights reserved. > > I think the copyright year should be just 2024. Looks like the test is added in the repo first time. > Suggestion: > > * Copyright (c) 2024, Oracle and/or its affiliates. All rights reserved. Yes, the test is added to the repo for the first time, but the test is created from a closed tonga test which existed from 2015 onwards, that's why 2015 also has been given here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20532#discussion_r1734241896 From mvs at openjdk.org Wed Aug 28 08:50:40 2024 From: mvs at openjdk.org (Manukumar V S) Date: Wed, 28 Aug 2024 08:50:40 GMT Subject: RFR: 8338103: Stabilize and open source a Swing OGL ButtonResizeTest [v7] In-Reply-To: <8--CxVHS_jclzzN2PWYkI0W3yr7w1al5PSqRdis-PUc=.2f57c378-49cc-40bc-b042-f6aa9bfed07d@github.com> References: <8--CxVHS_jclzzN2PWYkI0W3yr7w1al5PSqRdis-PUc=.2f57c378-49cc-40bc-b042-f6aa9bfed07d@github.com> Message-ID: <0gZIinB6utUypnqG3nEJagUGbgAog8Ap1CSG2pTa0Hc=.6c21da95-ffcc-4aed-a9e4-46a861bf4182@github.com> > This PR creates a new test by stabilising and open sourcing a closed test. > This test verifies that the OpenGL pipeline does not create artifacts with swing components after window is zoomed to maximum size and then resized back to normal. > This test is run twice, with and without the flags "-Dsun.java2d.opengl=True -Dsun.java2d.opengl.fbobject=false" . > > This is tested(15 times per platform) in all the available mach5 headful platforms and found to be stable. Manukumar V S has updated the pull request incrementally with one additional commit since the last revision: Review comments fixed : Sorted imports, formatting changes, saving images only on failure, compare changed, dispose on EDT ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20532/files - new: https://git.openjdk.org/jdk/pull/20532/files/5694b681..715ddbc0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20532&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20532&range=05-06 Stats: 45 lines in 1 file changed: 14 ins; 21 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/20532.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20532/head:pull/20532 PR: https://git.openjdk.org/jdk/pull/20532 From abhiscxk at openjdk.org Wed Aug 28 09:01:40 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Wed, 28 Aug 2024 09:01:40 GMT Subject: RFR: 8308588: Unnecessary synchronized on GTKStyle#ICONS_MAP can be removed Message-ID: `static final Map ICONS_MAP` is modified only in `static` block. Then [com.sun.java.swing.plaf.gtk.GTKStyle#get](https://github.com/kumarabhi006/jdk/blob/73f7a5f15dbba54a98f3916ff1190520ac07874d/src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKStyle.java#L892) method read from it within `synchronized (ICONS_MAP)` block. As this map is read-only and all its content is initialized in static block we can safely remove synchronized from get call. ------------- Commit messages: - Remove Synchronized block Changes: https://git.openjdk.org/jdk/pull/20741/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20741&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8308588 Stats: 4 lines in 1 file changed: 0 ins; 3 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20741.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20741/head:pull/20741 PR: https://git.openjdk.org/jdk/pull/20741 From abhiscxk at openjdk.org Wed Aug 28 09:05:20 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Wed, 28 Aug 2024 09:05:20 GMT Subject: RFR: 8338103: Stabilize and open source a Swing OGL ButtonResizeTest [v6] In-Reply-To: <0NbRtU-LzUgcDU1ZVeLCkeRQzPsv-AVE2Bq-GtsqfjM=.dbe954da-4afb-4f9b-adab-6ed9f3876f60@github.com> References: <8--CxVHS_jclzzN2PWYkI0W3yr7w1al5PSqRdis-PUc=.2f57c378-49cc-40bc-b042-f6aa9bfed07d@github.com> <0NbRtU-LzUgcDU1ZVeLCkeRQzPsv-AVE2Bq-GtsqfjM=.dbe954da-4afb-4f9b-adab-6ed9f3876f60@github.com> Message-ID: On Wed, 28 Aug 2024 04:55:33 GMT, Abhishek Kumar wrote: >> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision: >> >> Review comment fixed : Added different @test tags for different platforms > > test/jdk/javax/swing/JButton/SwingButtonResizeTestWithOpenGL.java line 133: > >> 131: } else { >> 132: System.out.println("Button focus not gained..."); >> 133: throw new RuntimeException("Can't gain focus on button even after waiting too long.."); > > Crosses the limit of 80 columns here and few more lines below. Please limit it to 80 columns. There are still few lines present which goes beyond the limit of 80 lines. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20532#discussion_r1734289579 From mvs at openjdk.org Wed Aug 28 09:16:48 2024 From: mvs at openjdk.org (Manukumar V S) Date: Wed, 28 Aug 2024 09:16:48 GMT Subject: RFR: 8338103: Stabilize and open source a Swing OGL ButtonResizeTest [v8] In-Reply-To: <8--CxVHS_jclzzN2PWYkI0W3yr7w1al5PSqRdis-PUc=.2f57c378-49cc-40bc-b042-f6aa9bfed07d@github.com> References: <8--CxVHS_jclzzN2PWYkI0W3yr7w1al5PSqRdis-PUc=.2f57c378-49cc-40bc-b042-f6aa9bfed07d@github.com> Message-ID: <6ymYYYTjqTLmBqsRHJ9nApKDh43J_BNTWS5aEnk8PVM=.be95c0d5-9552-4406-8c1a-1998f82e54d7@github.com> > This PR creates a new test by stabilising and open sourcing a closed test. > This test verifies that the OpenGL pipeline does not create artifacts with swing components after window is zoomed to maximum size and then resized back to normal. > This test is run twice, with and without the flags "-Dsun.java2d.opengl=True -Dsun.java2d.opengl.fbobject=false" . > > This is tested(15 times per platform) in all the available mach5 headful platforms and found to be stable. Manukumar V S has updated the pull request incrementally with one additional commit since the last revision: Review comments fixed : Hard wrap at 80 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20532/files - new: https://git.openjdk.org/jdk/pull/20532/files/715ddbc0..8dd8f3a0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20532&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20532&range=06-07 Stats: 55 lines in 1 file changed: 33 ins; 0 del; 22 mod Patch: https://git.openjdk.org/jdk/pull/20532.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20532/head:pull/20532 PR: https://git.openjdk.org/jdk/pull/20532 From abhiscxk at openjdk.org Wed Aug 28 09:16:48 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Wed, 28 Aug 2024 09:16:48 GMT Subject: RFR: 8338103: Stabilize and open source a Swing OGL ButtonResizeTest [v7] In-Reply-To: <0gZIinB6utUypnqG3nEJagUGbgAog8Ap1CSG2pTa0Hc=.6c21da95-ffcc-4aed-a9e4-46a861bf4182@github.com> References: <8--CxVHS_jclzzN2PWYkI0W3yr7w1al5PSqRdis-PUc=.2f57c378-49cc-40bc-b042-f6aa9bfed07d@github.com> <0gZIinB6utUypnqG3nEJagUGbgAog8Ap1CSG2pTa0Hc=.6c21da95-ffcc-4aed-a9e4-46a861bf4182@github.com> Message-ID: <5LKezvUye8JP72IjcApY78fTKjBzzZJINgjGI4zRT2s=.dff4b9a5-c41c-4b01-a634-b488f08037bb@github.com> On Wed, 28 Aug 2024 08:50:40 GMT, Manukumar V S wrote: >> This PR creates a new test by stabilising and open sourcing a closed test. >> This test verifies that the OpenGL pipeline does not create artifacts with swing components after window is zoomed to maximum size and then resized back to normal. >> This test is run twice, with and without the flags "-Dsun.java2d.opengl=True -Dsun.java2d.opengl.fbobject=false" . >> >> This is tested(15 times per platform) in all the available mach5 headful platforms and found to be stable. > > Manukumar V S has updated the pull request incrementally with one additional commit since the last revision: > > Review comments fixed : Sorted imports, formatting changes, saving images only on failure, compare changed, dispose on EDT test/jdk/javax/swing/JButton/SwingButtonResizeTestWithOpenGL.java line 53: > 51: * resized back to normal. The test case simulates this operation using > 52: * a JButton. A file image of the component will be saved before and after > 53: * window resize. The test passes if both button images are the same. Suggestion: * a JButton. A file image of the component will be saved before and after * window resize if test fails. The test passes if both button images are the same. test/jdk/javax/swing/JButton/SwingButtonResizeTestWithOpenGL.java line 187: > 185: Point buttonLoc = buttonLocRef.get(); > 186: System.out.println("Button loc: " + buttonLoc); > 187: bimage = robot.createScreenCapture(new Rectangle(buttonLoc.x, buttonLoc.y, button.getWidth(), button.getHeight())); Can we return the capturedScreen directly? I guess **yes** and then BufferedImage object is not required and can be removed. test/jdk/javax/swing/JButton/SwingButtonResizeTestWithOpenGL.java line 261: > 259: int g2; > 260: int b1; // blue > 261: int b2; Just a suggestion Suggestion: int r1, r2; // red int g1, g2; // green int b1, b2; // blue test/jdk/javax/swing/JButton/SwingButtonResizeTestWithOpenGL.java line 280: > 278: b2 = cm2.getBlue(o2); > 279: > 280: if ((Math.abs(r1 - r2) > threshold) || (Math.abs(g1 - g2) > threshold) || (Math.abs(b1 - b2) > threshold)) { Should we save the absolute difference value as `Math.abs(r1 - r2)` is used multiple times? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20532#discussion_r1734290812 PR Review Comment: https://git.openjdk.org/jdk/pull/20532#discussion_r1734295294 PR Review Comment: https://git.openjdk.org/jdk/pull/20532#discussion_r1734301880 PR Review Comment: https://git.openjdk.org/jdk/pull/20532#discussion_r1734306088 From mvs at openjdk.org Wed Aug 28 09:16:49 2024 From: mvs at openjdk.org (Manukumar V S) Date: Wed, 28 Aug 2024 09:16:49 GMT Subject: RFR: 8338103: Stabilize and open source a Swing OGL ButtonResizeTest [v6] In-Reply-To: References: <8--CxVHS_jclzzN2PWYkI0W3yr7w1al5PSqRdis-PUc=.2f57c378-49cc-40bc-b042-f6aa9bfed07d@github.com> <0NbRtU-LzUgcDU1ZVeLCkeRQzPsv-AVE2Bq-GtsqfjM=.dbe954da-4afb-4f9b-adab-6ed9f3876f60@github.com> Message-ID: On Wed, 28 Aug 2024 09:02:42 GMT, Abhishek Kumar wrote: >> test/jdk/javax/swing/JButton/SwingButtonResizeTestWithOpenGL.java line 133: >> >>> 131: } else { >>> 132: System.out.println("Button focus not gained..."); >>> 133: throw new RuntimeException("Can't gain focus on button even after waiting too long.."); >> >> Crosses the limit of 80 columns here and few more lines below. Please limit it to 80 columns. > > There are still few lines present which goes beyond the limit of 80 lines. Hard wrapped at 80 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20532#discussion_r1734306670 From mvs at openjdk.org Wed Aug 28 09:22:22 2024 From: mvs at openjdk.org (Manukumar V S) Date: Wed, 28 Aug 2024 09:22:22 GMT Subject: RFR: 8338103: Stabilize and open source a Swing OGL ButtonResizeTest [v7] In-Reply-To: <5LKezvUye8JP72IjcApY78fTKjBzzZJINgjGI4zRT2s=.dff4b9a5-c41c-4b01-a634-b488f08037bb@github.com> References: <8--CxVHS_jclzzN2PWYkI0W3yr7w1al5PSqRdis-PUc=.2f57c378-49cc-40bc-b042-f6aa9bfed07d@github.com> <0gZIinB6utUypnqG3nEJagUGbgAog8Ap1CSG2pTa0Hc=.6c21da95-ffcc-4aed-a9e4-46a861bf4182@github.com> <5LKezvUye8JP72IjcApY78fTKjBzzZJINgjGI4zRT2s=.dff4b9a5-c41c-4b01-a634-b488f08037bb@github.com> Message-ID: On Wed, 28 Aug 2024 09:06:23 GMT, Abhishek Kumar wrote: >> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision: >> >> Review comments fixed : Sorted imports, formatting changes, saving images only on failure, compare changed, dispose on EDT > > test/jdk/javax/swing/JButton/SwingButtonResizeTestWithOpenGL.java line 187: > >> 185: Point buttonLoc = buttonLocRef.get(); >> 186: System.out.println("Button loc: " + buttonLoc); >> 187: bimage = robot.createScreenCapture(new Rectangle(buttonLoc.x, buttonLoc.y, button.getWidth(), button.getHeight())); > > Can we return the capturedScreen directly? I guess **yes** and then BufferedImage object is not required and can be removed. The screen captured BufferedImage(bimage) is directly returned now, do you want to change it ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20532#discussion_r1734315191 From mvs at openjdk.org Wed Aug 28 09:31:21 2024 From: mvs at openjdk.org (Manukumar V S) Date: Wed, 28 Aug 2024 09:31:21 GMT Subject: RFR: 8338103: Stabilize and open source a Swing OGL ButtonResizeTest [v7] In-Reply-To: References: <8--CxVHS_jclzzN2PWYkI0W3yr7w1al5PSqRdis-PUc=.2f57c378-49cc-40bc-b042-f6aa9bfed07d@github.com> <0gZIinB6utUypnqG3nEJagUGbgAog8Ap1CSG2pTa0Hc=.6c21da95-ffcc-4aed-a9e4-46a861bf4182@github.com> <5LKezvUye8JP72IjcApY78fTKjBzzZJINgjGI4zRT2s=.dff4b9a5-c41c-4b01-a634-b488f08037bb@github.com> Message-ID: On Wed, 28 Aug 2024 09:19:51 GMT, Manukumar V S wrote: >> test/jdk/javax/swing/JButton/SwingButtonResizeTestWithOpenGL.java line 187: >> >>> 185: Point buttonLoc = buttonLocRef.get(); >>> 186: System.out.println("Button loc: " + buttonLoc); >>> 187: bimage = robot.createScreenCapture(new Rectangle(buttonLoc.x, buttonLoc.y, button.getWidth(), button.getHeight())); >> >> Can we return the capturedScreen directly? I guess **yes** and then BufferedImage object is not required and can be removed. > > The screen captured BufferedImage(bimage) is directly returned now, do you want to change it ? Ohh you are talking about the BufferedImage object, yes it is needed as the screen capture is inside a try block. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20532#discussion_r1734328708 From mvs at openjdk.org Wed Aug 28 09:35:05 2024 From: mvs at openjdk.org (Manukumar V S) Date: Wed, 28 Aug 2024 09:35:05 GMT Subject: RFR: 8338103: Stabilize and open source a Swing OGL ButtonResizeTest [v9] In-Reply-To: <8--CxVHS_jclzzN2PWYkI0W3yr7w1al5PSqRdis-PUc=.2f57c378-49cc-40bc-b042-f6aa9bfed07d@github.com> References: <8--CxVHS_jclzzN2PWYkI0W3yr7w1al5PSqRdis-PUc=.2f57c378-49cc-40bc-b042-f6aa9bfed07d@github.com> Message-ID: > This PR creates a new test by stabilising and open sourcing a closed test. > This test verifies that the OpenGL pipeline does not create artifacts with swing components after window is zoomed to maximum size and then resized back to normal. > This test is run twice, with and without the flags "-Dsun.java2d.opengl=True -Dsun.java2d.opengl.fbobject=false" . > > This is tested(15 times per platform) in all the available mach5 headful platforms and found to be stable. Manukumar V S has updated the pull request incrementally with one additional commit since the last revision: Review comments fixed : Created abs variables, formatting changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20532/files - new: https://git.openjdk.org/jdk/pull/20532/files/8dd8f3a0..539bb5bf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20532&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20532&range=07-08 Stats: 16 lines in 1 file changed: 4 ins; 4 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/20532.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20532/head:pull/20532 PR: https://git.openjdk.org/jdk/pull/20532 From abhiscxk at openjdk.org Wed Aug 28 09:38:24 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Wed, 28 Aug 2024 09:38:24 GMT Subject: RFR: 8338153: java/awt/Checkbox/CheckboxCheckerScalingTest.java test failed on linux machine In-Reply-To: References: Message-ID: On Tue, 27 Aug 2024 06:04:47 GMT, Tejesh R wrote: > Test failed intermittently on particular host. Though analysis pointed out to a test frame at left top on that host, I've updated the test for further stabilizing it. Two things done here: > 1. Move the frame to center of the screen rather than left top. > 2. Added tolerance checks for color comparison - this is based on analysis reports where the image didn't had exact black color which is supposed to be. So like other test cases, providing some tolerance for comparison. test/jdk/java/awt/Checkbox/CheckboxCheckerScalingTest.java line 78: > 76: for (int j = 0; j < imageAfterChecked.getWidth(); j++) { > 77: Color pixelColor = new Color(imageAfterChecked.getRGB(i, j)); > 78: if (compareColor(pixelColor)) { Current pixel comparison suggests that the test passes even if one pixel satisfies the condition. This may give some false positive result. Is it possible to test all pixel and then check the number of pixels passed against total number of pixels compared and if it is more than some percentage value ( may be ~85-90) then return true otherwise false. This may lead to avoid the tolerance check if sufficient number of pixels are exactly black in color. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20723#discussion_r1734337419 From abhiscxk at openjdk.org Wed Aug 28 09:42:20 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Wed, 28 Aug 2024 09:42:20 GMT Subject: RFR: 8338103: Stabilize and open source a Swing OGL ButtonResizeTest [v7] In-Reply-To: References: <8--CxVHS_jclzzN2PWYkI0W3yr7w1al5PSqRdis-PUc=.2f57c378-49cc-40bc-b042-f6aa9bfed07d@github.com> <0gZIinB6utUypnqG3nEJagUGbgAog8Ap1CSG2pTa0Hc=.6c21da95-ffcc-4aed-a9e4-46a861bf4182@github.com> <5LKezvUye8JP72IjcApY78fTKjBzzZJINgjGI4zRT2s=.dff4b9a5-c41c-4b01-a634-b488f08037bb@github.com> Message-ID: On Wed, 28 Aug 2024 09:29:09 GMT, Manukumar V S wrote: >> The screen captured BufferedImage(bimage) is directly returned now, do you want to change it ? > > Ohh you are talking about the BufferedImage object, yes it is needed as the screen capture is inside a try block. I meant to say -- Can we return the captured screen like.. `return robot.createScreenCapture(new Rectangle(buttonLoc.x, buttonLoc.y, button.getWidth(), button.getHeight()));` If it is possible probably `BufferedImage bimage` object can be removed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20532#discussion_r1734343069 From mvs at openjdk.org Wed Aug 28 09:48:44 2024 From: mvs at openjdk.org (Manukumar V S) Date: Wed, 28 Aug 2024 09:48:44 GMT Subject: RFR: 8338103: Stabilize and open source a Swing OGL ButtonResizeTest [v10] In-Reply-To: <8--CxVHS_jclzzN2PWYkI0W3yr7w1al5PSqRdis-PUc=.2f57c378-49cc-40bc-b042-f6aa9bfed07d@github.com> References: <8--CxVHS_jclzzN2PWYkI0W3yr7w1al5PSqRdis-PUc=.2f57c378-49cc-40bc-b042-f6aa9bfed07d@github.com> Message-ID: > This PR creates a new test by stabilising and open sourcing a closed test. > This test verifies that the OpenGL pipeline does not create artifacts with swing components after window is zoomed to maximum size and then resized back to normal. > This test is run twice, with and without the flags "-Dsun.java2d.opengl=True -Dsun.java2d.opengl.fbobject=false" . > > This is tested(15 times per platform) in all the available mach5 headful platforms and found to be stable. Manukumar V S has updated the pull request incrementally with one additional commit since the last revision: Review comments fixed : Removed unwanted variable BufferedImage bimage ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20532/files - new: https://git.openjdk.org/jdk/pull/20532/files/539bb5bf..69f202aa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20532&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20532&range=08-09 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20532.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20532/head:pull/20532 PR: https://git.openjdk.org/jdk/pull/20532 From mvs at openjdk.org Wed Aug 28 09:48:44 2024 From: mvs at openjdk.org (Manukumar V S) Date: Wed, 28 Aug 2024 09:48:44 GMT Subject: RFR: 8338103: Stabilize and open source a Swing OGL ButtonResizeTest [v7] In-Reply-To: References: <8--CxVHS_jclzzN2PWYkI0W3yr7w1al5PSqRdis-PUc=.2f57c378-49cc-40bc-b042-f6aa9bfed07d@github.com> <0gZIinB6utUypnqG3nEJagUGbgAog8Ap1CSG2pTa0Hc=.6c21da95-ffcc-4aed-a9e4-46a861bf4182@github.com> <5LKezvUye8JP72IjcApY78fTKjBzzZJINgjGI4zRT2s=.dff4b9a5-c41c-4b01-a634-b488f08037bb@github.com> Message-ID: On Wed, 28 Aug 2024 09:39:13 GMT, Abhishek Kumar wrote: >> Ohh you are talking about the BufferedImage object, yes it is needed as the screen capture is inside a try block. > > I meant to say -- Can we return the captured screen like.. > > `return robot.createScreenCapture(new Rectangle(buttonLoc.x, buttonLoc.y, button.getWidth(), button.getHeight()));` > > If it is possible probably `BufferedImage bimage` object can be removed. Done, removed it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20532#discussion_r1734351830 From tr at openjdk.org Wed Aug 28 09:52:22 2024 From: tr at openjdk.org (Tejesh R) Date: Wed, 28 Aug 2024 09:52:22 GMT Subject: RFR: 8338153: java/awt/Checkbox/CheckboxCheckerScalingTest.java test failed on linux machine In-Reply-To: References: Message-ID: On Wed, 28 Aug 2024 09:35:13 GMT, Abhishek Kumar wrote: >> Test failed intermittently on particular host. Though analysis pointed out to a test frame at left top on that host, I've updated the test for further stabilizing it. Two things done here: >> 1. Move the frame to center of the screen rather than left top. >> 2. Added tolerance checks for color comparison - this is based on analysis reports where the image didn't had exact black color which is supposed to be. So like other test cases, providing some tolerance for comparison. > > test/jdk/java/awt/Checkbox/CheckboxCheckerScalingTest.java line 78: > >> 76: for (int j = 0; j < imageAfterChecked.getWidth(); j++) { >> 77: Color pixelColor = new Color(imageAfterChecked.getRGB(i, j)); >> 78: if (compareColor(pixelColor)) { > > Current pixel comparison suggests that the test passes even if one pixel satisfies the condition. This may give some false positive result. > Is it possible to test all pixel and then check the number of pixels passed against total number of pixels compared and if it is more than some percentage value ( may be ~85-90) then return true otherwise false. > > This may lead to avoid the tolerance check if sufficient number of pixels are exactly black in color. Checker mark will be less than 50% of the image. The image captured is around 8x8 pixels, in that we hardly can find 10% of black color (though with tolerance of 5-10 value). Since we are making decisions based on black color which is the actual checker color with tolerance, checking for one such match would be fine. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20723#discussion_r1734357861 From ihse at openjdk.org Wed Aug 28 11:28:19 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 28 Aug 2024 11:28:19 GMT Subject: RFR: 8339120: Use more fine-granular gcc unused warnings In-Reply-To: References: Message-ID: On Wed, 28 Aug 2024 06:38:48 GMT, Kim Barrett wrote: > We should make a similar set of changes for clang, though doing that in a separate proposal is good. Is there a JBS issue for that yet? Yes, we should. I am 80% done with that patch, but I have not yet opened a JBS ticket. Will do that now. > make/autoconf/flags-cflags.m4 line 239: > >> 237: # Additional warnings that are not activated by -Wall and -Wextra >> 238: WARNINGS_ENABLE_ADDITIONAL="-Wpointer-arith -Wreturn-type -Wsign-compare \ >> 239: -Wtrampolines -Wundef -Wunused-const-variable -Wunused-function \ > > I think we don't want `-Wunused-const-variable=2` (eqv. `-Wunused-const-variable`) for C++ > code. Recall that C++ const variables default to internal linkage (e.g. implicitly static). It's normal > to have a non-local constant in a header file that isn't used by every translation unit. For C++ use > `-Wunused-const-variable=1`. I think doing this might eliminate the need for disabling this warning > in a bunch of other places in this PR. Good point, I'll try that. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20733#issuecomment-2315053230 PR Review Comment: https://git.openjdk.org/jdk/pull/20733#discussion_r1734501680 From ihse at openjdk.org Wed Aug 28 12:34:28 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 28 Aug 2024 12:34:28 GMT Subject: RFR: 8339120: Use more fine-granular gcc unused warnings [v2] In-Reply-To: References: Message-ID: > Currently, we issue -Wno-unused for all files in gcc, which is a rather big sledgehammer to get rid of some warnings that proliferate in a few areas of the build. > > We should instead leave -Wunused turned on (as done by -Wall) and use a much more fine-grained approach to disabling specific warnings in specific files or libraries. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Use -Wunused-const-variable=1 instead ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20733/files - new: https://git.openjdk.org/jdk/pull/20733/files/7d4f1380..27cd3b06 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20733&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20733&range=00-01 Stats: 48 lines in 5 files changed: 8 ins; 1 del; 39 mod Patch: https://git.openjdk.org/jdk/pull/20733.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20733/head:pull/20733 PR: https://git.openjdk.org/jdk/pull/20733 From ihse at openjdk.org Wed Aug 28 12:34:29 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 28 Aug 2024 12:34:29 GMT Subject: RFR: 8339120: Use more fine-granular gcc unused warnings [v2] In-Reply-To: References: Message-ID: On Wed, 28 Aug 2024 11:26:01 GMT, Magnus Ihse Bursie wrote: >> make/autoconf/flags-cflags.m4 line 239: >> >>> 237: # Additional warnings that are not activated by -Wall and -Wextra >>> 238: WARNINGS_ENABLE_ADDITIONAL="-Wpointer-arith -Wreturn-type -Wsign-compare \ >>> 239: -Wtrampolines -Wundef -Wunused-const-variable -Wunused-function \ >> >> I think we don't want `-Wunused-const-variable=2` (eqv. `-Wunused-const-variable`) for C++ >> code. Recall that C++ const variables default to internal linkage (e.g. implicitly static). It's normal >> to have a non-local constant in a header file that isn't used by every translation unit. For C++ use >> `-Wunused-const-variable=1`. I think doing this might eliminate the need for disabling this warning >> in a bunch of other places in this PR. > > Good point, I'll try that. It turned out to be sort-of okay-ish. I explicitly listed like 6 or so per-file exclusions in Hotspot (even though my normal cutoff for just setting a component-wide exclude is 3-4) since it seems that you will want to look at and fix those. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20733#discussion_r1734588979 From ihse at openjdk.org Wed Aug 28 12:47:19 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 28 Aug 2024 12:47:19 GMT Subject: RFR: 8338768: Introduce runtime lookup to check for static builds [v2] In-Reply-To: References: <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com> Message-ID: On Tue, 27 Aug 2024 23:15:03 GMT, Jiangli Zhou wrote: >> And the discussion whether the checks are made "dynamically" or "statically" is too simplified to be really helpful. >> >> Currently, we compile two sets of all object files, with slightly different compiler arguments, one for dynamic libraries and one for static libraries. Files that are doing things differently for these two modes have an #ifdef, so the alternative way of doing things are not included in the object file. >> >> In your branch, you still have a separate compilation of all files for static builds, but you also try to figure out through various means (which involves jumping through some hoops to get the bootstrapping right) if this is a static build or a dynamic build. In a way, one could argue that this is just worse than the current solution, since you are still recompiling all files separately for static libraries so you could "know" at build time if you are static or not. >> >> What I am trying to do is to get to a point where we can compile almost all files just once, and then have two trivially small files that are compiled twice, with just a different value of a define that makes the difference. To propagate this information to all other object files, they need to call the function provided in this object file. So, is it then a "build time" lookup or a "runtime lookup", or a "static lookup" vs "dynamic lookup"? The semantics does not really matter. The whole point is that the difference in build is reduced to an absolute minimum. Sure, this single "lookup" function could be created more like the way you are doing in your branch to try to figure this out without the help of the build system, but there is really no point in that. This is a simple and elegant solution. > > @magicus please also specify contributor properly to so it's clear part of the change is based on/extracted from https://github.com/openjdk/leyden/tree/hermetic-java-runtime. @jianglizhou Are there any other authors on the `hermetic-java-runtime` branch that should be credited? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20666#issuecomment-2315222006 From ihse at openjdk.org Wed Aug 28 13:02:55 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 28 Aug 2024 13:02:55 GMT Subject: RFR: 8339120: Use more fine-granular gcc unused warnings [v3] In-Reply-To: References: Message-ID: <8Z0-2COIwtT2yDoSU8DkeNh2NbBOg7LZhFCEqtJzLOI=.83df3ab0-da2f-4b81-ab72-6091924ffdc1@github.com> > Currently, we issue -Wno-unused for all files in gcc, which is a rather big sledgehammer to get rid of some warnings that proliferate in a few areas of the build. > > We should instead leave -Wunused turned on (as done by -Wall) and use a much more fine-grained approach to disabling specific warnings in specific files or libraries. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Fix aarch54 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20733/files - new: https://git.openjdk.org/jdk/pull/20733/files/27cd3b06..7d3bf0d7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20733&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20733&range=01-02 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20733.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20733/head:pull/20733 PR: https://git.openjdk.org/jdk/pull/20733 From kbarrett at openjdk.org Wed Aug 28 13:38:20 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 28 Aug 2024 13:38:20 GMT Subject: RFR: 8339120: Use more fine-granular gcc unused warnings [v3] In-Reply-To: <8Z0-2COIwtT2yDoSU8DkeNh2NbBOg7LZhFCEqtJzLOI=.83df3ab0-da2f-4b81-ab72-6091924ffdc1@github.com> References: <8Z0-2COIwtT2yDoSU8DkeNh2NbBOg7LZhFCEqtJzLOI=.83df3ab0-da2f-4b81-ab72-6091924ffdc1@github.com> Message-ID: On Wed, 28 Aug 2024 13:02:55 GMT, Magnus Ihse Bursie wrote: >> Currently, we issue -Wno-unused for all files in gcc, which is a rather big sledgehammer to get rid of some warnings that proliferate in a few areas of the build. >> >> We should instead leave -Wunused turned on (as done by -Wall) and use a much more fine-grained approach to disabling specific warnings in specific files or libraries. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Fix aarch54 Changes requested by kbarrett (Reviewer). make/modules/java.desktop/lib/ClientLibraries.gmk line 284: > 282: > 283: ifeq ($(USE_EXTERNAL_HARFBUZZ), true) > 284: LIBFONTMANAGER_EXTRA_SRC = I think this 3space -> 2space indentation change shouldn't be part of this PR, esp. since 3space is used in other parts of this file. ------------- PR Review: https://git.openjdk.org/jdk/pull/20733#pullrequestreview-2266289452 PR Review Comment: https://git.openjdk.org/jdk/pull/20733#discussion_r1734691445 From erikj at openjdk.org Wed Aug 28 13:41:21 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 28 Aug 2024 13:41:21 GMT Subject: RFR: 8338768: Introduce runtime lookup to check for static builds [v2] In-Reply-To: References: <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com> Message-ID: <9YbB0gtUIqE5SAmbAMmVC_S8wNDa9kKPVop6uvKUxCY=.e000ded5-fcb8-42f9-bde7-97cd1f52ecf9@github.com> On Mon, 26 Aug 2024 02:07:39 GMT, David Holmes wrote: > I understand the cost overhead experienced by any individual Java run may be lost in the noise, but it still impacts every single Java run just to save some time/resources for the handful of builders of statically linked VMs. I am not a fan. I understand your stance and it's a fair principle. My opinion is that we need to weigh the pros and cons with more nuance. We are often in situations where have to weigh runtime performance against things like (openjdk) developer convenience, maintainability and build performance. As we are building the Java platform, we often give up a lot to eek out the last drops of runtime performance, but we sure aren't always making that tradeoff in favor of performance. As a very clear example, we could enable LTO (Link Time Optimization), which would likely give a measurable (though likely small) performance improvement at runtime, at the cost of a big increase in build time, but we haven't, because we don't think the tradeoff is worth it. My take on the current issue is that the potential savings in build time is easily comparable to using LTO or not, while the difference in runtime performance is likely different by orders of magnitudes. My point is that we make these kinds of calls quite often. So in this case, my take is that even if the size difference in the number of people impacted is big, I think the size difference in the actual impact more than makes up for it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20666#issuecomment-2315348318 From ihse at openjdk.org Wed Aug 28 15:01:33 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 28 Aug 2024 15:01:33 GMT Subject: RFR: 8339120: Use more fine-granular gcc unused warnings [v4] In-Reply-To: References: Message-ID: > Currently, we issue -Wno-unused for all files in gcc, which is a rather big sledgehammer to get rid of some warnings that proliferate in a few areas of the build. > > We should instead leave -Wunused turned on (as done by -Wall) and use a much more fine-grained approach to disabling specific warnings in specific files or libraries. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Fix ppc64 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20733/files - new: https://git.openjdk.org/jdk/pull/20733/files/7d3bf0d7..69a6b308 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20733&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20733&range=02-03 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20733.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20733/head:pull/20733 PR: https://git.openjdk.org/jdk/pull/20733 From ihse at openjdk.org Wed Aug 28 15:12:34 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 28 Aug 2024 15:12:34 GMT Subject: RFR: 8339120: Use more fine-granular gcc unused warnings [v5] In-Reply-To: References: Message-ID: > Currently, we issue -Wno-unused for all files in gcc, which is a rather big sledgehammer to get rid of some warnings that proliferate in a few areas of the build. > > We should instead leave -Wunused turned on (as done by -Wall) and use a much more fine-grained approach to disabling specific warnings in specific files or libraries. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Fix s390x build ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20733/files - new: https://git.openjdk.org/jdk/pull/20733/files/69a6b308..f4bdce72 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20733&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20733&range=03-04 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20733.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20733/head:pull/20733 PR: https://git.openjdk.org/jdk/pull/20733 From ihse at openjdk.org Wed Aug 28 15:12:34 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 28 Aug 2024 15:12:34 GMT Subject: RFR: 8339120: Use more fine-granular gcc unused warnings [v5] In-Reply-To: References: Message-ID: On Wed, 28 Aug 2024 12:29:36 GMT, Magnus Ihse Bursie wrote: >> Good point, I'll try that. > > It turned out to be sort-of okay-ish. I explicitly listed like 6 or so per-file exclusions in Hotspot (even though my normal cutoff for just setting a component-wide exclude is 3-4) since it seems that you will want to look at and fix those. Actually, it was probably a bad idea. I've been chasing platform-specific build failures for the last hour or so. :( But now at least it is done. I hope you guys can use this to actually fix the problems so it was worth it. ;-) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20733#discussion_r1734869178 From ihse at openjdk.org Wed Aug 28 15:12:34 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 28 Aug 2024 15:12:34 GMT Subject: RFR: 8339120: Use more fine-granular gcc unused warnings [v3] In-Reply-To: References: <8Z0-2COIwtT2yDoSU8DkeNh2NbBOg7LZhFCEqtJzLOI=.83df3ab0-da2f-4b81-ab72-6091924ffdc1@github.com> Message-ID: On Wed, 28 Aug 2024 13:35:19 GMT, Kim Barrett wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix aarch54 > > make/modules/java.desktop/lib/ClientLibraries.gmk line 284: > >> 282: >> 283: ifeq ($(USE_EXTERNAL_HARFBUZZ), true) >> 284: LIBFONTMANAGER_EXTRA_SRC = > > I think this 3space -> 2space indentation change shouldn't be part of this PR, esp. since 3space is > used in other parts of this file. Really? That is sooo broken. :( But fair enough, I'll do a separate PR on the broken indentation. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20733#discussion_r1734867997 From kbarrett at openjdk.org Wed Aug 28 15:17:52 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 28 Aug 2024 15:17:52 GMT Subject: RFR: 8339120: Use more fine-granular gcc unused warnings [v6] In-Reply-To: References: Message-ID: On Wed, 28 Aug 2024 15:15:03 GMT, Magnus Ihse Bursie wrote: >> Currently, we issue -Wno-unused for all files in gcc, which is a rather big sledgehammer to get rid of some warnings that proliferate in a few areas of the build. >> >> We should instead leave -Wunused turned on (as done by -Wall) and use a much more fine-grained approach to disabling specific warnings in specific files or libraries. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Roll back indentation fix Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20733#pullrequestreview-2266590446 From ihse at openjdk.org Wed Aug 28 15:17:52 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 28 Aug 2024 15:17:52 GMT Subject: RFR: 8339120: Use more fine-granular gcc unused warnings [v6] In-Reply-To: References: Message-ID: > Currently, we issue -Wno-unused for all files in gcc, which is a rather big sledgehammer to get rid of some warnings that proliferate in a few areas of the build. > > We should instead leave -Wunused turned on (as done by -Wall) and use a much more fine-grained approach to disabling specific warnings in specific files or libraries. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Roll back indentation fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20733/files - new: https://git.openjdk.org/jdk/pull/20733/files/f4bdce72..88654b97 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20733&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20733&range=04-05 Stats: 35 lines in 1 file changed: 0 ins; 0 del; 35 mod Patch: https://git.openjdk.org/jdk/pull/20733.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20733/head:pull/20733 PR: https://git.openjdk.org/jdk/pull/20733 From abhiscxk at openjdk.org Wed Aug 28 15:19:19 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Wed, 28 Aug 2024 15:19:19 GMT Subject: RFR: 8338153: java/awt/Checkbox/CheckboxCheckerScalingTest.java test failed on linux machine In-Reply-To: References: Message-ID: On Wed, 28 Aug 2024 09:49:54 GMT, Tejesh R wrote: >> test/jdk/java/awt/Checkbox/CheckboxCheckerScalingTest.java line 78: >> >>> 76: for (int j = 0; j < imageAfterChecked.getWidth(); j++) { >>> 77: Color pixelColor = new Color(imageAfterChecked.getRGB(i, j)); >>> 78: if (compareColor(pixelColor)) { >> >> Current pixel comparison suggests that the test passes even if one pixel satisfies the condition. This may give some false positive result. >> Is it possible to test all pixel and then check the number of pixels passed against total number of pixels compared and if it is more than some percentage value ( may be ~85-90) then return true otherwise false. >> >> This may lead to avoid the tolerance check if sufficient number of pixels are exactly black in color. > > Checker mark will be less than 50% of the image. The image captured is around 8x8 pixels, in that we hardly can find 10% of black color (though with tolerance of 5-10 value). Since we are making decisions based on black color which is the actual checker color with tolerance, checking for one such match would be fine. Ok. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20723#discussion_r1734879957 From abhiscxk at openjdk.org Wed Aug 28 15:29:23 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Wed, 28 Aug 2024 15:29:23 GMT Subject: RFR: 8338153: java/awt/Checkbox/CheckboxCheckerScalingTest.java test failed on linux machine In-Reply-To: References: Message-ID: On Tue, 27 Aug 2024 06:04:47 GMT, Tejesh R wrote: > Test failed intermittently on particular host. Though analysis pointed out to a test frame at left top on that host, I've updated the test for further stabilizing it. Two things done here: > 1. Move the frame to center of the screen rather than left top. > 2. Added tolerance checks for color comparison - this is based on analysis reports where the image didn't had exact black color which is supposed to be. So like other test cases, providing some tolerance for comparison. Ran the updated test on my local machine multiple times and it passed always. Looks good to me. ------------- Marked as reviewed by abhiscxk (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20723#pullrequestreview-2266620836 From jwaters at openjdk.org Wed Aug 28 15:34:20 2024 From: jwaters at openjdk.org (Julian Waters) Date: Wed, 28 Aug 2024 15:34:20 GMT Subject: RFR: 8339120: Use more fine-granular gcc unused warnings [v6] In-Reply-To: References: Message-ID: On Wed, 28 Aug 2024 15:17:52 GMT, Magnus Ihse Bursie wrote: >> Currently, we issue -Wno-unused for all files in gcc, which is a rather big sledgehammer to get rid of some warnings that proliferate in a few areas of the build. >> >> We should instead leave -Wunused turned on (as done by -Wall) and use a much more fine-grained approach to disabling specific warnings in specific files or libraries. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Roll back indentation fix Marked as reviewed by jwaters (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20733#pullrequestreview-2266632564 From kcr at openjdk.org Wed Aug 28 16:50:22 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 28 Aug 2024 16:50:22 GMT Subject: RFR: 8190329: [macos] Swing InterOp Platform.exit() crash [v2] In-Reply-To: References: Message-ID: On Wed, 28 Aug 2024 02:19:08 GMT, Prasanta Sadhukhan wrote: >> The testcase calls Platform.exit before the dialog is made visible but >> on macOS, JavaFX takes over the AppKit thread and uses that as the FX application thread. As part of the FX platform shutdown process, it detaches that thread from the JVM. This means that the AppKit thread is no longer available to Java processes >> so AWT crashes when it ties to access appkit thread. >> Fix is made to check if the thread has been detached for move-resize notification event before proceeding.. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Reattach thread if AWT is the owner of NSApplication I tested it with the existing JavaFX release and there is no more crash. I also instrumented the code and it does the right thing in both the case of AWT as owner and FX as owner, although in the latter case, it assumes it can cache the env for the first call to JNI that happens before the `ApplicationDelegate` is initialized. You might consider flipping the default and don't start caching it until the ApplicationDelegate says that AWT is the owner. src/java.desktop/macosx/native/libawt_lwawt/awt/ApplicationDelegate.m line 128: > 126: [ThreadUtilities setApplicationOwner:NO]; > 127: return nil; > 128: } If you flip the default, then you need to set it to YES here: [ThreadUtilities setApplicationOwner:YES]; (this might be best anyway, since then you will always set the flag) src/java.desktop/macosx/native/libosxapp/ThreadUtilities.m line 34: > 32: // The following must be named "jvm", as there are extern references to it in AWT > 33: JavaVM *jvm = NULL; > 34: static BOOL isNSApplicationOwner = YES; One possible suggestion would be to flip the default to `NO`, so as not to cache the env until we know we are the owner. ------------- Marked as reviewed by kcr (Author). PR Review: https://git.openjdk.org/jdk/pull/20688#pullrequestreview-2266788505 PR Review Comment: https://git.openjdk.org/jdk/pull/20688#discussion_r1734999212 PR Review Comment: https://git.openjdk.org/jdk/pull/20688#discussion_r1734998040 From jiangli at openjdk.org Wed Aug 28 17:19:23 2024 From: jiangli at openjdk.org (Jiangli Zhou) Date: Wed, 28 Aug 2024 17:19:23 GMT Subject: RFR: 8338768: Introduce runtime lookup to check for static builds [v2] In-Reply-To: References: <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com> Message-ID: On Tue, 27 Aug 2024 23:15:03 GMT, Jiangli Zhou wrote: >> And the discussion whether the checks are made "dynamically" or "statically" is too simplified to be really helpful. >> >> Currently, we compile two sets of all object files, with slightly different compiler arguments, one for dynamic libraries and one for static libraries. Files that are doing things differently for these two modes have an #ifdef, so the alternative way of doing things are not included in the object file. >> >> In your branch, you still have a separate compilation of all files for static builds, but you also try to figure out through various means (which involves jumping through some hoops to get the bootstrapping right) if this is a static build or a dynamic build. In a way, one could argue that this is just worse than the current solution, since you are still recompiling all files separately for static libraries so you could "know" at build time if you are static or not. >> >> What I am trying to do is to get to a point where we can compile almost all files just once, and then have two trivially small files that are compiled twice, with just a different value of a define that makes the difference. To propagate this information to all other object files, they need to call the function provided in this object file. So, is it then a "build time" lookup or a "runtime lookup", or a "static lookup" vs "dynamic lookup"? The semantics does not really matter. The whole point is that the difference in build is reduced to an absolute minimum. Sure, this single "lookup" function could be created more like the way you are doing in your branch to try to figure this out without the help of the build system, but there is really no point in that. This is a simple and elegant solution. > > @magicus please also specify contributor properly to so it's clear part of the change is based on/extracted from https://github.com/openjdk/leyden/tree/hermetic-java-runtime. > @jianglizhou Are there any other authors on the `hermetic-java-runtime` branch that should be credited? For any commits in https://github.com/openjdk/leyden/compare/master...hermetic-java-runtime contributed by other contributor(s) or additional contributor(s), I documented that the commit message (e.g. https://github.com/openjdk/leyden/commit/4faa3a964ec550e410c741048c7e0ed99ac64b52). The current PR is related to the following. Please refer to those commit messages. - https://github.com/openjdk/leyden/commit/7d75a7f4d6aa020b7580fbbf660b2b3e3a41b274 - https://github.com/openjdk/leyden/commit/22d8c439157b61acdfe99090d39f91c09388b1b1 ------------- PR Comment: https://git.openjdk.org/jdk/pull/20666#issuecomment-2315882065 From abhiscxk at openjdk.org Wed Aug 28 17:42:21 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Wed, 28 Aug 2024 17:42:21 GMT Subject: RFR: 8338103: Stabilize and open source a Swing OGL ButtonResizeTest [v10] In-Reply-To: References: <8--CxVHS_jclzzN2PWYkI0W3yr7w1al5PSqRdis-PUc=.2f57c378-49cc-40bc-b042-f6aa9bfed07d@github.com> Message-ID: On Wed, 28 Aug 2024 09:48:44 GMT, Manukumar V S wrote: >> This PR creates a new test by stabilising and open sourcing a closed test. >> This test verifies that the OpenGL pipeline does not create artifacts with swing components after window is zoomed to maximum size and then resized back to normal. >> This test is run twice, with and without the flags "-Dsun.java2d.opengl=True -Dsun.java2d.opengl.fbobject=false" . >> >> This is tested(15 times per platform) in all the available mach5 headful platforms and found to be stable. > > Manukumar V S has updated the pull request incrementally with one additional commit since the last revision: > > Review comments fixed : Removed unwanted variable BufferedImage bimage Changes look good to me now. Ran the test on my local mac machine and test passed. ------------- Marked as reviewed by abhiscxk (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20532#pullrequestreview-2266899324 From duke at openjdk.org Wed Aug 28 17:46:22 2024 From: duke at openjdk.org (duke) Date: Wed, 28 Aug 2024 17:46:22 GMT Subject: RFR: 8338103: Stabilize and open source a Swing OGL ButtonResizeTest [v10] In-Reply-To: References: <8--CxVHS_jclzzN2PWYkI0W3yr7w1al5PSqRdis-PUc=.2f57c378-49cc-40bc-b042-f6aa9bfed07d@github.com> Message-ID: <8lmDoF7dILFm9cTPmPIu0wUA7pkl6_5tDsqgO7JdolY=.7ac89fb8-f9b6-441d-a391-800ae92bb371@github.com> On Wed, 28 Aug 2024 09:48:44 GMT, Manukumar V S wrote: >> This PR creates a new test by stabilising and open sourcing a closed test. >> This test verifies that the OpenGL pipeline does not create artifacts with swing components after window is zoomed to maximum size and then resized back to normal. >> This test is run twice, with and without the flags "-Dsun.java2d.opengl=True -Dsun.java2d.opengl.fbobject=false" . >> >> This is tested(15 times per platform) in all the available mach5 headful platforms and found to be stable. > > Manukumar V S has updated the pull request incrementally with one additional commit since the last revision: > > Review comments fixed : Removed unwanted variable BufferedImage bimage @openjdk[bot] Your change (at version 69f202aa81e0b2f6a66348608ab720d8e17cdc53) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20532#issuecomment-2315928658 From prr at openjdk.org Wed Aug 28 17:57:25 2024 From: prr at openjdk.org (Phil Race) Date: Wed, 28 Aug 2024 17:57:25 GMT Subject: RFR: 8338103: Stabilize and open source a Swing OGL ButtonResizeTest [v10] In-Reply-To: References: <8--CxVHS_jclzzN2PWYkI0W3yr7w1al5PSqRdis-PUc=.2f57c378-49cc-40bc-b042-f6aa9bfed07d@github.com> Message-ID: On Wed, 28 Aug 2024 09:48:44 GMT, Manukumar V S wrote: >> This PR creates a new test by stabilising and open sourcing a closed test. >> This test verifies that the OpenGL pipeline does not create artifacts with swing components after window is zoomed to maximum size and then resized back to normal. >> This test is run twice, with and without the flags "-Dsun.java2d.opengl=True -Dsun.java2d.opengl.fbobject=false" . >> >> This is tested(15 times per platform) in all the available mach5 headful platforms and found to be stable. > > Manukumar V S has updated the pull request incrementally with one additional commit since the last revision: > > Review comments fixed : Removed unwanted variable BufferedImage bimage Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20532#pullrequestreview-2266925383 From mvs at openjdk.org Wed Aug 28 17:57:26 2024 From: mvs at openjdk.org (Manukumar V S) Date: Wed, 28 Aug 2024 17:57:26 GMT Subject: Integrated: 8338103: Stabilize and open source a Swing OGL ButtonResizeTest In-Reply-To: <8--CxVHS_jclzzN2PWYkI0W3yr7w1al5PSqRdis-PUc=.2f57c378-49cc-40bc-b042-f6aa9bfed07d@github.com> References: <8--CxVHS_jclzzN2PWYkI0W3yr7w1al5PSqRdis-PUc=.2f57c378-49cc-40bc-b042-f6aa9bfed07d@github.com> Message-ID: <3dv6J7OaecyV411cjxqq9neDmDzLd9wS3PklKSlG8aA=.5e385368-5d0c-4067-94f5-43aee87fd0cb@github.com> On Fri, 9 Aug 2024 18:45:18 GMT, Manukumar V S wrote: > This PR creates a new test by stabilising and open sourcing a closed test. > This test verifies that the OpenGL pipeline does not create artifacts with swing components after window is zoomed to maximum size and then resized back to normal. > This test is run twice, with and without the flags "-Dsun.java2d.opengl=True -Dsun.java2d.opengl.fbobject=false" . > > This is tested(15 times per platform) in all the available mach5 headful platforms and found to be stable. This pull request has now been integrated. Changeset: 3d49fb8a Author: Manukumar V S URL: https://git.openjdk.org/jdk/commit/3d49fb8a17ceec6e23595bc8affc89765899f72b Stats: 352 lines in 1 file changed: 352 ins; 0 del; 0 mod 8338103: Stabilize and open source a Swing OGL ButtonResizeTest Reviewed-by: abhiscxk, prr, tr ------------- PR: https://git.openjdk.org/jdk/pull/20532 From dnguyen at openjdk.org Wed Aug 28 18:20:20 2024 From: dnguyen at openjdk.org (Damon Nguyen) Date: Wed, 28 Aug 2024 18:20:20 GMT Subject: RFR: 8308588: Unnecessary synchronized on GTKStyle#ICONS_MAP can be removed In-Reply-To: References: Message-ID: On Wed, 28 Aug 2024 08:54:39 GMT, Abhishek Kumar wrote: > `static final Map ICONS_MAP` is modified only in `static` block. Then [com.sun.java.swing.plaf.gtk.GTKStyle#get](https://github.com/kumarabhi006/jdk/blob/73f7a5f15dbba54a98f3916ff1190520ac07874d/src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKStyle.java#L892) method read from it within `synchronized (ICONS_MAP)` block. As this map is read-only and all its content is initialized in static block we can safely remove synchronized from get call. I remember simply testing this change when originally triaging this. How did you test this change for stability? ------------- PR Review: https://git.openjdk.org/jdk/pull/20741#pullrequestreview-2266970672 From serb at openjdk.org Wed Aug 28 18:24:20 2024 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 28 Aug 2024 18:24:20 GMT Subject: RFR: 8190329: [macos] Swing InterOp Platform.exit() crash [v2] In-Reply-To: References: Message-ID: On Wed, 28 Aug 2024 02:19:08 GMT, Prasanta Sadhukhan wrote: >> The testcase calls Platform.exit before the dialog is made visible but >> on macOS, JavaFX takes over the AppKit thread and uses that as the FX application thread. As part of the FX platform shutdown process, it detaches that thread from the JVM. This means that the AppKit thread is no longer available to Java processes >> so AWT crashes when it ties to access appkit thread. >> Fix is made to check if the thread has been detached for move-resize notification event before proceeding.. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Reattach thread if AWT is the owner of NSApplication src/java.desktop/macosx/native/libosxapp/ThreadUtilities.m line 67: > 65: } > 66: > 67: + (JNIEnv*)getJNIEnv { The cached version of 'getJNIEnv' was added for performance reasons to skip `attachCurrentThread` if we know for sure that initialization has already completed. But is it still necessary to track all this flags now, maybe the `attachCurrentThread` now smart enough to check that the current thread was already attached, or it is just fast enough? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20688#discussion_r1735116029 From erikj at openjdk.org Wed Aug 28 19:36:19 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 28 Aug 2024 19:36:19 GMT Subject: RFR: 8339120: Use more fine-granular gcc unused warnings [v6] In-Reply-To: References: Message-ID: On Wed, 28 Aug 2024 15:17:52 GMT, Magnus Ihse Bursie wrote: >> Currently, we issue -Wno-unused for all files in gcc, which is a rather big sledgehammer to get rid of some warnings that proliferate in a few areas of the build. >> >> We should instead leave -Wunused turned on (as done by -Wall) and use a much more fine-grained approach to disabling specific warnings in specific files or libraries. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Roll back indentation fix Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20733#pullrequestreview-2267102496 From nsiatras at gmail.com Wed Aug 28 07:55:35 2024 From: nsiatras at gmail.com (Nikos Siatras) Date: Wed, 28 Aug 2024 10:55:35 +0300 Subject: Seeking feedback on a possible JDatePicker Swing component Message-ID: Yes, we will be very happy to see a date picker in Swing! My company develops a commercial CNC Control software and a CAM (Computer Aided Manufacturing) software for desktop. We build both software using Swing. We are currently working on a new software for remote control of continuous 3D printers and the Date-Time picker will be more than welcomed! - Is it of interest ? Yes it is ! - Would you use it ? Yes, we will use it ! - What features must it have ? It has to be functional for date, time and date-time - What features are nice to have ? Able to provide range selection for date, time and date-time Regards, Nikos Siatras CEO @ SourceRabbit -------------- next part -------------- An HTML attachment was scrubbed... URL: From achung at openjdk.org Wed Aug 28 21:40:18 2024 From: achung at openjdk.org (Alisen Chung) Date: Wed, 28 Aug 2024 21:40:18 GMT Subject: RFR: 8308588: Unnecessary synchronized on GTKStyle#ICONS_MAP can be removed In-Reply-To: References: Message-ID: On Wed, 28 Aug 2024 08:54:39 GMT, Abhishek Kumar wrote: > `static final Map ICONS_MAP` is modified only in `static` block. Then [com.sun.java.swing.plaf.gtk.GTKStyle#get](https://github.com/kumarabhi006/jdk/blob/73f7a5f15dbba54a98f3916ff1190520ac07874d/src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKStyle.java#L892) method read from it within `synchronized (ICONS_MAP)` block. As this map is read-only and all its content is initialized in static block we can safely remove synchronized from get call. What's the benefit of removing synchronized from the get call? Also were tests run on all platforms that use GTK? ------------- PR Review: https://git.openjdk.org/jdk/pull/20741#pullrequestreview-2267314744 From achung at openjdk.org Wed Aug 28 21:46:18 2024 From: achung at openjdk.org (Alisen Chung) Date: Wed, 28 Aug 2024 21:46:18 GMT Subject: RFR: 8338153: java/awt/Checkbox/CheckboxCheckerScalingTest.java test failed on linux machine In-Reply-To: References: Message-ID: On Tue, 27 Aug 2024 06:04:47 GMT, Tejesh R wrote: > Test failed intermittently on particular host. Though analysis pointed out to a test frame at left top on that host, I've updated the test for further stabilizing it. Two things done here: > 1. Move the frame to center of the screen rather than left top. > 2. Added tolerance checks for color comparison - this is based on analysis reports where the image didn't had exact black color which is supposed to be. So like other test cases, providing some tolerance for comparison. test/jdk/java/awt/Checkbox/CheckboxCheckerScalingTest.java line 51: > 49: private static BufferedImage imageAfterChecked; > 50: private static volatile boolean checkmarkFound = false; > 51: private static final int TOLERANCE = 10; Is this tolerance needed for the test to pass? Would just moving the test to the center be enough for this fix? I agree with Abhishek that there might be false positives, particularly with color profiles where the test should fail but would pass with this change, especially since this is a ui scaling test. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20723#discussion_r1735323692 From abhiscxk at openjdk.org Thu Aug 29 04:04:24 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Thu, 29 Aug 2024 04:04:24 GMT Subject: RFR: 8308588: Unnecessary synchronized on GTKStyle#ICONS_MAP can be removed In-Reply-To: References: Message-ID: On Wed, 28 Aug 2024 18:17:56 GMT, Damon Nguyen wrote: > I remember simply testing this change when originally triaging this. How did you test this change for stability? Yeah I saw your comment on JBS. I couldn't think of writing any test case for this fix. I ran all the regression tests in CI and there was no failure observed for the proposed changes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20741#issuecomment-2316668888 From abhiscxk at openjdk.org Thu Aug 29 04:12:18 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Thu, 29 Aug 2024 04:12:18 GMT Subject: RFR: 8308588: Unnecessary synchronized on GTKStyle#ICONS_MAP can be removed In-Reply-To: References: Message-ID: <8Yk_Bmk1A1sxngW1mSXzV7xHxOouL2vVAENSCSepKSw=.d18361ab-ebca-413c-a0d7-c57690e46fce@github.com> On Wed, 28 Aug 2024 21:37:39 GMT, Alisen Chung wrote: > What's the benefit of removing synchronized from the get call? As I mentioned earlier, `ICONS_MAP` are initialized only in **static block** and after that it is just referenced to access the value out of it. Even though `ICONS_MAP` are accessed simultaneously for read operation by multiple threads, it won't lead to any inconsistent state. So, the use of Synchronized look unnecessary to me and the removal of Synchronized shouldn't affect the object state in multi threaded environment. > Also were tests run on all platforms that use GTK? Basically I ran the regression tests for linux platform which is supposed to have GTK environment. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20741#issuecomment-2316675427 From tr at openjdk.org Thu Aug 29 04:25:20 2024 From: tr at openjdk.org (Tejesh R) Date: Thu, 29 Aug 2024 04:25:20 GMT Subject: RFR: 8338153: java/awt/Checkbox/CheckboxCheckerScalingTest.java test failed on linux machine In-Reply-To: References: Message-ID: On Wed, 28 Aug 2024 21:43:29 GMT, Alisen Chung wrote: >> Test failed intermittently on particular host. Though analysis pointed out to a test frame at left top on that host, I've updated the test for further stabilizing it. Two things done here: >> 1. Move the frame to center of the screen rather than left top. >> 2. Added tolerance checks for color comparison - this is based on analysis reports where the image didn't had exact black color which is supposed to be. So like other test cases, providing some tolerance for comparison. > > test/jdk/java/awt/Checkbox/CheckboxCheckerScalingTest.java line 51: > >> 49: private static BufferedImage imageAfterChecked; >> 50: private static volatile boolean checkmarkFound = false; >> 51: private static final int TOLERANCE = 10; > > Is this tolerance needed for the test to pass? Would just moving the test to the center be enough for this fix? I agree with Abhishek that there might be false positives, particularly with color profiles where the test should fail but would pass with this change, especially since this is a ui scaling test. Tolerance is required when we are going with screen capture comparison since I see slight change in intensity of colors in captured image, not really sure of what might be the exact cause for it on some machines/some test runs. Also I've seen some tests considers this tolerance while testing. I confirmed it by decoding the pixel color of captured image (Below image). Coming to false positives, yes this is the trade off when the test is made automatic. I see no other way to confirm the check mark with captured image. Other option left is to make the test manual one, yet I feel this way is better than manual. I've captured several runs without the fix where the captured area will be just white background and with fix when checkmark is drawn on UI scale of 2.0 it is drawn inside the area without any other interference which might have led to false positive. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20723#discussion_r1735548153 From tr at openjdk.org Thu Aug 29 04:43:49 2024 From: tr at openjdk.org (Tejesh R) Date: Thu, 29 Aug 2024 04:43:49 GMT Subject: RFR: 8326027: Comparing buffered images of white background frame fails in Mac Message-ID: On analysis of captured image, it is observed that there are few pixels which vary slightly w.r.t to expected color. Hence tolerance is included in color comparison. Tested in mach5 multiple time and its green. ------------- Commit messages: - Update with tolerance value for color comparison Changes: https://git.openjdk.org/jdk/pull/20760/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20760&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8326027 Stats: 11 lines in 1 file changed: 7 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/20760.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20760/head:pull/20760 PR: https://git.openjdk.org/jdk/pull/20760 From tr at openjdk.org Thu Aug 29 05:01:19 2024 From: tr at openjdk.org (Tejesh R) Date: Thu, 29 Aug 2024 05:01:19 GMT Subject: RFR: 8308588: Unnecessary synchronized on GTKStyle#ICONS_MAP can be removed In-Reply-To: References: Message-ID: On Wed, 28 Aug 2024 08:54:39 GMT, Abhishek Kumar wrote: > `static final Map ICONS_MAP` is modified only in `static` block. Then [com.sun.java.swing.plaf.gtk.GTKStyle#get](https://github.com/kumarabhi006/jdk/blob/73f7a5f15dbba54a98f3916ff1190520ac07874d/src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKStyle.java#L892) method read from it within `synchronized (ICONS_MAP)` block. As this map is read-only and all its content is initialized in static block we can safely remove synchronized from get call. Yes, it looks like redundant though. One slight concern is that, does GTKStockIcon has any role to play with synchronized block? If that doesn't has anything with synchronization then its good to go. ------------- PR Review: https://git.openjdk.org/jdk/pull/20741#pullrequestreview-2267682324 From psadhukhan at openjdk.org Thu Aug 29 05:07:24 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 29 Aug 2024 05:07:24 GMT Subject: Integrated: 8336873: BasicSplitPaneDivider:oneTouchExpandableChanged() should mention that implementation depends on SplitPane.supportsOneTouchButtons property In-Reply-To: References: Message-ID: On Tue, 23 Jul 2024 04:07:56 GMT, Prasanta Sadhukhan wrote: > BasicSplitPaneDivider:oneTouchExpandableChanged() spec doesn't mention that it will create left/right button only if L&F supports SplitPane.supportsOneTouchButtons which is now added in javadoc.. This pull request has now been integrated. Changeset: eb7ead58 Author: Prasanta Sadhukhan URL: https://git.openjdk.org/jdk/commit/eb7ead58fd70822669d2aa1a0053814e58955f82 Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod 8336873: BasicSplitPaneDivider:oneTouchExpandableChanged() should mention that implementation depends on SplitPane.supportsOneTouchButtons property Reviewed-by: prr, abhiscxk ------------- PR: https://git.openjdk.org/jdk/pull/20289 From abhiscxk at openjdk.org Thu Aug 29 05:08:18 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Thu, 29 Aug 2024 05:08:18 GMT Subject: RFR: 8308588: Unnecessary synchronized on GTKStyle#ICONS_MAP can be removed In-Reply-To: References: Message-ID: On Thu, 29 Aug 2024 04:58:42 GMT, Tejesh R wrote: > One slight concern is that, does GTKStockIcon has any role to play with synchronized block? Sorry, I didn't understand what do you mean. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20741#issuecomment-2316723282 From psadhukhan at openjdk.org Thu Aug 29 05:23:19 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 29 Aug 2024 05:23:19 GMT Subject: RFR: 8308588: Unnecessary synchronized on GTKStyle#ICONS_MAP can be removed In-Reply-To: <8Yk_Bmk1A1sxngW1mSXzV7xHxOouL2vVAENSCSepKSw=.d18361ab-ebca-413c-a0d7-c57690e46fce@github.com> References: <8Yk_Bmk1A1sxngW1mSXzV7xHxOouL2vVAENSCSepKSw=.d18361ab-ebca-413c-a0d7-c57690e46fce@github.com> Message-ID: <3rRNLs34b_Jq3nYBmJMNQPAg19h8gCu9t40WJeVFVm8=.2411e029-95ac-48d4-91a4-0debd59082fb@github.com> On Thu, 29 Aug 2024 04:09:18 GMT, Abhishek Kumar wrote: > Basically I ran the regression tests for linux platform which is supposed to have GTK environment. Added the CI link in JBS. FWIW, Running tests on linux environment will test it on default MetalL&F which will not test this GTK path unless you specify GTK L&F in `swing.defaultlaf` to it ------------- PR Comment: https://git.openjdk.org/jdk/pull/20741#issuecomment-2316736721 From tr at openjdk.org Thu Aug 29 05:23:20 2024 From: tr at openjdk.org (Tejesh R) Date: Thu, 29 Aug 2024 05:23:20 GMT Subject: RFR: 8308588: Unnecessary synchronized on GTKStyle#ICONS_MAP can be removed In-Reply-To: References: Message-ID: On Thu, 29 Aug 2024 05:05:17 GMT, Abhishek Kumar wrote: > > One slight concern is that, does GTKStockIcon has any role to play with synchronized block? > > Sorry, I didn't understand what do you mean. I meant, since `ICONS_MAP` stores `GTKStockIcon` as value, I was wondering does that make any difference or need for the map to be synchronized? I also came across Immutable Maps which are inherently thread safe. If ICONS_MAP are immutable one, then Synchronized block is definitely redundant. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20741#issuecomment-2316736863 From abhiscxk at openjdk.org Thu Aug 29 05:29:19 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Thu, 29 Aug 2024 05:29:19 GMT Subject: RFR: 8308588: Unnecessary synchronized on GTKStyle#ICONS_MAP can be removed In-Reply-To: <3rRNLs34b_Jq3nYBmJMNQPAg19h8gCu9t40WJeVFVm8=.2411e029-95ac-48d4-91a4-0debd59082fb@github.com> References: <8Yk_Bmk1A1sxngW1mSXzV7xHxOouL2vVAENSCSepKSw=.d18361ab-ebca-413c-a0d7-c57690e46fce@github.com> <3rRNLs34b_Jq3nYBmJMNQPAg19h8gCu9t40WJeVFVm8=.2411e029-95ac-48d4-91a4-0debd59082fb@github.com> Message-ID: On Thu, 29 Aug 2024 05:20:09 GMT, Prasanta Sadhukhan wrote: > FWIW, Running tests on linux environment will test it on default MetalL&F which will not test this GTK path unless you specify GTK L&F in `swing.defaultlaf` to it Ok... I will test with GTK L&F option which I missed earlier. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20741#issuecomment-2316742847 From psadhukhan at openjdk.org Thu Aug 29 06:24:49 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 29 Aug 2024 06:24:49 GMT Subject: RFR: 8190329: [macos] Swing InterOp Platform.exit() crash [v3] In-Reply-To: References: Message-ID: <-hkcutP4Z9Oud7nwKE4z3f6wb96csvlGlZPmrQzoNpI=.391b95d9-eb8c-4aac-b026-b6ed84ebbb52@github.com> > The testcase calls Platform.exit before the dialog is made visible but > on macOS, JavaFX takes over the AppKit thread and uses that as the FX application thread. As part of the FX platform shutdown process, it detaches that thread from the JVM. This means that the AppKit thread is no longer available to Java processes > so AWT crashes when it ties to access appkit thread. > Fix is made to check if the thread has been detached for move-resize notification event before proceeding.. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Flip default owner flag ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20688/files - new: https://git.openjdk.org/jdk/pull/20688/files/effb3f09..acbabc91 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20688&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20688&range=01-02 Stats: 5 lines in 3 files changed: 1 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/20688.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20688/head:pull/20688 PR: https://git.openjdk.org/jdk/pull/20688 From psadhukhan at openjdk.org Thu Aug 29 06:24:50 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 29 Aug 2024 06:24:50 GMT Subject: RFR: 8190329: [macos] Swing InterOp Platform.exit() crash [v2] In-Reply-To: References: Message-ID: On Wed, 28 Aug 2024 16:42:57 GMT, Kevin Rushforth wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: >> >> Reattach thread if AWT is the owner of NSApplication > > src/java.desktop/macosx/native/libosxapp/ThreadUtilities.m line 34: > >> 32: // The following must be named "jvm", as there are extern references to it in AWT >> 33: JavaVM *jvm = NULL; >> 34: static BOOL isNSApplicationOwner = YES; > > One possible suggestion would be to flip the default to `NO`, so as not to cache the env until we know we are the owner. Flipped the default to NO.. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20688#discussion_r1735632039 From ihse at openjdk.org Thu Aug 29 07:32:21 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 29 Aug 2024 07:32:21 GMT Subject: Integrated: 8339120: Use more fine-granular gcc unused warnings In-Reply-To: References: Message-ID: On Tue, 27 Aug 2024 20:04:21 GMT, Magnus Ihse Bursie wrote: > Currently, we issue -Wno-unused for all files in gcc, which is a rather big sledgehammer to get rid of some warnings that proliferate in a few areas of the build. > > We should instead leave -Wunused turned on (as done by -Wall) and use a much more fine-grained approach to disabling specific warnings in specific files or libraries. This pull request has now been integrated. Changeset: 362f9ce0 Author: Magnus Ihse Bursie URL: https://git.openjdk.org/jdk/commit/362f9ce077baa900ed81a0473ec0187efde132ef Stats: 61 lines in 17 files changed: 39 ins; 0 del; 22 mod 8339120: Use more fine-granular gcc unused warnings Reviewed-by: jwaters, kbarrett, erikj ------------- PR: https://git.openjdk.org/jdk/pull/20733 From abhiscxk at openjdk.org Thu Aug 29 07:45:19 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Thu, 29 Aug 2024 07:45:19 GMT Subject: RFR: 8308588: Unnecessary synchronized on GTKStyle#ICONS_MAP can be removed In-Reply-To: References: Message-ID: On Thu, 29 Aug 2024 05:20:20 GMT, Tejesh R wrote: > I meant, since `ICONS_MAP` stores `GTKStockIcon` as value, I was wondering does that make any difference or need for the map to be synchronized? I also came across Immutable Maps which are inherently thread safe. If ICONS_MAP are immutable one, then Synchronized block is definitely redundant. `GTKStockIcon` objects are also created inside static block, So, I guess that should be fine. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20741#issuecomment-2316925469 From ihse at openjdk.org Thu Aug 29 08:29:20 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 29 Aug 2024 08:29:20 GMT Subject: RFR: 8338768: Introduce runtime lookup to check for static builds [v2] In-Reply-To: <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com> References: <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com> Message-ID: On Wed, 21 Aug 2024 22:14:40 GMT, Magnus Ihse Bursie wrote: >> As a preparation for Hermetic Java, we need to have a way to look up during runtime if we are using a statically linked library or not. >> >> This change will be the first step needed towards compiling the object files only once, and then link them into either dynamic or static libraries. (The only exception will be the linktype.c[pp] files, which needs to be compiled twice, once for the dynamic libraries and once for the static libraries.) Getting there will require further work though. >> >> This is part of the changes that make up the draft PR https://github.com/openjdk/jdk/pull/19478, which I have broken out. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Also update build to link properly Okay. Unless I misunderstand something, there were no additional authors to be credited for these two commits. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20666#issuecomment-2317008624 From abhiscxk at openjdk.org Thu Aug 29 11:56:20 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Thu, 29 Aug 2024 11:56:20 GMT Subject: RFR: 8308588: Unnecessary synchronized on GTKStyle#ICONS_MAP can be removed In-Reply-To: References: <8Yk_Bmk1A1sxngW1mSXzV7xHxOouL2vVAENSCSepKSw=.d18361ab-ebca-413c-a0d7-c57690e46fce@github.com> <3rRNLs34b_Jq3nYBmJMNQPAg19h8gCu9t40WJeVFVm8=.2411e029-95ac-48d4-91a4-0debd59082fb@github.com> Message-ID: <1IYyFTZ7NAY-hXgEnp_SQ80SIqYzDixnwzZ-U0KGNCs=.2f7945cc-5568-4e20-bbdc-4e00b624991e@github.com> On Thu, 29 Aug 2024 05:26:47 GMT, Abhishek Kumar wrote: > FWIW, Running tests on linux environment will test it on default MetalL&F which will not test this GTK path unless you specify GTK L&F in `swing.defaultlaf` to it @prsadhuk Ran the tests with GTK Look and Feel option in CI and the tests failed with or without fix is same except one test failure `JFrameMenuSerializationTest.java`. This test failed with the exception `Exception: java.lang.NullPointerException: Cannot invoke "javax.swing.plaf.synth.SynthStyle.getColor(javax.swing.plaf.synth.SynthContext, javax.swing.plaf.synth.ColorType)" because "style" is null` when run without the fix. However, I checked the test result without fix in CI pipeline and the test result shows it passed but the html log file shows `java.lang.NullPointerException: Cannot invoke "javax.swing.plaf.synth.SynthStyle.getColor(javax.swing.plaf.synth.SynthContext, javax.swing.plaf.synth.ColorType)" because "style" is null` under System.err output. Checked in my local machine and this test fails with the same exception. I think this is not related with the fix proposed here because it seems the **GTKStyle object itself is null** if it is run with GTK L&F option. Added the CI link when tests are ran with GTK L&F option in JBS. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20741#issuecomment-2317432908 From aivanov at openjdk.org Thu Aug 29 12:37:18 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 29 Aug 2024 12:37:18 GMT Subject: RFR: 8308588: Unnecessary synchronized on GTKStyle#ICONS_MAP can be removed In-Reply-To: <8Yk_Bmk1A1sxngW1mSXzV7xHxOouL2vVAENSCSepKSw=.d18361ab-ebca-413c-a0d7-c57690e46fce@github.com> References: <8Yk_Bmk1A1sxngW1mSXzV7xHxOouL2vVAENSCSepKSw=.d18361ab-ebca-413c-a0d7-c57690e46fce@github.com> Message-ID: On Thu, 29 Aug 2024 04:09:18 GMT, Abhishek Kumar wrote: > > What's the benefit of removing synchronized from the get call? > > As I mentioned earlier, `ICONS_MAP` are initialized only in **static block** and after that it is just referenced to access the value out of it. Even though `ICONS_MAP` are accessed simultaneously for read operation by multiple threads, it won't lead to any inconsistent state. So, the use of Synchronized look unnecessary to me and the removal of Synchronized shouldn't affect the object state in multi threaded environment. I agree with @turbanoff's evaluation in [the bug description](https://bugs.openjdk.org/browse/JDK-8308588#descriptionmodule): As this map is read-only and _all its content is initialized in `clinit`_, we can safely remove `synchronized` from `get` call. We may go further and make `ICONS_MAP` unmodifiable map: Map iconsMap = new HashMap<>(); iconsMap.put("FileChooser.cancelIcon", new GTKStockIcon("gtk-cancel", 4)); iconsMap.put("FileChooser.okIcon", new GTKStockIcon("gtk-ok", 4)); iconsMap.put("OptionPane.yesIcon", new GTKStockIcon("gtk-yes", 4)); iconsMap.put("OptionPane.noIcon", new GTKStockIcon("gtk-no", 4)); iconsMap.put("OptionPane.cancelIcon", new GTKStockIcon("gtk-cancel", 4)); iconsMap.put("OptionPane.okIcon", new GTKStockIcon("gtk-ok", 4)); ICONS_MAP = Collections.unmodifiableMap(iconsMap); This guarantees that `ICONS_MAP` cannot be modified; additionally the map is fully initialised by the time it's assigned to `ICONS_MAP` member. Alternatively, as IDEA suggests, `Map.of` can be used instead: ICONS_MAP = Map.of( "FileChooser.cancelIcon", new GTKStockIcon("gtk-cancel", 4), "FileChooser.okIcon", new GTKStockIcon("gtk-ok", 4), "OptionPane.yesIcon", new GTKStockIcon("gtk-yes", 4), "OptionPane.noIcon", new GTKStockIcon("gtk-no", 4), "OptionPane.cancelIcon", new GTKStockIcon("gtk-cancel", 4), "OptionPane.okIcon", new GTKStockIcon("gtk-ok", 4)); ------------- PR Comment: https://git.openjdk.org/jdk/pull/20741#issuecomment-2317527619 From aivanov at openjdk.org Thu Aug 29 12:45:20 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 29 Aug 2024 12:45:20 GMT Subject: RFR: 8308588: Unnecessary synchronized on GTKStyle#ICONS_MAP can be removed In-Reply-To: References: Message-ID: <6x-ET9JwHAubdYGbHnoAVp5FEc2VYJM4eUN5B0ReaHM=.5a6c52d7-4769-475d-9f15-9646b7a5c794@github.com> On Thu, 29 Aug 2024 05:20:20 GMT, Tejesh R wrote: > > > One slight concern is that, does GTKStockIcon has any role to play with synchronized block? > > > > > > Sorry, I didn't understand what do you mean. > > I meant, since `ICONS_MAP` stores `GTKStockIcon` as value, I was wondering does that make any difference or need for the map to be synchronized? In fact, `synchronized` block around `ICONS_MAP.get` had no effect. To be correct, the value for `ICONS_MAP` had to be assigned inside a `synchronized` block too. Otherwise, it is not thread-safe. > I also came across Immutable Maps which are inherently thread safe. If ICONS_MAP are immutable one, then Synchronized block is definitely redundant. Effectively, `ICONS_MAP` is an immutable map. It's initialised in a static initialiser and is never modified afterwards. As far as I can tell, `GTKStockIcon` objects stored in the map aren't modified either. Thus, the entire structure is immutable and is thread-safe without additional synchronisation. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20741#issuecomment-2317545926 From aivanov at openjdk.org Thu Aug 29 12:49:22 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 29 Aug 2024 12:49:22 GMT Subject: RFR: 8308588: Unnecessary synchronized on GTKStyle#ICONS_MAP can be removed In-Reply-To: References: Message-ID: On Wed, 28 Aug 2024 08:54:39 GMT, Abhishek Kumar wrote: > `static final Map ICONS_MAP` is modified only in `static` block. Then [com.sun.java.swing.plaf.gtk.GTKStyle#get](https://github.com/kumarabhi006/jdk/blob/73f7a5f15dbba54a98f3916ff1190520ac07874d/src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKStyle.java#L892) method read from it within `synchronized (ICONS_MAP)` block. As this map is read-only and all its content is initialized in static block we can safely remove synchronized from get call. It looks good to me as it is. However, I'd go further and use either `Map.of` or `Collection.unmodifiableMap` to emphasise the fact that the map is read-only. src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKStyle.java line 893: > 891: GTKStockIcon stockIcon = ICONS_MAP.get(key); > 892: > 893: if (stockIcon != null) { Suggestion: GTKStockIcon stockIcon = ICONS_MAP.get(key); if (stockIcon != null) { Maybe remove the blank line? It used to separate a block where `stockIcon` was initialised and the condition. Now it's better to keep these two lines closer. ------------- PR Review: https://git.openjdk.org/jdk/pull/20741#pullrequestreview-2268627382 PR Review Comment: https://git.openjdk.org/jdk/pull/20741#discussion_r1736137111 From aivanov at openjdk.org Thu Aug 29 13:00:20 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 29 Aug 2024 13:00:20 GMT Subject: RFR: 8326027: Comparing buffered images of white background frame fails in Mac In-Reply-To: References: Message-ID: On Thu, 29 Aug 2024 04:38:29 GMT, Tejesh R wrote: > On analysis of captured image, it is observed that there are few pixels which vary slightly w.r.t to expected color. Hence tolerance is included in color comparison. > Tested in mach5 multiple time and its green. I wonder whether the tolerance wouldn't be required if `Robot.createMultiResolutionScreenCapture` was used to create the screenshot and then analysing the original image which didn't go through down-scaling in High DPI environment. test/jdk/javax/swing/JFrame/JFrameBackgroundRefreshTest.java line 140: > 138: > 139: private static boolean compareImages(BufferedImage bufferedImage) { > 140: Color firstPixel = new Color(bufferedImage.getRGB(0,0)); Suggestion: final Color firstPixel = new Color(bufferedImage.getRGB(0, 0)); test/jdk/javax/swing/JFrame/JFrameBackgroundRefreshTest.java line 151: > 149: } > 150: > 151: private static boolean compareColor(Color c1, Color c2) { Shall we move such a method into `Util`? More and more test cases add tolerance to color comparison. Yeah, it's simple enough? and adding a library makes it somewhat harder to run a test in stand-alone mode, without jtreg. test/jdk/javax/swing/JFrame/JFrameBackgroundRefreshTest.java line 155: > 153: Math.abs(c1.getGreen() - c2.getGreen()) < TOLERANCE && > 154: Math.abs(c1.getBlue() - c2.getBlue()) < TOLERANCE; > 155: } Suggestion: private static boolean compareColor(Color c1, Color c2) { return Math.abs(c1.getRed() - c2.getRed()) < TOLERANCE && Math.abs(c1.getGreen() - c2.getGreen()) < TOLERANCE && Math.abs(c1.getBlue() - c2.getBlue()) < TOLERANCE; } Java Coding Style recommends putting operators on the continuation line, it makes it obvious to the reader it is a continuation of an expression. ------------- PR Review: https://git.openjdk.org/jdk/pull/20760#pullrequestreview-2268640859 PR Review Comment: https://git.openjdk.org/jdk/pull/20760#discussion_r1736144750 PR Review Comment: https://git.openjdk.org/jdk/pull/20760#discussion_r1736154776 PR Review Comment: https://git.openjdk.org/jdk/pull/20760#discussion_r1736145854 From ihse at openjdk.org Thu Aug 29 14:21:54 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 29 Aug 2024 14:21:54 GMT Subject: RFR: 8339156: Use more fine-granular clang unused warnings Message-ID: Currently, we issue -Wno-unused for all files in clang, which is a rather big sledgehammer to get rid of some warnings that proliferate in a few areas of the build. We should instead leave -Wunused turned on (as done by -Wall) and use a much more fine-grained approach to disabling specific warnings in specific files or libraries. This is similar to what has been done for gcc in JDK-8339120. ------------- Commit messages: - 8339156: Use more fine-granular clang unused warnings Changes: https://git.openjdk.org/jdk/pull/20770/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20770&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8339156 Stats: 60 lines in 16 files changed: 42 ins; 1 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/20770.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20770/head:pull/20770 PR: https://git.openjdk.org/jdk/pull/20770 From jiangli at openjdk.org Thu Aug 29 15:00:21 2024 From: jiangli at openjdk.org (Jiangli Zhou) Date: Thu, 29 Aug 2024 15:00:21 GMT Subject: RFR: 8338768: Introduce runtime lookup to check for static builds [v2] In-Reply-To: References: <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com> Message-ID: On Thu, 29 Aug 2024 08:26:16 GMT, Magnus Ihse Bursie wrote: > Okay. Unless I misunderstand something, there were no additional authors to be credited for these two commits. That's correct for these. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20666#issuecomment-2317982354 From kcr at openjdk.org Thu Aug 29 15:17:23 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 29 Aug 2024 15:17:23 GMT Subject: RFR: 8190329: [macos] Swing InterOp Platform.exit() crash [v3] In-Reply-To: <-hkcutP4Z9Oud7nwKE4z3f6wb96csvlGlZPmrQzoNpI=.391b95d9-eb8c-4aac-b026-b6ed84ebbb52@github.com> References: <-hkcutP4Z9Oud7nwKE4z3f6wb96csvlGlZPmrQzoNpI=.391b95d9-eb8c-4aac-b026-b6ed84ebbb52@github.com> Message-ID: On Thu, 29 Aug 2024 06:24:49 GMT, Prasanta Sadhukhan wrote: >> The testcase calls Platform.exit before the dialog is made visible but >> on macOS, JavaFX takes over the AppKit thread and uses that as the FX application thread. As part of the FX platform shutdown process, it detaches that thread from the JVM. This means that the AppKit thread is no longer available to Java processes >> so AWT crashes when it ties to access appkit thread. >> Fix is made to check if the thread has been detached for move-resize notification event before proceeding.. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Flip default owner flag Marked as reviewed by kcr (Author). Updated changes look good. I tested it and it does what I would expect. ------------- PR Review: https://git.openjdk.org/jdk/pull/20688#pullrequestreview-2269149181 PR Comment: https://git.openjdk.org/jdk/pull/20688#issuecomment-2318050832 From kcr at openjdk.org Thu Aug 29 15:17:25 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 29 Aug 2024 15:17:25 GMT Subject: RFR: 8190329: [macos] Swing InterOp Platform.exit() crash [v2] In-Reply-To: References: Message-ID: On Wed, 28 Aug 2024 18:22:03 GMT, Sergey Bylokhov wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: >> >> Reattach thread if AWT is the owner of NSApplication > > src/java.desktop/macosx/native/libosxapp/ThreadUtilities.m line 67: > >> 65: } >> 66: >> 67: + (JNIEnv*)getJNIEnv { > > The cached version of 'getJNIEnv' was added for performance reasons to skip `attachCurrentThread` if we know for sure that initialization has already completed. But is it still necessary to track all this flags now, maybe the `attachCurrentThread` now smart enough to check that the current thread was already attached, or it is just fast enough? It seems best to make minimal changes in the normal case where AWT creates the toolkit, which this PR does. You raise a good question as to whether we could get rid of the caching entirely. That seems like something to consider in a follow-up. We would need to do measure the performance impact. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20688#discussion_r1736452484 From andrew at openjdk.org Thu Aug 29 16:34:31 2024 From: andrew at openjdk.org (Andrew John Hughes) Date: Thu, 29 Aug 2024 16:34:31 GMT Subject: RFR: 8328999: Update GIFlib to 5.2.2 In-Reply-To: References: Message-ID: On Fri, 26 Apr 2024 21:37:56 GMT, Alisen Chung wrote: > Updating giflib, clientlibs tests are green on all platforms I'm looking at this in backporting to 8u and this change seems odd: ~~~ -https://sourceforge.net/p/giflib/code/ci/master/tree/openbsd-reallocarray.c +tree/README ~~~ Is it really intentional to remove the URL? Should the new line not be: https://sourceforge.net/p/giflib/code/ci/master/tree/README and then: https://sourceforge.net/p/giflib/code/ci/master/tree/openbsd-reallocarray.c further down? Especially as it says "There have been many other contributors; see the attributions in the version-control history to learn more." and this is removing the link to the version control system. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18985#issuecomment-2318307942 From erikj at openjdk.org Thu Aug 29 16:53:19 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 29 Aug 2024 16:53:19 GMT Subject: RFR: 8339156: Use more fine-granular clang unused warnings In-Reply-To: References: Message-ID: On Thu, 29 Aug 2024 13:14:35 GMT, Magnus Ihse Bursie wrote: > Currently, we issue -Wno-unused for all files in clang, which is a rather big sledgehammer to get rid of some warnings that proliferate in a few areas of the build. > > We should instead leave -Wunused turned on (as done by -Wall) and use a much more fine-grained approach to disabling specific warnings in specific files or libraries. > > This is similar to what has been done for gcc in JDK-8339120. Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20770#pullrequestreview-2269506759 From andrew at openjdk.org Thu Aug 29 17:32:27 2024 From: andrew at openjdk.org (Andrew John Hughes) Date: Thu, 29 Aug 2024 17:32:27 GMT Subject: RFR: 8328999: Update GIFlib to 5.2.2 In-Reply-To: References: Message-ID: On Fri, 26 Apr 2024 21:37:56 GMT, Alisen Chung wrote: > Updating giflib, clientlibs tests are green on all platforms Filed [JDK-8339271](https://bugs.openjdk.org/browse/JDK-8339271) ------------- PR Comment: https://git.openjdk.org/jdk/pull/18985#issuecomment-2318449266 From kbarrett at openjdk.org Thu Aug 29 18:48:20 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 29 Aug 2024 18:48:20 GMT Subject: RFR: 8339156: Use more fine-granular clang unused warnings In-Reply-To: References: Message-ID: On Thu, 29 Aug 2024 13:14:35 GMT, Magnus Ihse Bursie wrote: > Currently, we issue -Wno-unused for all files in clang, which is a rather big sledgehammer to get rid of some warnings that proliferate in a few areas of the build. > > We should instead leave -Wunused turned on (as done by -Wall) and use a much more fine-grained approach to disabling specific warnings in specific files or libraries. > > This is similar to what has been done for gcc in JDK-8339120. Looks good. make/autoconf/flags-cflags.m4 line 266: > 264: # These warnings will never be turned on, since they generate too many > 265: # false positives. > 266: DISABLED_WARNINGS="unknown-warning-option unused-parameter" JDK-8339120 added -Wunused-const-variable=1 and -Wunused-result to gcc's WARNINGS_ENABLE_ADDITIONAL, to "make up" for the corresponding removal of disabling -Wunused. That isn't done here. I assume that was intentional, probably to avoid needing more of the specific disables in this PR. That's fine. We can do more warning option cleanups later in conjunction with corresponding code changes. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20770#pullrequestreview-2269819308 PR Review Comment: https://git.openjdk.org/jdk/pull/20770#discussion_r1736918417 From mvs at openjdk.org Thu Aug 29 19:13:26 2024 From: mvs at openjdk.org (Manukumar V S) Date: Thu, 29 Aug 2024 19:13:26 GMT Subject: RFR: 8339233: Test javax/swing/JButton/SwingButtonResizeTestWithOpenGL.java#id failed: Button renderings are different after window resize Message-ID: This is a highly intermittent failure, it failed only once in CI on a particular windows machine and passed on all other runs. Failure reason: When the button was displayed for the first time, the focus rectangle drawn on the button text(Button A) was not seen(failure images attached in the bug). Fix: To stabilize the test, I have added a line -> button.setFocusPainted(false), so that the focus rectangle will not be painted ------------- Commit messages: - 8339233: Test javax/swing/JButton/SwingButtonResizeTestWithOpenGL.java#id failed: Button renderings are different after window resize Changes: https://git.openjdk.org/jdk/pull/20777/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20777&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8339233 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20777.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20777/head:pull/20777 PR: https://git.openjdk.org/jdk/pull/20777 From ihse at openjdk.org Thu Aug 29 20:43:20 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 29 Aug 2024 20:43:20 GMT Subject: RFR: 8339156: Use more fine-granular clang unused warnings In-Reply-To: References: Message-ID: On Thu, 29 Aug 2024 18:44:22 GMT, Kim Barrett wrote: >> Currently, we issue -Wno-unused for all files in clang, which is a rather big sledgehammer to get rid of some warnings that proliferate in a few areas of the build. >> >> We should instead leave -Wunused turned on (as done by -Wall) and use a much more fine-grained approach to disabling specific warnings in specific files or libraries. >> >> This is similar to what has been done for gcc in JDK-8339120. > > make/autoconf/flags-cflags.m4 line 266: > >> 264: # These warnings will never be turned on, since they generate too many >> 265: # false positives. >> 266: DISABLED_WARNINGS="unknown-warning-option unused-parameter" > > JDK-8339120 added -Wunused-const-variable=1 and -Wunused-result to gcc's > WARNINGS_ENABLE_ADDITIONAL, to "make up" for the corresponding removal of > disabling -Wunused. That isn't done here. I assume that was intentional, > probably to avoid needing more of the specific disables in this PR. That's > fine. We can do more warning option cleanups later in conjunction with > corresponding code changes. No, it was just not needed by clang. `-Wunused-result` is enabled by `-Wunused-value` which is enabled by `-Wunused` which is enabled by `-Wall`. Or something like that. I think it made sense, but the documentation was bad so you had to jump around to understand how things were related. `Wunused-const-variable=1` does not exist in clang, but whatever the closest matching thing was, was enabled as well indirectly already. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20770#discussion_r1737153568 From serb at openjdk.org Thu Aug 29 21:37:19 2024 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 29 Aug 2024 21:37:19 GMT Subject: RFR: 8190329: [macos] Swing InterOp Platform.exit() crash [v2] In-Reply-To: References: Message-ID: On Wed, 28 Aug 2024 16:43:49 GMT, Kevin Rushforth wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: >> >> Reattach thread if AWT is the owner of NSApplication > > src/java.desktop/macosx/native/libawt_lwawt/awt/ApplicationDelegate.m line 128: > >> 126: [ThreadUtilities setApplicationOwner:NO]; >> 127: return nil; >> 128: } > > If you flip the default, then you need to set it to YES here: > > > [ThreadUtilities setApplicationOwner:YES]; > > > (this might be best anyway, since then you will always set the flag) Do we want to use cached version for this case? `[NSApp isMemberOfClass:[NSApplication class]] && overrideDelegate` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20688#discussion_r1737232505 From kcr at openjdk.org Thu Aug 29 23:03:18 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 29 Aug 2024 23:03:18 GMT Subject: RFR: 8190329: [macos] Swing InterOp Platform.exit() crash [v2] In-Reply-To: References: Message-ID: On Thu, 29 Aug 2024 21:34:18 GMT, Sergey Bylokhov wrote: >> src/java.desktop/macosx/native/libawt_lwawt/awt/ApplicationDelegate.m line 128: >> >>> 126: [ThreadUtilities setApplicationOwner:NO]; >>> 127: return nil; >>> 128: } >> >> If you flip the default, then you need to set it to YES here: >> >> >> [ThreadUtilities setApplicationOwner:YES]; >> >> >> (this might be best anyway, since then you will always set the flag) > > Do we want to use cached version for this case? > `[NSApp isMemberOfClass:[NSApplication class]] && overrideDelegate` Hmm. Probably not. We don't really expect that anyone will ever set the (undocumented) env variable that will set the `overrideDelegate` flag, but it might be safest to only use the cached env if `[NSApp isKindOfClass:[NSApplicationAWT class]]`. If so, one way to do this would be to change line 129 to: [ThreadUtilities setApplicationOwner:[NSApp isKindOfClass:[NSApplicationAWT class]]]; Or keep track of a second flag, something like this: BOOL isApplicationOwner = NO; if (NSApp != nil) { if ([NSApp isMemberOfClass:[NSApplication class]] && overrideDelegate) shouldInstall = YES; if ([NSApp isKindOfClass:[NSApplicationAWT class]]) { shouldInstall = YES; isApplicationOwner = YES; } } [ThreadUtilities setApplicationOwner:isApplicationOwner]; ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20688#discussion_r1737403557 From serb at openjdk.org Thu Aug 29 23:17:18 2024 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 29 Aug 2024 23:17:18 GMT Subject: RFR: 8326027: Comparing buffered images of white background frame fails in Mac In-Reply-To: References: Message-ID: On Thu, 29 Aug 2024 04:38:29 GMT, Tejesh R wrote: > On analysis of captured image, it is observed that there are few pixels which vary slightly w.r.t to expected color. Hence tolerance is included in color comparison. > Tested in mach5 multiple time and its green. Have you checked what is the root cause? Are the pixels drawn incorrectly in the frame, or is the robot distorting the colors when it grabs the pixels? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20760#issuecomment-2319362753 From alanb at openjdk.org Fri Aug 30 04:40:20 2024 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 30 Aug 2024 04:40:20 GMT Subject: RFR: 8339156: Use more fine-granular clang unused warnings In-Reply-To: References: Message-ID: <1lG4XEx1lF8Hu6csMsC9jNvDImrf9Pd5_xblOGlOyh4=.26a4c1cc-cc26-4581-8236-107ec28fe840@github.com> On Thu, 29 Aug 2024 13:14:35 GMT, Magnus Ihse Bursie wrote: > Currently, we issue -Wno-unused for all files in clang, which is a rather big sledgehammer to get rid of some warnings that proliferate in a few areas of the build. > > We should instead leave -Wunused turned on (as done by -Wall) and use a much more fine-grained approach to disabling specific warnings in specific files or libraries. > > This is similar to what has been done for gcc in JDK-8339120. I wonder if there should be JBS issues for the specific source files/warnings so they can be looked at more closely (or maybe you've looked at them all already). Just wondering about the maintainability of DISABLED_WARNINGS_xxx values that list specific files as I assume they can bit rot quickly. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20770#issuecomment-2320021124 From tr at openjdk.org Fri Aug 30 04:56:17 2024 From: tr at openjdk.org (Tejesh R) Date: Fri, 30 Aug 2024 04:56:17 GMT Subject: RFR: 8326027: Comparing buffered images of white background frame fails in Mac In-Reply-To: References: Message-ID: On Thu, 29 Aug 2024 12:58:11 GMT, Alexey Ivanov wrote: > I wonder whether the tolerance wouldn't be required if `Robot.createMultiResolutionScreenCapture` was used to create the screenshot and then analysing the original image which didn't go through down-scaling in High DPI environment. Yes, I have observed that some of the HiDPI image capture have this shades of pixels from expected which would require tolerance to be considered while comparing. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20760#issuecomment-2320045167 From abhiscxk at openjdk.org Fri Aug 30 04:57:56 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Fri, 30 Aug 2024 04:57:56 GMT Subject: RFR: 8308588: Unnecessary synchronized on GTKStyle#ICONS_MAP can be removed [v2] In-Reply-To: References: Message-ID: > `static final Map ICONS_MAP` is modified only in `static` block. Then [com.sun.java.swing.plaf.gtk.GTKStyle#get](https://github.com/kumarabhi006/jdk/blob/73f7a5f15dbba54a98f3916ff1190520ac07874d/src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKStyle.java#L892) method read from it within `synchronized (ICONS_MAP)` block. As this map is read-only and all its content is initialized in static block we can safely remove synchronized from get call. Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: Use Collections.unmodifiableMap and remove blank line ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20741/files - new: https://git.openjdk.org/jdk/pull/20741/files/5775df65..af1fdbdc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20741&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20741&range=00-01 Stats: 17 lines in 1 file changed: 1 ins; 1 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/20741.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20741/head:pull/20741 PR: https://git.openjdk.org/jdk/pull/20741 From abhiscxk at openjdk.org Fri Aug 30 05:01:19 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Fri, 30 Aug 2024 05:01:19 GMT Subject: RFR: 8308588: Unnecessary synchronized on GTKStyle#ICONS_MAP can be removed [v2] In-Reply-To: <6x-ET9JwHAubdYGbHnoAVp5FEc2VYJM4eUN5B0ReaHM=.5a6c52d7-4769-475d-9f15-9646b7a5c794@github.com> References: <6x-ET9JwHAubdYGbHnoAVp5FEc2VYJM4eUN5B0ReaHM=.5a6c52d7-4769-475d-9f15-9646b7a5c794@github.com> Message-ID: <7XI32Ypg5-XEyzJhI4xNh_Aj9JUpmPOwBdOQdvj_3RM=.99c2cfa1-dd42-401f-8cb8-37d4913f4881@github.com> On Thu, 29 Aug 2024 12:42:49 GMT, Alexey Ivanov wrote: >>> > One slight concern is that, does GTKStockIcon has any role to play with synchronized block? >>> >>> Sorry, I didn't understand what do you mean. >> >> I meant, since `ICONS_MAP` stores `GTKStockIcon` as value, I was wondering does that make any difference or need for the map to be synchronized? I also came across Immutable Maps which are inherently thread safe. If ICONS_MAP are immutable one, then Synchronized block is definitely redundant. > >> > > One slight concern is that, does GTKStockIcon has any role to play with synchronized block? >> > >> > >> > Sorry, I didn't understand what do you mean. >> >> I meant, since `ICONS_MAP` stores `GTKStockIcon` as value, I was wondering does that make any difference or need for the map to be synchronized? > > In fact, `synchronized` block around `ICONS_MAP.get` had no effect. > > To be correct, the value for `ICONS_MAP` had to be assigned inside a `synchronized` block too. Otherwise, it is not thread-safe. > >> I also came across Immutable Maps which are inherently thread safe. If ICONS_MAP are immutable one, then Synchronized block is definitely redundant. > > Effectively, `ICONS_MAP` is an immutable map. It's initialised in a static initialiser and is never modified afterwards. > > As far as I can tell, `GTKStockIcon` objects stored in the map aren't modified either. > > Thus, the entire structure is immutable and is thread-safe without additional synchronisation. @aivanov-jdk I guess `Maps.of` can't be used here because there are few elements put inside a map after `tk.checkGtkVersion(3, 10, 0)` condition evaluation at [L1193](https://github.com/kumarabhi006/jdk/blob/73f7a5f15dbba54a98f3916ff1190520ac07874d/src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKStyle.java#L1193). Instead used `Collections.unmodifiableMap` to make the `ICONS_MAP` read only. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20741#issuecomment-2320053428 From tr at openjdk.org Fri Aug 30 05:02:18 2024 From: tr at openjdk.org (Tejesh R) Date: Fri, 30 Aug 2024 05:02:18 GMT Subject: RFR: 8326027: Comparing buffered images of white background frame fails in Mac In-Reply-To: References: Message-ID: On Thu, 29 Aug 2024 23:14:29 GMT, Sergey Bylokhov wrote: > Have you checked what is the root cause? Are the pixels drawn incorrectly in the frame, or is the robot distorting the colors when it grabs the pixels? The issue occurs intermittently/might be even host specific. It occurs when Robot.createMultiResolutionScreenCapture is used to capture HiDPI image and comparing them. I believe it's related to Robot capture, rather than pixel drawn incorrectly since we haven't observed such case in headless test which actually compares colors using Graphics paint to buffered image. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20760#issuecomment-2320054912 From kbarrett at openjdk.org Fri Aug 30 05:09:18 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 30 Aug 2024 05:09:18 GMT Subject: RFR: 8339156: Use more fine-granular clang unused warnings In-Reply-To: <1lG4XEx1lF8Hu6csMsC9jNvDImrf9Pd5_xblOGlOyh4=.26a4c1cc-cc26-4581-8236-107ec28fe840@github.com> References: <1lG4XEx1lF8Hu6csMsC9jNvDImrf9Pd5_xblOGlOyh4=.26a4c1cc-cc26-4581-8236-107ec28fe840@github.com> Message-ID: On Fri, 30 Aug 2024 04:37:55 GMT, Alan Bateman wrote: > I wonder if there should be JBS issues for the specific source files/warnings so they can be looked at more closely (or maybe you've looked at them all already). Just wondering about the maintainability of DISABLED_WARNINGS_xxx values that list specific files as I assume they can bit rot quickly. The idea, from the build component POV, is that teams responsible for the various parts of the code where warnings are being suppressed are responsible for filing issues to address them and scheduling the work to do so. Different teams have different approaches to backlog issues, how they prioritize them, and whether they keep them open or close as WNF because they don't see getting to them for a long time, if ever. I personally dislike the last approach, but it's not under my control. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20770#issuecomment-2320065831 From tr at openjdk.org Fri Aug 30 07:02:20 2024 From: tr at openjdk.org (Tejesh R) Date: Fri, 30 Aug 2024 07:02:20 GMT Subject: RFR: 8326027: Comparing buffered images of white background frame fails in Mac In-Reply-To: References: Message-ID: <0x_LRI-7CgAPkl4MqCyj3expYkQG400TGVnTnaA1Ks0=.948b548d-45ea-4c9d-a090-e1db4a40beba@github.com> On Thu, 29 Aug 2024 12:55:50 GMT, Alexey Ivanov wrote: >> On analysis of captured image, it is observed that there are few pixels which vary slightly w.r.t to expected color. Hence tolerance is included in color comparison. >> Tested in mach5 multiple time and its green. > > test/jdk/javax/swing/JFrame/JFrameBackgroundRefreshTest.java line 151: > >> 149: } >> 150: >> 151: private static boolean compareColor(Color c1, Color c2) { > > Shall we move such a method into `Util`? > > More and more test cases add tolerance to color comparison. Yeah, it's simple enough? and adding a library makes it somewhat harder to run a test in stand-alone mode, without jtreg. Yeah, adding it to library will make it harder to run a test in stand-alone mode. There is this `Util.testBoundsColor()` in Util and I don't see much of test using it though. I guess it's better to leave the comparison to individual test, rather than trying to make it generic. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20760#discussion_r1738062680 From aivanov at openjdk.org Fri Aug 30 07:18:18 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 30 Aug 2024 07:18:18 GMT Subject: RFR: 8326027: Comparing buffered images of white background frame fails in Mac In-Reply-To: References: Message-ID: <0FKvhBMfDuyvzus_Q_sjhmFB02FPipKX9p54KNy6w0k=.cf25ba18-9c25-4079-aeae-c2ffeaf0eafe@github.com> On Fri, 30 Aug 2024 04:59:58 GMT, Tejesh R wrote: > > Have you checked what is the root cause? Are the pixels drawn incorrectly in the frame, or is the robot distorting the colors when it grabs the pixels? > > The issue occurs intermittently/might be even host specific. It occurs when Robot.createMultiResolutionScreenCapture is used to capture HiDPI image and comparing them. I believe it's related to Robot capture, rather than pixel drawn incorrectly since we haven't observed such case in headless test which actually compares colors using Graphics paint to buffered image. I assume it's the opposite: if `Robot.createMultiResolutionScreenCapture` was used, the colours would be accurate (as displayed); whereas `Robot.createScreenCapture` scales down the screenshot which may introduce colour inaccuracy. > > I wonder whether the tolerance wouldn't be required if `Robot.createMultiResolutionScreenCapture` was used to create the screenshot and then analysing the original image which didn't go through down-scaling in High DPI environment. > > Yes, I have observed that some of the HiDPI image capture have this shades of pixels from expected which would require tolerance to be considered while comparing. This is why I asked the question: does the comparison remain accurate without the need for tolerance if you use `Robot.createMultiResolutionScreenCapture` and use the highest resolution from the returned multi-resolution image? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20760#issuecomment-2320305136 From tr at openjdk.org Fri Aug 30 07:23:19 2024 From: tr at openjdk.org (Tejesh R) Date: Fri, 30 Aug 2024 07:23:19 GMT Subject: RFR: 8326027: Comparing buffered images of white background frame fails in Mac In-Reply-To: <0FKvhBMfDuyvzus_Q_sjhmFB02FPipKX9p54KNy6w0k=.cf25ba18-9c25-4079-aeae-c2ffeaf0eafe@github.com> References: <0FKvhBMfDuyvzus_Q_sjhmFB02FPipKX9p54KNy6w0k=.cf25ba18-9c25-4079-aeae-c2ffeaf0eafe@github.com> Message-ID: On Fri, 30 Aug 2024 07:15:42 GMT, Alexey Ivanov wrote: > > > Have you checked what is the root cause? Are the pixels drawn incorrectly in the frame, or is the robot distorting the colors when it grabs the pixels? > > > > > > The issue occurs intermittently/might be even host specific. It occurs when Robot.createMultiResolutionScreenCapture is used to capture HiDPI image and comparing them. I believe it's related to Robot capture, rather than pixel drawn incorrectly since we haven't observed such case in headless test which actually compares colors using Graphics paint to buffered image. > > I assume it's the opposite: if `Robot.createMultiResolutionScreenCapture` was used, the colours would be accurate (as displayed); whereas `Robot.createScreenCapture` scales down the screenshot which may introduce colour inaccuracy. > > > > I wonder whether the tolerance wouldn't be required if `Robot.createMultiResolutionScreenCapture` was used to create the screenshot and then analysing the original image which didn't go through down-scaling in High DPI environment. > > > > > > Yes, I have observed that some of the HiDPI image capture have this shades of pixels from expected which would require tolerance to be considered while comparing. > > This is why I asked the question: does the comparison remain accurate without the need for tolerance if you use `Robot.createMultiResolutionScreenCapture` and use the highest resolution from the returned multi-resolution image? My bad, I misplaced `robot.createScreenCapture()` with `Robot.createMultiResolutionScreenCapture`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20760#issuecomment-2320316643 From psadhukhan at openjdk.org Fri Aug 30 07:23:54 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 30 Aug 2024 07:23:54 GMT Subject: RFR: 8190329: [macos] Swing InterOp Platform.exit() crash [v4] In-Reply-To: References: Message-ID: > The testcase calls Platform.exit before the dialog is made visible but > on macOS, JavaFX takes over the AppKit thread and uses that as the FX application thread. As part of the FX platform shutdown process, it detaches that thread from the JVM. This means that the AppKit thread is no longer available to Java processes > so AWT crashes when it ties to access appkit thread. > Fix is made to check if the thread has been detached for move-resize notification event before proceeding.. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Use cached Env only for AWT NSApplication and not for Override-delegate ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20688/files - new: https://git.openjdk.org/jdk/pull/20688/files/acbabc91..105fe7d6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20688&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20688&range=02-03 Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20688.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20688/head:pull/20688 PR: https://git.openjdk.org/jdk/pull/20688 From psadhukhan at openjdk.org Fri Aug 30 07:28:24 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 30 Aug 2024 07:28:24 GMT Subject: RFR: 8190329: [macos] Swing InterOp Platform.exit() crash [v2] In-Reply-To: References: Message-ID: On Thu, 29 Aug 2024 23:01:08 GMT, Kevin Rushforth wrote: >> Do we want to use cached version for this case? >> `[NSApp isMemberOfClass:[NSApplication class]] && overrideDelegate` > > Hmm. Probably not. We don't really expect that anyone will ever set the (undocumented) env variable that will set the `overrideDelegate` flag, but it might be safest to only use the cached env if `[NSApp isKindOfClass:[NSApplicationAWT class]]`. > > If so, one way to do this would be to change line 129 to: > > > [ThreadUtilities setApplicationOwner:[NSApp isKindOfClass:[NSApplicationAWT class]]]; > > > Or keep track of a second flag, something like this: > > > BOOL isApplicationOwner = NO; > if (NSApp != nil) { > if ([NSApp isMemberOfClass:[NSApplication class]] && overrideDelegate) shouldInstall = YES; > if ([NSApp isKindOfClass:[NSApplicationAWT class]]) { > shouldInstall = YES; > isApplicationOwner = YES; > } > } > [ThreadUtilities setApplicationOwner:isApplicationOwner]; Updated PR to cache JNIEnv only for NSApplicationAWT instance ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20688#discussion_r1738101573 From tr at openjdk.org Fri Aug 30 07:44:18 2024 From: tr at openjdk.org (Tejesh R) Date: Fri, 30 Aug 2024 07:44:18 GMT Subject: RFR: 8339233: Test javax/swing/JButton/SwingButtonResizeTestWithOpenGL.java#id failed: Button renderings are different after window resize In-Reply-To: References: Message-ID: On Thu, 29 Aug 2024 19:07:29 GMT, Manukumar V S wrote: > This is a highly intermittent failure, and it failed only once in CI on a particular windows machine and passed on all other runs. > > Failure reason: > When the button was displayed for the first time, the focus rectangle drawn on the button text(Button A) was not seen(failure images attached in the bug). > > Fix: > To stabilize the test, I have added a line -> button.setFocusPainted(false), so that the focus rectangle will not be painted After going through the test runs which you have shared, I suggest some stabilization is required along with FocusPaint fix. As attached here, in one of your test runs, failure is caused due to capture of distorted image. ![image2](https://github.com/user-attachments/assets/5744cb82-24da-45c3-a5d9-e88b7864bae3) ------------- PR Review: https://git.openjdk.org/jdk/pull/20777#pullrequestreview-2271459780 From alanb at openjdk.org Fri Aug 30 10:07:23 2024 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 30 Aug 2024 10:07:23 GMT Subject: RFR: 8338768: Introduce runtime lookup to check for static builds [v2] In-Reply-To: <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com> References: <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com> Message-ID: On Wed, 21 Aug 2024 22:14:40 GMT, Magnus Ihse Bursie wrote: >> As a preparation for Hermetic Java, we need to have a way to look up during runtime if we are using a statically linked library or not. >> >> This change will be the first step needed towards compiling the object files only once, and then link them into either dynamic or static libraries. (The only exception will be the linktype.c[pp] files, which needs to be compiled twice, once for the dynamic libraries and once for the static libraries.) Getting there will require further work though. >> >> This is part of the changes that make up the draft PR https://github.com/openjdk/jdk/pull/19478, which I have broken out. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Also update build to link properly I think the approach is pragmatic and okay. I agree it looks a bit unusual to be testing the image type at runtime but it doesn't seem to be measurable and not a concern right now. In the future, I suspect we will have many places in the libraries that will need to test this at runtime for 30+ other reasons. ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20666#pullrequestreview-2271829178 From ysuenaga at openjdk.org Fri Aug 30 10:23:33 2024 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Fri, 30 Aug 2024 10:23:33 GMT Subject: RFR: 8339309: unused-variable warnings happen in libfontmanager Message-ID: I saw following errors (warnings) when I tried to build OpenJDK on Fedora 40 with gcc-14.2.1-1.fc40.x86_64: /home/ysuenaga/github-forked/jdk/src/java.desktop/share/native/libfontmanager/HBShaper_Panama.c: In function ?jdk_hb_shape?: /home/ysuenaga/github-forked/jdk/src/java.desktop/share/native/libfontmanager/HBShaper_Panama.c:101:16: error: unused variable ?yPtSize? [-Werror=unused-variable] 101 | float yPtSize = euclidianDistance(matrix[2], matrix[3]); | ^~~~~~~ cc1: all warnings being treated as errors * For target support_native_java.desktop_libfontmanager_X11FontScaler.o: /home/ysuenaga/github-forked/jdk/src/java.desktop/unix/native/libfontmanager/X11FontScaler.c: In function ?Java_sun_font_NativeFont_getGlyphAdvance?: /home/ysuenaga/github-forked/jdk/src/java.desktop/unix/native/libfontmanager/X11FontScaler.c:270:32: error: unused variable ?descent? [-Werror=unused-variable] 270 | int direction, ascent, descent; | ^~~~~~~ /home/ysuenaga/github-forked/jdk/src/java.desktop/unix/native/libfontmanager/X11FontScaler.c:270:24: error: unused variable ?ascent? [-Werror=unused-variable] 270 | int direction, ascent, descent; | ^~~~~~ /home/ysuenaga/github-forked/jdk/src/java.desktop/unix/native/libfontmanager/X11FontScaler.c:270:13: error: unused variable ?direction? [-Werror=unused-variable] 270 | int direction, ascent, descent; | ^~~~~~~~~ /home/ysuenaga/github-forked/jdk/src/java.desktop/share/native/libfontmanager/freetypeScaler.c: In function ?Java_sun_font_FreetypeFontScaler_createScalerContextNative?: /home/ysuenaga/github-forked/jdk/src/java.desktop/share/native/libfontmanager/freetypeScaler.c:516:19: error: unused variable ?scalerInfo? [-Werror=unused-variable] 516 | FTScalerInfo *scalerInfo = | ^~~~~~~~~~ /home/ysuenaga/github-forked/jdk/src/java.desktop/share/native/libfontmanager/freetypeScaler.c: In function ?Java_sun_font_FreetypeFontScaler_getGlyphPointNative?: /home/ysuenaga/github-forked/jdk/src/java.desktop/share/native/libfontmanager/freetypeScaler.c:1655:13: error: unused variable ?point? [-Werror=unused-variable] 1655 | jobject point = NULL; | ^~~~~ ------------- Commit messages: - 8339309: unused-variable warnings happen in libfontmanager Changes: https://git.openjdk.org/jdk/pull/20790/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20790&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8339309 Stats: 8 lines in 3 files changed: 0 ins; 5 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/20790.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20790/head:pull/20790 PR: https://git.openjdk.org/jdk/pull/20790 From abhiscxk at openjdk.org Fri Aug 30 10:42:34 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Fri, 30 Aug 2024 10:42:34 GMT Subject: RFR: 8051591: Test javax/swing/JTabbedPane/8007563/Test8007563.java fails Message-ID: Test was failing on multiple platforms mainly windows and linux and was problemlisted for all platforms. Increased the delay from 200ms to 500 ms to fetch the correct background color using robot. Now test passed for multiple iteration (~50 times) in CI pipeline for all platforms. Wild imports are expanded and test is pulled out of an extra level of folder. Test removed from `Problem-list` file as well. CI testing link is posted in JBS. ------------- Commit messages: - Test stabilize, wild imports expand Changes: https://git.openjdk.org/jdk/pull/20791/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20791&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8051591 Stats: 282 lines in 3 files changed: 144 ins; 138 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20791.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20791/head:pull/20791 PR: https://git.openjdk.org/jdk/pull/20791 From ihse at openjdk.org Fri Aug 30 10:54:20 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 30 Aug 2024 10:54:20 GMT Subject: RFR: 8338768: Introduce runtime lookup to check for static builds [v2] In-Reply-To: References: <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com> Message-ID: On Mon, 26 Aug 2024 02:07:39 GMT, David Holmes wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: >> >> Also update build to link properly > > I understand the cost overhead experienced by any individual Java run may be lost in the noise, but it still impacts every single Java run just to save some time/resources for the handful of builders of statically linked VMs. I am not a fan. @dholmes-ora This PR now has three reviewers approving it. You say you are "not a fan". Does this mean you want to veto this change? Or can you be willing to accept it, even if you do not like it? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20666#issuecomment-2320832777 From ihse at openjdk.org Fri Aug 30 11:35:51 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 30 Aug 2024 11:35:51 GMT Subject: RFR: 8339156: Use more fine-granular clang unused warnings [v2] In-Reply-To: References: Message-ID: > Currently, we issue -Wno-unused for all files in clang, which is a rather big sledgehammer to get rid of some warnings that proliferate in a few areas of the build. > > We should instead leave -Wunused turned on (as done by -Wall) and use a much more fine-grained approach to disabling specific warnings in specific files or libraries. > > This is similar to what has been done for gcc in JDK-8339120. Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: - Merge branch 'master' into finegranular-clang-unused - 8339156: Use more fine-granular clang unused warnings ------------- Changes: https://git.openjdk.org/jdk/pull/20770/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20770&range=01 Stats: 60 lines in 16 files changed: 42 ins; 1 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/20770.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20770/head:pull/20770 PR: https://git.openjdk.org/jdk/pull/20770 From ihse at openjdk.org Fri Aug 30 11:35:51 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 30 Aug 2024 11:35:51 GMT Subject: RFR: 8339156: Use more fine-granular clang unused warnings In-Reply-To: References: Message-ID: On Thu, 29 Aug 2024 13:14:35 GMT, Magnus Ihse Bursie wrote: > Currently, we issue -Wno-unused for all files in clang, which is a rather big sledgehammer to get rid of some warnings that proliferate in a few areas of the build. > > We should instead leave -Wunused turned on (as done by -Wall) and use a much more fine-grained approach to disabling specific warnings in specific files or libraries. > > This is similar to what has been done for gcc in JDK-8339120. As Kim says. I can pave the way for the component teams to fix the warnings as smoothly as possible, but I cannot and will not try to fix the actual issue. (When I embarked on the journey to try and improve the warning situation, I na?vely tried to fix some "simple" warnings, thinking that would be easier than to turn off the warning... Heh! Just let me say, I'm not doing that again.) I used to file a JBS issue whenever I disabled a warning on a component, but they were mostly just ignored or closed after several years without any action, so I got tired of doing all the paperwork for nothing. Maybe we can try to raise some general awareness that teams should check up what warnings they have disabled and see if they can fix them? I know some teams, like client-libs, have tons of warnings, are well aware of the fact, but do not have the manpower to be able to address them. Other teams might just be oblivious to the situations, however, but I have no way to tell which way it is. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20770#issuecomment-2320924437 From aivanov at openjdk.org Fri Aug 30 15:16:19 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 30 Aug 2024 15:16:19 GMT Subject: RFR: 8308588: Unnecessary synchronized on GTKStyle#ICONS_MAP can be removed [v2] In-Reply-To: References: Message-ID: On Fri, 30 Aug 2024 04:57:56 GMT, Abhishek Kumar wrote: >> `static final Map ICONS_MAP` is modified only in `static` block. Then [com.sun.java.swing.plaf.gtk.GTKStyle#get](https://github.com/kumarabhi006/jdk/blob/73f7a5f15dbba54a98f3916ff1190520ac07874d/src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKStyle.java#L892) method read from it within `synchronized (ICONS_MAP)` block. As this map is read-only and all its content is initialized in static block we can safely remove synchronized from get call. > > Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: > > Use Collections.unmodifiableMap and remove blank line Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20741#pullrequestreview-2272702899 From aivanov at openjdk.org Fri Aug 30 15:16:20 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 30 Aug 2024 15:16:20 GMT Subject: RFR: 8308588: Unnecessary synchronized on GTKStyle#ICONS_MAP can be removed [v2] In-Reply-To: <6x-ET9JwHAubdYGbHnoAVp5FEc2VYJM4eUN5B0ReaHM=.5a6c52d7-4769-475d-9f15-9646b7a5c794@github.com> References: <6x-ET9JwHAubdYGbHnoAVp5FEc2VYJM4eUN5B0ReaHM=.5a6c52d7-4769-475d-9f15-9646b7a5c794@github.com> Message-ID: On Thu, 29 Aug 2024 12:42:49 GMT, Alexey Ivanov wrote: >>> > One slight concern is that, does GTKStockIcon has any role to play with synchronized block? >>> >>> Sorry, I didn't understand what do you mean. >> >> I meant, since `ICONS_MAP` stores `GTKStockIcon` as value, I was wondering does that make any difference or need for the map to be synchronized? I also came across Immutable Maps which are inherently thread safe. If ICONS_MAP are immutable one, then Synchronized block is definitely redundant. > >> > > One slight concern is that, does GTKStockIcon has any role to play with synchronized block? >> > >> > >> > Sorry, I didn't understand what do you mean. >> >> I meant, since `ICONS_MAP` stores `GTKStockIcon` as value, I was wondering does that make any difference or need for the map to be synchronized? > > In fact, `synchronized` block around `ICONS_MAP.get` had no effect. > > To be correct, the value for `ICONS_MAP` had to be assigned inside a `synchronized` block too. Otherwise, it is not thread-safe. > >> I also came across Immutable Maps which are inherently thread safe. If ICONS_MAP are immutable one, then Synchronized block is definitely redundant. > > Effectively, `ICONS_MAP` is an immutable map. It's initialised in a static initialiser and is never modified afterwards. > > As far as I can tell, `GTKStockIcon` objects stored in the map aren't modified either. > > Thus, the entire structure is immutable and is thread-safe without additional synchronisation. > @aivanov-jdk I guess `Maps.of` can't be used here because there are few elements put inside a map after `tk.checkGtkVersion(3, 10, 0)` condition? It's possible to use `Map.of` if you put the condition as a conditional operator to each value. Yet it would make the intention less clear. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20741#issuecomment-2321574112 From honkar at openjdk.org Fri Aug 30 16:41:23 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Fri, 30 Aug 2024 16:41:23 GMT Subject: RFR: 8332901: Select{Current,New}ItemTest.java for Choice don't open popup on macOS [v4] In-Reply-To: References: Message-ID: On Tue, 20 Aug 2024 14:47:23 GMT, Alexey Ivanov wrote: >> I looked at `java/awt/Choice/SelectCurrentItemTest/SelectCurrentItemTest.java`, ran it and noticed that the test does not open the popup of the `Choice` component on macOS 14.x. >> >> If the popup does not open, the test does not verify anything ? it always passes. >> >> I refactored the test and added a mouse listener to the `Choice` component. If mouse click isn't registered, the test fails. >> >> Later, I found a similar test: `test/jdk/java/awt/Choice/SelectNewItemTest/SelectNewItemTest.java`. It clicks on another item in the Choice popup and expects to receive `ItemEvent`. >> >> I refactored both tests and moved them into `Choice/SelectItem` folder. >> >> `SelectCurrentItemTest` encapsulates the common test logic and provides overridable methods to customise conditions for `SelectNewItemTest`. >> >> Now, `SelectNewItemTest` extends `SelectCurrentItemTest` and overrides the conditions as well as the coordinates for clicking the popup of the `Choice` component. >> >> ~~The updated test fails for me locally on macOS Sonoma 14.5. This is likely the result of [JDK-8322653](https://bugs.openjdk.org/browse/JDK-8322653): _[macos14] : Mouse clicks are not received within 3 pixels of the window boundary_.~~ >> >> To work around JDK-8322653, both tests use non-resizable frame. Both updated tests pass on CI and locally on macOS 14.5. This is why I removed `SelectNewItemTest` from problem-list. > > Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision: > > Amend the copyright year in SelectCurrentItemTest Updated changes and summary looks good. ------------- Marked as reviewed by honkar (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20601#pullrequestreview-2273031833 From erikj at openjdk.org Fri Aug 30 16:46:30 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 30 Aug 2024 16:46:30 GMT Subject: RFR: 8339156: Use more fine-granular clang unused warnings [v2] In-Reply-To: References: Message-ID: On Fri, 30 Aug 2024 11:35:51 GMT, Magnus Ihse Bursie wrote: >> Currently, we issue -Wno-unused for all files in clang, which is a rather big sledgehammer to get rid of some warnings that proliferate in a few areas of the build. >> >> We should instead leave -Wunused turned on (as done by -Wall) and use a much more fine-grained approach to disabling specific warnings in specific files or libraries. >> >> This is similar to what has been done for gcc in JDK-8339120. > > Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: > > - Merge branch 'master' into finegranular-clang-unused > - 8339156: Use more fine-granular clang unused warnings Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20770#pullrequestreview-2273037764 From ihse at openjdk.org Fri Aug 30 16:46:31 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 30 Aug 2024 16:46:31 GMT Subject: Integrated: 8339156: Use more fine-granular clang unused warnings In-Reply-To: References: Message-ID: On Thu, 29 Aug 2024 13:14:35 GMT, Magnus Ihse Bursie wrote: > Currently, we issue -Wno-unused for all files in clang, which is a rather big sledgehammer to get rid of some warnings that proliferate in a few areas of the build. > > We should instead leave -Wunused turned on (as done by -Wall) and use a much more fine-grained approach to disabling specific warnings in specific files or libraries. > > This is similar to what has been done for gcc in JDK-8339120. This pull request has now been integrated. Changeset: a528c4b3 Author: Magnus Ihse Bursie URL: https://git.openjdk.org/jdk/commit/a528c4b370be1e7730778268cf8c52ffcfd27048 Stats: 60 lines in 16 files changed: 42 ins; 1 del; 17 mod 8339156: Use more fine-granular clang unused warnings Reviewed-by: erikj, kbarrett ------------- PR: https://git.openjdk.org/jdk/pull/20770 From achung at openjdk.org Fri Aug 30 17:42:19 2024 From: achung at openjdk.org (Alisen Chung) Date: Fri, 30 Aug 2024 17:42:19 GMT Subject: RFR: 8338153: java/awt/Checkbox/CheckboxCheckerScalingTest.java test failed on linux machine In-Reply-To: References: Message-ID: On Thu, 29 Aug 2024 04:22:52 GMT, Tejesh R wrote: >> test/jdk/java/awt/Checkbox/CheckboxCheckerScalingTest.java line 51: >> >>> 49: private static BufferedImage imageAfterChecked; >>> 50: private static volatile boolean checkmarkFound = false; >>> 51: private static final int TOLERANCE = 10; >> >> Is this tolerance needed for the test to pass? Would just moving the test to the center be enough for this fix? I agree with Abhishek that there might be false positives, particularly with color profiles where the test should fail but would pass with this change, especially since this is a ui scaling test. > > Tolerance is required when we are going with screen capture comparison since I see slight change in intensity of colors in captured image, not really sure of what might be the exact cause for it on some machines/some test runs. Also I've seen some tests considers this tolerance while testing. I confirmed it by decoding the pixel color of captured image (Below image). > Coming to false positives, yes this is the trade off when the test is made automatic. I see no other way to confirm the check mark with captured image. Other option left is to make the test manual one, yet I feel this way is better than manual. I've captured several runs without the fix where the captured area will be just white background and with fix when checkmark is drawn on UI scale of 2.0 it is drawn inside the area without any other interference which might have led to false positive. > > image One more thing, how did you arrive to this number as the tolerance? I assume that maybe other tests also set tolerance as 10? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20723#discussion_r1739185070 From honkar at openjdk.org Fri Aug 30 18:22:19 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Fri, 30 Aug 2024 18:22:19 GMT Subject: RFR: 8338153: java/awt/Checkbox/CheckboxCheckerScalingTest.java test failed on linux machine In-Reply-To: References: Message-ID: On Tue, 27 Aug 2024 06:04:47 GMT, Tejesh R wrote: > Test failed intermittently on particular host. Though analysis pointed out to a test frame at left top on that host, I've updated the test for further stabilizing it. Two things done here: > 1. Move the frame to center of the screen rather than left top. > 2. Added tolerance checks for color comparison - this is based on analysis reports where the image didn't had exact black color which is supposed to be. So like other test cases, providing some tolerance for comparison. As @kumarabhi006 and @alisenchung pointed out I think there might be cases of false positives with high tolerance values. Following are couple of suggestions: - Check if a lower more optimal value of tolerance works. - Continue pixel compare till you encounter 4-5 pixels of the expected color (with tolerance) - Adding debug logs to see which colors pass the criteria. ------------- PR Review: https://git.openjdk.org/jdk/pull/20723#pullrequestreview-2273237979 From honkar at openjdk.org Fri Aug 30 18:26:19 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Fri, 30 Aug 2024 18:26:19 GMT Subject: RFR: 8338153: java/awt/Checkbox/CheckboxCheckerScalingTest.java test failed on linux machine In-Reply-To: References: Message-ID: On Tue, 27 Aug 2024 06:04:47 GMT, Tejesh R wrote: > Test failed intermittently on particular host. Though analysis pointed out to a test frame at left top on that host, I've updated the test for further stabilizing it. Two things done here: > 1. Move the frame to center of the screen rather than left top. > 2. Added tolerance checks for color comparison - this is based on analysis reports where the image didn't had exact black color which is supposed to be. So like other test cases, providing some tolerance for comparison. test/jdk/java/awt/Checkbox/CheckboxCheckerScalingTest.java line 80: > 78: if (compareColor(pixelColor)) { > 79: checkmarkFound = true; > 80: break check; @TejeshR13 Logging the pixelColor inside the if block can be useful for debugging purpose. You could add a counter variable here and continue until 4-5 pixels match the criteria. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20723#discussion_r1739229296 From prr at openjdk.org Fri Aug 30 22:05:21 2024 From: prr at openjdk.org (Phil Race) Date: Fri, 30 Aug 2024 22:05:21 GMT Subject: RFR: 8339309: unused-variable warnings happen in libfontmanager In-Reply-To: References: Message-ID: On Fri, 30 Aug 2024 10:17:38 GMT, Yasumasa Suenaga wrote: > I saw following errors (warnings) when I tried to build OpenJDK on Fedora 40 with gcc-14.2.1-1.fc40.x86_64: > > > /home/ysuenaga/github-forked/jdk/src/java.desktop/share/native/libfontmanager/HBShaper_Panama.c: In function ?jdk_hb_shape?: > /home/ysuenaga/github-forked/jdk/src/java.desktop/share/native/libfontmanager/HBShaper_Panama.c:101:16: error: unused variable ?yPtSize? [-Werror=unused-variable] > 101 | float yPtSize = euclidianDistance(matrix[2], matrix[3]); > | ^~~~~~~ > cc1: all warnings being treated as errors > * For target support_native_java.desktop_libfontmanager_X11FontScaler.o: > /home/ysuenaga/github-forked/jdk/src/java.desktop/unix/native/libfontmanager/X11FontScaler.c: In function ?Java_sun_font_NativeFont_getGlyphAdvance?: > /home/ysuenaga/github-forked/jdk/src/java.desktop/unix/native/libfontmanager/X11FontScaler.c:270:32: error: unused variable ?descent? [-Werror=unused-variable] > 270 | int direction, ascent, descent; > | ^~~~~~~ > /home/ysuenaga/github-forked/jdk/src/java.desktop/unix/native/libfontmanager/X11FontScaler.c:270:24: error: unused variable ?ascent? [-Werror=unused-variable] > 270 | int direction, ascent, descent; > | ^~~~~~ > /home/ysuenaga/github-forked/jdk/src/java.desktop/unix/native/libfontmanager/X11FontScaler.c:270:13: error: unused variable ?direction? [-Werror=unused-variable] > 270 | int direction, ascent, descent; > | ^~~~~~~~~ > /home/ysuenaga/github-forked/jdk/src/java.desktop/share/native/libfontmanager/freetypeScaler.c: In function ?Java_sun_font_FreetypeFontScaler_createScalerContextNative?: > /home/ysuenaga/github-forked/jdk/src/java.desktop/share/native/libfontmanager/freetypeScaler.c:516:19: error: unused variable ?scalerInfo? [-Werror=unused-variable] > 516 | FTScalerInfo *scalerInfo = > | ^~~~~~~~~~ > /home/ysuenaga/github-forked/jdk/src/java.desktop/share/native/libfontmanager/freetypeScaler.c: In function ?Java_sun_font_FreetypeFontScaler_getGlyphPointNative?: > /home/ysuenaga/github-forked/jdk/src/java.desktop/share/native/libfontmanager/freetypeScaler.c:1655:13: error: unused variable ?point? [-Werror=unused-variable] > 1655 | jobject point = NULL; > | ^~~~~ src/java.desktop/share/native/libfontmanager/HBShaper_Panama.c line 101: > 99: if (getenv("HB_NODEVTX") != NULL) { > 100: float xPtSize = euclidianDistance(matrix[0], matrix[1]); > 101: float yPtSize = euclidianDistance(matrix[2], matrix[3]); I paused to think about whether the problem is really that the division below should be using yPtSize .. in other words, the correct fix isn't always as obvious as it might look. For the record, I think the unused var is becuase it was patterned after the code code in HBShaper.c which stores the yPtSize in a struct, but here it is clear that it isn't used. fi->xPtSize = euclidianDistance(fi->matrix[0], fi->matrix[1]); fi->yPtSize = euclidianDistance(fi->matrix[2], fi->matrix[3]); if (getenv("HB_NODEVTX") != NULL) { fi->devScale = fi->xPtSize / fi->ptSize; Now, as far as I can they aren't used except in that fn, so probably can also go .. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20790#discussion_r1739448726 From honkar at openjdk.org Sat Aug 31 00:33:18 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Sat, 31 Aug 2024 00:33:18 GMT Subject: RFR: 8339233: Test javax/swing/JButton/SwingButtonResizeTestWithOpenGL.java#id failed: Button renderings are different after window resize In-Reply-To: References: Message-ID: On Thu, 29 Aug 2024 19:07:29 GMT, Manukumar V S wrote: > This is a highly intermittent failure, and it failed only once in CI on a particular windows machine and passed on all other runs. > > Failure reason: > When the button was displayed for the first time, the focus rectangle drawn on the button text(Button A) was not seen(failure images attached in the bug). > > Fix: > To stabilize the test, I have added a line -> button.setFocusPainted(false), so that the focus rectangle will not be painted Since the following are on unchanged lines, I'm including it as a consolidated note: 1. robot.setAutoWaitForIdle(true); robot.setAutoDelay(200); doesn't change anything as there are no robot mouse or key events so it can be removed. 2. Individual `robot.delay()` can be added after UI creation and when frame state is changed to stabilize the test. 3. Frame is assigned null after disposing which is not required and can be removed. private void disposeFrame() { if (frame != null) { frame.dispose(); frame = null; } } ------------- PR Review: https://git.openjdk.org/jdk/pull/20777#pullrequestreview-2273688593 From honkar at openjdk.org Sat Aug 31 00:50:20 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Sat, 31 Aug 2024 00:50:20 GMT Subject: RFR: 8051591: Test javax/swing/JTabbedPane/8007563/Test8007563.java fails In-Reply-To: References: Message-ID: On Fri, 30 Aug 2024 10:36:27 GMT, Abhishek Kumar wrote: > Test was failing on multiple platforms mainly windows and linux and was problemlisted for all platforms. Increased the delay from 200ms to 500 ms to fetch the correct background color using robot. Now test passed for multiple iteration (~50 times) in CI pipeline for all platforms. Wild imports are expanded and test is pulled out of an extra level of folder. > Test removed from `Problem-list` file as well. > > CI testing link is posted in JBS. SecondaryLoop secondaryLoop = Toolkit.getDefaultToolkit().getSystemEventQueue() .createSecondaryLoop(); I'm not sure if the SecondaryLoop is required or if it can be simplified? ------------- PR Review: https://git.openjdk.org/jdk/pull/20791#pullrequestreview-2273692301 From ysuenaga at openjdk.org Sat Aug 31 04:24:22 2024 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Sat, 31 Aug 2024 04:24:22 GMT Subject: RFR: 8339309: unused-variable warnings happen in libfontmanager In-Reply-To: References: Message-ID: On Fri, 30 Aug 2024 22:03:11 GMT, Phil Race wrote: >> I saw following errors (warnings) when I tried to build OpenJDK on Fedora 40 with gcc-14.2.1-1.fc40.x86_64: >> >> >> /home/ysuenaga/github-forked/jdk/src/java.desktop/share/native/libfontmanager/HBShaper_Panama.c: In function ?jdk_hb_shape?: >> /home/ysuenaga/github-forked/jdk/src/java.desktop/share/native/libfontmanager/HBShaper_Panama.c:101:16: error: unused variable ?yPtSize? [-Werror=unused-variable] >> 101 | float yPtSize = euclidianDistance(matrix[2], matrix[3]); >> | ^~~~~~~ >> cc1: all warnings being treated as errors >> * For target support_native_java.desktop_libfontmanager_X11FontScaler.o: >> /home/ysuenaga/github-forked/jdk/src/java.desktop/unix/native/libfontmanager/X11FontScaler.c: In function ?Java_sun_font_NativeFont_getGlyphAdvance?: >> /home/ysuenaga/github-forked/jdk/src/java.desktop/unix/native/libfontmanager/X11FontScaler.c:270:32: error: unused variable ?descent? [-Werror=unused-variable] >> 270 | int direction, ascent, descent; >> | ^~~~~~~ >> /home/ysuenaga/github-forked/jdk/src/java.desktop/unix/native/libfontmanager/X11FontScaler.c:270:24: error: unused variable ?ascent? [-Werror=unused-variable] >> 270 | int direction, ascent, descent; >> | ^~~~~~ >> /home/ysuenaga/github-forked/jdk/src/java.desktop/unix/native/libfontmanager/X11FontScaler.c:270:13: error: unused variable ?direction? [-Werror=unused-variable] >> 270 | int direction, ascent, descent; >> | ^~~~~~~~~ >> /home/ysuenaga/github-forked/jdk/src/java.desktop/share/native/libfontmanager/freetypeScaler.c: In function ?Java_sun_font_FreetypeFontScaler_createScalerContextNative?: >> /home/ysuenaga/github-forked/jdk/src/java.desktop/share/native/libfontmanager/freetypeScaler.c:516:19: error: unused variable ?scalerInfo? [-Werror=unused-variable] >> 516 | FTScalerInfo *scalerInfo = >> | ^~~~~~~~~~ >> /home/ysuenaga/github-forked/jdk/src/java.desktop/share/native/libfontmanager/freetypeScaler.c: In function ?Java_sun_font_FreetypeFontScaler_getGlyphPointNative?: >> /home/ysuenaga/github-forked/jdk/src/java.desktop/share/native/libfontmanager/freetypeScaler.c:1655:13: error: unused variable ?point? [-Werror=unused-variable] >> 1655 | jobject point = NULL; >> | ^~~~~ > > src/java.desktop/share/native/libfontmanager/HBShaper_Panama.c line 101: > >> 99: if (getenv("HB_NODEVTX") != NULL) { >> 100: float xPtSize = euclidianDistance(matrix[0], matrix[1]); >> 101: float yPtSize = euclidianDistance(matrix[2], matrix[3]); > > I paused to think about whether the problem is really that the division below should be using yPtSize .. in other words, the correct fix isn't always as obvious as it might look. > > For the record, I think the unused var is becuase it was patterned after the code code in HBShaper.c which stores the yPtSize in a struct, but here it is clear that it isn't used. > > fi->xPtSize = euclidianDistance(fi->matrix[0], fi->matrix[1]); > fi->yPtSize = euclidianDistance(fi->matrix[2], fi->matrix[3]); > if (getenv("HB_NODEVTX") != NULL) { > fi->devScale = fi->xPtSize / fi->ptSize; > > > Now, as far as I can they aren't used except in that fn, so probably can also go .. In addition, I've confirmed `euclidianDistance` does not make any side-effects. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20790#discussion_r1739601532 From mvs at openjdk.org Sat Aug 31 09:08:59 2024 From: mvs at openjdk.org (Manukumar V S) Date: Sat, 31 Aug 2024 09:08:59 GMT Subject: RFR: 8339233: Test javax/swing/JButton/SwingButtonResizeTestWithOpenGL.java#id failed: Button renderings are different after window resize [v2] In-Reply-To: References: Message-ID: > This is a highly intermittent failure, and it failed only once in CI on a particular windows machine and passed on all other runs. > > Failure reason: > When the button was displayed for the first time, the focus rectangle drawn on the button text(Button A) was not seen(failure images attached in the bug). > > Fix: > To stabilize the test, I have added a line -> button.setFocusPainted(false), so that the focus rectangle will not be painted Manukumar V S has updated the pull request incrementally with one additional commit since the last revision: Review Comments Fixed : Further stabilized the test by increasing the delay as well as removing some unwanted lines of code ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20777/files - new: https://git.openjdk.org/jdk/pull/20777/files/58979a38..3e8e35a6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20777&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20777&range=00-01 Stats: 8 lines in 1 file changed: 0 ins; 6 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20777.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20777/head:pull/20777 PR: https://git.openjdk.org/jdk/pull/20777 From mvs at openjdk.org Sat Aug 31 09:12:22 2024 From: mvs at openjdk.org (Manukumar V S) Date: Sat, 31 Aug 2024 09:12:22 GMT Subject: RFR: 8339233: Test javax/swing/JButton/SwingButtonResizeTestWithOpenGL.java#id failed: Button renderings are different after window resize In-Reply-To: References: Message-ID: On Thu, 29 Aug 2024 19:07:29 GMT, Manukumar V S wrote: > This is a highly intermittent failure, and it failed only once in CI on a particular windows machine and passed on all other runs. > > Failure reason: > When the button was displayed for the first time, the focus rectangle drawn on the button text(Button A) was not seen(failure images attached in the bug). > > Fix: > To stabilize the test, I have added a line -> button.setFocusPainted(false), so that the focus rectangle will not be painted > After going through the test runs which you have shared, I suggest some stabilization is required along with FocusPaint fix. As attached here, in one of your test runs, failure is caused due to capture of distorted image. ![image2](https://private-user-images.githubusercontent.com/94159358/363084865-5744cb82-24da-45c3-a5d9-e88b7864bae3.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjUwOTU0NjgsIm5iZiI6MTcyNTA5NTE2OCwicGF0aCI6Ii85NDE1OTM1OC8zNjMwODQ4NjUtNTc0NGNiODItMjRkYS00NWMzLWE1ZDktZTg4Yjc4NjRiYWUzLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNDA4MzElMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjQwODMxVDA5MDYwOFomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPWYwODc2N2Q4MDM5MjJmMzYwYTE5ZTgwODc3MmUxYzFhNTEyOGFjNmNmY2Y4MGI5ZDE5MjhjZGNjN2NhMmUwOTQmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JmFjdG9yX2lkPTAma2V5X2lkPTAmcmVwb 19pZD0wIn0.A2c6iE8KJsIv9W2_uyRyHTnfIpE3cjy_9Rs9uGUXnP4) I have further stabilised the test by increasing the delay before taking the screenshot and I ran it 100 times on the same machine where it failed earlier and now all the runs are passed. Latest Mach5 links are attached in the bug. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20777#issuecomment-2322836951 From mvs at openjdk.org Sat Aug 31 09:12:23 2024 From: mvs at openjdk.org (Manukumar V S) Date: Sat, 31 Aug 2024 09:12:23 GMT Subject: RFR: 8339233: Test javax/swing/JButton/SwingButtonResizeTestWithOpenGL.java#id failed: Button renderings are different after window resize [v2] In-Reply-To: References: Message-ID: On Sat, 31 Aug 2024 00:30:50 GMT, Harshitha Onkar wrote: > Since the following are on unchanged lines, I'm including it as a consolidated note: > > 1. robot.setAutoWaitForIdle(true); > robot.setAutoDelay(200); > doesn't change anything as there are no robot mouse or key events so it can be removed. > 2. Individual `robot.delay()` can be added after UI creation and when frame state is changed to stabilize the test. > 3. Frame is assigned null after disposing which is not required and can be removed. > > ``` > private void disposeFrame() { > if (frame != null) { > frame.dispose(); > frame = null; > } > } > ``` Fixed all these. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20777#issuecomment-2322837108 From dholmes at openjdk.org Sat Aug 31 11:57:19 2024 From: dholmes at openjdk.org (David Holmes) Date: Sat, 31 Aug 2024 11:57:19 GMT Subject: RFR: 8338768: Introduce runtime lookup to check for static builds [v2] In-Reply-To: References: <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com> Message-ID: On Fri, 30 Aug 2024 10:51:30 GMT, Magnus Ihse Bursie wrote: >> I understand the cost overhead experienced by any individual Java run may be lost in the noise, but it still impacts every single Java run just to save some time/resources for the handful of builders of statically linked VMs. I am not a fan. > > @dholmes-ora This PR now has three reviewers approving it. You say you are "not a fan". Does this mean you want to veto this change? Or can you be willing to accept it, even if you do not like it? @magicus There is no "veto" power in OpenJDK. You have your reviewers, I have to accept it even if I don't like it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20666#issuecomment-2322873797 From kcr at openjdk.org Sat Aug 31 15:26:20 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 31 Aug 2024 15:26:20 GMT Subject: RFR: 8190329: [macos] Swing InterOp Platform.exit() crash [v4] In-Reply-To: References: Message-ID: On Fri, 30 Aug 2024 07:23:54 GMT, Prasanta Sadhukhan wrote: >> The testcase calls Platform.exit before the dialog is made visible but >> on macOS, JavaFX takes over the AppKit thread and uses that as the FX application thread. As part of the FX platform shutdown process, it detaches that thread from the JVM. This means that the AppKit thread is no longer available to Java processes >> so AWT crashes when it ties to access appkit thread. >> Fix is made to check if the thread has been detached for move-resize notification event before proceeding.. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Use cached Env only for AWT NSApplication and not for Override-delegate Marked as reviewed by kcr (Author). ------------- PR Review: https://git.openjdk.org/jdk/pull/20688#pullrequestreview-2273885569 From mark.yagnatinsky at barclays.com Fri Aug 30 21:21:49 2024 From: mark.yagnatinsky at barclays.com (mark.yagnatinsky at barclays.com) Date: Fri, 30 Aug 2024 21:21:49 -0000 Subject: date picking with JSpinner? Message-ID: I noticed that no one in the original thread mentioned that JSpinner already allows picking a date and time. (In fact, for picking a time, the UI is not too bad; the date picking is where the real gap is.) Just curious if there's any plan to look at the existing functionality for things like: * Inspiration: what does it do well or poorly * Ease of migration: can someone already using JSpinner migrate without too much hassle? * E.g., can we re-use Editors and Models? * Will the new class extend JSpinner? That sounds crazy at first but on second thought it's not clear to me that the semantics are wrong. * Non-regressions: the new class should be "at least as good" from a user's perspective (not a coder's perspective; the actual user of the GUI). * One thing that JSpinner gets right that a late of date pickers get wrong is that it's easy modify the year while keeping the day/month constant. I don't have anything useful to add, I was just curious. This message is for information purposes only. It is not a recommendation, advice, offer or solicitation to buy or sell a product or service, nor an official confirmation of any transaction. It is directed at persons who are professionals and is intended for the recipient(s) only. It is not directed at retail customers. This message is subject to the terms at: https://www.ib.barclays/disclosures/web-and-email-disclaimer.html. For important disclosures, please see: https://www.ib.barclays/disclosures/sales-and-trading-disclaimer.html regarding marketing commentary from Barclays Sales and/or Trading desks, who are active market participants; https://www.ib.barclays/disclosures/barclays-global-markets-disclosures.html regarding our standard terms for Barclays Investment Bank where we trade with you in principal-to-principal wholesale markets transactions; and in respect to Barclays Research, including disclosures relating to specific issuers, see: https://publicresearch.barclays.com. __________________________________________________________________________________ If you are incorporated or operating in Australia, read these important disclosures: https://www.ib.barclays/disclosures/important-disclosures-asia-pacific.html. __________________________________________________________________________________ For more details about how we use personal information, see our privacy notice: https://www.ib.barclays/disclosures/personal-information-use.html. __________________________________________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: